I stuck my stripboard Sanguino (red S) on my RepRap machine to see if it would fly. I want to do this so I can play with more than one extruder at once, for support material and so on.
Getting it to start working was pretty simple - I redefined the pins in init.dist.h for the Single Arduino Snap code, and the RepRap Java software started talking to it straight away.
With a bit of messing about I got the axes moving, then - when I put the wires on the pins I'd actually defined in the header file - the zero opto-sensors worked too.
But I got a lot of comms errors. These were much reduced by adding:
for(int i = 1; i < 32; i++)
{
pinMode(i, OUTPUT);
digitalWrite(i, LOW);
}
to the initialisation code, then letting the classes set the pins they actually use as they want. (Incidentally, the Arduino code doesn't do this for all the pins it uses - maybe it should...)
I suspect we have some stray interrupts from somewhere (like noise on unconnected pins), and also some code in there that switches off interrupts for too long, and so it loses bytes from the input stream.
The comms errors are still too bad to make the extruder go properly, though the temperatures are being measured fine.
If you want to play it's all at: http://reprap.svn.sourceforge.net/viewvc/reprap/trunk/reprap/firmware/Sanguino/
The pin assignments are in the OpenOffice spreadsheet here.
Tomorrow, if I have time, I'll see if Zach's upgrade just below cures some of the problems...
Is this comms problem a thing that's been happening in Arduino or is this specific to Sanguino?
ReplyDeleteWhat perfect timing, just started wiring up all the boards etc I got from zach including a Sanguino and was wondering what to pin/connect it out as.
ReplyDeleteI made a simple breakout board for the Sanguino using 2.54mm pitch screw terminals and put a floppy drive power connector on board to make plugging in the ATX SMPSU easy (There are more of the floppy power connectors left over than the style usually used on the other driver boards.)
Thanks for the spreadsheet I will use this as the wiring guide.
A quick passing thought flagged up after looking through the pin out spreadsheet.
ReplyDeleteThe SPI pins are currently earmarked for a second extruder (great).
Is it worth considering juggling the pins and leaving them free to be SPI.
There are a number of devices that would benefit from SPI most notably the Magnetic Encoder board from the RRRF.
I have also come across several internet references to using cheap memory cards in conjunction with SPI for data storage (either catalog of parts to print, or as a resilient download buffer, freeing up internal memory for clever code)
Thoughts for what they are worth.
Forrest: There are a few comms probs with the Arduino, but the error-corrections fix them and they aren't too bad. At the moment the Sanguino is worse, but I only just hacked it together, so I was amazed it worked at all.
ReplyDeleteAK: The pin assignments are definitely not set in concrete. As long as we have PWMs where we need them I'm happy to move stuff about to optimise. If we keep all the fancy stuff on Extruder 2, then it'll be freed up when we move from Darwin to Mendel, as Mendel will only have one extruder (at a time - there'll be a row of 'em to swap...)
Send me a copy of the spreadsheet with your preferences :-)
"At the moment the Sanguino is worse, but I only just hacked it together, so I was amazed it worked at all."
ReplyDeleteYeah, comms is a problem, it seems, no matter what you're doing. With Tommelise, I'm currently trying to chase down why the PC drops the USB connection to the controller board periodically for no particular reason. It seems to only be happening when I'm running the Dremel to do milling.
It's odd, because the Dremel isn't electrically connected to the controller board in any way and I've got the controller board protected by a UPS system. All I can figure is that the Dremel occasionally puts out a magnetic pulse big enough and the USB line acts as an antenna scrambling the connection.
Fortunately, since my print files are written on EEPROMS beforehand, the milling goes right on with only the PC/Tommelise link lost. That's no big deal.
Unfortunately for hardware SPI (easiest and quickest) the pins allocated by Atmel are specifically
ReplyDelete28, 29 and 31.
And fall bang in the middle of the block put aside for Extruder 1.
28, Extruder_1 fan
29, Extruder_1 motor_dir
31, Extruder_1 valve_dir
Ugger My OCD urges like things organized into nice neat blocks.
Other than those 3 a small number of digital outputs are needed to provide device select. (Minimum 1)
The digital output can be any that are left free so are really not critical. My best suggestion is to go with 2 pins if we have them free and want to reserve them.
Where we are finding pin space tight one reserved will do. others could be pressed into service if some other peripheral is'nt in service.
Where they are really does'nt matter.
A note for interfacing to a memory card (MMC or SD) can be found here
http://www.captain.at/electronic-atmega-mmc.php
It would be fun to have a Darwin/Mendel parts catalog preprocessed and ready to print as a memory card image.
Write from a PC card writer, plug in, run up a terminal and tell the Darwin to get on with replicating.