Proper place for G-code interpreter

I've always found it impressive that the 5D code included a G-code interpreter. What a cool capability for our little Arduinos!

But lately I'm less convinced that the interpreter should be included in the firmware. I've been looking towards getting proper acceleration code working along with microstepping, and I'm feeling very limited by the available CPU cycles. Spending CPU cycles parsing G-code when it could easily be done on the PC side just seems like a waste. With the motherboard responsible for managing the movement (step calculation & timing) of four stepper motors, it seems to me that its focus should be there, with as few distractions as possible.

I'd be curious what other people think...

-Tim

Completely agree that the software should be built with a strict focus on driving the hardware. However, I also thing that with smart programming and scheduling, it should be possible to do a whole load of processing on the AVR. Key is to use the right abstractions. For example, never use floating point. Directly parse decimal numbers in scaled integers scaled just right (16 bits with 0.01mm resolution should work just fine) allow efficient processing. I'd rather send "stylized" gcode than think of a customer protocol.

The main thing is that the host-side software driving the RepRap should be sure to simplify curves that are too detailed and be aware of the various machine parameters, so the gcode stays compact and does not over-specify the actions required to be taken.

-Geert

I have always thought it madness to send floating point ASCII numbers to the target. That is why I do all my own software and firmware.

I do the interpretation and maths in Python on the PC and send binary commands in machine specific units to the micro. The consequence is that my software and firmware is much simpler and I have never had problems with segment pauses.

---

[www.hydraraptor.blogspot.com]

There is one advantage of the G code being in the firmware.
It is easy to debug the electronics by being able to send G codes from a terminal.
It is also a universal standard so it is easy to code for other process on the reprap such as PCB machining.
With development moving towards the Ardiuno Mega will the CPU limitation be solved?

---

Regards

Ian

Yes G-code is OK for an input language, or stored in a file but rather than send it down a serial link with a program it is much better to have that program translate it before it sends it.

True there is a small advantage that you can send ascii text to debug, but on the other hand my firmware is so much simpler and I have a source level debuggers that I never felt the need to send raw commands manually. If I did then since Python is interactive I can just type Hydra.goto_xyz((10,100,200),16), no harder than opening a terminal and typing G1 X10.0 Y100.0 Z200.0 F960.0 or whatever.

---

[www.hydraraptor.blogspot.com]

The other benefit is when available the capability to run the Reprap from the SDcard

Yes but an SD card can just as easily store the binary code. In fact it is probably shorter.

---

[www.hydraraptor.blogspot.com]

FYI,

I discovered this weekend that Skeinforge has a binary export option. It also has a small gcode export option if you are concerned about fitting gcode files on SD cards or reducing the parsing load.

nophead said >

I have always thought it madness to send floating point ASCII numbers to the target. That is why I do all my own software and firmware.


Hi Nophead

Can I download a copy of your software and firmware?

regards

Stephen

It isn't online at the moment. I plan to put it on GIT hub sometime next year when I have completed my electronics design and made it compatible with Skeinforge again.

---

[www.hydraraptor.blogspot.com]

>I plan to put it on GIT hub sometime next year
Thanks nophead(). Look forward to it.

Stephen