Structure of parsing and interpreting

Hi,

I restarted programming after a long break.

Im still working on my own cnc software. I have been reading through the

source code for the parsing and interpreting and sending to motion planner

and finally machining.

im just working on the parsing and i struggled to work out what to do with the lines

of g code. so i set to studying a few open source cnc packages.

The ones that work on small printers lasers tend to push parts of a program from a file and

machine that section, and so on. I think could have that wrong, i dont own one so cant see

the beast running.

I looked at grbl and it looks like a cut down linuxcnc package.

It seems to do the same state machine

I might have this wrong.

does the linuxcnc software read single lines of g code and machine at the same time?

it looks like single lines of code are parsed, sent to conversion, maths functions running during

machine cycle time, everything slowly pushed and popped out of some ring buffer and sent to

the motors. So its reading code, parsing, converting and machining all at the same time.

thats a lot of cpu work.

i cant see where it reads all of the g code,and writes it out in, one pass, to a conversion file/buffer.

Which would make sense as the file/buffer could then be converted (by performing all the heavy maths)

into line segments and, turn them into steps for the motors - all in one pass to a file/buffer and send that

to the motors ( only after everything else has been done )- no reading, parsing, conversion and machining on the fly.

Hope this makes sense..

Im sure thats whats going on, i just cant see where its doing it.

if its not doing that then there must be some fundamental reason why it cant.

Hope some one can explain whats going on under the hood.

You can set the lookahead level in LinuxCNC, but it does not read and parse the
entire file except for the backplot and basic limits checking. Preprocessing the entire file
will not work with motion that is affected by real time feedback (threading, tapping,
probing, etc) these require real time trajectory planner involvement.

My take on this and I'm not saying I'm 100% right. There are several seperate processes firewalled off from each other communicating via shared memory and NML messages.

The gcode is read and buffered, parsed, validated and converted or tokenised into motion segments (one segment may be spread over more than one line). This tokenised output is consumed by the Trajectory planner which in turn instructs motion to move the motors.

You will hear us speak about real time (must happen on time every millisecond) and non-realtime (not time critical eg gcode
buffering and user space (the GUI often written in Python screen handlers in conjunction with a windowing screen design environment.

I have had a longer look - I understand the need to get the backplot listing run through in one pass that makes sense.
I think i get what your saying about getting into the machine to do checks and set up different tools and probes.
Its a choice i suppose.
Im writing mine to do all the parsing and the conversions into three files
one holds all the readable g code listing and is displayed in the screens listing window. The second file holds canon machine instructions only with a line index
system.
The third file holds the motor movement steps, with all the trajectory planning
already inserted.
All three files get synched to the machining instruction ( by line indexing).
if the machine crashes. the last instruction will have already been indexed
and can be restarted near the crash point.
the machining can be stopped at any time to do all the manual handling you
indicate. I think its a good plan. and thanks for the feedback.
I learn s new thing every hour of every minute of every second of this lifetime

thats what i think i have been reading - many thanks