Problem with Z offset parameter

The problem is this. I have a layer (a single color) where I have various objects, at this level I have assigned a Z offset to work out of focus (I want to get a thicker incision line).
Start the job, the machine starts, the machine plane moves correctly down, it starts to make the first object, then returns to the initial 0 focus, moves down again and executes the second object, returns to the initial 0, moves downwards and performs the third object, and so on for all the objects.
I would like the plane to lower, run all the objects on the level and then come back into focus. Wouldn’t it be better? Why does it have to move the plan to each object? Work gets very slow …

The reason it works the way it does is that I cannot make assumptions about what you are cutting, or why you are using the offset. You could be using it to clear clamps or hold downs, for example, in which case, leaving the head lowered when moving between cuts could hit a clamp.

I have an option to optimize Z moves coming - it is already working for g-code devices, and being worked on for DSP systems now.

1 Like

Ok, I understand the reasons, it would be very convenient to have an option to choose from in the layer to decide whether to move the axis for each object or to hold it for the whole layer. It can be done? It is essential for customers who want to work out of focus, otherwise the processing becomes very long. Thanks

The current implementation is a global setting for optimizing Z. I could do it per layer, but that assumes that you are using ‘Order by Layer’ which is not a requirement.

Now that I think of it, it would be cool to be able to mark an area in Lightburn that basically tells the laser to not go there when planning a cut strategy. Especially handy when combined with a camera.

I always use the layer order and also all my clients. It would be sufficient to put an option in the layer to specify to the machine not to move the Z between objects that have the same value.

This is hard to do - it would be very easy to create a layout where more than one non-cutting move was required to get around an area like this, and Ruida controllers do not allow more than one non-cutting move in a row within a job. It’s a weird limitation, but it’s there. I might have to try this again, but I tried it for the purpose of producing a manual overscan move, shaped like a square bracket ] and the controller just halted.

Ah, sorry for going so off-topic here. Too bad the Ruida controllers seems to be too limited for this but thanks for replying! Thinking about getting a different lens with a longer focal distance anyway, to prevent the laser head from bumping into stuff :slight_smile: