Current command execution feedback about grbl HOT 24 CLOSED

I'm also looking for a way to get feedback about the current execution state. I was thinking that a very simple solution would be for grbl to, upon completing a gcode line, send back to the host a single character indicating that it has completed a line. This minimizes the time the AVR spends in communication routines, which, depending on the gcode, could become unnecessarily large.

For gcode that consists of a great many rapidly completed commands, it might be useful to include a setting for a divisor that would reduce the frequency of 'line completed' transmissions to some fraction of the total (i.e., send the 'line completed' indicator once every 10 gcode lines).

from grbl.

The problem with rapid g-code should be resolved in the edge branch now as transmission is now interrupt-driven and will not halt g-code processing.

As for feedback on current executing command that is kind of complicated as the g-code is processed into execution blocks which may or may not correspond to a specific line of g-code. But I see the need for this with graphical client software. Maybe each execution block could be tagged with a line number and a client get a notification of this line number each time a new block is started. Some times to "current command" indicator on the client software would skip a line or two, but that might not be a problem. If a nice client arise with an implementor indicating the need for this, I would consider implementing it.

from grbl.

I'm currently working on a graphical client with a file and tool path
viewer. At the moment it plots the tool path as it sends each line to GRBL,
but when the moves are long the toolpath view on screen isn't event remotely
representative of where the machine is.

The purpose of the client is to allow more fully-featured gcode to be used.
It is based on the TurboCNC gcode engine and currently supports loops,
fixtures, variables, subroutines, etc. I intend to add touch-probe support
too, but I need to get to home/limit switch support first.

On Sun, Jun 5, 2011 at 3:16 PM, simen <
[email protected]>wrote:

The problem with rapid g-code should be resolved in the edge branch now as
transmission is now interrupt-driven and will not halt g-code processing.

As for feedback on current executing command that is kind of complicated as
the g-code is processed into execution blocks which may or may not
correspond to a specific line of g-code. But I see the need for this with
graphical client software. Maybe each execution block could be tagged with a
line number and a client get a notification of this line number each time a
new block is started. Some times to "current command" indicator on the
client software would skip a line or two, but that might not be a problem.
If a nice client arise with an implementor indicating the need for this, I
would consider implementing it.

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/16#comment_1305859

from grbl.

Fantastic. I look forward to seeing it! So you would utilize a "current execution block" feedback mechanism if it became available?

from grbl.

Definitely. I'm curious what sorts of commands are blocked together. If I
can predict how the blocking works I can use that in the UI to avoid any
appearance of skipped lines.

On Mon, Jun 6, 2011 at 12:49 PM, simen <
[email protected]>wrote:

Fantastic. I look forward to seeing it! So you would utilize a "current
execution block" feedback mechanism if it became available?

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/16#comment_1310705

from grbl.

Oh, that's easy: Any line that results in a physical motion of the tool is an execution block. The rest is just handled as state in the parser or results in synchronous operation. So this:

g0 x10 f100
f500
g1z-2
f200
g1x0

is three execution blocks. I propose that clients that want feedback on which line is executing provide line numbers in their input to grbl. This is supported by the g-code standard and then grbl could spit out a little notification each time a numbered line is executed. This avoids any extraneous configuration settings.

Alas I just found out that TurboCNC is not open source – so your client can never be open source? :-/

Anyway, I'll reopen this ticket and add is as a todo

from grbl.

Ok, that blocking will be easy to deal with. I probably won't have to do
anything other than add line numbers to my grbl output (and keep track of
where they map back to my input file). I think I'm only sending
movement-producing commands already.

The TurboCNC code is what I call 'source available', since you get access to
it when you pay for the program. User produced binaries made with it are
distributable. It is unlikely that it will ever be OSS compatible.

My application uses it currently in an 'engine' configuration, so I could
get the features I wanted (sub-routines, variable inputs, etc) as fast as
possible. My code, the non-TurboCNC parts, are available under an OSS
license. When I get more of the meat of the application done I'll get the
TurboCNC-based execution engine swapped out with a free version. In the
meantime, if there is interest I can slice it out as a DLL so that others
can compile the app.

On Mon, Jun 6, 2011 at 1:08 PM, simen <
[email protected]>wrote:

Oh, that's easy: Any line that results in a physical motion of the tool is
an execution block. The rest is just handled as state in the parser or
results in synchronous operation. So this:

@@@
g0 x10 f100
f500
g1z-2
f200
g1x0
@@@

is three execution blocks. I propose that clients that want feedback on
which line is executing provide line numbers in their input to grbl. This is
supported by the g-code standard and then grbl could spit out a little
notification each time a numbered line is executed. This avoids any
extraneous configuration settings.

Alas I just found out that TurboCAD is not open source so your client can
never be open source? :-/

Anyway, I'll reopen this ticket and add is as a todo

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/16#comment_1310807

from grbl.

Hi, using Nx for the line numbers as input for grbl and a response with the line number after processing from grbl seems like a good solution to me. It's pretty straightforward to match input and output with that.

from grbl.

Yes, this is ideal for me. My grbl output module only sends a line when the
machine should move, and always includes the feed rate with the line. The
gcode file I'm reading to produce the output may have any sort of input, but
thats easy enough to handle.

On Tue, Jun 7, 2011 at 2:23 AM, urbanlink <
[email protected]>wrote:

Hi, using Nx for the line numbers as input for grbl and a response with the
line number after processing from grbl seems like a good solution to me.
It's pretty straightforward to match input and output with that.

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/16#comment_1314080

from grbl.

I came to echo the comments asking for a command to query current status.

Specifically, I would love to have a command that would simply return a "busy" or "done" status, and a command that would return the current positions of the axes. Being able to query the motor positions is especially important in combination with the emergency stop command to allow recovery and resumption.

from grbl.

I will give this priority, but it takes some design consideration to keep it simple so please don't hold your breath.

from grbl.

For my purposes, I just needed feedback when the buffer is empty, because for my application, I only send a few commands at a time, then wait for them to finish, so I added a "print 'Done\n'" statement when the buffer is empty. I'm new to git, so I haven't figured out how to check in the changes. (or get the comment formatting to work)

Stan

diff simen-grbl-74576a8/planner.c simen-grbl-74576a8_mod/planner.c
64a65
> #include <avr/pgmspace.h>
363c364,367
<   if (block->step_event_count == 0) { return; };
---
>   if (block->step_event_count == 0) { 
>     printPgmString(PSTR("Done\n\r"));  // notify controller we are done
>     return;
>   };

diff simen-grbl-74576a8/stepper.c simen-grbl-74576a8_mod/stepper.c
33a34
> #include <avr/pgmspace.h>
162a164
>       printPgmString(PSTR("Done\n\r"));  // nofify controller we are done
251c253
<   while(plan_get_current_block()) { sleep_mode(); }    
---
>   while(plan_get_current_block()) { sleep_mode(); }

from grbl.

Thanks. That's a good thing to have. I'll include this when I add the status feature.

from grbl.

just committed a tested version to my fork that reports the line number associated with the block currently being processed (if given and not 0) by printing"@line_number" on a separate line.

from grbl.

I'm also looking forward to the N response for when blocks are completed. It would also be nice to have a way of requesting Grbl's current ideas about position. Like if I could send a $P and Grbl would echoback 3.422,235.3,23.103 or something that would be awesome. That would be very useful to see how good my machine position estimation is doing for progress though long gcode lines. Having a way of being certain that my program and Grbl agree on position is important.

Do you think polling such a thing once every second or two would be too much? I'm unclear on how sensitive to serial communications the output plus trains are. I guess once I get my test arduino hooked up and counting output pulses I can run some tests on that myself.

Do you have any gut feeling about the best baud rate to use with Grbl? (In terms of not causing hickups in the output) right now I'm just running at the default 9600, but it will eventually be important to go faster and I was wondering if you had any recommendations for a faster standard speed to try?

from grbl.

Lots going on right now, so sorry that my responses here are sparse these days. I assume that polling status every second or so will be no problem for grbl. Actually it might even be better if grbl could be set to report status regularly without having to waste cycles transmitting the poll command. But I'll have to test this to be sure.

When it comes to baud rate I have no idea. There is something between the FTDI-drivers and OS X that precludes me from using any other rate, so I have just stuck with it.

from grbl.

Yes, I have to be in a special mode anyway while streaming down the commands, so being able to set a mode where to broadcasts a position update would be fine. Oh it's a bummer you're stuck at 9600. I guess that's a good reason to try and make sure it works well at 9600. I guess I'll only worry about faster connection speeds if that some how becomes a problem. I guess if one were streaming down a lot of very quick to process tiny steps of gcode it might be a bottle neck already, but I won't worry about that for a while.

from grbl.

This is a follow-up to my response on issue #15, regarding real-time feedback and commands (i.e. status queries, reset/pause, enable/disable block delete or acceleration planner, speed limiting, etc.)

I'm beginning to think that the solution to this problem is to re-write how sleep mode is handled and make serial protocol manage all executions. There are a lot of places in the code that forces the Arduino into a sleep mode, mainly in the planner. If each valid gcode block is forced to wait for buffer availability to be processed at the serial protocol, instead of in the planner. This allows for the serial protocol to keep running, accept external commands and immediately process them, regardless how full the buffer is. Any real-time command will likely have a near immediate response, since a gcode block should process within a few milliseconds.

This approach shouldn't effect how grbl behaves, except for G02/03 arcs. Currently, arcs generate a high number of lines and feed them directly into the planner and buffer, bypassing the serial protocol. For this to work, arc would need to be re-written too. But this is not as bad as it seems. The nice thing about arcs is that they have known lengths, radii, and speeds with known entry and exit directions. Meaning, you can calculate the centripetal acceleration beforehand. In other words, you can compute the fastest feedrate your machine can handle going around the arc by v_arc = sqrt(a_max * R_arc). So, with a bit of re-arranging and more math, you should be able to treat an arc just like a line in the planner. You would then only need a seperate lightweight function that would generate the arc for the steppers via the now known entry and exit factors and nominal feedrate based on centripetal acceleration.

from grbl.

Simen, I've been running the FTDI's on OSX at 115,200 with no issues (other than the OMG-FTDI-crashed-my-entire-system-when-I-unplugged--the-USB-port-or-powered-it-down-while-still-connected issue.) We can exchange notes if you like. - Alden

from grbl.

The Arduino Uno doesn't appear to use the FTDI drivers. It shows up as a USB modem. You can also avoid the "OMG---" problem by using the the user mode libFTDI drivers, though I hear they have other issues :-( I'm still running at 9600 because it is fine for my app.

Stan

On Aug 20, 2011, at 9:07 PM, aldenhart wrote:

Simen, I've been running the FTDI's on OSX at 115,200 with no issues (other than the OMG-FTDI-crashed-my-entire-system-when-I-unplugged--the-USB-port-or-powered-it-down-while-still-connected issue.) We can exchange notes if you like. - Alden

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/16#issuecomment-1861970

from grbl.

Interesting. Thanks for the heads up.

from grbl.

Hi - I've tried to implement stwspoon's edit, and apparently am not getting the statement in the right place. If I draw a continuous circle for instance, I'd expect to see one "done" (or whatever text you prefer) at the end. I am getting continuous "done", I believe, after the queue is filled. I know there was a request for queuing M commands, but it seems this function, done correctly, would allow a GUI/uploader to know when motion is complete. Any eta on this, or someone who's got it to work right? Thanks!

from grbl.

I made the following mods. My app doesn't use circles, so I would not have seen this. Also I had to add a change where the queue never fills up because the requested move is zero length and gets optimized out.

Stan

diff ./planner.c /Users/stanw/Documents/Compass Scanner/Software/simen-grbl-74576a8/planner.c
58d57
< #include <avr/pgmspace.h>
364,367c363
< if (block->step_event_count == 0) {
< printPgmString(PSTR("Done\n\r")); // notify controller we are done
< return;

< };

if (block->step_event_count == 0) { return; };

diff ./stepper.c /Users/stanw/Documents/Compass Scanner/Software/simen-grbl-74576a8/stepper.c
24,25d23
< #include <avr/pgmspace.h>
<
165d162
< printPgmString(PSTR("Done\n\r")); // nofify controller we are done

On Sep 27, 2011, at 9:36 AM, ghartc wrote:

Hi - I've tried to implement stwspoon's edit, and apparently am not getting the statement in the right place. If I draw a continuous circle for instance, I'd expect to see one "done" (or whatever text you prefer) at the end. I am getting continuous "done", I believe, after the queue is filled. I know there was a request for queuing M commands, but it seems this function, done correctly, would allow a GUI/uploader to know when motion is complete. Any eta on this, or someone who's got it to work right? Thanks!

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/16#issuecomment-2213012

from grbl.

I'm not sure what you're trying to do, but circles generate lots and lots of
tiny line segments internally and sends them to the planner with
acceleration off. This is why you are getting a lot of 'Done's. If you want
to know when the queue is done, the easiest way to do it is to have your
interface count how many blocks you have sent subtract how many grbl
responses you get.

I'm currently looking into the status problem. It's pretty tricky trying to
cram it into the serial stream along with the g-code. There are also a lot
of bug fixes in my grbl fork with the acceleration planner, junction speed
handling, and arcs with acceleration planning.

On Tue, Sep 27, 2011 at 2:44 PM, stwspoon <
[email protected]>wrote:

I made the following mods. My app doesn't use circles, so I would not have
seen this. Also I had to add a change where the queue never fills up because
the requested move is zero length and gets optimized out.

Stan

diff ./planner.c /Users/stanw/Documents/Compass
Scanner/Software/simen-grbl-74576a8/planner.c
58d57
< #include <avr/pgmspace.h>
364,367c363
< if (block->step_event_count == 0) {
< printPgmString(PSTR("Done\n\r")); // notify controller we are done
< return;

< };

if (block->step_event_count == 0) { return; };

diff ./stepper.c /Users/stanw/Documents/Compass
Scanner/Software/simen-grbl-74576a8/stepper.c
24,25d23
< #include <avr/pgmspace.h>
<
165d162
< printPgmString(PSTR("Done\n\r")); // nofify controller we are done

On Sep 27, 2011, at 9:36 AM, ghartc wrote:

Hi - I've tried to implement stwspoon's edit, and apparently am not
getting the statement in the right place. If I draw a continuous circle for
instance, I'd expect to see one "done" (or whatever text you prefer) at the
end. I am getting continuous "done", I believe, after the queue is filled.
I know there was a request for queuing M commands, but it seems this
function, done correctly, would allow a GUI/uploader to know when motion is
complete. Any eta on this, or someone who's got it to work right? Thanks!

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/16#issuecomment-2213012

Reply to this email directly or view it on GitHub:
https://github.com/simen/grbl/issues/16#issuecomment-2216003

from grbl.