G-/M-Code Specification

Hello!

Please excuse me if the following should be a typical newbie question - but I could not (yet) find the information I need.

Is there anywhere a brief specification of the G codes and M codes (and anything else) which the host software sends to the Arduino controller?

As I am controlling my "FTIStrap" (see [forums.reprap.org]) by the host itself, I am planning to

- extend the RepRap host software in a way that it writes the G-/M-code to a file
and
- write a little G-/M-code interpreter which finally drives my FTIstrap

Does anybody have the information I need?

Thanks in advance for any help!

---

Kind regards,

Andreas Rozek

Skienforge Contains (in a subdirectory) an executable for each of the M-codes. It's intended for people using seperate software (MACH3, I think. Open-source CAM software. It doesn't generate g-code, it's just "machine interface via parrallel port" software) which will execute the external program each time it comes across an unfamiliar M-code. People doing this (I think nophead is one) use an arduino to do the M-codes, and the MACH3 stuff to run the positioning system. There's no good reason that I'm aware of to modify the host software - Enrique's Skienforge suite will do everything you need. Skienforge also does several things (like tower building) than the host software doesn't do yet.

I don't remember all the G-codes, but off the top of my head they are:
G0(Fast movement), G1 (feedrate-controlled movement)
Inch/mm
Relative/absolute postioning
Go Home
Go Home via an intermediate point
Dwell
Set as Home

Arc codes (G2/G3) are included in the arduino g-code firmware, but don't work worth crap. I'm working on it. Slowly.

P.S. I did pretty good for going from memory! Missed only "dwell" and "set current as home"

Edited 1 time(s). Last edit at 09/25/2008 12:20PM by John Gilmore.

---

--
I'm building it with Baling Wire

here:

[reprap.org]

and here:

[reprap.org]

John,

thanks for the information - I will have a look at that "Skienforge" (do not yet know what that is)

Matt,

thanks for your response - I know these pages, but they do not specify the format of the parameters.

---

Kind regards,

Andreas Rozek

Hi Andreas;
skeinforge you can find here:
[forums.reprap.org]

'sid

Sid,

thanks - I found it. I think, I'll try it next week.

---

Kind regards,

Andreas Rozek

> Arc codes (G2/G3) are included in the arduino
> g-code firmware, but don't work worth crap. I'm
> working on it. Slowly.

I am curious what problems you have been having with the arc codes, since I wrote the code for this. Can you send me some example G-code to indicate where they are not working?

Draw a circle. Make it about four or five inches across. Observe the drawing process. When it's done, examine the finished product. You'll observe the following things:

1. The drawing process is extremely shaky. There are significant pauses between line segments, which on my repstrap at least cause significant noise. It's fairly quiet till it gets to the arcs, and then it sounds like it's trying to chew pieces of itself off...

2. It's squashed on the diagonals. If fact, the curvature actually goes negative, a real no-no for a circle. Looks more like a bloated cloverleaf, really.

3. Did it draw the correct size circle? in the correct direction? If you draw a half-circle does it REALLY end up at the target point? (I'd have to double check, but IIRC the answer to each of those last three was no...)

The time spent on calcualtion of trigonometric functions on an eight bit processor is considerable, and even then (as evidenced by the squashed diagonals) you don't get terribly accurate results. Please use the midpoint circle algorythm instead. It's MUCH quicker, gives step-perfect results, and takes less code space. Yes it needs a different case for each octant, but you'll note that the G-Code values are designed for the modpoint circle algorythm. It takes a square root at the begining to determine the radius, and a multiply or two for setup. Everything after that is add and subtract until you hit the target point.

I made an example implementation for all eight octants with start and stops, but I'm unsure how well it'll translate to C.

I've been trying to rewrite it to queue lines and feed them to an interrupt routine, but every time I turn on the interrupts I get garbage out the serial port. Since it's trying to do that inside the interrupt routine it's interfering with the step timing! I'm fairly sure a bogus call to Serial.print("") is the culprit, but haven't been able to track it down. Pretty much stalled at this point, got distracted by other projects.

---

--
I'm building it with Baling Wire

You make a fair point about some of the deficiencies in the code used, although I am surprised that it has been causing you so many problems - I have been using it almost daily for a variety of tasks without too much difficulty. Perhaps this is mainly because I have been using quite small arcs (<50mm dia) on which the problem of diagonals is less prominent. It was a case of writing some code quickly to fulfil an urgent need, which has since not been updated. I would be very eager to see your implementation.

With regard to using an interrupt-driven system (ala the SNAP firmware) I have been trying the exact same thing, with the exact same problem. I believe it can be resolved through using the right choice of timer for a timed interrupt to do the stepping, and reading lines asynchronously. There are three timers on the Arduino and there are conflicts with the serial lines on at least two of them, my memory is a bit hazy since it's a few months since I last worked on it.

I am currently working on some code to accelerate and decelerate at the beginning and end of each movement, for this to work effectively though there has to be look-ahead, which makes things even more complicated...

One thing I would like to point out. I find statements like "Arc codes (G2/G3) are included in the arduino g-code firmware, but don't work worth crap" quite unhelpful and rather discourteous. We are all contributing to this project in our own time and with the resources and expertise we have available, all of which are limited. If there is something which you think could be done better, by all means do so, but keep your criticism constructive. Check for example in the SVN logs who is responsible for the piece of code in question and open a dialogue with them, suggest alternatives, but don't dismiss others' hard work without considering how you would feel in the same position.

I appoligize. They didn't work for what I tried to do. I'd post the g-code, but I'm not at home. I tried to write "Hello World!" and the e and o came out badly wrong. They where only a ~20mm across, and the problem was easily visible at that scale. Maybe there is a library issue? The noise issue is at least somewhat a limitation of the platform (no interrupts). The sqaushed diagonals may be a product of a disfunctional library.

Strange to hear about the interrupt conflict with serial. I copied the code for controling the interrupts FROM the SNAP firmware, so I wouldn't think that would be a problem. I've been assuming it's a bad call rather than a hardware issue. I'm planning on copying the serial comms routines into my dev directory and modifying Serial.print("") to print the source call address (i.e. the top address on the return stack) and see where that took me. (Replacing it with "asm jmp Serial.println()" should work...)

I'd love to show you my implementation, but until I get past this "bad serial when timer interrupt enabled" schtick it's more plan than code. I was able to implement the algorythm in python, mostly because I can access python at work. I wasn't able to find an implemention designed for a plotter/mill, so couldn't crib it from somewhere else. Dead time between calls is SO nice sometimes. Doesn't change the fact I've got nothing though.

---

--
I'm building it with Baling Wire

Apology accepted.

I can't say for certain without having a look at the SNAP firmware, but I think that it is not a problem here because it always waits until a move has finished before ok'ing the next instruction from the host. The problem seemed to arise when trying to read serial data whilst the timed interrupt was enabled. The serial system on the ATMEGA128 is buffered so it should not be because bytes are getting lost.

I am having a look at the datasheet for the ATMEGA128 right now and hope to do some work on this next week - what I am trying to accomplish is that if say you are making a 90degree turn, that instead of the machine running at whatever speed you have set with the F code before slamming to a halt and attempting to accelerate again straight up to speed, that it will gracefully decelerate before accelerating up again. If the movement vector of the next move has some component tangential to the current move, then it will not slow to zero but to this velocity - in this way two parallel moves (eg. G91 G0 X10 followed by G0 X10) will be executed as one smooth movement. This is not possible at the moment because there is always a pause while the next instruction is read - the only way to deal with this is to have stepper movements done in a timed interrupt routine and do comms asynchronously.

I've though about the acceleration thing. One solution is to replace "instant angle" corners, which require infinite acceleration, with arc codes.

A circular arc gives us constant acceleration, but not constant acceleration on each axis. The g-code specification I read indicated two modes - constant feedrate mode (which may round corners to acheive a constant feedrate) or precise positioning (which may slow down on corners to get them precise enough). So this sort of thing has been addressed before and has a industry standard solution of some sort.

I was planning on putting the rounding logic into the host-side software though. Either modify skienforge, or modify send.py to include the arc codes when cornering. Probably modify the acceleration logic in skienforge to do arc codes when appropriate (i.e. when not turning off the extruder.) If step-perfect arcs and asyncronous comms are implemented in the firmware, it would make sense to do arcs for even quite small movements. And it'd all run smoothly, greatly reducing noise, vibration, and lost steps.

I don't think that full acceleration control can be implemented in 16K of code on an 8-bit processor. It MIGHT be possible on the sanguino with it's larger code size, but I doubt it. Skeinforge already does end-of-extrusion acceleration control, so replacing the middle angles with arcs should be enough and is relatively simple on the host side.

---

--
I'm building it with Baling Wire

Guys

A quick question.

What G-Code standard are we coding to (if any) G-Code is one of those wonderfully unstandard standards.

I am looking to add some code for driving the universal touch probe but haven't got a clear picture yet as to which Gnn.n I should be hanging the code off of.

Turbocnc seems to have something written to use G32 which seems to clash with another machine vendors implementations etc etc etc

Where as there is a straight probe command in RS274NGC specified as G38.2 which could be adapted/used.

Any help to clarify which standard we are aiming at would be great.

Cheers

aka47

---

Necessity hopefully becomes the absentee parent of successfully invented children.

I've been giving myself a crash course on REPRAP over the last few days, and I'm surprised,

I saw in one document... I think in a reprapper's blog, that the PC was sending out the step commands, and that they were buffered into a quad EEPROM eray. Now, I see this thread, where g-code is being used, and is requiring an 8 bit micro to do some fast maths on the spot... albeit a rushed implementation.

What's the rational for the reprap control board processor to be doing this number crunching instead of the PC ?

I was thinking that the PC creating the code could do that work, precompensate for any axis resolution irregularities (i.e. I have just finished my own X-Y-Z hardware yesterday, but for various reasons of availability and practicality, I've got X,Y on M6 running 1mm thread pitch from 7.5 deg steppers, and Z on M8 at 1.25mm thread pitch running on a 1.8 deg stepper.)

Some machines are going to have low mass, others high mass. My machine has relatively high mass, so it's going to need to ramp speed up and down if it's to go fast at all. Those sorts of calculations, are more competently done by a fast pentium/etc PC processor, and a file kept for configuration setting for the reprap machine in use. That way, all the computational grunt work is done by the PC, customised to the printer the job is being done on, and then received by the low end micro, to get on with the tasks, without having to squeeze interrupts in between maths calculations, and perhaps find a result is not available, then missing steps, overshooting steps because the calculation wait interfered with the momentum of the machines moving parts.

Given the complaints I see from reprappers over delays from G-code production causing print blobs etc, I would have thought that once the embedded SW received the data, there would be no more reasons for interruption...

Things like valves on the print head, I am seeing now as bandages on an irregular motion of the platform ?

So, I'm very interested, because I think that to get personal satisfaction with the embedded environment, I will have to use a processor with more pins for higher PCB integration, and for cost sensitivity, I'm going to probably use an Arm Cortex.



I apologise for the complaining nature of my post, I am actually very appreciative, in advance, of all the hard work that you guys are putting in.

Still, this is my take on the situation, as a newcomer.

Graham Daniel.

Good morning from Germany!

Graham,

I might be wrong, but you might have mixed up different controller techniques for different kind of RepRaps and RepStraps.

E.g., my "FTIStrap" is controlled by a PC (rather than a micro controller), which sends the stepper signals to the RepStrap - just because I am using fischertechnik interfaces (the primary idea behind the FTIStrap was to use as many existing parts as possible and to avoid any kind of soldering)

RepStraps differ in their construction, in the mass of their mechanics etc., RepRaps not (so much). Using a micro controller for driving steppers speeds things up and guarantee proper timing. Usually, steppers need high constant pulse rates (when running, and slopes when starting and stopping) which are difficult to achieve over serial ports - the FTIStrap is in a very special situation, as their steppers need very few steps for a single rotation.

Thus, using a micro controller is normally the best approach for controlling steppers (not only in this project) - and today, they are also powerfull enough to handle some math.

---

Kind regards,

Andreas Rozek

Hi Andreas,
I'm in New Zealand, evening here, and summer.
After I last posted to this thread, I saw a renewed thread initiated by Chris, in which it appears he's addressed many of the issued discussed above. He's struggling with code space though.

I follow your reasoning, indeed many PC operating systems have poor resolution on their available interrupts, so I understand the natural progression to a microcontroller, of course it allows serial comms too, (RestInPeace PC parallel port)

I will revisit, when I'm in a position to consider the g-code programming implications for myself, now I've built my 3 axis, I want my own platform to drive it, and that involves a couple of months design work in my spare time... maybe more.

Thanks,
Graham.