...but a square made by a Sanguino-controlled RepRap...
...running the G-code interpreter driven directly by the standard Java host software.
The control panel can now send G codes if they're switched on too, so you can control a G-code RepRap interactively.
I want to get to the point where we can drive both the Arduino and Sanguino running either the SNAP protocol or G-code all using the same program.
The next step is to reconfigure the Sanguino so it uses the latest pinouts decided by Zach to give the maximum electronic versatility.
Initially I saw SNAP and gcode as one or the other, but I have come to realise that they are two very different things with different purposes. SNAP being a control protocol, and gcode being an instruction set, and that having both would be useful.
ReplyDeleteBasic fabrication can be done very well in gcode, as this enables the PC to be disconnected etc. But for other more experimental uses of the RepRap, e.g. things that require a lot of feedback / processing will be it will make sense to use SNAP.
As the Sanguino has four times the memory of an Arduino, and the firmware currently more or less fills and arduino, we should be able to fit both in only half the space!
I really need to get my hands on some Arduinos / Sanguinos (never used before but admired), as I am in a situation again where I have the magical combination of spare time and money too to buy bits. I sense another big order to Zach coming up.
Yes - I agree. The G-Code driver, for example, has to go through a certain amount of contortion just to get a temperature reading back. GCodes are essentially one way (which is a strength given you can put them in a file); SNAP is two-way, which - as you point out - is also useful.
ReplyDeleteGiven the ease of reprogramming both the Arduino and the Sanguino, I'm not sure that I'll put both protocols in the same program for the Sanguino. It probably makes sense to keep them separate, not least to maintain support for the Arduino.