Why is x/y position in thousandths but move-to only in hundredths?
I am struggling to follow you here.
Please use a screen capture tool to share some context.
I’m guessing you’re working in inches.
Lightburn may ultimately ignore the thousandths digit, but having no idea how that is handled makes it an unknown to translate to accurate move coordinates. Should we round or truncate? Really, the interface should be made to match.
1 Like
Actually it makes even less sense - the move panel, which only accepts hundredths, reports position in thousandths.
I would consider the use of hundredths a bug.
So no follow-up?
Bugs like this are everywhere in LB and reflect on the quality of implementation. It is pretty shameful that they exist, much less that no one follows up when they are pointed out.
Why is this being ignored?
I am personally escalating this request and every other request you’ve made.
I apologize if you’re feeling ignored - that’s on me.
Are you suggesting that you need to move the position of your laser to a precision of better than 1/100th of a mm? The data entry boxes scale to accommodate the largest number they’ll fit. If we make them accept 3 decimals instead of 2, it takes more screen space for the window, so this felt like a reasonable compromise.
If you’ve never heard the term “demandopotomus” it’d be worth you looking it up. Your tone comes across like a petulant child, which is likely why you’re being engaged with less and less.
The bugs are being logged, investigated, and if determined to be real, they’ll be fixed. We have 5 devs, one of whom is in the middle of an intercontinental move, and we have a number of other users aside from yourself, in addition to prior commitments to vendors and other partners.
You’re not being ignored, or targeted, but you are being a pain in the a$$. Please attempt to be civil here - we’re trying to work with you, and you’ve raised some valid issues, but if you can’t behave you’ll be muted or banned. Having a concern doesn’t give you the right to berate my staff or other users.
3 Likes
I am simply suggesting that the units for position should match the units for movement. If movement to thousandths doesn’t make sense, then position should not be described in thousandths. It should not be up to the user to decide whether to round or truncate when reproducing movement to coordinates.
My other concerns largely revolve around 1. regard for basic OS / domain norms established over the past 40 years and 2. the existence of crashes (which should not exist, ever, at all). What you describe as being a “pain in the a$$” (apparently “a$$” makes it all ok?) is the consequence of relegating your product support to a community forum where the first responders are apologists defending the existence of every bug or design flaw. If you want a more civil and organized exchange, set up a proper bug tracker where the issues can be dealt with in a civilized fashion appropriate to the domain, and where users can see the resolution status and know that the bugs are being worked on. The current result is the product of choices that you have made about how to organize the support and bug reporting pipeline.
I have no animosity regarding the existence of design flaws. They are inevitable in the process of software design. I have animosity toward those who respond to the attempt to engage design flaws by implying lack of education, knowledge, experience, etc. The goal should be to find the terms that will create the best, most usable, most effective software possible. This happens when the software anticipates how users use it. I am trying to address how users use it, and how 40+ years of software development have developed conventions that address how users use it. Lightburn should respect these conventions, particularly when they are OS norms.
I don’t always have control over these things, unfortunately. I’m not sure what “OS norms” you’re referring to with regard to the precision issue, but one of your others, the copy/paste shortcut bug, is likely an interaction with the framework we use for cross platform development (Qt). The same application level code is built for Windows, MacOS, and Linux, but Qt subverts a few things under the hood and doesn’t always get it right, and getting around it has occasionally proven troublesome.
Regarding bug reporting, the best way to ensure bugs are seen and logged is to email them to support@lightburnsoftware.com. By using our community forum, you engage the community by choice.
On which hardware? On a Ruida, movement is specified in microns. On a galvo, it’s in bits, where 16 bits is the addressable range of the field, and on GCode devices, it’s floating point numbers that ultimately get converted to steps, at whatever stepping resolution the hardware allows.
Also, the precision of placement of artwork in the design needn’t match the precision of movement of the hardware, either - People often work on designs sized for one project or machine, then scale for a different one. Earlier versions of LightBurn used hundredths for the position accuracy and it was changed to thousandths because a number of users made a case for the additional precision.
Well when you changed it to thousandths you forgot to update the move units. Move and position should share the same units. I can’t imagine any argument whatsoever otherwise. When you move, you move to a position. Having a position that you can’t move to is definitively a bug.
This is not about hardware. This is about two interfaces in Lightburn. You cannot paste position into movement to move there. That should be considered a bug.
Your clarification actually makes it clear that this is a serious bug not just an interface fail. If the controller can position as accurately as thousandths (or more) but the move interface can’t, then moving to a rounded/truncated position via the move interface won’t end up at the position of the actual element. That is a serious problem.
Other norms that are broken that come to mind offhand include:
- box selection does not consistently include the same elements and does not match other programs like illustrator in how it selects items
- shift click does not deselect an item when selected
- layer default handling (we can discuss that on the other thread, which I plan to catch up with today)
There are many more. I will have to start making a list.