Makes no difference either way, object or grid on off or both on or off. I’m still running 1.7 with no issues. 2.0 was suppose to pull 1.7 setting into RC. The only thing I noticed that wasn’t pulled over to RC was the MOVE speed settings. Could be but I don’t think it’s a user setting issue.
For me it’s working good enough for what I do,I just notices it’s not what it was in 1.7. Maybe issue should be put on the list somewhere near the bottom as I’m sure developers have more pressing issues to solve.
This was perfect, thank you! I’ll take a look Monday - I was travelling the last 2 days and didn’t have the energy to open the laptop to take a closer look.
Ok, so, correct me if I’m wrong, because I managed to replicate the issue with my own fresh setup as well - this happens when you’re down to the 2nd decimal visible on the grid, right?
Given the UI screenshots and your settings, you’re working in millimeters.
I don’t want to be pedantic, but accuracy down to the 3rd decimal of a millimeter is positioning down to the micron. I am not aware of many machines capable of doing that if they’re not using high precision ball screws in a thermally controlled environment.
I would go so far as to say that accuracy of +/-0.05mm for a machine driven by belts, with a laser kerf of 0.05mm (the Orturs you run have a rectangular kerf of 0.07x0.06mm from what I could find) already means you can only get a repeated precision of cut/engraving down to 0.1mm (100 microns).
So thanks for pointing that out, I’m filing it in the bucket of things to check and investigate, but what we’re seeing is a rounding error. The LightBurn UI will not go below the 2nd decimal place when in mm mode. So if you click on 99.256, the UI will round it up to 99.26mm. Similarly 99.253 would become 99.25mm. Even if the gcode sent is correct, we round up or down the last digit of positioning for the UI.
Yep, you"re right and is also what I said to the other member i was chatting with. The accuracy is less than the capability of the beam and with other issues you most likely have that this issue should be at the bottom of the list as its usable for most of what i do with the lasers. As for zooming in tight and showing what i may presume to be an accurate representation of the position of the laser in respect to the point i selected is off from past versions. I do zoom tight for accuracy of using the Print and Cut feature when trying to recover from an issue with a cut. At least past version"s gave me a representation of accuracy even though the laser was microns off.
I’m working to figure out another issue I found with the Fire button with the Position tool and the Frame tool. Laser on is supposed to be on when selected and button turn red. What I get is Gray, select and get nothing when Red then select again and button turns Gray and laser come on. Must be Red Again to turn off. When using Frame the laser comes on and frames as usual but laser does not shut down when complete. Works as it’s should when Fire button indicator is red. It works incorrectly when using the position tool also. I have yet to do a complete check of setting or uninstalled and reinstalled the latest 2.0 nor have I looked or information concerning this issue on the forum. You may or may not have had this issue reported or maybe know about it already so I’ll leave the conversation with that.
Lightburn is the best thing to happen to Lasers as a tool and not a toy which is why I continue to support this software. Thank you for your support.
Sorry for coming out as a “err, you bugged me for that” kind of grumpy - I’ve been dealing with too much heat and not enough AC over here.
The precision thing makes a lot more sense with Print’n’Cut, which I hadn’t realized was a use-case. It’s pretty clearly a rounding process in play, we’ll just need to see if it interferes with anything to keep the 3rd decimal in the position we use.
Regarding the Fire button behavior during framing, I thought I had fixed something that could be related, but now I’m not so certain. If you want to open a new thread about it, tag me directly so I don’t lose sight of it. Otherwise I’m happy working through it here.
The ideal way to check what’s going on would be if you can clear the console before you toggle the laser on, turn on “Show All”, and then Fire laser and frame, so we can see what happens when that would cause the issue.
Thanks, and sorry for the snippy tone - there are still other bugs we’re chasing down with more or less success. Thank you for giving us something that makes it easy to find - on both counts.
Ok I think I’m going to need a bit more of a step by step direction on the fire button bug you’re encountering.
From what I could test, it behaves exactly the same as in 1.7 - it will only pass through the power during framing if you shift-click the frame button.
Otherwise it will use the power set in the device settings - if the toggle for it is enabled.
On a fresh start the fire button works as it always has. I notices the issue twice before but didn’t really pay much attention to it. This is the third time this has happen on 2.0 and this time I investigated what was actually happening. I run two of the same model lasers at the same time only i run my main laser on 2.0 and the other 1.7 for now on the same computer. Don’t know if that has anything to do with the issue at this point, I’m still trying to figure out what causes it. I will swap LB versions with the lasers and see what it get later today. When I can reproduce issue on purpose I’ll make you aware of the conditions.
Also a question, are files created between version suppose to be backward compatible? I saved my work last night to reboot 2.0 and opened file of my 1.7 laser. Attached messages were displayed.
Ok thanks - do let me know about the steps when you can.
Regarding the file compatibility: the star shape is a new primitive in 2.0 - if your design file has it, that won’t work in 1.7, unfortunately. It’s not very well written up.
2.0 will read the 1.7 files, but 1.7 will fail on newer features (i.e. star or double star shapes).
Ha! I’m use to it and understand. I’m a broadcast/studio/field production that can fix things engineer of 40 yrs and deal with producers that expect things to work the way they want and not how it works. On top of that hardware manufactures that release hardware that just doesn’t work as shown at the NAB or demo on their web site and they get a bit snooty when I say it wasn’t shown to us with these bugs or lack of capabilities. That’s a pisser when I must sell the idea to buy new equipment and it comes in and doesn’t do all it was supposed to.
I know LB 2 is a beta and don’t expect it not to be buggy which is why I’m running 1.7 on the other laser for any production work. I’m sure you all have your plate full issues to hash out and I’m actually happy to try and help make 2.0 released with as few bugs as possible. Beta usually gets handed out to the few for testing and not the masses to overwhelm you guys with bumps and hiccups.
Ooooh woops, my bad for that assumption. I’ve been laser-focused on Gcode machines since that was the highest level of MillMage/LightBurn crossover there was to deal with for me.
I will double check why this isn’t updating as it should on Ruida.
I figured Fire button issue out. Select an object and frame it. While its framing with laser visibly on go to move tab and turn Fire to on, red position. At this point on and off are reversed. Do the same step again only turn laser off and all is normal again. I know, just don’t do that… At least for now i don’t have save my work to reboot LB to get this function to work correctly.
Hope this helps.
Another thing while figuring this one out, I’m guessing its part of the same issue as above. The power setting on the fire button works strange. Move value up or down, .25 increments with the fire button red, laser on, for every .25 up or down the laser turn on an off. I set the power to 2.0% Fire on and go up to 2.5% the fire button reverses when selected, on is off. Again with Fire button red or on, laser is actually off run power back to 2.0% or up to 3.0% and press the Fire button, condition is normal again.
That’s all I’ve got. If you need a log created while I tinker i can do that if you cant recreate the conditions yourself.
That is now expected and as designed. The shown position is always updated from what the device sends us. We won’t assume the laser moved somewhere simply because we told it to anymore. Especially on Grbl devices with incorrectly set firmware this can be dangerous…
Alright, so I think the first problem where you toggle the Fire button while the machine is still moving is a bit harder to fix - it’s logged but it may not be fixed in the first patch release.
The second one about the odd behavior while the Fire button is on should be fixed in the next release.
Thanks for you support. I noticed you’re quite busy now that RC9 was dropped as an actual update to 1.7.
Looks like the node bug of leaving an orphan with the undo button was made aware and being fixed. I would had found that one eventually. Other than that I’ve got nothing more. Stay cool…
