Tuesday, March 3, 2015

RigidBot projects

The list of 3D printed artefacts I need is growing longer each week. In no particular order:


  1. If I decide to continue with the RUMBA controller board, I will need an enclosure for it.
  2. I need an enclosure for the Parallella which will hold the fan over the Zynq chip.
  3. I want a translucent enclosure for the CharlieCube I made late last year.
  4. My "grand project" is a Perl 6 implementation of the Threesus project. The original project has a video camera watching an iPad screen, OCRing the image it sees, deciding the best next move then activating one of two stepper motors to swipe the iPad screen up or down, left or right. Not sure if I want to get to the stage of using the stepper motors (although I have a couple in my spares box). I want to use my Raspberry Pi with camera module for the video processing, so I would like to build an enclosure to hold the RPi and camera in a config which makes it usable for OCRing an iPad (or iPhone).
  5. An enclosure for a reflow oven controller.
  6. An enclosure for a coffee bean roaster controller I am designing for an Elektor competition.

RigidBot repairs

The sharp-witted amongst us will have noted in my previous blog that I had found the cause of all the problems with the RigidBot, but I didn't recognise it even while I was writing about it.

The open-circuit on pin 1 of the extruder flat cable is a sufficient explanation of all the problems the printer showed. I simply didn't follow an orderly chain of testing the components and cables to isolate the cable.

Anyway I've ordered some replacement cable and connectors and I will now have to wait the three or four weeks it takes will they arrive.

My hypothesis is that I will be able to return the original main board to the printer, replace the faulty cable and everything will work correctly. And if it doesn't, I now have so many replacement parts that I can replace nearly all of the fragile parts of the printer to keep it running.

Monday, March 2, 2015

RigidBot tale of woe

My pretty RigidBot(RB) was churning out pretty and occasionally useful things for a few weeks after it arrived in October. I made every mistake there is to make with the RB until I finally got it printing reasonably accurate and repeatable things. I even ordered some "crystal" ABS filament with the intention of putting a translucent cover over the CharlieCube.

Then last December the extruder died. I'm not sure if I was the cause. I had accidentally put a knot in the filament and left the printer running overnight. So it spent about 12 hours pulling the same section of filament.

Initially I thought one of the coils in the stepper motor had burnt out or partially degraded. So I ordered a replacement motor and went on to other things. But the motor I'd ordered was the wrong one and it required a higher current. So I ordered another one. But this one didn't have the flat on the shaft. D'oh!

In the meantime I tried swapping motors around and eventually realised it was the driver that was faulty, not the motor.

Pity that the RB main board is an all-in-one board. Apparently it was done to "save money". But according to the RB wiki, Invent-A-Part (IAP) had to re-work every single board because the Chinese supplier had cheated on a whole swag of parts (without mentioning it to IAP of course) and the boards were dying all over the place. So much for saving money.

A few hundred RB owners quickly realised that the RB main board was simply a RUMBA board with stepper driver modules built onto the PCB instead of being pluggable (and hence replaceable). There was sufficient demand that one enterprising chap built a (BYEBYE) breakout board for the RB extruder cable so it wasn't necessary to completely re-wire the RB to replace the main board.

So I ordered a Geeetech RUMBA board + 5 x A4988 modules (+ heatsinks) and a BYEBYE board and forgot about the RB for six weeks and worked on other stuff.

The RUMBA and BYEBYE boards arrived last week a day apart and so began my tale of woe (not actually woe, just a huge exercise in yak-shaving).

All the RUMBA connections are screw terminals. I feel happier with these. No stuffing around with crimping tools etc. First I had to unsolder the thick power cable from the power supply board and replace it with bare wires I could put in the screw terminals. I don't have a soldering iron with sufficient wattage to melt the thick layers of solder holding the wires to the PS PCB. Luckily I do have a hot air gun for SMD soldering and when I cranked it up, I was able to melt the solder enough to extract the wires.

The next task was making connections from the BYEBYE board to the RUMBA board. Last year I had purchased a 'Make your own cable' kit from SeeedStudio which proved really helpful for keeping wires in some sort of order otherwise it would have been an even bigger rat's nest. (In retrospect, I should also have purchased the 'Make your own keyed cable' kit as many of the connections would have been cleaner with a keyed plug. No harm done though.)

So after a couple of days wiring and checking and checking again, I turned on the power and waited for puffs of smoke or flames or whatever. Nothing. Just some lights which should have been on.

Then began the task of programming the RUMBA. I was following Jonathan Roscoe's excellent blog on just this exercise. I've had to learn heaps of details about the RB (and 3D printers in general).

First I had to learn how to flash the Marlin firmware into the RUMBA. Took me a while to realise the RUMBA is simply an Arduino with some pre-wired peripherals (e.g. stepper motors, thermistors, heaters etc. etc.). Once that got through my thick skull, I was able to use all I had learned playing with Arduinos.

I've been using Repetier-Host(RH) to drive the RB and the Panel tab is particularly useful for testing individual parts of the RB. Using RH I was able to work out that the wiring for the motors on the RUMBA is different from the RB main board. The X, Y and Z motors were going in reverse. Simply required swapping the Blue and Red wires. The Z-steppers weren't responding correctly and I had to tear the RB almost completely apart before I was able to isolate each Z-stepper and verify that the A4988 module was faulty. Luckily when the Geeetech package arrived, they'd included 6 x A4988 instead of the 5 which I thought I was ordering. So after swapping in one of the spares the Z-axis worked correctly. I then had to put the RB back together again.

So finally I was ready to test the extruder motor, the original cause of all this hoohah. And it didn't work. Maybe a connection wasn't working. I traced the wires and discovered the BYEBYE board is missing a trace altogether. [Ed: no it was my faulty circuit tester; the board is fine.] So I tried plugging the extruder motor directly into the RUMBA and it sat there buzzing. We've heard that before, it means a faulty A4988. Luckily I had one more spare. I swapped it in and the extruder motor now turned correctly. Two faulty A4988s! I wonder if I accidentally damaged them when I put the heat sinks on.

So back to the wiring harness. Discovered that pin 1 in flat cable is not connected. Was it always open-circuit? Presumably not, otherwise motor would never have worked.

Anyway this gives me an excuse to take the whole extruder apart and put back the original stepper motor with the flattened shaft. Talk about an exercise in futility aka yak-shaving. And now I have to find where to get a replacement flat cable.


Friday, October 10, 2014

May your antiquated book publishing models die, die, die!

Read an interesting review of what appears to be an interesting book, Hieroglyph.

I read the sample chapter and was ready to buy it. Book was "released" 14 Sep 2014. Clicked on the ebook button so I could read it straight away. "This publication is not available in your area" (Australia). Huh?

Oh well, maybe Amazon.com could help. Nope: "we do not have pricing for the Kindle version yet". Paperback? "Not available till 2015".

So here is a book publisher which will not sell me a book I would like to buy right now.

I can guess why of course. They want to sell hardcover versions for a few months, then paperback versions, then ebooks but only in USA. Then sometime in the middle of next year they'll get around to making ebook version available to Oz.

So of course I will wait till it's available as a Torrent, download it and pay nothing. Or simply forget about it. There are some people who like to buy hard copies of books. I'm not one of them. I don't have the room any more. I only buy electronic versions. (Yes, I do buy (some) ebooks, usually on the spur of the moment of course.)

And the final irony is that the book is about optimistic techno futures. Hah! hah!

Rigidbot arrived!

Last week my almost despaired of Rigidbot 3D printer kit arrived. Project was successfully funded in May 2013 and here it is October 2014. Incredible tale of what can go wrong when you're trying to start a startup. All the usual suspects: dodgy suppliers substituting cheaper, lower quality parts; huge blowout in shipping costs; China Post doing it's best to completely destroy itself by never actually shipping what they said they did.

Anyway here's my baby:
Here's some of my first experiments in extruding:
Here's why I have a lot to learn (that box corner is not meant to lift up):
And here's why the Rigidbot is an incredible kit. It can basically be assembled with one Allen key (supplied), but there's a couple of parts need smaller keys (also supplied). However, it also needs a mallet (not supplied) because some of the tubes/rods simply do not fit easily inside some of the plastic fittings.
Now I have to learn how to design parts from scratch as well as re-use existing designs. Thingiverse.com has a huge number of designs to start with. But I've also had to learn to use OpenSCAD to design the box. (I tried simply using a Gcode file offered here but the differences between Felix printers and Rigidbots are too great. And I also discovered there are no usable Gcode to STL converters any more. There might have been a couple of years ago but not maintained now.)

Then I had to learn about various slicers and dicers to generate Gcode from the design and upload the print task to the Rigidbot. Eventually settled on Repetier-Host for Mac for initial prototyping but also installed Octoprint on my RPi so I can offload print tasks to RPi while I continue with MacBook.


Friday, July 11, 2014

A DHCP client (fail?)

I was hoping to implement a DHCP client in the GA144 as mentioned in a previous blog. I'm more familiar with Perl than C these days so I downloaded the Net::DHCP::Packet module from CPAN and proceeded to use some of the examples to test out the DHCP server on my router. It's a lot easier to single-step through Perl code (for me at least) than using GDB on a compiled C program.

The sample dhcp daemon and test scripts work well. But when I tried talking to my router I was able to get a DHCPOFFER but was unable to get a DHCPACK reply. And even that would only work when I used the MAC address of my Mac(!). I couldn't use any other MAC address. I just don't know enough about DHCP to know if the router is acting correctly or not. The router's log says it receives the DHCP request and that it sends an OFFER and an ACK but the ACK packet doesn't seem to arrive. Possibly issues with firewalls etc.

There's a lot of code in Net::DHCP::Packet and it occurred to me that a DHCP client is not really necessary for this project. Nice to have but maybe not this iteration. I can load the IP address I've assigned to it using the code in the previous blog so there will be no conflict with my network devices.

So I'll proceed to step 2: a 'Hello world' server which simply sends the same reply to whatever inquiry it receives.


Tuesday, July 1, 2014

Make a PCB pt2

I received the parts for the GettingToBlinky PCB I talked about in a previous blog. And they sat there for over a week while I caught up with a few other tasks I had.

Today I felt like whiling away a couple of hours without straining my brain too much and building a Blinky device seemed like the perfect task. I love the smell of burning flux in the morning.

Despite all my mutterings about using solder paste, a pick and place tool and a heat gun, I realised the parts in this project are quite large. Certainly easy enough to see under a magnifying lamp to hand solder. So with help of some Blu-Tack to hold the board still and a bit more Blu-Tack on the end of a screwdriver to lift the components out of their containers and place them on the board I soldered it all together.

I started with the 7555 because it has the smallest pads and is in the centre of the board so I didn't want other components getting in the way. Then I added the diode, resistors and capacitor in that order. The LDR is actually a big large for the thru-holes I placed for it but long leads made it easy to get it into place.

So then it was time to solder the battery holder in place and finally we were ready to roll!

I inserted the battery after checking and re-checking the polarity and...

Nothing. No blinky!

I pulled out the battery just in case something was cooking and proceeded to measure every component and trace I could. Everything checked out.

So I re-inserted the battery and measured the voltage across pin 8 (Vdd) and pin 1 (GND) of the 7555. Nothing!

A bit closer inspection of the battery holder made me suspect that I might have some sort of short. So I partially inserted the battery and yay! blinky! But if I pushed the battery fully into the clip it stopped. But nothing was shorting. I looked at the battery and I looked at the board where it connects and it looks like the solder pad is too flat or the battery flexes slightly concavely at that point. Anyway the solution was obvious. I unsoldered the battery clip, added a large drop of solder to the GND pad on the board, resoldered the clip and reinserted the battery and yay! blinky! And I could push the battery fully into the clip now and it continues working.

Here's the "offending" centre GND pad:
I had to add a blob of solder to it to raise it's height enough to contact the battery negative. Here's the clip and battery in place:

And finally, Blinky!

Some lessons for the future

The blink rate is supposed to vary depending on how much light falls on the LDR. The GettingToBlinky tutorial left the actual value or even the range undisclosed. I picked a value at random from Digi-Key (16-33K) but this is probably way too low considering it's connected to a 470K resistor. Probably should have been 160-330K. No harm done but unless I knew the blink rate is supposed to vary, I probably wouldn't notice the slight change that does occur as I move the LDR from bright light to darkness.

The second lesson is far more serious, and potentially dangerous. The battery clip touches one of the LDR leads:
Fortuitously, this LDR lead actually does connect to the positive terminal of the battery and so no harm done. However the potential for disaster is quite obvious. And again the solution is so simple. I had plenty of room on the board to move the thru holes for the LDR away from the battery clip but I had left the outline of the original SMD version and not updated it to that of the thru hole version. As a result I didn't see the potential conflict.

Which brings me to the third lesson. I made the mistake with the LDR and battery clip placement because I purchased these components blind, relying on diagrams and data sheets. In all my years as an electrical engineer, I never did that. I always insisted on having the actual components in my hands so I could measure them myself and see how they all fitted together. Digi-Key and similar suppliers are wonders compared to the old days but the potential for mistakes seems to rise when one is relying solely on data sheets.

On the other hand, in this brave new world where I can design and have these boards built for AU$1.40 plus AU$3.00 for components each, I think I can live with the cost of ordering sight unseen. The savings in time and money is enormous.

So tomorrow I will try out reflow soldering with solder paste and a heat gun.