Status report with wrong stat

[breiler]

I'm using {sv:1} and {si:250}to receive status reports during and after a command has been sent to the controller and in version 101.03 it sometimes ends up with the wrong sr:stat.

So for instance if I issue the following command I get a sr:stat saying that it's running. I would expect it to be 3 (program stop) or 4 (program end).

>>> {"gc":"G20"}
{"r":{},"f":[1,0,14]}
{"sr":{"posx":10,"unit":0,"stat":5}}

If I run a G0-command it works as expected:

>>> {"gc":"G0 X11"}
{"r":{},"f":[1,0,17]}
{"sr":{"posx":10.09847,"vel":39.37,"stat":5}}
{"sr":{"posx":10.26381}}
{"sr":{"posx":10.42914}}
{"sr":{"posx":10.59448}}
{"sr":{"posx":10.75883}}
{"sr":{"posx":10.92416}}
{"sr":{"posx":11,"vel":0,"stat":3}}

I don't experience the same problem in version 100.26 but that's probably because it doesn't report the stat for the G20-command:

>>> {"gc":"G20"}
{"r":{},"f":[1,0,14]}
{"sr":{"unit":0}}

The G0-command works as expected:

>>> {"gc":"G0 X11"}
{"r":{},"f":[1,0,17]}
{"sr":{"posx":2.501,"vel":1000,"momo":0,"stat":5}}
{"sr":{"posx":6.7}}
{"sr":{"posx":10.752,"vel":595.97}}
{"sr":{"posx":11,"vel":0,"stat":3}}

[justinclift]

Interesting. Could indeed be a bug.

As a general thought, I think it's recommended to send G-Code as plain text, instead of using the json format. Changing variable settings and the various control things are recommended for json though. 😄

[justinclift]

Ahhh, here's the wiki page I was thinking of:

• https://github.com/synthetos/g2/wiki/g2core-Communications#line-mode-reference-implementation

Under the Notes section:

Note that {"gc":"...} Gcode line are considered control lines and bypasses motion planner buffer tests and are acknowledged immediately. Consider sending GCode as unwrapped text, while observing linemode protocol. See issue 287 for more detail.

[breiler]

Thanks for the quick reply @justinclift, I didn't bother looking into the existing code for sending GCode commands. It's now fixed so that GCode commands are sent without wrapping with {"gc":..}.
(this made no difference with the wrong stat in version 101.03)

[justinclift]

Cool. Good point, as that really does sound like a bug. 😉

[justinclift]

Testing here now... agreed. This is happening for me now too. Reverting my Due back to 100.26, and this bug isn't showing up.

[giseburt]

This is very odd. I’m not sure why G20/G21 would have ever caused a stat change. I believe the old behavior is a bug. You *should* however see the `unit` value change in the status report. Also, since it’s gcode you can put an `Nxxx` in front of it and with the right `jv` value see that the line was received in the response. G20/G21 are among the gcode commands that do not participate in a cycle. Basically if it only changes the way other following codes are interpreted then it won’t change the stat. *However*, if the machine was not in a cycle and you send any gcode, it will automatically start one. Since we don’t wait for the user to push a “cycle start” button we automatically start a cycle when we see any gcode. I was looking over the pull request comments (but not the code) in the UGCS repo, and see what you’re going for. In the DRO case mentioned, the system stat changed to RUN with just the G20/G21 (or something you sent before) but there was nothing there to cause motion. If you send M0 or M2 (which resets stuff, so maybe avoid this one) as the first line of gcode the system sends, it’ll show stat of STOP or END (respectively).

…

On Tue, Jul 17, 2018 at 1:58 AM Justin Clift ***@***.***> wrote: Testing here now... agreed. This is happening for me now too. Reverting my Due back to 100.26, and this bug isn't showing up. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#367 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXj0Y5k0PhRTQnQlggSaE4Kp0WT3-6Yks5uHYsTgaJpZM4U_Vkk> .

[MitchBradley]

I'm having the same problem, but with G10.

G10 just sets the offsets, without causing any motion. cm_cycle_start() is called early in _execute_gcode_block(), regardless of what is in the block. It looks as if, when no motion is involved, there are cases where cm_cycle_end() never gets called.

The addition of the blanket cm_cycle_start() came in commit ae0145c , described as "Some comments and naming changes to offsets for clarity". It seems that a semantic change came along for the ride.