Changed format for live feedback in Grbl 1.1c

[beikeland]

Terminal output from the new live feedback in Grbl 1.1c:

WARN: Connecting to Port /dev/ttyUSB0,115200
Connected to /dev/ttyUSB0at 115200
Recv:
Recv: Grbl 1.1c ['$' for help]
Recv: [MSG:'$H'|'$X' to unlock]
Recv: <Alarm|MP<Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.|Ov:100,100,100>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.|WCO:0.000,0.000,0.000>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.|Ov:100,100,100>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.|WCO:0.000,0.000,0.000>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.|Ov:100,100,100>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.|WCO:0.000,0.000,0.000>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.|Ov:100,100,100>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
Recv: <Alarm|MPos:0.000,0.000,0.000|Bf:16,128|F:0.>
WARN: Closing Port /dev/ttyUSB0

Can update with motion etc when I can be by the machine and test later if it helps.

[beikeland]

The error messages are reduced to error codes, overview of codes to look up is here i believe https://github.com/gnea/grbl/blob/edge/grbl/report.h

[beikeland]

Its been pointed out that you can use ´#define USE_CLASSIC_REALTIME_REPORT´ to retain the old feedback for now.

https://github.com/gnea/grbl/blob/edge/grbl/config.h#L288

[ghost]

@beikeland I updated the regex to split on "|" too, have another test and let me know (:

[iceman1979]

Are you specifying $10=3 or something else?

[cprezzi]

This 'quick and dirty' method of parsing | in one go with : and , is not reliable, because the amount and order of parameters in statusReport from GRBL depends on configuration and status. On my machine, I only got MPos from GRBL when $10=3. With $10=2 I got WPos, but no MPos, so x/y/z is not at the right position. It's better to parse it correctly by first break it in segments of piped-parts, then separate by : & , to get param: val, val, val (number of values depending on param).

@peter: It seems you only patched | in "public/js/grbl.js", but this is not used for display update. You need to patch it also in "public/js/socketcomms.js" which seems to updates the X/Y/Z Position display and BullseyePosition.

[cprezzi]

Here is my code for socketcomm.js (tested with GRBL v1.1d, should also work with v0.9):

function updateStatus(data) {
    // till GRBL v0.9: <Idle,MPos:0.000,0.000,0.000,WPos:0.000,0.000,0.000>
    // since GRBL v1.1: <Idle|WPos:0.000,0.000,0.000|Bf:15,128|FS:0,0|Pn:S|WCO:0.000,0.000,0.000>

    // Extract state
    var state = data.substring(data.indexOf('<') + 1, data.search(/(,|\|)/));

    // Extract WPos (set $10=2!)
    var start = data.search(/wpos:/i) + 5;
    if (start){
        var pos = data.substr(start).split(/,|\|/, 3);
    }

    if (state == 'Alarm') {
        $("#machineStatus").removeClass('badge-ok')
        $("#machineStatus").addClass('badge-notify')
        $("#machineStatus").removeClass('badge-warn')
        $("#machineStatus").removeClass('badge-busy')
    } else if (state == 'Home') {
        $("#machineStatus").removeClass('badge-ok')
        $("#machineStatus").removeClass('badge-notify')
        $("#machineStatus").removeClass('badge-warn')
        $("#machineStatus").addClass('badge-busy')
    } else if (state == 'Hold') {
        $("#machineStatus").removeClass('badge-ok')
        $("#machineStatus").removeClass('badge-notify')
        $("#machineStatus").addClass('badge-warn')
        $("#machineStatus").removeClass('badge-busy')
    } else if (state == 'Idle') {
        $("#machineStatus").addClass('badge-ok')
        $("#machineStatus").removeClass('badge-notify')
        $("#machineStatus").removeClass('badge-warn')
        $("#machineStatus").removeClass('badge-busy')
    } else if (state == 'Run') {
        $("#machineStatus").removeClass('badge-ok')
        $("#machineStatus").removeClass('badge-notify')
        $("#machineStatus").removeClass('badge-warn')
        $("#machineStatus").addClass('badge-busy')
    }
    $('#machineStatus').html(state);

    if (Array.isArray(pos)){
        $('#mX').html(pos[0]);
        $('#mY').html(pos[1]);
        $('#mZ').html(pos[2]);
        if (bullseye) {
            setBullseyePosition(pos[0], pos[1], pos[2]); // Also updates #mX #mY #mZ
        }
    }
}

[cprezzi]

Don't forget to set the new params: $10 = 2 (for WPos & Buffer State) $30 = max. Laser PWM $31 = min. Laser PWM $32 = 1 (Laser mode on)

[ghost]

I would love a pull request to fix it better (:

On Oct 25, 2016 9:58 PM, "Claudio Prezzi" notifications@github.com wrote:

If you like, I can send you my code when I'm back in the office tomorrow.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-256158138, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr22UgzDMY8Iq3qKlNdqbADSQnvdJTks5q3l9TgaJpZM4KXBcM .

[beikeland]

For $32=1 to be fully useful does not the generated G code need to have S parameter added to all moves, and remove the M03/M05 commands to turn off/on laser between segments? Use S0 to turn off laser instead.

I can help test, but thats the limit of my scope for now.

On Wed, Oct 26, 2016 at 3:54 PM, Claudio Prezzi notifications@github.com wrote:

Don't forget to set the new params: $30 = max. Laser PWM $31 = min. Laser PWM $32 = Laser mode (on=1)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-256354366, or mute the thread https://github.com/notifications/unsubscribe-auth/ACk5btxQy2L58WpoaHVkEyyOWzwnRyXLks5q31uNgaJpZM4KXBcM .

[ghost]

LW3 does not automatically add m3/m5 unless you add that to laseron/Laseroff commands in settings, gcode. The default (Smoothieware uses this too) is blank commands for on/off. Then g0 moves = laser off, g1 =laser on. We have S values on every line.

[iceman1979]

I set M3 S0 in my start code block and M5 in my end code block. I also set the laser off command to S0

The S value on a line is only required if it changes but it doesn't hurt to have it in there for every line.

[cprezzi]

For me it worked with or without setting M3/M5. If M3/M5 is not configured in settings, you need to set M3S0 in the Start-Code and M5 in End-Code. In LaserMode, GRBL accepts S Values in each G-Move and sets the correct PWM for the Laser.

@openhardwarecoza: I'd like to send a pull request, but I'm not used to work with git, so give me some time to find out ;)

[ghost]

@cprezzi - after this fix, we seem to have a trailing > that doesnt get removed?

[krolco]

I stepped through the parsing code from the PR, and it looks like it returns correct results -- no trailing greater-than in the parse. I couldn't figure out where this comes from either.

[cprezzi]

This could probably happen when WPos-Values are not followed by another param (like with GRBL v0.9). Need to delete the > in the string before parsing WPos.

[cprezzi]

@openhardwarecoza - I updated master. Could you please check if it's corrected now?

[cprezzi]

Good documentation of GRBL v1.1 protocoll changes: https://github.com/gnea/grbl/blob/edge/doc/markdown/change_summary.md

[ghost]

Remember that Smoothie feedback is parsed by the same function...

<Idle,MPos:49.5756,279.7644,-15.0000,WPos:0.0000,0.0000,0.0000>

This is the output from Smoothie...

On Thu, Oct 27, 2016 at 10:42 AM, Claudio Prezzi notifications@github.com wrote:

I don't get any trailing > on my PC: [image: dro] https://cloud.githubusercontent.com/assets/5457949/19760423/fd5b6004-9c31-11e6-9005-29b92ffa45be.jpg

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-256582448, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2wvGEJk9sZQ-KpHxuCNsrnqcm0TMks5q4GPngaJpZM4KXBcM .

[iceman1979]

The output will be different based on your $10 setting in GRBL. I have mine set to $10=2 based on the comments in the code but ideally it should be set to $10=1 so that GRBL is not sending back the buffer bytes remaining. This is meant for debugging only and is recommended to not use this for production runs as it can cause latency issues with GRBL.

You can't ask too much of these little arduinos lol

On Thu, Oct 27, 2016 at 6:24 AM, Claudio Prezzi notifications@github.com wrote:

Good documentation of GRBL v1.1 protocoll changes: https://github.com/gnea/grbl/blob/edge/doc/markdown/change_summary.md

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-256604562, or mute the thread https://github.com/notifications/unsubscribe-auth/AAUF8e1F7cTL13qSDIcGCFe_huFNKtLaks5q4HvIgaJpZM4KXBcM .

[iceman1979]

Maybe we can look at the welcome message and set a flag that indicates smoothi or GRBL?

[ghost]

The two are so close that theres almost no point. We did do hectic auto detection on LaserWeb (v1) and it later became a nightmare. Thats why in later versions we made it configurable through a gcode settings and macro panel so it really works with anything

On Oct 27, 2016 10:11 PM, "iceman1979" notifications@github.com wrote:

Maybe we can look at the welcome message and set a flag that indicates smoothi or GRBL?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-256755282, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr24VZ0tr7Zd-UsPTSV8d35BTge1p0ks5q4QVsgaJpZM4KXBcM .

[iceman1979]

Cool!

[cprezzi]

@iceman1979 - Please check the new settings for $10 of GRBL v1.1 (https://github.com/gnea/grbl/blob/edge/doc/markdown/settings.md). With $10=1 you only get MPos instead of WPos, which breaks DRO. You have to set $10=0 if you don't want Buffer info.

[cprezzi]

@openhardwarecoza - Thanks for the mention. I checked it and Smoothie parses exatly like old GRBL, so my last fix should also be good for smoothie ;)

[cprezzi]

It would be possible to use MPos for DRO, if WPos is not available. Should I implement that?

[iceman1979]

I believe the options for $10 would be 0, 1, 2, 3 depending on if you want MPos, WPos, with or without buffer data. Is LW3 not capable of supporting all of those options? Meaning can we only use work position with LW3?

If it doesn't break LW3 then I would suggest supporting all of the $10 options.

[ghost]

@cprezzi , yes if wpos is not available fall back to mpos. That would be elegant

Another option, we can always send $10 on connecting to force a state we want:

https://github.com/openhardwarecoza/LaserWeb3/blob/master/server-grbl.js#L186-L191

(Mind you i think we need something other than 'version' for Grbl on line 191 there anyway)

Anyway, adding a line there to send $10=whateveritmustbe is an option.

[maudette01432]

@ Peter - I was thinking that same thing. My concern with that is it would be changing a configuration (EEPROM) setting and there is the possibility that you won't be able to exit gracefully and set it back. Maybe only warn and leave it up to the user before writing new configuration...and/or document recommended GRBL configuration.

[cprezzi]

@iceman1979 - Not exactly. Mode 3 is not supported anymore (read the link I posted). GRBL v1.1 only supports $10 = 0, 1 or 2. $10=1 means MPos insted of WPos, which is not parsed in LW jet.

[cprezzi]

@openhardwarecoza - If we set $10 by code (which I do in the start G-Code at the moment), then we don't need a fallback for MPos. How about Smoothie? Do we allways get WPos from it, or do we have to set the right params too?

[ghost]

Smoothie only returns one kind of grbl status line in response to '?' as far as I know... But lets check with @wolfmanjm if i am correct

On Oct 28, 2016 8:50 PM, "Claudio Prezzi" notifications@github.com wrote:

@openhardwarecoza https://github.com/openhardwarecoza - If we set $10 by code (which I do in the start G-Code at the moment), then we don't need a fallback for MPos. How about Smoothie? Do we allways get WPos from it, or do we have to set the right params too?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-256999181, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2yEk9DsA1g_-ZHkjCy8DPPduUtXmks5q4kPcgaJpZM4KXBcM .

[cprezzi]

I think it's easyer to add the MPos fallback. This way, it doesn't matter, what's set in $10.

[ghost]

Agreed. If its not too much trouble, that would be best

On Oct 28, 2016 8:53 PM, "Claudio Prezzi" notifications@github.com wrote:

I think it's easyer to add the MPos fallback. This way, it doesn't matter, what's set in $10.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-256999914, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr22UqsPS58p3gkkRYEyNVjGnyiX8gks5q4kSbgaJpZM4KXBcM .

[cprezzi]

It's just 3 lines of code ;)

[iceman1979]

@cprezzi I did, that's where I got it from :)

Use the table below enables and disable reporting options. Simply add the values listed of what you'd like to enable, then save it by sending Grbl your setting value. For example, the default report with machine position and no buffer data reports setting is $10=1. If work position and buffer data are desired, the setting will be $10=2.

@chamnit, please correct me if I'm miss stating this.

It is a bit mask system $10=0 (0000, WPos without buffer data) $10=1 (0001, MPos without buffer data) $10=2 (0010, WPos with buffer data) $10=3 (0011, MPos with buffer data)

[wolfmanjm]

@openhardwarecoza Smoothie only returns a fixed data for the ? command the realtime MPOS and WPOS. I don't see any reason to make it more complicated.

[ghost]

@wolfmanjm thanks (: - yes please dont make it more complex. See here we are fixing parsers again for grbl lol. Yours, still works lol.

On Oct 28, 2016 9:28 PM, "Jim Morris" notifications@github.com wrote:

@openhardwarecoza https://github.com/openhardwarecoza Smoothie only returns a fixed data for the ? command the realtime MPOS and WPOS. I don't see any reason to make it more complicated.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-257007696, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr2zW0nVmTvXuwb9n-xmBlAdORjiVtks5q4kzlgaJpZM4KXBcM .

[chamnit]

@iceman1979 : Yes. You are correct.

@openhardwarecoza : For the record, the recent change in v1.1 was necessary to cram significantly more real-time data (overrides, pin states, accessory states, buffer states, line numbers, realtime feed and speeds, etc), still reduce the overhead involved with serial comm, and make it easier for GUIs to maintain their code down the road. It was a necessary evil, which I know is painful but trust me that it's for the better.

Having both MPos and WPos in the same message is a complete waste, because all you need is the coordinate offset, which rarely changes. Once you have it, it's a simple arithmetic to compute the other position vector.

[ghost]

firmwarewars lol

On Oct 28, 2016 9:39 PM, "Sonny Jeon" notifications@github.com wrote:

@iceman1979 https://github.com/iceman1979 : Yes. You are correct.

@openhardwarecoza https://github.com/openhardwarecoza : For the record, the recent change in v1.1 was necessary to cram significantly more real-time data (overrides, pin states, accessory states, buffer states, line numbers, realtime feed and speeds, etc), still reduce the overhead involved with serial comm, and make it easier for GUIs to maintain their code down the road. It was a necessary evil, which I know is painful but trust me that it's for the better.

Having both MPos and WPos in the same message is a complete waste, because all you need is the coordinate offset, which rarely changes. Once you have it, it's a simple arithmetic to compute the other position vector.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/openhardwarecoza/LaserWeb3/issues/156#issuecomment-257009460, or mute the thread https://github.com/notifications/unsubscribe-auth/AHVr21LbNgM1-t-LiEit_jHhRXx64kOhks5q4k7igaJpZM4KXBcM .

[iceman1979]

@chamnit Thanks, I appreciate the confirmation. I want to make sure I'm not saying something incorrect.

[iceman1979]

@openhardwarecoza lol, too funny. Don't hate but you know I have to put my vote in for GRBL :)

[cprezzi]

@iceman1979 - Sorry for the mistake. You was right and I was wrong (hmmm) :(

@chamnit - I realy like the new features from v1.1 a lot and the new format for status reports makes parsing a child's play ;)

[cprezzi]

PS: I'm allready playing with the overrides ;)

[iceman1979]

Lol, no worries. I'm just glad I was right for once lol. That doesn't happen too often for me :)

[cprezzi]

Did anybody test if this version is still working with smoothie?

[cprezzi]

This feature was merged to master branch, so I close the issue now.

[cspwcspw]

Suppose grbl is reporting WPos and occasionally also sends WCO status. (Easier if we assume no axis movement is occurring.) If the active workspace changes (e.g. I send a G10 to select a different workspace), will the new WCO be reported immediately on my next status poll, so that the WPos and "most recently received WCO" are always in sync? Or is it possible to get a "new" WPos value based on my new workspace selection, even though I haven't yet seen the new WCO?

I have a related issue when my GUI attaches to an already initialized and running machine. Until I've received the first WCO, I cannot properly calculate MPos.

And then just for my own interest: what is the reason for providing a choice between reporting WPos or MPos? Would it not be cleaner to say "We always report MPos. Deal with it!" As chamnit has pointed out, it is a simple matter for a GUI to convert from either to the other once WCO is known.

Thanks

[cprezzi]

@cspwcspw: Your post is related to Grbl, not LaserWeb! Please post your question on https://github.com/gnea/grbl/issues.