Why is everyone using arduinos to interpret gcode?

1Mbps on UART is hard, I expect noise, clock glitches may ruins the packets.

People want print on SD for 2 reasons,
1. they need not to keep the computer running the host, connecting to the USB. Especially when Diablo 3 (insert your favorite CPU intensive program) and printing host doesn't mix well.
2. Performs better on small arc/corner because of the processing latency.
Why it prints better when prints from SD? I can't say for sure but believe the latencies are introduced in the host program. It has a high jitters (inconsistency latency) to read a wake up the host thread, read gcode line, send it down to the USB.

So if you take away the gcode->step calculation functions from the MCU, the host must do it. And if I want to print from SD because of reason 1 (free my computer from running the host because I want to play Diablo 3 while printing), there must be some other kind of hardware running the host. RPi would do the job...but does that mean now I have to buy a RPi in additional to the Arduino/AVR?

Then why not just take the R2C2 way...dump the AVR, just do everything with ARM. Sounds more cost effective, less problem (high speed communication), less complex to me.

My solution shouldn't require any additional controllers; just the RPi since I'm using SPI-based, fully integrated stepper motor motion controllers.

R2C2 looks pretty nice. My only complaint about it is the lack of modular expansion of stepper drivers. I'm constantly debating that tradeoff, but I think there's some significant benefits to be had by going with the RPi.

What is the Gcode?

sam0737 Wrote:
-------------------------------------------------------
> 1Mbps on UART is hard, I expect noise, clock
> glitches may ruins the packets.
>
I'm a bit worried about that but most firmwares are running rs232 at 250Mbaud (except its a short hop from the ft232 to the avr, but I only need 500kbaud max and probably less most of the time

>...but does that mean now I
> have to buy a RPi in additional to the
> Arduino/AVR?
>
I never planned to have an AVR in my setup, just an 80p pic on each controller board. I sent a couple of boards off to production earlier this week. The cost of parts for a single board is about £9 and that includes pcb, a single stepper driver, a single power mosfet, 2 endstop headers and a fan header. 4 or 5 of those boardshooked up in parallel would run the average machine and cost £50-£60 (including the interface board at about the same cost). They all take commands from an interface board which is basically a board with an ATX connector, MCP2200 (usb to serial that can be reprogrammed) and an RS485 bus driver. The MCP2200 needs some revised firmware to handle sending commands at defined times, which takes the timing problem away from the host pc. If I combine that with a raspberrypi i've got a full set of electronics with a lot of processing power for less than £100 and I have a decent amount of power to run more complex algorithms (handling circles for instance).

Anniraks idea is a bit less dumb than mine as it takes commands defining paths rather than individual steps which would mean it should get away with lower bandwidth. I think bandwidth isn't really the big problem, its the lack of buffers, especially if usb is only sending packets at 1mS timeslots. SD card won't have that problem as its basically reading the gcode in using SPI which the avr has direct control of. Keeping the buffers full will be a lot easier with a binary protocol as (especially on the MCP2200 with 256bytes of DMA RAM) it will be easier to pick in a few mS of commands.

I'm not worried about using the host for something else. I have a mini-itx box I use for printing but a £25 raspberrypi should be more than enough and with £60 of electronics and a £15 ATX power supply you could have a full set of electronics for £100.

Pete

G-code is the command protocol that most RepRaps use.

---

Bob Morrison
Wörth am Rhein, Germany
"Luke, use the source!"
BLOG - PHOTOS - Thingiverse

pete-theobald Wrote:
-------------------------------------------------------
> sam0737 Wrote:
> --------------------------------------------------
> -----
> > 1Mbps on UART is hard, I expect noise, clock
> > glitches may ruins the packets.
> >
> I'm a bit worried about that but most firmwares
> are running rs232 at 250Mbaud (except its a short
> hop from the ft232 to the avr, but I only need
> 500kbaud max and probably less most of the time
You must have miscounted the zero. Marlin default is 250Kbps, or 0.25Mbps, or 250000 bit per second.


> >...but does that mean now I
> > have to buy a RPi in additional to the
> > Arduino/AVR?
> >
> I never planned to have an AVR in my setup, just
> an 80p pic on each controller board.
PIC? It's just as fast as AVR - they are the same class of MCU.

8 bit PICs run four times slower for a given clock speed. I.e. they need four clocks for each instruction. And the instructions are a lot more primitive than AVR so C runs considerably slower on a PIC18.

---

[www.hydraraptor.blogspot.com]

nophead Wrote:
-------------------------------------------------------
> 8 bit PICs run four times slower for a given clock
> speed. I.e. they need four clocks for each
> instruction. And the instructions are a lot more
> primitive than AVR so C runs considerably slower
> on a PIC18.

Yep, PICs run one instruction per 4 cycles so 20MHz is only 5MIPs. I think they're also a risc processor which means they don't have the benefit of specialist instructions. that said, they have DMA modules, lots of timers and PWM modules so you can keep a fair bit of stuff running in separate modules. I'm planning to use DMA to receive messages, PWM modules to run heated beds, extruders and fans and the rest can happen in code as it doesnt need to run so fast.

Pete

Hi, I am new here and have started working on a RepRap-related project for OSE [opensourceecology.org]. The first iteration has been done with grbl on Arduino

I have been thinking about converting G-Code to an intermediate PVT (position-velocity-time) waypoint format, then using Arduino to generate the step/direction (using cubic spline interpolation) from that. This is similar to some CANOpen DS402 motion control that Maxon, etc. do in their servo drive modules. PVT mode is designed for splicing together continuous smooth moves out of segments, unlike the trapezoidal point-to-point trajectory generators in L6740 etc. For attaining the same deviation from ideal path it takes a lot fewer PVT (spline) segments than linear segments so bandwidth to Arduino, buffer size, etc should be a non-issue.

Another thing I am contemplating is using ROS protocol to stream data to the Arduino (I have used [www.ros.org] successfully in a past project), ROS also provides a time sync service which could keep multiple Arduino slaves in sync if some grander multi-axis scheme materializes. (A 5-axis CNC torch table that pivots the torch head to do angle cuts would be cool...) I have tried rosserial in Raspberry Pi but I think the serial_node.py script needs optimization: [wiki.jigsawrenaissance.org]

Agreed that when we use big buffers to handle communication stack latency (e.g. in USB, serial, ethernet) that there has to be another route for homing and perhaps status feedback but that fits pretty cleanly into ROS comms architecture just by adding another topic or service.

All this is handwaving right now, any comments?

Chuck

I think you have to try. Without actually trying it's difficult to do a good judgement, as often hidden details, like the 32-bit division in the acceleration algorithm, turn out to be major obstacles.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

I thought GCodes were for CNCs and then adapted to Repraps...

Anyways, I don't know this seems obvious to me but, linuxCNC/emc2 uses drivers for steppers on the parallel port, while arduino based electronics also uses stepper drivers. Now, any CNC use a CAM that takes the .STL and produce gcodes or whatever signals on the parallel bus to control the drivers, but the reprap does no computing (else the PID for the heaters and maybe a little accel/decel for the movements). The point is, for a reprap, all is done in the slicing of the stl on the host pc, so the gcodes are not generated by the arduino, but simply interpreted and the printer is doing what its told to.. So for linuxCNC to "print", its just a matter of sending the gocodes on the usb serial connection, queue in 8 lines of gcode in advance and keep 'em flowing (sounds easier said then done... ).

So what Im doing here will sound like heretic to y'all, I'm actually using Gen7 electronics to drive my tabletop Mantis to mill (eventually ) PCBs. Now, where I fall short is the CAM are all made for CNC and not usb electronics, so using the printer/printer electronics to do some CNC work is kinda hard with Pronterface/Printrun and Slic3r... Though the gcodes come from the CAD I use for creating the pcb, getting the work done would be nicer with a CAM for cnc, so maybe a plug-in for linuxCNC/emc2 to use the Printrun's console API. Now I'm at the point where I will add gcodes in the firmware to do whats needed (like mirror X or Y axis for double sided pcb milling) but if anyone knows a good tutorial on printing a double sided pcb on a diy tabletop mil or anything on using reprap electronics to do some milling work would be nice.

Thanks in advance,
MikE

Quote

Now, where I fall short is the CAM are all made for CNC and not usb electronics, so using the printer/printer electronics to do some CNC work is kinda hard with Pronterface/Printrun and Slic3r...

Huh? G-code is G-code and a G-code compiler doesn't care the slightest how the electronics makes machine movement from that. I run G-code made on Catia with Teacup just fine. The same G-code simulates in EMC2 perfectly as well.

Quote

like mirror X or Y axis for double sided pcb milling

All G-code compilers making G-code for PCB milling I'm aware of do that already.

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

Thanks for responding, but on the matter of the subject, I guess the keyword I was missing was "realtime", because all CNC CAM are actuating the motor drives in realtime, with some multiple threads or processes running at the same time. Now for the 3d printers, the realtime part is done in the Arduino/electronic with PWMs and such, with queued-in commands (gcode lines) and having a "realtime" response to the PC host is relative to the usb communication link. Also, adding complex collision detection algorithms or lets say a toolpath creation and simulation is problematic because of the process speed a arduino has. So maybe one way to go is to add an expansion connector, akin to the parallel port and have a more direct interface with the electronics/hardware. But then again, the parallel port is somewhat on the brink of extinction, am I right? So I'd say, let's make something that works on the pci-e, but then you'd need a really faster uC to do the job... All this is telling me is CNCs need to be a little more like 3d printers (usb connection part), and 3d printers need to be a little more like CNCs (CAM "realtime" part). I'm still a newb so tell me if I'm wrong, thank you.

Now, for the precedent post, I'm really grateful for the info and I will look into the GCodes more deeply because, from what I understand gEDA/pcb can produce "non advanced g-code". Maybe casting them in the Pronterface would give me a better flow to execute double sided boards milled PCBs but today I will be reading more on pyCAM, which seems suited to what I do. And from what I read around here, I guess its not so bad to throw the gcodes directly using the pronterface but I believe pyCAM will really help with the organisation, even if it's not driving the printer/cnc directly, I can still simulate after in emc2 and run the gcodes with Printrun. [sourceforge.net]

Thanks everyone,
MikE

Quote

Also, adding complex collision detection algorithms or lets say a toolpath creation and simulation is problematic because of the process speed a arduino has.

Controllers by definition don't do tool path generation. Neither Arduino based ones nor EMC(2).

---

Generation 7 Electronics	Teacup Firmware	RepRap DIY

@pete-theobald
So what was the end result of your test boards? I read through this topic in hopes of a resolution.