[gnea/grbl-Mega Issue#57] Parser state message question

#1 – winder 于 2018-04-03

Most grbl interfaces end up implementing a gcode parser eventually and keep track of the state in parallel to grbl. Here are a few examples:
* UGS: GcodeParser.java
* bCNC: CNC.py
* Grbl-Panel: GrblState.vb
* LaserGRBL: StateBuilder.cs

#2 – chamnit 于 2018-04-03

@barma1ey : It’s not clear why you would want to combine Grbl $ commands with a line of g-code. Unless you want to know the parser state after each g-code block. If so, that is a waste of bandwidth. It’s usually not necessary to know the state that closely. Do you have a particular application that requires it?

#3 – barma1ey 于 2018-04-03

@winder Yes, i know this. Of course, to parse each line before sending it to grbl seems to be the most obvious / easiest way. But the planner says it is not so good idea. Need to implement a queue

@chamnit I am planning to install some kind of tool change device on my machine. semi-automatic maybe. The idea was to pause program (M1 M6 Tx) when change is required, and state string was intended to notify operator which tool to use.

#4 – chamnit 于 2018-04-03

@barma1ey : In that case, it would be best to analyze the g-code prior to sending tool change g-codes (not M6 itself since Grbl doesn’t support it). You can easily wait until you get a reply from Grbl upon parsing the prior g-code line before doing anything related to a tool change. No need to constantly query for g-code parser state.