Combining $ commands

[foxylad]

I have a gcode file that starts with two Grbl settings:

$30=1000
$32=1
...

The chrome-gcode-sender console shows these as being sent on the same line, which causes Grbl1.1 to return an error 3:

Grbl 1.1f ['$' for help]
> $30=1000 $32=1
error:3

I thought at first this would be an issue with unix line endings, but after rewriting the gcode file with CR/LF line endings the problem remains - the console still shows the setting commands on the same line.

If I remove one or both $ commands, it works. I think chrome-gcode-sender is combining commands, and in this case of Grbl settings commands, doing it incorrectly.

Possible fix: In gcode_util.js line 105, add a check for settings commands:

if (c == 'G' || c == 'M' || c == '$') {

[sir-buckyball]

Thanks for the potential fix.

In general I'm a little worried about trying to parse non-gcode commands in this code. It's usually dangerous to make such adjustments during a job.

potential issues that come to mind:

1) Grbl also has a '$$' command which displays current settings, which means the code needs to perform a lookahead before splitting. https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9#---view-grbl-settings 2) Every gcode command should be responded to by the machine with a 'ok\n' ; that is not the case for non-gcode commands like '$132' which would print a configuration command. At present the code treats any non 'ok\n' as an error, prints the message, and stops sending new commands until the user has resolved the issue.

Reading through https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands I see there are several new commands specific to Grbl v1.1. Supporting any commands that Grbl supports in a manner compatible with various other gcode-based machines may well prove difficult. I suppose making separate generic and grbl modes could help.

[foxylad]

Hi -

I agree that parsing non-gcode commands is dubious, but I'd go further and suggest that parsing any commands is dubious (with the possible exception of manually entered commands). I was surprised that the sender manipulated the gcode at all.

My rationale for this is that producing accurate gcode for a particular device is the job of the gcode generator. Trying to make the sender second-guess the generator means it needs to know about every gcode dialect, leading to continual upgrades and an ever-expanding settings page. Surely it is better to assume that the gcode generator knows what it is doing (again, unless it is human!) and simply send lines as presented.

Still, that's a philosophical argument you might not agree with. For the matter at hand, Grbl does return an OK for $ commands, and also for $$ (after printing all the settings), so I think my fix would still work. $ commands should only appear in gcode meant for Grbl devices, so it should be safe.

Cheers! Greg.

Virtual Industries Group Mobile: +64 21 333 291

https://www.schoolinterviews.co.nz https://www.messagemyway.com

On 3 October 2017 at 16:46, Buck Clay notifications@github.com wrote:

Thanks for the potential fix.

In general I'm a little worried about trying to parse non-gcode commands in this code. It's usually dangerous to make such adjustments during a job.

potential issues that come to mind:

1. Grbl also has a '$$' command which displays current settings, which means the code needs to perform a lookahead before splitting. https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9#--- view-grbl-settings https://github.com/grbl/grbl/wiki/Configuring-Grbl-v0.9#---view-grbl-settings
2. Every gcode command should be responded to by the machine with a 'ok\n' ; that is not the case for non-gcode commands like '$132' which would print a configuration command. At present the code treats any non 'ok\n' as an error, prints the message, and stops sending new commands until the user has resolved the issue.

Reading through https://github.com/gnea/grbl/wiki/Grbl-v1.1-Commands I see there are several new commands specific to Grbl v1.1. Supporting any commands that Grbl supports in a manner compatible with various other gcode-based machines may well prove difficult. I suppose making separate generic and grbl modes could help.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/sir-buckyball/chrome-gcode-sender/issues/44#issuecomment-333730814, or mute the thread https://github.com/notifications/unsubscribe-auth/AFPkTZHwCDMl8fk6kNhuT4JYuCUDm7Hcks5soa4vgaJpZM4PpzXZ .