Grbl negative space not supported by bounding box

[AlligatorFate]

Hey it looks like negative space is still not supported by your bounding box calculations. I think this is a valid use case because it is common for CNC and that is the default for grbl. Here’s a description from the grbl FAQ:

Grbl Negative Space

This current code:

                        x = float(match.groups(1)[0])
                    if x < minX:
                        minX = x
                    if x > maxX:
                        maxX = x

Means that if you initialize maxX to 0, and you’re trying to work in negative space, the upper bound will always be way over at 0. Same for y.

This is why I was suggesting initializing minX and minY to 100000 and maxX and maxY to -100000 in the issue thread.

Apologies if I’m missing something, though.

[synman]

I'll take a peak... I don't foresee a problem initializing them to int min/max values.

Bit by absolute positioning again it seems. Can you attach some gcode that exhibits the problem?

[AlligatorFate]

Here's some simple gcode that cuts a square:

G17 G90 G21 (T3: 2.0mm EndMill) ; M6 T3 M3 S1000.0000 (Pocket_Shape) G0 Z5.0000 G0 X-10.9951 Y-10.9631 G0 Z3.0000 G1 X-10.9951 Y-10.9631 Z0.0000 F480.00 G1 X-28.9885 Y-10.9631 Z0.0000 F240.00 G1 X-28.9885 Y-11.7295 Z0.0000 F240.00 G2 X-28.0255 Y-10.9988 Z0.0000 I0.9629 J-0.2691 F240.00 G1 X-12.0308 Y-10.9988 Z0.0000 F240.00 G2 X-11.0308 Y-11.9988 Z0.0000 I-0.0000 J-1.0000 F240.00 G1 X-11.0308 Y-27.9935 Z0.0000 F240.00 G2 X-11.7821 Y-28.9565 Z0.0000 I-0.9838 J-0.0070 F240.00 G1 X-10.9951 Y-28.9565 Z0.0000 F240.00 G1 X-10.9951 Y-10.9631 Z0.0000 F240.00 G0 X-10.9951 Y-10.9631 Z5.0000 G0 X-28.9885 Y-28.2423 Z5.0000 G0 X-28.9885 Y-28.2423 Z3.0000 G1 X-28.9885 Y-28.2423 Z0.0000 F480.00 G1 X-28.9885 Y-28.9565 Z0.0000 F240.00 G1 X-28.2948 Y-28.9565 Z0.0000 F240.00 G2 X-28.9885 Y-28.2423 Z0.0000 I0.2579 J0.9445 F240.00 G0 Z5.0000 M5 G17 G90 ; M2

You can see that X extends from about -10 to about -30 and Y extends from about -10 to about -30. So, it's a box about 20 by 20.

But the boundary calculation loads up as 29 by 29 because the box is positioned -10 left from the X origin and -10 down from the Y origin.

I'm thinking that without initializing to 0, Xmax would have been -10.9951 and Ymax would have been -10.9631.

I hope that helps.

[synman]

it does.... my first thought is absolute positioning is not being detected....

G17 G90

causes both tests to fail:

                if command.startswith("G90"):
                    # absolute positioning
                    self.positioning = 0
                    continue

                if command.startswith("G91"):
                    # relative positioning
                    self.positioning = 1
                    continue

I think you're just getting lucky because I initialize self.positioning to 0.

I'm going to convert these to a contains(), play with the min and max values and probably have a point release out later today / this evening.

[synman]

With:

            minX = float("inf")
            minY = float("inf")
            maxX = float("-inf")
            maxY = float("-inf")

and

                if "G90" in command.upper():
                    # absolute positioning
                    self.positioning = 0
                    continue

                if "G91" in command.upper():
                    # relative positioning
                    self.positioning = 1
                    continue

We start to get some more reasonable numbers (using your sample gcode):