Form and function of status reporting. about grbl HOT 11 CLOSED

Great writeup, and much to consider. I just wanted to say something about line numbers: I think dead reckonning line numbers by counting input is hard to use as a client often may preprocess the file and even delete lines from the input. Personally I would prefer that we used the line-numbering standard from g-code and have line number reports be an optional feature that you "turned on" by actually numbering your lines. A preprocessing client that wanted to show current line in its interface would tag each line as it streamed it to grbl.

When it comes to reporting, maybe rather than polling, ? could turn on periodic reporting (e.g. every second) and ! would turn it back off. In a typical streaming setting the uplink would be pure gcode and downstream pure status. Just a thought.

from grbl.

Great summary from me too.

Many choices are probably very personal, depending on the environment and and task at hand. So the question really is: how much flexibility vs bloated code can we afford (e.g. '?' turns periodic reporting on, '!' turns it off, '#' gives a one shot report etc.); and how do we accommodate hackability for those who still feel the need for something different.

Further, a lot of these questions are strongly connected to the interface design. I would suggest a crawl-walk-run approach, i.e. start with something that can be used with a simple streaming script or terminal and then see what might be added for the needs of a GUI (e.g. binary data format for faster update cycles). Let's see how many ftoa()'s we can squeeze into the idle time :-)

One thing to consider though: how do the status reports mix with the parser status when a report is triggered while commands are still being processed?

Regarding line numbers, I totally agree with Simen: they should come from the g-code 'N'-commands. (If not defined they could default to zero).

So much for now.

from grbl.

I've thought about many of these issues and here's what I've implemented so far (and am in the process of implementing) for TinyG. This is still evolving, and I'm also happy to adjust as these things get hammered out. I'm also happy to contribute whatever code people might want.

1. report.c. Good idea.
2. What to report? All the reportable items are selectable because asking for them all is a big flood. Items are:
   • xyz & abc work position. These are identified by tokens xwp, ywp,... perhaps should add machine position as well: xmp, ymp... I first did the positions as as arrays (as you suggest), but my collaborators complained that they wanted them as independent variables because it's easier to parse. So I changed it. But they were doing JSON, not command line, and I think the arrays are easier to read. It also conveniently keeps things flat in the accessor code.
   • line number (ln). If the N words are present it reports them as line number. If not it reports counted lines. This takes about 4 bytes of RAM (double), and extracting the N word falls out of the grbl parser very naturally. The count is still useful in identifying problems as you can find the right line by the line counter in most text editors. Preprocessed G-code? maybe not.
   • machine state (ms). States are reset, run, stop, feedhold. This is VERY useful for releasing the streaming program when the gcode is actually complete.
   • feedrate. yes. I have this as velocity (vel) because it's delivered for feeds and traveses, and technically there is no feedrate for traverses. Semantics.
   • motion mode and gcode block. I'm thinking of adding this. This will allow EZ readouts and colored drawings from console programs (feeds are one color, traverses another).
   • since everything is configurable you may also want to optionally include:
     ** firmware version
     ** gcode units mode (G20, G21)
     ** absolute mode (G90, G91)
     ** plane selection (G17, G18, G19)
     ** offsets (IJK)
     ... and a whole host of other parameters too numerous to list. I have this working both as command-line mode and JSON, so in either you can just query the variable (get) the get the return (i.e. the name with a null value). So perhaps the non-realtime variables are not needed in the status report itself. (more on the evolving JSON spec can be found below. comments welcome.) http://www.synthetos.com/wiki/index.php?title=Projects:TinyG-JSON
3. I like the look. Basically it's JSON without the curlies and quotes. To tailor reports I've been playing with just sending in the tokens you want in the report with 'true' values (for the SET semantic). The system remembers this and returns the report according to spec.
4. How should it work? Here are the methods TinyG implements:
   • ad-hoc query. There is a "status_report" object (friendlyname "status_report", token "sr"). If you ask for sr you get the status report as specified. I've been implementing this as ?sr and {"sr":null} (the friendlyname forms also work: ?status_report and {"status_report":null} )
   • status_interval (si). If you set the si token to non-zero you get a report every N milliseconds while the machine is moving. And you always get one at the end of travel. The minimum ms value is about 100ms, and there may be a max as well. If you don't want this behavior just set si to zero.
   • additionally there is the SET method mentioned in (2) above.

Let me know what you think.

Alden

from grbl.

Simen:
Good point on both notes. The g-code line numbering would be the most direct and simple to understand for reporting. But since g-code line numbering isn't exactly consistent from user to user and CAM to CAM software, there needs to be another way to know what block is in-process. As Alden suggests, he uses both, but I think mixing both would make for some confusion. Hard to say what to do. Are there any other ideas on how to track the block in-process?

Your comment on the polling leads to another question. For the feed hold, resume, and abort features to work, there needs to be an interface to allow these commands to interrupt grbl's main program to immediately execute. For a software/USB based setup, this means the only way to send commands to grbl is through the serial rx/tx interface, piggy-backed on the g-code streaming. To do this, an external interface must be able to inject these special characters into the stream so the serial read function picks them off to set the runtime execution flags. Status reports were added here mainly because it was easy to do.

So if we decide to include XON/XOFF flow control, how do we still send these runtime commands through this without requiring a specialized streaming interface? One answer would be: don't send them and move this functionality to physical buttons on the spare I/O pins. But at the cost of having a software interface. There might be a nice solution to this streaming problem. I just haven't thought of one yet.

As for periodic reporting, do we have an available timer to handle this? As far as I understand, we have Timer1 and Timer2 used by the stepper module and I've read that Timer0 is generally a don't touch timer. If a timer is available, I agree that this would be the best way to send the reporting. Also, as Alden has in his code, does it make sense to allow both timer based and ad-hoc reporting?

Jens:
The g-code parser should be independent of the real-time status reporting, as they are reporting what the steppers are doing and executing. As of now, there isn't a way to prevent overwriting variables by the stepper module when a report is triggered, but when overwriting occurs, it's rare and doesn't seem to cause to many problems. You just have to make sure that the variables are being written only by the stepper module to prevent two simultaneous writes.

With the customization and fear of bloat, I think using a toggle scheme in the settings should help with preventing bloat. This would also provide a clear blueprint for users to modify the report.c source file to their needs. But, I think I would still have to draft one up to see how it would really look.

Alden:
Good catch on the g-code modes. This is whole other realm of reports that may need to be reported, but likely at a much slower rate. This could be a separate reporting scheme.. perhaps call it 'modal report' or something like this. It would likely need to be sent ad-hoc and no faster than every second or so, not the 10-20Hz like with the stepper position.

As for TinyG's implementations, it seems that we have a general agreement on what needs to be there. The JSON formatting probably can be integrated by users by just modifying the report.c source file. I would prefer to keep things nicely human readable and short, mainly not to confuse new users. The way I see it, if we do make a report.c source file, people could just write and distribute their own to be compiled by users or forks. Plug and play hopefully.

from grbl.

A finer point on line numbers - if the N's are present I prefer to use them. I only count lines if the N's are not there.

Timers: Doesn't the 328 have an RTC? That's what I use.

The need for other reports is why I haven't attached the status report directly to the ?, but use ?sr. It comes in through the normal command line interface, not the "signals" traps used by ! (feedhold) and ~ (cycle start) and ^x (abort)

I agree on the JSON. It's a special thing I'm doing for some console writers who want to work directly to dictionaries / hashmaps. I think I've managed to integrate it in so it's "modeless" - it just starts if you send a line beginning with a curly and stops when you send a line beginning with a $. I like the idea of a separate report.c

from grbl.

I have been working on a GUI for jogging my CNC, written in Processing. The difficulty is that when a button is pressed, let's say "+x", to jog the CNC along the X-axis in the positive direction, GRBL responds with a serial "Ok" message, but it does so immediately, not when the operation is finished. To be clear I am running GRBL 0.7d, I'm not sure if this behavior is different in the "edge" branch. So ideally I would like to be able to "poll" GRBL for whether the operation is finished or for GRBL to send something like "done". It sounded like that might be possible with the planned status reporting feature which the wiki said is on the roadmap. The behavior I'm trying to avoid is that repeated presses of a jogging button don't continue to send additional movement gcode lines, until the previous line is executed. I will try to upload the Processing program to my fork of GRBL, still figuring out github and git. The code is very alpha, functional though, and I'm not a programmer by trade, so it might be kinda hack, open to feedback.

from grbl.

the "ok" message indicates that the g-code line was parsed all right. It is also an indicator that the space that the line occupied in the buffer is free again. In this function the "ok" message is already being used by programs, like the stream.py script, that feed grbl as fast as possible.

One way to indicate when exactly a g-code line is started to be run can be achieved by using g-code line number reporting (I will provide the code for this soon). But if your line is the only and last line to be run that still doesn't give you the "g-code line finished" report. The finish of the last g-code command could be read from the number of blocks in the command buffer. When this becomes zero then your command has finished running.

The way I do it right now in my https://github.com/jgeisler0303/grblUI is to compare 3 consecutive position reports (polling at 100ms). If there is no change then that means that movement has stopped and the command has finished.

from grbl.

A simple 'Done' worked for me (see issue 12) as I needed to know that the motion had stopped. I added a "Done" print statement when the command buffer is empty. I also added a 'Done' in the planner because sometimes the movement was optimized out. I was using 74576a8, but it probably can be added to the newer branches.

from grbl.

In TinyG I added a synthetic state variable like so:

enum cmCombinedState {
COMBINED_RESET = 0, // machine has been reset or aborted
COMBINED_CYCLE, // machine is running (cycling)
COMBINED_PROGRAM_STOP, // program stop or no more blocks
COMBINED_PROGRAM_END, // program end
COMBINED_RUN, // motion is running
COMBINED_HOLD, // motion is holding
COMBINED_HOMING, // homing cycle active
COMBINED_PROBE, // probe cycle active
COMBINED_JOG // jogging is treated as a cycle
};

The state is one of the parameters you can request to be reported in a status report (token is "stat"). So when the system is running the value "Run" is returned in the status report. On the last status report the value "Stop" is returned, assuming there are no more blocks queued to run. Note: Even though "Cycle" is in there this isn't exposed to the interface.

-Alden

from grbl.

Can anyone help me with getting "done" status? I write a small program for my bot in python and only way to know that we have reached final destination is to check change of MPos after initialising of the new gcode. I am sure that's possible to get reply like "done" or "buffer clear" in special mode. For example "*G00 x100" could give reply after execution of this code was complete. "G00 x200" can give only "ok" reply as usual. Thanks for any help.

from grbl.

Hello,
To know that a command was executed gcode sending through the serial port:
Serial.print("?\n\r");
then check sometimes if the return of the first five characters equals "<Idle"
example:

void TestEdle(){
while( stateGcode() != "<Idle" );
while( stateGcode() != "<Idle" );
while( stateGcode() != "<Idle" );
}

Comments are welcome,
Milton Vilela
São Paulo - Brasil

from grbl.