After several separate attempts to work out why my end stops were not triggering, on several different occasions over a month or two, double and triple checking the wiring, trying just about every combination of settings in the firmware, I was still no further forward.
I decided to add a connector to the breadboard where I first tested out the hall effect sensor, so that I could verify that they were actually working correctly and I was using the correct side of the magnet with each one.
Sure enough all worked perfectly: I move the magnet close and the LED comes on proving that all is well with the sensor wiring.
I try with hardware pull up resistors between signal and VCC on the sanguinololu board, and with software pull up resistors within the repetier firmware, still no joy.
I try the M119 G-Code to see what the sensor is showing, high or low, again with all of the various different settings in firmware, but all I see is the value staying the same regardless of what I do with the magnet to trigger the sensor.
I edge a little nearer to the problem when I start checking the voltages on the pins of the sanguinololu board both triggered and non triggered between signal and ground – for some reason they are pretty much the same at around 1.3V which seems very odd.
I eventually realise that I when I check the ground to VCC connections of the sensor connections and these are showing minimal voltage (millivolts) that something must be wrong with my wiring on the sanguinololu board.
I check the board in Eagle and there it is plain as day – there is no power to the V+ terminals of the sensors unless a bridge is soldered in place between two of three pads depending on your choice of 5V or 12V.
Sure enough on re-reading the sanguinololu page, under the section titled Endstops, there is a section that mentions soldering a bridge between two of three connectors depending on your choice of 5V or 12V to supply the power to the end stops.
So I remove the board from the inside of the printer frame and solder a bridge so as to make use of 12V for the sensors, reset some of the firmware values, use built-in pull up resistors, and lo and behold the end stops are now working perfectly.
At this point I had the Z axis homing to the minimum setting, and decided now was as good a time as any to try out a dry test print, and what better than the front half of the Pirates of the Caribbean coin from Thingiverse.
I loaded up the STL file into Repetier Host and had Slic3r generate some G-Code, then ran that on the printer.
The estimated time for the print was around 4 minutes, although that was somewhat optimistic, some of the seconds seemed to take ages, and ultimately it failed with about 40 seconds to go, complaining about resend errors and eventually dropped the connection to the printer due to only receiving errors.
I reset everything and tried again, but with the same result at around the same place.
More searching and this looks like it is possibly a communications issue with the Repetier firmware complaining about lines that it has not yet received or has somehow dropped, there are also comments about this possibly being fixed in newer versions of the firmware.
The version I have been using up to now is 0.71, so I download the latest which is 0.91 apply as many of my settings as I can find in the configuration.h and pins.h files and compile up and download this new version to the sanguinololu.
I decided that I don’t like the Z axis homing to the minimum value as this could cause the print head to crash into whatever may be on the bed, or even into the bed itself, so I relocated the sensor to the top of the Z axis and made the appropriate changes to the firmware, as this version happily supports this configuration.
The next issue I have is that the printer now tries to print the coin 250mm up in the air after homing all of the axes!
After trying all sorts of settings, none of which had the desired result, I removed the G28 (home all axes) entry from the Custom G-Code section of the Printer Settings in the Slic3r configuration pop-up and manually set the Z starting height and then choose the “Set Home” button on the Print Panel within Repetier Host to convince the software that this is the new Z=0 value prior to starting the print.
This time the print ran all the way through to completion and the host software was keeping track with the printer with regards screen output and what the printer was actually doing, whereas on the previous version of firmware the host appeared to be a few lines of code ahead of the printer and eventually exceeded the available buffer space causing the resend errors.
If I had decided to start with a less complex test piece it may have been some time before I ran into the buffer issue as it only seemed to manifest when lots of tiny moves were being carried out for the surface detail of the coin.
After reading a few horror stories about less than ideal track sizes on the sanguinololu board for the current required for running a heated bed, I have decided that I will run the heated bed directly off the power supply, using the output on the board to activate a suitable relay to enable/disable the connection. This will probably be a 30 or 40A SPST automotive one that I will almost certainly have already somewhere in my garage, or failing that, available for £0.99 on ebay.
The image below is from a thread on the eventorbot forum where they discuss the issue and then show the basic circuit and the use of a flyback diode across the relay connections to prevent back EMF destroying the MOSFET on the sanguinololu board.
