search

synman / Octoprint-Bettergrblsupport

Better Grbl Support Plugin for Octoprint based (loosely) on the original Grbl Support plugin developed by mic159
https://github.com/synman/Octoprint-Bettergrblsupport/wiki
64 stars 19 forks source link

Coordinate values are messed up for some jobs #56

Closed synman closed 2 years ago

synman commented 2 years ago

I haven't been able to recreate this myself but you can't argue with a picture.

I made coordinate matching less strict with 2.0 to lighten up on CPU load during processing (simplified regex). I suspect something in the source file is throwing the match off.

Unknown
synman commented 2 years ago

attaching supplied gcode

Swan_2_T3.gcode.txt e

at first glance I do not see a position mode (absolute vs relative) being specified in this file. Looking over the code, I default to absolute position (G90) if a G90 or G91 command is not provided.

Weird that the file doesn't specify it. I'm guessing this is absolute coordinate by the way the gcode is written.

Additionally, I see this:

G18 G3 X81.648 Z-9.935 I-0.317 K0

The arc plane (G18) command prefixing the G3 may be throwing off my patten matching too.

synman commented 2 years ago

I was able to reproduce this on one condition. If I forced bgs to think the machine was in relative position mode, if I played the file through I was able to reproduce the obnoxious coordinate values:

2022-01-01 18:04:09,938 - octoprint.plugins.bettergrblsupport - DEBUG - x=-2389.84 y=-22383.23
2022-01-01 18:04:09,939 - octoprint.plugins.bettergrblsupport - DEBUG - x=-2355.78 y=-22383.23
2022-01-01 18:04:09,939 - octoprint.plugins.bettergrblsupport - DEBUG - x=-2322.70 y=-22383.23
2022-01-01 18:04:09,946 - octoprint.plugins.bettergrblsupport - DEBUG - x=-2290.26 y=-22383.23
2022-01-01 18:04:09,948 - octoprint.plugins.bettergrblsupport - DEBUG - x=-2257.91 y=-22383.23
2022-01-01 18:04:09,950 - octoprint.plugins.bettergrblsupport - DEBUG - x=-2226.01 y=-22383.23
2022-01-01 18:04:09,952 - octoprint.plugins.bettergrblsupport - DEBUG - x=-2194.34 y=-22383.23
2022-01-01 18:04:09,954 - octoprint.plugins.bettergrblsupport - DEBUG - x=-2168.77 y=-22383.23

I'm going to close this issue as invalid because as a general rule gcode files should ALWAYS specify which coordinate system they are using, absolute (G90) vs relative (G91). I think this is rather dangerous because there's no telling what would have happened with this session if the machine was actually in relative mode before the session started.

There is one remaining question I have. How did the known position system between bgs and the actual machine become out of sync?

I would definitely pass along this feedback (no coordinate system command included in generated gcode) to whoever maintains the post processor responsible for creating this file.

I may also sneak in some sanity check code within bgs itself to keep it in sync with the machine. I'll tag this issue if I do so. One thought I have is to daisy chain a $G command into the existing connection setup logic.