2.5D Dynamic Safe-Z design questions

[Jorropo]

Hello I want to add a 2.5D Dynamic Safe-Z feature.

The problem I am trying to solve is that my Safe-Z is configured at 22mm even tho most things on the build plate are 1~3mm above Z0 (the build plate is at ~-10mm).

However I am unable to lower Safe-Z at let's say 5mm because my tool changer is 2cm high.

However² the tool changer is on the side of the machine and nearly all moves the machine would never be able to hit it.

The idea to solve this is that along the global Safe-Z setting the user would be able to configure a 2.5D map.

This means in my case I would be able to set Safe-Z to 1mm on most of my build plate except where the tool changer is.

Consider a move from a feeder to the bottom camera unless it is one of the two feeders who's path intersects with the tool changer, they wouldn't have to move up and down as high making the machine faster overall.

Even the two poor side feeders become faster since they no longer have to go straight up and down at a 90° but the motion planner can use a 3D diagonal move as long as the part ends up above the tool changer in time.

Implementation wise I think to use a mm discrete 2D image (stored as an array) of mm float heights.

Interpolation between discrete positions will be conservative (figure out the 4 cornering pixels and take the maximum value out of the four).

Questions I think I have good answers to:

1. Consider a move intersecting a high slender tower, how to find the optimal move which is to sweep by the side rather than climbing completely above it ?

This complexifies path finding and I just wont implement it.

That means my solution will solve XY by going in a straight line just like we already do, but then it will perform 1.5D pathfinding for the Z axis, the algorithm for this is simple and CPU cheap (O(N) where N is the length of the path).

2. Consider a nozzle going parallel to a high wall, how to make sure the part doesn't hit the wall since even though the nozzle misses it ?

I'll make use of the Length & Width package properties to compute the diagonal and extrude all surfaces and edges by the diagonal while doing 1.5D height pathfinding.

This assumes a worst case where the nozzle picked up the part in one corner and it is sticking as far possible

2.1. parts heights ?

This will be handled like dynamic Z today, the nozzle tip position will be assumed to be part's height lower than it really is.

In other words, the code will ensure the bottom of the part is at the Safe-Z not the nozzle tip.

2.2. tolerances ?

As we know reality isn't perfect and as described this feature would always aim to barely touch the highest Z points on the path.

To solve this there will be a margin setting, it will do the same extrusion trick and extrude all surfaces and edges as long as the margin is set to.

3. What about boards and parts on boards ?

The board length, width and rotation settings will be used to make sure the 2.5D map is at least as high as the board's Z position where it is located.

Same for all placed components.

4. What about nozzle clearance ?

The nozzle tip might fit down a tight hole but the nozzle itself becomes bigger in the XY.

This exact problem is already encountered by non planar (2.5D) 3D printer slicing.

The usual solution is to measure an angle between the nozzle tip and the part of the piece of the head with the lowest angle, this is easily done with a ruler and a protractor.

Then the software models nozzle intersection as a cône who's tip is where the nozzle tip is.

It requires doing a bit of trig when adding the parts height (or not but that means we will be a bit more conservative than we need to).

Questions I do not have answers to:

A. How to let users configure the map ?

My first idea is to let users upload Type 0 PNG height maps with minimum and maximum height values.

You could generate it from a CAD software but that doesn't sound easy to figure out and I don't know if there is a standard way to embed the dynamic range of the height map in a physical unit inside a PNG.

My second idea is to let people upload USD files, they are meant for being interchangeable and all files contain* physical representation which makes it trivial to convert it to mm grid. But that means we need to do isometric projection along Z ourself. This is some amount of code but it is pure (thus easily testable) and would be completely isolated from the rest of the codebase except from its top most functions API so I think the risk is low.
I have no idea how good USD's support is in CAD suites tho but I don't think this is awful if it missing because this isn't something you have to do often and if everything else fails as long as you can load your model and scale it into blender you could export a compatible USD.

My knowledge of MCAD is extremely low, please pitch in if there is a well known 3D exchange format I don't know about.

*if it is absent a default « meters per unit » of 0.01 (CM) is assumed.

My last idea is to let people specify « build plates obstructions » in the machine's config, theses would be 3D rectangles that can be rotated, it sounds painful for something not rectangle shape and hard to keep in sync as you edit your machine.

B. How to handle multiple nozzle heads ?

On the lumenpnp I have the head have two nozzles sharing the Z axis (classic single actuator, when one goes down the other one goes up).

Currently this is safe because Safe-Z more or less equalizes the two heads heights.

But consider a move that would cause nozzle 1 to go down (let's say a pick) and this cause nozzle 2 to be very high up, if nozzle 2 moves to a safe-z far away it will do an efficient shallow descent, which means nozzle 1 will do a shallow climb and it's not unlikely nozzle 1 will hit something.

I think the best solution is to have the head class takes care of nozzle Safe-Z moves (nozzles class would forward safe-z pathfinding to the head class) which would use the nozzle tip offsets to compute the line XY line drawn by all the nozzles on the head and make sure all of them maintain their respective safe-z.

[Toby Dickenson]

Hi Jorropo, thanks for starting the design discussion here

On Fri, 15 Aug 2025 at 23:01, Jorropo <jorro...@gmail.com> wrote:

Hello I want to add a 2.5D Dynamic Safe-Z feature.

The problem I am trying to solve is that my Safe-Z is configured at 22mm even tho most things on the build plate are 1~3mm above Z0 (the build plate is at ~-10mm). 

FYI, the conventional openpnp z axis Z=0 is with the nozzles balanced and retracted. It looks like you have Z=0 in the middle of your working volume. Thats not necessarily a problem, but it is unconventional. More details here:  https://github.com/openpnp/openpnp/wiki/Machine-Axes

Consider a move from a feeder to the bottom camera unless it is one of the two feeders who's path intersects with the tool changer, they wouldn't have to move up and down as high making the machine faster overall.

That sounds like a reasonable requirement.

 

I'll make use of the Length & Width package properties to compute the diagonal and extrude all surfaces and edges by the diagonal while doing 1.5D height pathfinding.

I fear you are heading towards a complicated design, and you raise some valid questions for which I dont know the answer. Maybe I misunderstand, but could this be as simple as:

* Find the the tallest obstacle on *this* x/y move

* Add that to the SafeZ limit, the same way we do for dynamic safeZ. Carrying a tall part has the same effect as crossing a tall obstacle.

"1.5D height pathfinding" and "use a 3D diagonal move" makes it sound like you are planning a terrain-hugging motion, which would be unnecessarily complicated and unnecessarily different from what we have today. That would need to interact with motion blending that can generate optimised rounded motion through the safe-z volume, and the subordinate motion system which gradually rotates parts during long moves. That gets above my level of understanding of the openpnp motion system.

Toby

[Jorropo]

> "1.5D height pathfinding" and "use a 3D diagonal move" makes it sound like you are planning a terrain-hugging motion, which would be unnecessarily complicated and unnecessarily different from what we have today. That would need to interact with motion blending that can generate optimised rounded motion through the safe-z volume, and the subordinate motion system which gradually rotates parts during long moves. That gets above my level of understanding of the openpnp motion system.

Terrain hugging motion perfectly describes what I have in mind.

This is better than the ⋂ motion because as you know limits are said per axis so the head can travel faster in absolute terms if we ask it to move all 3 axes simultaneously.

Consider that within one path segment if the Z travel time is <= than X's or Y's we moved Z without incurring any time cost.

Also the total paths will be shorter.

I don't think we need to integrate with the motion planner and find optimal moves as long as the terrain hugging moves are better than the alternative.

I want to try generating a sequence of Z segments and let the motion planner try its best.

I think it should give results close to optimal if the 1.5D path finding code generate XY & >=Z moves allowing the motion planner to do uncoordinated turns on it's own.

>  * Find the the tallest obstacle on *this* x/y move
> * Add that to the SafeZ limit, the same way we do for dynamic safeZ. Carrying a tall part has the same effect as crossing a tall obstacle.

Sure this is a better solution than what we have currently and nothing prevents sending a second PR implementing terrain hugging later.

We still need to do the face extrusion trick and nozzle clearance angle altho it can be limited to the XY plane because parts overhang the nozzle.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/openpnp/CAH35urehg-Ws4L7qJDP%3D7R5JSSZecMu9iaSrMmOhTzOiK2Utvw%40mail.gmail.com.

[Jan]

Hi Toby! Hi Jorropo!


On August 18, 2025 5:31:11 PM GMT+02:00, Toby Dickenson <to...@tarind.com> wrote:
[...]

>I fear you are heading towards a complicated design, and you raise some
>valid questions for which I dont know the answer. Maybe I misunderstand,
>but could this be as simple as:
>* Find the the tallest obstacle on *this* x/y move
>* Add that to the SafeZ limit, the same way we do for dynamic safeZ.

>Carrying a tall part has *the same effect* as crossing a tall obstacle.
>
Extending Safe-Z like that is probably not ideal because Safe-Z assumes the same Z everywhere, which means the nozzle is first raised above the eg. toolchangen bevor moving there. The proposed solution whould raise to Safe-Z first and then to the toolchangen while moving there provinding a shorter move.
Detecting this situations and splitting the move if required could be done before adding it to the motion queue. This would be before motion blending and hence not effect it.
It's just the question how to detect the required z there. Part height is already applied in case of Safe-Z at that place and placement information might not be available anymore.

Jan

[Toby Dickenson]

Hi Jan,

MoveableUtils.moveToLocationAtSafeZ is where dynamic safe z accounting happens today. That function does know the start and end points for the move, so it could apply a further reduction for any intersecting obstacles. That looks very achievable without any terrain-hugging behavior. Maybe the splitting could be done there too.

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/openpnp/04C8DAA8-473D-4535-B3FF-D4A7F76E3DA9%40googlemail.com.

[Jan]

Hi Toby!
That sounds like a nice and clean implementation. However, as we're changing the definition of Safe-Z, we need to make sure that we cover all cases.
Jan