Release Candidate 5 of LightBurn 2.0.00 is now available here:
Important Notice on System Compatibility
Starting in 2.0, LightBurn supports only Windows 10 (and higher) or macOS 11 (and higher) operating systems. Linux operating systems are no longer supported.
2.0 will be the final release that supports macOS 11 — subsequent releases will require macOS 12 (and higher).
You will always be able to use the most recent version of LightBurn that is compatible with your operating system and was released within your license’s valid update period. To download an earlier version of LightBurn that is compatible with an outdated operating system, visit our release repository.
This build includes the following updates:
Change Log for LightBurn-v2.0.00-RC-5
Changes Since LightBurn-v2.0.00-RC-4
Existing Feature Updates
Emblaser Pro updates (#821)
Change Emblaser3 to use new camera lens calibration
Added grayscale support for BSL devices (#826)
UI pass #2 (DEV-880)
Save background size / shift values with camera settings
Added support for ‘week of year’ in ISO-8061 (#838)
Remember galvo rotary jog step between runs
Taper Warp now supports inches (#842)
Finally got the language / system locale to play nice together (#843)
Finally got the language / system locale to play nice together
All numeric labels now use locale settings
Added ability to move layers up/down with hotkeys (#847)
Bug Fixes
Fixed directory creation issue on MacOS.
Fix initilization of device units in device settings
Fixing XTool protocol homing and jogging behavior.
Fixing the ToolModel to return WPOS instead of MPOS in LightBurn
Prevent app hang on close when network Ruida device selected
Prevent app hang on open/close projects when network Ruida device selected
Updated drag string behavior to show both line ends correctly (#831)
Fixed speed output units in Variable Text Cut Setting mode (#832)
Remove Qt version check from Connection_UDP::GetMaxPacketSize
HSpace value messed up alignment (#833)
Baking variable text didn’t update shape bounds
Don’t render shapes with zero prims as a single dot
Trace shouldn’t crash if given an empty image (#836)
QT bug on importing SVG hex-based colors (#839)
Correctly handle comma vs period numeric separator for different locales
Patterned vector fills could crash the AI file importer (#848)
Miscellaneous
Implement proper tooltips for all image mode controls (#829)
Warn user if rotary config loaded while using Ruida device (#825)
@Rick Hello I just tested the export of camera settings with the offset set. I changed the offset to something else, and then imported the camera settings. The offset was not restored. I was told the work was added to the 2.0 release, I did not know if it was completed and deployed as of yet. Thank you Brian
Thank you. I see @LightBurn has responded to the fider post you shared.
From Oz: The offset you highlighted above is the laser pointer offset, IE the red-dot offset. It has nothing to do with the camera. The “X Shift” and “Y Shift” values in the “Adjust” tab of the camera window move the camera image around on the workspace, and are the ones saved and restored with the camera settings.
@Rick I responded to the ticket, as I have learned this method years ago, from watching many others set the offset for their camera this way, in turn turning the camera into the red dot laser pointer. If the x and y shift is supposed to work just like offset and get saved with the camera export, I will try it. All I know is once I calibrate the offset with my camera calibration, they are alligned perfectly and I never have to recalibrate for that material thickness. I will try to see if the x and y work like I have been using the offset, because right now, my calibrations with offset is 100% accurate evey time.
The Background Shift values do get saved to the .lbcm on export now.
You likely have a laser with an adjustable bed. On lasers where you change the height of the laserhead instead, using different material thicknesses throws off the alignment because the distance between material surface and camera changes.
@Aaron.F Agreed, yes the distance between the bed and camera can change. This is why a workaround (so you do not have to have many calibrations based on material thickness) is keeping the distance between the camera and the bed the same, so with thicker materials i can move the bed down, to maintain the same distance which then keeps the calibration for the same distance. - Hope that makes sense.
Hello, the x-shift and y-shift get saved, I tested it yesterday, and was told from the support that they get exported as part of the camera calibration. This is how I save them by calibration.
Not yet. The Lightburn team is still working on resolving some issues during development. The software can connect to the G9, but some features are currently incomplete. We recommend using the free SGD Laser software for now.
