Where lightburn show actual position of laser module?

[abatinxs (Mikolaj)]

I cant find option to show where actualy is laser head. In LaserGRBL this function is default (moving cross) in lightburn I cant find this option.

[Woodcraft (John Matteson)]

Please see:

Position Laser - LightBurn Documentation

[abatinxs (Mikolaj)]

Thank you, but that’s not what I wanted. The solution provided makes the laser head follow the mouse, it appears where I clicked the mouse on the work area. What I want is for me to see a marker on the work area where the laser is currently located. If the laser head moves, these movements are not visible on the work area. Best regards!

[thelmuth (Tim Helmuth)]

In the laser window, click show last position.

[abatinxs (Mikolaj)]

Thanks! This option will show me live position tracking of laser head? Or only last position? I looking for option to show me always, where is laser head. Best regards!!!

[thelmuth (Tim Helmuth)]

@abatinxs

will show me live position tracking of laser head? Or only last position?

Not sure, try it and see. I don’t think it reports live though.

[ednisley]

@abatinxs

looking for option to show me always, where is laser head

Because the controller does not provide a stream of data detailing the laser head’s position, LightBurn cannot report where it is while it’s in motion without sending a specific request.

From GRBL’s doc on Status Reporting:

Developers can use this data to provide an on-screen position digital-read-out (DRO) for the user and/or to show the user a 3D position in a virtual workspace. We recommend querying Grbl for a ? real-time status report at no more than 5Hz. 10Hz may be possible, but at some point, there are diminishing returns and you are taxing Grbl’s CPU more by asking it to generate and send a lot of position data.

Remember that lasers move much faster than CNC spindles, so interrupting the command flow with position queries will affect the controller’s ability to control the smooth motion required for good cutting & engraving.

Because different controllers have different internal buffer sizes, with some capable of absorbing the entire G-Code program, LightBurn cannot predict where the laser head will be at any time.

Basically, just watch the laser move to know where it is!

[Woodcraft (John Matteson)]

Here’s a different post explaining the rationale for the absence of a live view.

Real View like Preview on real laser track?

Is Real View on real laser track possible like in Preview? In the kind of LaserGRBL? So we can see what is done and what is to do. Or is it available and I have not seen it. Regards Thomas

Real View like Preview on real laser track?

LightBurn will not provide features that could be considered to facilitate any type of Remote Monitoring. It is just not safe and we need to sleep at night. On a GCode controller, you see progress on the computer because the job is being streamed on the fly as it is run. With a DSP controller, the job is sent to the controller in one go, and the controller runs the job. Sometimes the controller starts running the job before the send it complete, but any ‘progress’ you see at the PC is the progr…

[abatinxs (Mikolaj)]

Big thanks thelmuth and for everyone. Lightburn has no live indicator and you have to live with it.

[LSS (Samuli Samuelsson)]

@abatinxs

Lightburn has no live indicator and you have to live with it.

The reason why LB doesn’t have that feature is actually twofold.
One is the previously mentioned safety -or more precisely lack of it- side of that feature (which I for one agree with completely) and outside unsupervised automation, that feature doesn’t have many uses.
The other is the huge strain a system like that presents to the computational side of things.

If You really, really want/need one for some reason, just install XY(Z) position indicators onto Your rails (direct closed loop operation).

Google Search

Or, if maximum accuracy isn’t required (and it usually isn’t with “touchless” machining), stepper motors with an encoder or position feedback windings (indirect closed loop operation).

If Your controller doesn’t support such a feature, You’ll obviously need a controller that does -or simply because LB won’t be able to use that data- route the data onto a different system to be post-processed.

Marrying the feed from that “different system” onto LB might prove a challenge, but usually in similar cases in the past, the position data was overlaid onto a copy of whatever task the (C)NC XY(Z) movement was performing, and used only(/mainly) for observational and monitoring purposes.

Without closed loop feedback, the position request @ednisley talked about will only tell where the head should be, not where it actually is.
For general monitoring that may be sufficient, for controlling the job, it really isn’t.

AFAIK using the direct or indirect position feedback is still somewhat rare unless there’s a very good reason to do so, even if the system is equipped with one.

When using closed loop operation, the point of diminishing returns approach very fast, especially with fast moving, hard accelerating and decelerating machines like lasers or multiaxis robot arms.
And obviously only work in systems that run the program line by line, not the whole program from start to end.

The feedbacks can be looked as an additional axes, and adding one will pretty much double the computational requirements if the same performance is required.
So XY motion with closed loop feedback requires ~8 times the computational power the plain XY motion does.

If in use, there’s also the issue of what to do with that position feedback data when it differs from what the position is supposed to be.
It’s somewhat hard to adjust the movement data on the fly without the adjustment showing as a flaw in the product, and halting the process midway because the position is a step off is obviously among the last thing anyone wants to do.

Regards,
Sam