Reported Sizes

[thothloki]

How is the sizing calculated when you load a file?
When i load a file that is 83x50mm, it shows up as over 100k mm

[barnold96]

I always use the center of a project as my origin. I had a similar issue to your description when I forgot to set Lightburn to use the center as origin. It was set for left front origin, so the size was reported as many times the actual size of my project. I changed Lb, re-saved the gcode and all was well.

[thothloki]

I always use the center of a project as my origin. I had a similar issue to your description when I forgot to set Lightburn to use the center as origin. It was set for left front origin, so the size was reported as many times the actual size of my project. I changed Lb, re-saved the gcode and all was well.

so all I have to do is use center start and i am good?. Dang. I am going to try that tomorrow

[AlligatorFate]

I changed the init.py script for Bettergrblsupport that I run in on_event so that I initialize minX and minY to 100000 and maxX and maxY to -100000. Then I calculate x from float(match.groups(1) [0]) rather than x+float(match.groups(1) [0]). (And similar for y.)

After doing this, the size calculations are correct, even with the origin is not the center. In my case, because of the way my machine is set up, it's more convenient for the origin to be the bottom left. So this change causes the size to be correct.

I could make a change and check it in somwhere here, if that's helpful to synman.

[synman]

sorry for the delay guys... life has gotten in the way of my hobbies lately. attach your change here, submit a pull request ... however you want to get it to me and I'll make sure it gets integrated back into master.

[AlligatorFate]

I checked changes in here:
https://github.com/AlligatorFate/Octoprint-Bettergrblsupport
Please let me know if there's a better way. Only 1 file changed.

[synman]

This is going to require some testing as I suspect what you've effectively done is change the calculation to respond to absolute positioning rather than relative positioning.

We may need to keep track of the Grbl Positioning mode for this cover all use cases. While this may work for your machine, I doubt it will work with mine.

Some additional thoughts. I never thought to test Lightburn positioning other than center. I'll have to play with that.

@AlligatorFate what "slicer" are you using? Am also curious why you needed to cast the regex extraction to float before the final cast to int.

[synman]

G90 vs G91 -- should be a good place to start for further testing

https://gcodetutor.com/gcode-tutorial/g90-g91-gcode.html

[synman]

ok, you guys have me going today.... Check out some of things I always do as part of "my workflow".

I think this is a big part of the problem.... this is my workflow.... not necessarily yours :)

First notice where I always place images Lightburn:

Second, notice how I configure my start position:

I'm thinking the Start From is more at play here than Job Origin. I could swear I tested various job origins... What I have not deviated from is I always use "Current Position" as my Start From.

I believe we can probably fix this by keeping track of the positioning mode. G90 will require absolutes (always taking the last value entered --- hence not accumulating the value). G91 will require accumulation as was originally developed.

[synman]

It is GCODE like this that is throwing off the calculation:

[AlligatorFate]

@synman: Yes, I'm using absolute positioning, G90 with a local coordinate system. I'm using FreeCAD Path workbench to generate the gcode. I'm using CNC, not laser. Yeah, I see where you're going with keeping the positioning mode. Might be just a switch between methods based on the state.

I understand the risk that an arc could go outside the box since the code only considers G1 or G0. In practice (so far) that hasn't been much of a problem. But yeah. The G3 gives the endpoint as X, Y, Z. So a slight improvement would be to just consider G3 along with G0 and G1. But still a chance the arc curves out of the box. I'd still rather have an "approximate" bounding box rather than none. (Of course I may change my mind on that with experience....) I'd rather have the arcs than the box.

[synman]

I'm working on a fix at this moment.

First up is tracking positioning mode ... simple enough to do so by keeping track of the last G90 / G91.

G3/G4 support was inadvertently already in place with the existing regex. I've always assumed it's okay to ignore IJR / etc because all we really care about are the min and max stops of X and Y.

It's rather silly fix truth be told.... basically:

                        if relative positioning:
                            x = x + float(match.groups(1)[0])
                        else
                            x = float(match.groups(1)[0])

[synman]

this fix is working well with neje example provided

@lathemaster I'm assuming I've at least got your dimensions in the ball park now.