Why use G code

There are several projects on the forums to reduce the cost and complexity of the reprap electronics either by using the pc as host or reducing the size of the firmware so it fits in a smaller arduino.

I have had a search through the forums but cannot see anyone who has suggested the following approach.

Dont use G code to send to the arduino, but instead calculate the number of steps each motor has to move and send that data. The arduino firmware would be much smaller and could fit into the cheapest arduino available or even a couple of very cheap devices on the machine.

You could use skeinforge to generate G codes, then pass the data through a program to easily perform many functions in the PC. By using the PC to do the bulk of the data transforms, g code interpretation and floating point calculations, the arduino would only have to handle temperature control and the basics of recieving and transmitting the data bits to the motors. You might need a few codes for extruder start/stop etc. but the load on the arduino would be reduced. Eliminating floating point arithmetic for example would mean that the arduino doesn't have to hold the floating point library in memory reducing the firmware size considerably.

Please feel free to discuss or pull this idea apart.

That is how my firmware works it does just the realtime movement of the steppers and the heater control. The PC does all the calculations. Much simpler and works better.

---

[www.hydraraptor.blogspot.com]

My firmware also takes this approach. Host interprets GCode, and sends lower level motion commands to firmware (my research deal with motion as N-dimensional cubic spline curves, though, which can be computed very easily and quickly using integer math.)

It's not ready for primetime yet... (still!)

I decided to go the opposite way. My atmel mega 325 reads the g-code data from an sd-card and directly drives darlington transistors (TIP 120) to run unipolar stepper motors. Interpreting g-code is not that time consuming (it is already quite basic anyway) ... I think you can't drive cost lower than that. The mega 325 is powerful enough running @ 8 MHz internal oscillator to drive the motors with open loop pwm...
In my experience real time processing is more reliable on the microcontroller level.

www.3dp-tools.com

If using the USB connectivity to the Arduino, there are USB-host-protocol related delays of up to 25 milliseconds that would prevent the system you proposed from working real-time unless it has significant onboard buffering ( eg with a SD card, or some Ram or something ) to pre-buffer the upcoming commands prior to sending them to the microcontroller.

Like nophead said, this is quite do-able, but it's an entirely different approach to the current system. I'd encourage both you ( and nophead ) to try it out, and publish your results ( in the wiki)! If it's workable, and not too much of a divergance from the current "arduino-based" platform, it's quite likely that people with start using it!

I for one would love to see a arduino+RAM system that worked like you describe! ( eg I2C EEPROM, or SPI based SD-MMC , or something else?) . Alternatively, using the "Mega", with it's already built-in 8 KB of RAM, and 4 KB of EEPROM might be enough, who knows?

[www.arduino.cc]


Buzz.