Bug? 1.4.05 and 1.7.00

For developers or anyone else to take a look at.
When I made this GRBL Lightburn v1.4.05

project (here’s just a part of it) I noticed that the laser started from the outside, I moved the line to another layer and it was solved.
But I had the urge to go and see what was going on, so in the original version if I change the priority of the shapes everything works as expected. I haven’t changed any settings. I’ve now tested it with Lightburn 1.7.00 and it’s still wrong.
cut_opt_settings

Very strange

I wonder where you found LightBurn 1.7.00, while I see a topic " Public Beta Release - LightBurn v1.6.00" in the forum.
Is this an alpha release?

It’s not apparent what the bug would be that you’re referring to.

What’s the complication, what are you expecting to happen, and what’s happening instead?

This would be part of the non-public beta releases.

2 Likes

Yes, there is a special test group for BSL/SeaCAD lasers (galvo lasers), particularly the Gweike G2 galvo. Some xTool S1 features are in early testing as well.

I’ll fire up a 1.7.00 and test this.

I selected the inner shapes first and the cutting started with the outer shapes, I just changed the priority and everything was fine.
This also happened with 1.4.05.

Following this topic, in my speed tests I went to test larger movements, with the same file I’ve been using for a few days, I duplicated the shapes and moved them to the end of the bed, and BAM the laser turned on, the layer had power. Undo repeated but I couldn’t replicate, a GLITCH? I think there must be a problem in cleaning values from memory, some stay resident, because when the operation is not as expected, closing and opening Lightburn everything is “normal”.

I still have to tinker with the options, but using a CUSTOM GCODE profile:

    1. Changing the Fast Whitspace Scan values or turning them off doesn’t affect the (non-cut)speed.
    1. Turning Return to Finish Position on doesn’t work, although if it’s on, if I set User End Script to a different position, it wraps up the movements.

What was the before and after priorities set to?

The priorities were 0 (default?) then I changed top egg to 1 and bottom egg to 2.

Edit: I’ve looked at it now and it’s still not perfect, starting with the top egg Lightburn cut out the inner shapes and before finish go to the outer shapes and then back to the inside.

  1. I remembered that I had seen some “out of place” coordinates in my image tests, so I went to check them out, I don’t know if it’s the expected output…

Image_teste__both.gc (1.8 KB)
Image_teste__only_mask.gc (1.7 KB)
Image_teste_only_rect.gc (388 Bytes)
Image_teste__GRBL.lbrn2 (9.8 KB)
2. In the meantime, I discovered the ants outside the selection boundaries?
ants_outside_of_selection

I don’t wanna be a beta-tester, although it’s by force of circumstance.:crying_cat_face: :crying_cat_face:

To me it looks like the yellow highlighted area is due to the rectangle placed behind the image being offset.

I was finally able to reproduce this. I’m running 1.7.00 on Win11.

It looks like 2 conditions are necessary in this example:

  1. design must have the more complex egg closer to the origin. This orienation results in the outer shape being cut first.

    This one does not.
  2. This requires multiple sub-layers to be present.

Removing either condition seems to result in inner shapes being cut first.

I’ll ask @Rick or @JohnJohn to confirm the condition.

I posted the .lbrn2, alternately showing only the image or only the rectangles within the 80cm x 55 cm area, the image was produced by placing an image (image snip capturing text) next to it, duplicating the rectangles, moving them above the image, mask flatten deleting the first rectangles and moving the result produced to x=50 y=150, to have consistency in my tests.

Can you state the actual problem that you’re observing with images and what you’re trying to demonstrate? It’s not obvious based on what you’ve posted thus far.

A new machine, following this topic I’ve conducted a series of tests/configurations to optimize the speeds, but in the meantime I’ve noticed some problems, e.g. in the last case of images, it starts engraving outside the limits and ends within the limits. Is this to be expected?

Selection position: x=50 Y=150
Selection size: 80 x 55
output GCode:

  • ;Bounds: X47.4 Y149.95 to X131.9 Y203.45

  • G00 G17 G40 G21 G54

  • G90

  • ;Image @ 6000 mm/min, 0% power

  • M9

  • M5

  • G0 X47.403Y149.952

  • ;Layer C01

  • G91

  • G1 X2.5S0F6000 ()…47.4≠50 ; 47.4+2.5 = 49.9 ≠ 50 ; 80+50≠131.9 ; 150+55≠203.45

Just to add another problem: if I press left ALT release count to five and then press E, the Edit menu opens.

This is standard behaviour on any windows application
Left alt enables Menu shortcuts → press it again and it toggles off

Word shows it better
When left alt is pressed.


On lightburn notice on pressing left alt you get a underline on the letter - which if pressed - triggers menu
image

Ok, is a toggle.

1 Like

I tried it in Win7, Lightburn already has the ALT toggle but in other applications it doesn’t, it must have become standard from Win10 and I missed that info.

Thanks
Always learning.

1 Like

The return to Finish Position works if I:

  • Toggle off switchg and click OK
  • Open Device settings again toggle on switch and click OK.

Lightburn takes over and works.

Almost there!
At 4000mm/mm
A little wobbly in the curves of letters ( maybe slow down a bit)