Go Down

Topic: Does G-Code require interpreter to respond after command? (Read 824 times) previous topic - next topic

greengiant83

I am making a little machine that interprets g-code and moves some steppers around appropriately. I am using an arduino as the brains on the machine side and sending commands to it from some software I am also building.


If it receives a command to move the steppers, lets say, a thousand steps how does the computer know when its done moving and ready to receive another command?

Once the arduino receives a command, "L101G01X9Y10" for example, should it respond with any sort of code to say "Ok I got it, give me another command"?

johnwasser

When G-Code was first developed the characters were punched into paper tape.  The CNC machine would read characters from the paper tape until it had something to do and then to that.  When it was done with the operation it would read more from the tape.  This is a from of "flow control".  The Arduino doesn't implement any flow control on the serial port so if you want it you have to implement it yourself.  One way to do that is to use XON and XOFF characters.  The Arduino would send XOFF to the PC when it had enough data to work with and send XON when it was ready for more.  This would require a program on the PC side that could handle the XON and XOFF characters arriving from the Arduino.
Send Bitcoin tips to: 1L3CTDoTgrXNA5WyF77uWqt4gUdye9mezN
Send Litecoin tips to : LVtpaq6JgJAZwvnVq3ftVeHafWkcpmuR1e

greengiant83

Is the XON and XOFF thing generally implemented in professional grade cam software?

I would take what your saying to mean that in standard applications that the interpretor doesn't talk back and just listens for commands. In lieu of that I would assume that it would buffer the commands and act on then as it is ready. Does a standard gcode sending application attempt to space out the commands as it expects to be required, or do they normally just send the whole thing down in one fell swoop?

johnwasser

The software that sends G-Code might implement a flow control protocol (like XON/XOFF) or it may assume the underlying serial hardware will do it with hardware flow control: RTS/CTS signals.
Send Bitcoin tips to: 1L3CTDoTgrXNA5WyF77uWqt4gUdye9mezN
Send Litecoin tips to : LVtpaq6JgJAZwvnVq3ftVeHafWkcpmuR1e

dewy721

There is a way to control the flow of data from EMC2 (linux Cam program) via python. The concept simply works like this:

EMC maniplates G-Code, then outputs the data to HAL (EMC's hardware absrtaction layer).
Upon startup HAL loads a python script as a "user module".
This python script does three things:
  Creates a serial link to your arduino.
  Pulls X/Y/Z/Whatever coordinates from EMC and sends them over the serial link to the arduino.
  Gives the arduino the ability to send commands back, such as pause, e-stop, limit switches, etc.

In this regard you would have the flow control your looking for and a full tilt industry compliant g-code parser with acceleration, canned routines, all that jazz. I know because thats what I'm doing now. Can send you the scripts if you would like.

Grumpy_Mike

In the RepRap 3D printer world the G-code interpreter sends an string back saying "OK" when it is ready for a new command.

These commands can be buffers to allow the software to look ahead. This is useful to know for example if you have no need to ramp down the speed because the command after the current one is not going to require a change in motor direction.

Go Up