Positive Z, and maven test run machine setup

[vespaman]

Hi Guys, 

While doing further testing on the multi bottom vision stuff, I have realized that I had previously misunderstood some results regarding Z/SafeZ/Component height etc. By some freak accident it seemed to work just fine earlier, I still do not know how that was possible, but obviously I had all setting aligned for success, by accident.

So, now that I (think I) know better, I need to take care about Z not being adjusted for component height when going to camera pit. This is needed since both/all nozzles needs to stay in the same Z position regardless of the component height, so there's no Z movement enforced. Most machines can only have same Z with safeZ set to the position of Z home afaik.

Easy, I thought first; just test against movements above safeZ. Then I realized there might be machines out there that has a positive Z movement (even though this is strongly advised against). The test stuff seems to confirm this; I get a positive Z target adjustment of the test component. 

So now, my idea is to check if the target Z-move will not cross 0 (in either direction), and if it tries to - just cap the Z at zero or leave Z where it is. But the test machine indicates that also this is not easy, since it has a SafeZ at exactly 0. So there's nothing that gives away if this machine has a positive of negative Z, which makes it hard to pass the test with this methodology.

So first:
Just to rule out that I have not misunderstood the code I am using, I'd like to verify that the test setup actually does include a machine with positive nozzle movement.

I guess the machine settings is the ones found in resources/config/BasicJobTest/machine.xml regardless of test(?), this is a very basic machine, and I can't make out if it will have a positive or negative Z. 

Second:

There are a lot of machines and I'd like to make sure I am not oversimplifying this - can I indeed just use this kind of methodology, or is this plain wrong? Is there a better way that I am not seeing?

While writing this, an uglier solution comes to my mind; after pick, simple hinder any Z movement when going to the camera pit (and once in the pit), by looking at some "global_displacement_enable" variable. Maybe this is better than trying to be too smart about it?

 - Micael

[Jan]

Hi Micael!
I'm not entirely sure I understand your problem.
First, OpenPnP relays on a right-handed coordinate system which means
that the Z axis is pointing upwards. This means, that PCB-Z is lower
then Safe-Z. However, experts might find ways to configure an ugly
machine the other way around... Most locations are addresses using
preconfigured Z values (pick location, static safe-Z), others use simple
math to calculate the Z to use using a preconfigured location and
component height (dynamic safe-z, bottom vision, place location).
You're right, it is strongly recommended to configure Safe-Z <= 0 and
PCB-Z < Safe-Z for a very simple reason: OpenPnP treats uninitialized
locations as Z = 0. So it is just safe that Z == 0 is within Safe-Z.
To my knowledge, there is nothing that prevents OpenPnP from using
positive Z values. If you have e.g. a large component and your bottom
vision camera Z at 0, OpenPnP will move to the camera with a positive Z
given by the height of the component to align its bottom with the camera Z.
You may specify limits for each axes. However, for cam style setups (as
with your CHM-T) this will not help as it can not be applied to
individual nozzle Z axes, only to the cam axis, that drives them. If you
try to move one nozzle up, you'll automatically move the other down.

Jan

> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/
> openpnp/2b36bd93-ba4b-45d8-a75b-fa90de62da32n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/2b36bd93-ba4b-45d8-a75b-
> fa90de62da32n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

The way multi bottom vision works is to have both nozzles at the same level, when arriving to the camera pit. This is not happening in the single bottom vision, since the first nozzle will be adjusted to the height of the component on the nozzle tip, when it travels to the pit. This means that the second nozzle in a 2 nozzle machine generally will be lowered the same height as the component is lifted on the fist nozzle.

I need to find the best way to cap this, with it A) still going through the test (where first question above is, if it is actually a positive Z setup), and B) not causing issues in the different system models that is out there. I'm looking for the logic behind doing the cap or not.

I would prefer if this could be automatic (the "don't pass 0" test or similar), but then I can't see how my code would pass the the test machine setup (without me changing the test, which I'd prefer not to do (since I can't really see the consequences of it)). Adding a manual setup for this would be easy, of course, but not so intuitive perhaps. 

 -  Micael

[Toby Dickenson]

The default factory configuration on a lumenpnp machine is to have Z=0 just below the pcb surface. This is quite unconventional of course, but there are lots of machines out there running this set up.

Toby

--
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/8b7af5b0-1e33-43c4-91d3-51beedbd2b97n%40googlegroups.com.

[vespaman]

The default factory configuration on a lumenpnp machine is to have Z=0 just below the pcb surface. This is quite unconventional of course, but there are lots of machines out there running this set up.

Interesting! 

So, is Z home with a positive value?  
I suppose, in this case, one could conclude that, the current (starting-) position would be positive, yet lower than safeZ, and if the target Z is above safeZ, we could cap it at safeZ. This conclusion would also be true even if it has a negative normal (negative) Z, I think.

But the test machine, does not reveal any such information afaict.

  - Micae

[Mike Menci]

Open PnP - see manual : https://github.com/openpnp/openpnp/wiki/Machine-Axes

[Toby Dickenson]

Hi Micael,

I have read the rest of this thread now :-)

Easy, I thought first; just test against movements above safeZ.

This is where I got lost. Can you explain what this "test" is for please

[vespaman]

Hi Toby,

If the machine is setup to use multiple bottom vision cameras, there are some prerequisites; disable dynamic Z & set safeZ at Z home. Once this is done, during a run; After all nozzles has picked their components, they will all be at safeZ, which what we want/need.

But:- when head sets off to camera pit, current single bottom vision camera solution will adjust Z for the component height. 

The main objective is to find a way to know if the targeted Z move will go for "above safeZ" (by "above", I mean physically above). Since the machine may have a positive Z, we need to take this into consideration. 

We need to know this, since we cannot allow this, since it will (on a cam machine) result in the second nozzle being pushed down (and on a see-saw machine, the first nozzle will also go high) - i.e. nozzles will not be on the same level, which in turn means that we need to do a physical move between first and second nozzles (which we do not want). If we would simply ignore the Z diff (not doing a physical move), the second component size will be too large according to bottomvision, since it expects it to be at a specific Z. What I am trying say, is that they both need to stay in the Z level, not adjusting for component height (esp on a cam machine, since there's no way for openpnp to know the actual Z on a normal cam machine, once it goes above safeZ).

However, when I earlier today tried the above (testing against safeZ), the compositing test failed, since there's not enough information in the test machine, to conclude if the test machine is setup as a machine with positive or negative Z. Or at least, this is my take on it. safeZ is simply zero on the test machine. But since the adjustment is positive from the starting Z, I guess the test machine actually acts like a positive Z machine. (I did therefore not yet test this on my physical (normal negative Z) machine)

IF an automatic detection cannot be done with enough degree of certainty, a fall back would be to have a setting like "enable multi bottomvision cameras" and if this is true, always cap Z at safeZ when machine is heading to camera pit. Or maybe this could be implicitly found out by checking if there are multiple up-looking cameras. But I'm not sure I like that, since there might be reasons for someone to try out multiple cameras esp during machine setup. 

And:- maybe even if the test would work - I'd like to hear if there's any known issues with this, that I am no seeing (some machine setup that has some even weirder model than I can envision etc etc). 

 - Micael

[Jan]

Hi Micael!
I think I'm starting to understand where you'd like to go.
Ok, assuming the goal is to have bottom vision with two cameras and two
nozzles without motion in between.
I'd start to instruct the machine to move with as many axes as possible
to the first bottom vision location. Using subordinate motion this can
be easily archived and pre-rotation does the same for all nozzle
rotational axis. With that in place, you'll see just a small movement in
XY (given by the distance between cameras compared to the distance
between nozzles) and a significant movement in Z (depending on the part
height and camera Z). That is because bottom vision moves the bottom
side of the part on the nozzle to the camera location.
As we discussed earlier, you could calculate a new location (XY) that
spreads the distance between camera and nozzle such, that without
additional motion, both have the same offset. If bottom vision results
are corrected for this offset, you could skip the XY-movement between
the two.
For the Z location the situation is a little bit more difficult: on a
generic machine you'd have to assume, that each axis is free to move
individually. With the above you'd already be done. On a machine with
shared Z axis like cam-style, you could calculate a location (Z) in
which both nozzles are out of focus by the same amount. If you now
verify that this new location is within Safe-Z for both nozzles, you'd
be free to use it. If it is not, you're not allowed to move there
(directly). (moveToAtSafeZ() will handle that for you.)
To me, you need to always make sure not to violating Safe-Z...

Jan

> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/8b7af5b0-1e33-43c4-91d3-51beedbd2b97n%40googlegroups.com
> <https://groups.google.com/d/msgid/
> openpnp/8b7af5b0-1e33-43c4-91d3-51beedbd2b97n%40googlegroups.com?
> utm_medium=email&utm_source=footer>.

[vespaman]

Hi Jan,

OK, sorry, I thought you had read my up vision camera thread. If you do, you'll find that I have already accomplished most of the work.

I think I'm starting to understand where you'd like to go.
Ok, assuming the goal is to have bottom vision with two cameras and two
nozzles without motion in between.
I'd start to instruct the machine to move with as many axes as possible
to the first bottom vision location. Using subordinate motion this can
be easily archived and pre-rotation does the same for all nozzle
rotational axis. With that in place, you'll see just a small movement in
XY (given by the distance between cameras compared to the distance
between nozzles) and a significant movement in Z (depending on the part
height and camera Z). That is because bottom vision moves the bottom
side of the part on the nozzle to the camera location.
As we discussed earlier, you could calculate a new location (XY) that
spreads the distance between camera and nozzle such, that without
additional motion, both have the same offset. If bottom vision results
are corrected for this offset, you could skip the XY-movement between
the two.

All this is already in place, and was also in place in the short youtube video. (And what I am testing now)

 

For the Z location the situation is a little bit more difficult: on a
generic machine you'd have to assume, that each axis is free to move
individually. With the above you'd already be done. On a machine with
shared Z axis like cam-style, you could calculate a location (Z) in
which both nozzles are out of focus by the same amount.

Well, there's really no 'out of focus', since the camera/lens is/needs to be/ at the appropriate distance to cover the highest expected compents.

 

verify that this new location is within Safe-Z for both nozzles, you'd
be free to use it.

It is, since safeZ is set @home. The nozzles are at their top position.

 

 - Micael

[vespaman]

måndag 27 oktober 2025 kl. 23:13:36 UTC+1 skrev vespaman:

However, when I earlier today tried the above (testing against safeZ), the compositing test failed, since there's not enough information in the test machine, to conclude if the test machine is setup as a machine with positive or negative Z. Or at least, this is my take on it.

I have to correct myself - after thinking about it again; the test machine setup - it is negative Z, nothing else. The safeZ = 0 is what is causing my code to wrongly assume that the machine should cap the Z at safeZ, which in turn gives an size error in vision. (the test code moves the nozzle 'component height' above safeZ, which is what my code is triggering on).

 - Micael

[Toby Dickenson]

On Mon, 27 Oct 2025 at 22:13, vespaman <micael....@gmail.com> wrote:

Hi Toby,

If the machine is setup to use multiple bottom vision cameras, there are some prerequisites; disable dynamic Z & set safeZ at Z home. Once this is done, during a run; After all nozzles has picked their components, they will all be at safeZ, which what we want/need.

It sounds like you are working against some existing openpnp mechanisms here. You want the nozzles to end up at a specific Z, and you have noted that disabling various features will cause it to end up at that Z. But it is almost by coincidence.

Why not simply calculate the right Z. That is, the Z that puts both parts ready for vision. Then command the machine to move to that Z. The SafeZ mechanism can do whatever it wants, but the end position will be as you command.

 

the second component size will be too large according to bottomvision, since it expects it to be at a specific Z.

I think it needs to accommodate that anyway......

Suppose both nozzles carry 0603 resistor, both 0.5mm tall. Nozzles are balanced, and both resistors are at the camera Z focal plane. Perfect.

Next both nozzles carry sot23, both 1mm tall. Nozzles are balanced. Both parts are now 0.5mm closer than the focal plane, and both look larger than they would be.

[vespaman]

Hi Toby

If the machine is setup to use multiple bottom vision cameras, there are some prerequisites; disable dynamic Z & set safeZ at Z home. Once this is done, during a run; After all nozzles has picked their components, they will all be at safeZ, which what we want/need.

It sounds like you are working against some existing openpnp mechanisms here. You want the nozzles to end up at a specific Z, and you have noted that disabling various features will cause it to end up at that Z. But it is almost by coincidence.

Am I really? I would argue that safeZ is one of the cornerstones in the machine. And setting it at home, is how I read the setup documentation, to be the first way to get the machine robust (before doing optimizations with safeZ/Dynamic SafeZ). How can this be coincidence? (I thought I was working with the machine! :-) )

Why not simply calculate the right Z. That is, the Z that puts both parts ready for vision. Then command the machine to move to that Z. The SafeZ mechanism can do whatever it wants, but the end position will be as you command.

Yes, this is a possible solution. But as far as I know, the only "right Z" is Z home. This is only place where all nozzles are leveled, so there's no calculation needed, and this can be accomplished by simply setting safeZ here. This is known code, that works, and there's nothing magic about it, right?

It does, however, introduce one drawback; Dynamic safeZ can no longer be used. Maybe I was a bit self centered here, since I don't use Dynamic safe Z. :-)

So if we want to recover Dynamic safeZ (to and from placement), by inventing this new 'home-z' means the surgical knife needs to cut also into the pick code of OpenPnP, since for a machine model with more than one true Z axis, only the axis, carrying the first nozzle up for vision, will be managed by bottomvision code. The next axis will stay at whatever the pick left it at, meaning bottomvision will be forced to move it between the shots. We therefore (during pick) need to tell it to always lift all components to home-Z. 

It all (similar to both light and parallel vision processing) comes back to the fact that the bottomvision only deals with one nozzle at a time. 

So, we would get some Dynamic safe Z, if we also changed the pick code. Maybe it is worth it? I'm not sure if there's any easy way for each nozzle to individually move to the axis home position, but maybe there is somewhere. If not we do need to do this calculation to find it. This would worry me. :-)

Mind you, in the bottomvision code, we still need to manage (disallow) the Z movement for multiple bottom vision camera setups. But I think maybe it has to be a setup setting after all, especially if we now or later want to change pick code as well. Was hoping for making it all automatic, but, oh well.

 

 

the second component size will be too large according to bottomvision, since it expects it to be at a specific Z.

I think it needs to accommodate that anyway......

That is another story (or the next chapter, if you like), which I have not dealt with yet. But, just to clarify - a cam model machine most of the time stops a nozzle at a specific point, where after the other nozzle starts go down. OpenPnP does not know when this happens, so therefore the nozzles axes must never go above this point. This is the main reason for removing the Z change in the "move to camera pit" code. 

(Having the nozzles at the same levels also generally beneficiary for camera depth of field, since it will only need to span the height of the highest component)

 - Micael

[Jan]

Good morning!
At least I'm loosing track here. Because I still don't understand why
the absolute value of Safe-Z matters at all. So, please let me recap
what we have:
Your goal, Micael - and I closely followed every bit of progress you
posted - is to perform bottom vision on your two-nozzle-shared-Z machine
with two cameras without any motion between the two vision operations.
You solved that on the XY plane by allowing an offset between nozzle and
camera locations. If I understand you correctly, you're now trying to
solve it on the Z plane as well and face issues related to the shared Z
axis configuration or some test code.
First off, Safe-Z is a configurable value that has nothing to do with
homing. Although it is recommended - for safety reasons - to home into
the direction of Safe-Z, there are head designs out there which home
using a homing switch at the bottom. The value of the Safe-Z zone is
configured using the "Safe Zone Height" and "Safe Zone Low" parameters
on the axis.
As you already know, bottom vision usually takes place at the location
of the camera and that includes Z. You also know, that if the camera is
configured with 3d unit-per-pixel or advanced camera calibration, it can
be safely used at other Z values. Event though, to my knowledge, there
is option to configure that, the internal API shall support that. (I had
to modify the setup process to support forcing the cameras Z place -
where bottom vision is performed - to a specific value.)
If you perform bottom vision using your shared-Z-axis machine and using
the established code, you'd move the bottom side of the part on the
first nozzle to it's cameras Z, perform vision, and move the bottom side
of the part on the second nozzle to the other cameras Z. This operation
will almost always involve a Z movement as the preferred camera Z is low
enough to support perfectly focusing any part of any height. As you
don't wont this Z movement, I'd suggest to spread the motion between the
two nozzles bringing both to their cameras with a shall offset in Z. As
the motion is well defined and limited, it can without restriction of
generality be split and the resulting values are still limited and well
defined. Therefore I don't see why you need to cap anything or why the
specific value of Safe-Z is of any concern. It just does not enter the
math here. As Toby pointed out, if the resulting Z values you calculated
spreading the offset between the two nozzles is outside of Safe-Z, the
machine would move the the camera at Safe-Z and then lower the nozzle as
requested.

Jan

> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/07e55925-1996-43fc-9a9b-df3be3ab27f9n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/07e55925-1996-43fc-9a9b-
> df3be3ab27f9n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan]

Hi Micael!
When the machine has picking a part, it moves all nozzles to Safe-Z
(static or dynamic) before continuing. That's what moveToAtSafeZ() does
and that is used everywhere (?). There shall be no need to change
anythere here.
With your two-camera-code, you shall cover the generic solutions of
individual Z axes as well. This can be archived easily using the
subordinate-motion feature. This would automatically place all nozzles
at their cameras Z going via Safe-Z. (and gracefully handle shared z
axes machines by letting the primary Z take precedence.)
In addition you can add code to detects shared-Z-axis machines. On this
machines, the Z coordinate for bottom vision can be a calculated to use
a different value then the camera Z locations. You'd then make sure
bottom vision takes this into account and skips the Z motion when
continuing with the second nozzle.
I'm sure this would pass all tests we currently have.

Jan

On 28.10.2025 08:53, vespaman wrote:
> Hi Toby
>
> If the machine is setup to use multiple bottom vision cameras,
> there are some prerequisites; disable dynamic Z & set safeZ at Z
> home. Once this is done, during a run; After all nozzles has
> picked their components, they will all be at safeZ, which what
> we want/need.
>
>
> It sounds like you are working against some existing openpnp
> mechanisms here. You want the nozzles to end up at a specific Z, and
> you have noted that disabling various features will cause it to end
> up at that Z. But it is almost by coincidence.
>
>
> Am I really? I would argue that safeZ is one of the cornerstones in the
> machine. And setting it at home, is how I read the setup documentation,
> to be the first way to get the machine robust (before doing
> optimizations with safeZ/Dynamic SafeZ). How can this be coincidence? (I

> thought I was working /with/ the machine! :-) )

> Mind you, in the bottomvision code, we /still/ need to manage (disallow)

> the Z movement for multiple bottom vision camera setups. But I think
> maybe it has to be a setup setting after all, especially if we now or
> later want to change pick code as well. Was hoping for making it all
> automatic, but, oh well.
>
> the second component size will be too large according to
> bottomvision, since it expects it to be at a specific Z.
>
>
> I think it needs to accommodate that anyway......
>
>
> That is another story (or the next chapter, if you like), which I have
> not dealt with yet. But, just to clarify - a cam model machine most of
> the time stops a nozzle at a specific point, where after the other
> nozzle starts go down. OpenPnP does not know when this happens, so
> therefore the nozzles axes must never go above this point. This is the
> main reason for removing the Z change in the "move to camera pit" code.
> (Having the nozzles at the same levels also generally beneficiary for
> camera depth of field, since it will only need to span the height of the
> highest component)
>
>
>  - Micael
>

> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/

> openpnp/670120e2-eb1f-4b59-a084-67cf57af2d06n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/670120e2-eb1f-4b59-
> a084-67cf57af2d06n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Toby Dickenson]

On Tue, 28 Oct 2025 at 07:53, vespaman <micael....@gmail.com> wrote:

Hi Toby

If the machine is setup to use multiple bottom vision cameras, there are some prerequisites; disable dynamic Z & set safeZ at Z home. Once this is done, during a run; After all nozzles has picked their components, they will all be at safeZ, which what we want/need.

It sounds like you are working against some existing openpnp mechanisms here. You want the nozzles to end up at a specific Z, and you have noted that disabling various features will cause it to end up at that Z. But it is almost by coincidence.

Am I really? I would argue that safeZ is one of the cornerstones in the machine. And setting it at home, is how I read the setup documentation, to be the first way to get the machine robust (before doing optimizations with safeZ/Dynamic SafeZ). How can this be coincidence? (I thought I was working with the machine! :-) )

Where nozzles share a Z axis, SafeZ is a band, not a specific level. I&S configures that band by asking you to jog the nozzle over the tallest feature on the machine. This defines the edge of the SafeZ band as a position which is safe, but only just safe.

Having a band helps the machine make efficient moves. The 3rd order motion controller can plot a curve that drifts through that band. Lesser motion controllers move diagonally through the band.

You keep writing about "home", which is a sensible concept on a cam machine. But it is an alien concept to my machine where the nozzles are on a common belt and one moves up when the other moves down. My machine obviously passes through the Z=0 level quite frequently but it never stops there. When I press the P button to Park the head comes to rest at the edge of SafeZ, which is significantly unbalanced. There is no home.

 

Why not simply calculate the right Z. That is, the Z that puts both parts ready for vision. Then command the machine to move to that Z. The SafeZ mechanism can do whatever it wants, but the end position will be as you command.

Yes, this is a possible solution. But as far as I know, the only "right Z" is Z home. This is only place where all nozzles are leveled

Suppose one nozzle carries 0603 (0.5mm height) and the other nozzle carries sot23 (1mm height). Maybe the optimal Z is with one nozzle 0.25mm up, the other nozzle 0.25mm down, so that the bottom surface of both parts are at the same Z.

I can understand why that calculation seems unnecessary on a cam machine; just going to HomeZ (cam neutral) is close enough and easier.

But, to share a different perspective, a calculation like that seems unavoidable on a common belt machine where there is no homeZ to fall back on.

I'm not sure on the right approach here. Implementing double-vision support for all the machine configurations supported by openpnp will be hard.

[vespaman]

Hi Jan,

When the machine has picking a part, it moves all nozzles to Safe-Z
(static or dynamic) before continuing. That's what moveToAtSafeZ() does
and that is used everywhere (?). There shall be no need to change
anythere here.

LOL!  This is how I have it now! And the initial question was how to create the logic behind finding positive/negative Z automatically.

But if you read Tobys suggestion to create a new Z level explicitly for camera work, in order to also get Dynamic Z and decouple safeZ from the algorithm, you need to change also in pick code.

If not, at the very least, you might end up needing a camera depth of field twice the height of the max component height. This will most likely cause issues in many setups, including mine.

Let's say we do not set safeZ to its highest position, and perhaps we also have Dynamic safeZ; that would mean that the pick sequence might end with a unaligned cam.

In bottom vision code, we now take it on to move to camera pit. Since we only deal with a nozzle-per nozzle basis, we don't know about any upcoming nozzle/components. Only the one at hand. Right now. We therefore must not allow the bottom vision move, to move on the first or any upcoming nozzles' moves within the pit. 

Any alignment of the cam(s)/nozzles etc must take place during pick. This is why I so far settled for using highest safeZ. It is there, it is working. 

(But at the cost of not optimized Z management as pointed out by Toby)

With your two-camera-code, you shall cover the generic solutions of

I don't see this as a two-camera code. It could be 8 cameras for all I care. Typically one per nozzle.

 - Micael

[vespaman]

tisdag 28 oktober 2025 kl. 10:46:31 UTC+1 skrev to...@tarind.com:

On Tue, 28 Oct 2025 at 07:53, vespaman <micael....@gmail.com> wrote:

Hi Toby

If the machine is setup to use multiple bottom vision cameras, there are some prerequisites; disable dynamic Z & set safeZ at Z home. Once this is done, during a run; After all nozzles has picked their components, they will all be at safeZ, which what we want/need.

It sounds like you are working against some existing openpnp mechanisms here. You want the nozzles to end up at a specific Z, and you have noted that disabling various features will cause it to end up at that Z. But it is almost by coincidence.

Am I really? I would argue that safeZ is one of the cornerstones in the machine. And setting it at home, is how I read the setup documentation, to be the first way to get the machine robust (before doing optimizations with safeZ/Dynamic SafeZ). How can this be coincidence? (I thought I was working with the machine! :-) )

Where nozzles share a Z axis, SafeZ is a band, not a specific level. I&S configures that band by asking you to jog the nozzle over the tallest feature on the machine. This defines the edge of the SafeZ band as a position which is safe, but only just safe.

Yes, this is true. And this is perfect for the machines as we know them now. However, you can just as well skip the band, setting both hi and low to the same value. Even on your machine, you can set it so home is at perfect level, using either M206 or G92 depending on your controller, right? 

So far, I have thought that this is an acceptable tradeoff for getting faster bottom vision. I might be wrong here though, which is why I value the discussion.

Having a band helps the machine make efficient moves. The 3rd order motion controller can plot a curve that drifts through that band. Lesser motion controllers move diagonally through the band.

You keep writing about "home", which is a sensible concept on a cam machine. But it is an alien concept to my machine where the nozzles are on a common belt and one moves up when the other moves down. My machine obviously passes through the Z=0 level quite frequently but it never stops there.

I'm not sure any machine (perhaps with exception of the test "machine") really stops at 0. Mine certainly does not. 

When I press the P button to Park the head comes to rest at the edge of SafeZ, which is significantly unbalanced. There is no home.

OK, well we can call it something else if you like, I'm fine with Park. All (?) machines has a place where the nozzles can be aligned to the same Z. Some machines even has totally free Z control.

Also for me, on my cam machine, the cam was not fully in level before I started with dual cameras. 

 

Why not simply calculate the right Z. That is, the Z that puts both parts ready for vision. Then command the machine to move to that Z. The SafeZ mechanism can do whatever it wants, but the end position will be as you command.

Yes, this is a possible solution. But as far as I know, the only "right Z" is Z home. This is only place where all nozzles are leveled

Suppose one nozzle carries 0603 (0.5mm height) and the other nozzle carries sot23 (1mm height). Maybe the optimal Z is with one nozzle 0.25mm up, the other nozzle 0.25mm down, so that the bottom surface of both parts are at the same Z.

Well, this is what is done today, with the move from pick into bottom vision, and then with the move of the nozzle to the single cam. And as you know, we can't have same optimal bottom surface Z on a dual nozzle machine sharing the same axis, without actually moving the Z axis. It is done today nozzle by nozzle in the bottom vision. I.e. there's logic trying to find the overall best Z taking all nozzles into effect (and I don't think it is needed - the cameras needs to be able to av good enough focus throughout the shortest to the tallest component anyway). 

The only level we can take for granted is when both nozzles are at the same level, as detailed above. 

And - as far as I know, this means either using current safeZ or create a new Z level, maybe a better term would be balancedZ. 

And, the argument for adding balancedZ to the pick code, is to be able to support Dynamic SafeZ, right? (And also fully support 3rd order motion (which might be useful for the flyby/over guys) later on).

 

I can understand why that calculation seems unnecessary on a cam machine; just going to HomeZ (cam neutral) is close enough and easier.

No, this is not the case; we still have the rotational axis, and a gap between the cam and the nozzle wheel.

In fact the cam machines makes it more complicated, since a rotation move on Z means that _one_ nozzle will move down, but the other will mostly never move up as much, once we have reached a specific Z, since it has a physical stop, which OpenPnP does not know about. 

  - Micael

[Jan]

Hi Micael!

On 28.10.2025 11:27, vespaman wrote:
[...]> But if you read Tobys suggestion to create a new Z level

explicitly for
> camera work, in order to also get Dynamic Z and decouple safeZ from the
> algorithm, you need to change also in pick code.
> If not, at the very least, you might end up needing a camera depth of

> field /twice/ the height of the max component height. This will most

> likely cause issues in many setups, including mine.
>

I don't understand why you wont a new "Z level" and what that has to do
with Safe-Z.

> Let's say we do not set safeZ to its highest position, and perhaps we
> also have Dynamic safeZ; that would mean that the pick sequence might
> end with a unaligned cam.

Ok, you're silently mixing generic arguments with your cam specific
design. Safe-Z is defined per nozzle and on a shared Z axis setup, you
might be able to configured it such, that while one nozzle is in Safe-Z
the other is not. I'm not sure if that's allowed and if this would be
detected... And yes, I use dynamic Safe-Z (with 6mm clearance above
Board-Z) and I regularly have an unaligned cam arm. (Tobys 0402 with
0.5mm height is pulled up to 6.5mm above Board-Z after picking leaving
the nozzle slightly lower then the other.) That's no problem at all.
Once all nozzles are in Safe-Z they continue to move (as needed) while
the XY move takes place preparing the nozzle for their next requested Z.
I've setup my bottom vision camera Z the same as the Safe-Z boundary. So
the nozzle is already at the camera Z when reaching the camera.

> In bottom vision code, we now take it on to move to camera pit. Since we
> only deal with a nozzle-per nozzle basis, we don't know about any
> upcoming nozzle/components. Only the one at hand. Right now. We
> therefore must not allow the bottom vision move, to move on the first or
> any upcoming nozzles' moves within the pit.

> /Any alignment of the cam(s)/nozzles etc must take place during
> pick./ This is why I so far settled for using highest safeZ. It is
> there, it is working.

That's what I don't understand either.

Safe-Z is only relevant when moving between pick locations, cameras and
place locations. It does not matter whether you're using static or
dynamic Safe-Z. The only difference is the length of the Z move before
XY motion is allowed to start.
For bottom vision Safe-Z is simply irrelevant as the nozzle is moved to
the camera at/within Safe-Z and then lowered/raised to the required
camera Z location. (On bottom vision retry "Roaming Radius" is used to
allow the nozzle to be moved without going to Safe-Z.) By careful
tuning, you can setup the nozzle Z location for bottom vision to be
within Safe-Z and hence avoid the final Z motion before bottom vision.
If you'd like to do bottom vision with two nozzles using a shared Z
axis geometry and without any motion in between, special handling is
required because you can not have both nozzles at their perfect
locations (we discussed that earlier). You'd need to a) detect the
shared Z axis situation, b) verify that all effected cameras support
bottom vision outside their default Z location (have 3d units per pixel
configured or advanced camera calibration enabled) and c) only then
calculate a new Z value overwriting the default where bottom vision
shall take place. This new Z value is then handled the same ways as the
default: nozzles are in Safe-Z when moving to the cameras and
lowered/raised as needed after cameras have been reached.
You initially asked for positive Z values and how to pass marven tests.
I don't see where the specific value of Z is of relevant here. While the
nozzles are at the cameras Safe-Z restrictions are not applied. So any
value of Z is valid. I also don't see why any test shall fail if you
perform bottom vision at different then the default Z level, suppose the
camera supports that.

Jan

[vespaman]

Hi Guys,

@Jan, your answer just arrived while I was writing this. I hope you understand better after reading this, esp. the part "The typical cam machine problem"!

(If not, let me know!) 

So, after thinking a bit more on this...
1. I think I have given up on the idea of the automatic detection, if not for anything else, but for the test code.
2. Typical cam machines can/should probably be treated differently, since they are the bigger problem



The typical cam machine problem:
Since the current natural behavior of OpenPnP, in referenceBottomVision, is to move nozzle after nozzle into the specified camera focus point, it means that it will want push the nozzle down to meet this focus point, taking the component height into consideration.
On the first nozzle of the shared axle, this is done on the move to the camera pit. When doing this, the other nozzle will be physically capped at it's (unknown) highest point.
Since the point is to not move the head/nozzle between the pictures, this must be hindered in the first place - since introducing an unknown** Z to the second nozzle/shot will not work.
We must not allow one nozzle to be dipped, since this would mean that the other looses its known Z location.



Initially I thought this would be best handled by setting safe Z to its top most setting, and then keep the pick Z level during all bottom vision stages/nozzles.
But, as Toby pointed out, this might give too many downsides on machines with high Z span, (typically 2 nozzles on a common belt).


So, now I'm thinking, (at least for the typical cam-style machine) we need a setting, telling bottomVision code that it should move nozzles Z to a fixed location. Typically the balance point, and keep it there.
Then, safe Z and dynamic safe Z can be what ever they are set to.
This location could possibly be the previous camera focus point, but I have not looked into if this is good/makes sense. Maybe it can somehow also be calculated or found somewhere else.

The benefit of doing it this way, is that we don't have to change anything during pick. And machines that does not really need the fixed balanced point can simply leave things as is.
(The limiting factor on such machines, will be the camera/lens depth of field, but maybe there are more space to create a large enough field on those machines)


The downside with the above solution:

Cam-style machines with > 2 nozzles will still have to set their safeZ to top level, since the bottom vision code only deals with nozzle by nozzle, so the pick will leave the cam at the same level as the bottom vision setting has it.
Other machines with > 2 nozzles than that can create the needed depth of field should be fine.
                                                                                             
                                                                                             
Ideally, as I mentioned before, I think for fly-by and multi cameras, the bottom vision should perhaps not use the nozle-by-nozzle concept, since there's many limitations with it (light, optimal Z, parallel cv etc).
Another enhancement if not going for a special multi-cam/fly-by bottom vision, would be to also make the pick code optionally check and make use of the 'fixed location' Z, solving the remaining issues for >2 nozzle machines.


(**We could also have a setting for topmost physical Z for each nozzle, but I think that don't really serve any purpose, only making the setup much more complex.)



Hopefully my description of the problem and proposed solution makes sense :-)

 -  Micael

[Toby Dickenson]

We must not allow one nozzle to be dipped, since this would mean that the other looses its known Z location.

Aha! That is a key detail I had not appreciated before! If the cam is hugely imbalanced then one nozzle has accurate Z position (because it is pushed down) but the other does not (because it is at an endstop)

A balanced cam gives accurate control over both nozzles? How wide is the band before one nozzle hits its endstop?

[vespaman]

onsdag 29 oktober 2025 kl. 11:03:09 UTC+1 skrev to...@tarind.com:

A balanced cam gives accurate control over both nozzles? How wide is the band before one nozzle hits its endstop?

On my machine, the total gap (adding together both nozzles) is in the order of 0.5mm from the top of my head. Maybe a little bit more. Since the wheels are partly  rubber, it is not super easy to get an exact figure (guessing they have some variations around the circle).

 

[Jan]

Hi Micael!
Many thanks for this update. It now makes things clearer for me.
If I understand you correctly, you're basically suffering from a
hardware related issue, that is very specific to your particular head
design.
May I encourage you to PR what you already have as it provides major
improvements to OpenPnP: you added support to have more then one camera
for bottom vision and support to link them to nozzles to minimize the
travel between bottom vision operations. You already did (or you easily
could) archive your goal to not move at all for head designs with
individual Z axes. (For this heads you can even do bottom vision using
the perfect (camera) Z location.) That alone would - IMHO - be worth
merging.
For head designs with shared Z axes, we need to distinguish between two
kinds, the ones where the nozzles are free to move up and down like
Peters head and the ones where the nozzle motion is limited in one
direction like yours and probably other CAM style designs where the
nozzles are not free to move up while the other is pushed down.
For the first, your goal can be reached by calculating an average Z
position that brings both nozzles slightly out of focus. For today's
lenses and cameras and with the availability of 3d units per pixel
and/or advanced camera calibration, OpenPnP can handle that.
For the second (your CAM style head with limited motion towards
positive Z) I think your goal is still reachable if you provide an
option to configure a specific Z value (either for each nozzle or their
physical Z axis) at which bottom vision shall take place. This would
allow you to specify eg. the balance point for bottom vision. If you'd
configure your camera somewhere in the middle between min max part
height, you'd run bottom vision with about +-2.5mm out of focus max,
which shall still work.
For both shared z axes situations you'd need to add a way to detect or
configured it to be universal and to skip Z motion between bottom vision
operations...

Jan

On 29.10.2025 10:33, vespaman wrote:
> Hi Guys,
>
> @Jan, your answer just arrived while I was writing this. I hope you
> understand better after reading this, esp. the part "The typical cam
> machine problem"!
> (If not, let me know!)
>
> So, after thinking a bit more on this...
> 1. I think I have given up on the idea of the automatic detection, if
> not for anything else, but for the test code.
> 2. Typical cam machines can/should probably be treated differently,
> since they are the bigger problem
>
>
>
> The typical cam machine problem:
> Since the current natural behavior of OpenPnP, in referenceBottomVision,
> is to move nozzle after nozzle into the specified camera focus point, it
> means that it will want push the nozzle down to meet this focus point,
> taking the component height into consideration.
> On the first nozzle of the shared axle, this is done on the move to the
> camera pit. When doing this, the other nozzle will be physically capped
> at it's (unknown) highest point.
> Since the point is to not move the head/nozzle between the pictures,
> this must be hindered in the first place - since introducing an
> unknown** Z to the second nozzle/shot will not work.

> /We must not allow one nozzle to be dipped, since this would mean that
> the other looses its known Z location./

> was working /with/ the machine! :-) )

>
>
> Where nozzles share a Z axis, SafeZ is a band, not a specific
> level. I&S configures that band by asking you to jog the nozzle
> over the tallest feature on the machine. This defines the edge
> of the SafeZ band as a position which is safe, but only just safe.
>
>
> Yes, this is true. And this is perfect for the machines as we know
> them now. However, you can just as well skip the band, setting both
> hi and low to the same value. Even on your machine, you can set it
> so home is at perfect level, using either M206 or G92 depending on
> your controller, right?
>
> So far, I have thought that this is an acceptable tradeoff for
> getting faster bottom vision. I might be wrong here though, which is
> why I value the discussion.
>
>
>
> Having a band helps the machine make efficient moves. The 3rd
> order motion controller can plot a curve that drifts through
> that band. Lesser motion controllers move diagonally through the
> band.
>
> You keep writing about "home", which is a sensible concept on
> a cam machine. But it is an alien concept to my machine
> where the nozzles are on a common belt and one moves up when the
> other moves down. My machine obviously passes through the Z=0

> level quite frequently but it *never* *stops* there.

>
>
> I'm not sure any machine (perhaps with exception of the test
> "machine") really stops at 0. Mine certainly does not.
>
> When I press the P button to Park the head comes to rest at the

> edge of SafeZ, which is significantly unbalanced. *There is no
> home*.

> --
> 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
> <mailto:openpnp+u...@googlegroups.com>.
> To view this discussion visit https://groups.google.com/d/msgid/openpnp/

> a2252974-16ad-4566-97e4-a630aae85d1en%40googlegroups.com <https://
> groups.google.com/d/msgid/openpnp/a2252974-16ad-4566-97e4-
> a630aae85d1en%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Mike Menci]

Solution would be ;
Separate Z drivers (not cam for 2 nozzles but 1 each nozzle )
And focusing camera at Z +25mm (for example) and doing vision for bouth nozzles at this hight ..
just thinking loud…


Magic @iPhone

> Dne 3. nov. 2025 ob 10:03 je oseba 'Jan' via OpenPnP <ope...@googlegroups.com> zapisala:
>
> Hi Micael!

> 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/659eabe0-5456-479b-b06f-a8421edb177e%40googlemail.com.

[vespaman]

Hi Jan,

Many thanks for this update. It now makes things clearer for me.
If I understand you correctly, you're basically suffering from a
hardware related issue, that is very specific to your particular head
design.

I wouldn't really call it "suffering", since I found the solution quite early on. Maybe not the the best, but I never suffered. :-)

The reason for me detailing the problem is that you kept suggesting that this was not a problem - which it is on most (all?) machines with cam-style (like your own machine!). 
And it might also be a (lesser) problem on Peters Head, and the The Lumen style heads, in terms of focus management.

May I encourage you to PR what you already have as it provides major
improvements to OpenPnP: you added support to have more then one camera
for bottom vision and support to link them to nozzles to minimize the
travel between bottom vision operations.

Yes, I will -  I have decided to split it into two or three PR, one for the multi camera support, which is the largest one, and one for the change of bottom vision, dealing with the no-move and Z management.

The pipeline stuff for X/Y and Z could be the third. 

 

You already did (or you easily
could) archive your goal to not move at all for head designs with
individual Z axes. (For this heads you can even do bottom vision using
the perfect (camera) Z location.) That alone would - IMHO - be worth
merging.

In fact, no. 
My solution does not solve individual Z axes that uses dynamic Z, nor does it solve heads that has multiple shared axes.

This is why I pointed out that either A). the pick needs to pick to the proposed balance point (see below), or B). the bottom vision code is changed so that it does all nozzles in one go.

I personally struggle a bit with this, since machines with more nozzles are the ones that would benefit the most of either multiple cameras of fly by (once/if this is accomplished).

But I also realize that it might not be needed just now - we can always fix this later on. It is clear what needs to be done to make those machines to work.

For head designs with shared Z axes, we need to distinguish between two
kinds, the ones where the nozzles are free to move up and down like
Peters head and the ones where the nozzle motion is limited in one
direction like yours and probably other CAM style designs where the
nozzles are not free to move up while the other is pushed down.

 

For the first, your goal can be reached by calculating an average Z
position that brings both nozzles slightly out of focus. For today's
lenses and cameras and with the availability of 3d units per pixel
and/or advanced camera calibration, OpenPnP can handle that.

In reality, this will be the same balance point as below. 

 

For the second (your CAM style head with limited motion towards
positive Z) I think your goal is still reachable if you provide an
option to configure a specific Z value (either for each nozzle or their
physical Z axis) at which bottom vision shall take place.

Yes, this is what I suggested. This can also be useful also for the lumen kind of heads that Toby has, should the field of depth be an issue.

This would
allow you to specify eg. the balance point for bottom vision. If you'd
configure your camera somewhere in the middle between min max part
height, you'd run bottom vision with about +-2.5mm out of focus max,
which shall still work.

I have a field of depth at about 10mm on my machine, so this is not a problem. I.e. I have proper focus on all components that the machine can possibly handle.

 

For both shared z axes situations you'd need to add a way to detect or
configured it to be universal and to skip Z motion between bottom vision
operations...

Yes, this is already done.

I hope I can spend some more time with this during the week, I haven't had any time the last week. I need to find a way to make sure the composite test code into not falling into the problem I saw last week.

In fact,  I need to do a couple of panels this week, so it would be nice if I could have all in place before this, so this could be like a test run.

 - Micael

[vespaman]

Hi Mike,

Solution would be ;
Separate Z drivers (not cam for 2 nozzles but 1 each nozzle )
And focusing camera at Z +25mm (for example) and doing vision for bouth nozzles at this hight ..
just thinking loud…

Having separate Z steppers/drivers would be nice for a couple of reasons (apart from weight perhaps), but the problem presented is the same as with more than 2 shared nozzles.

Tell me, don't you have your head setup as 2x2 (all nozzles in a square)? I'm curious how you are thinking about fly-by with this setup. 2 cameras? Or am I mistaken with your setup? 

 

 - Micael

[Mike Menci]

Hi Micael, 
There are nice Nema12 Steppers which do not take a lot of space - could be used as well on belt driven Z+Z1 because the load is balanced always and there is no large torque needed for Up-down nozzles (except for nozzle changer - depends on type!)  Nema12 Pancake are used now largely on 3D printers and are match more reliable and with quite large torque..... so do not be afraid of using those..  
Why the same problem ? Independent nozzles would lover nozzle at UpCamera location only for Hight of Nozzle picked up SMT part - so bottom for SMT would always be at the same hight for Up Camera Vision ? 

Yes my Quadro PnP head used 2 Nema 12 for 4 axis Z movement ... but I am not testing ELP Camera  for my machine - Which you have in mind - but I sold it ... Not my any more... 

[vespaman]

 

There are nice Nema12 Steppers which do not take a lot of space - could be used as well on belt driven Z+Z1 because the load is balanced always and there is no large torque needed for Up-down nozzles (except for nozzle changer - depends on type!)  Nema12 Pancake are used now largely on 3D printers and are match more reliable and with quite large torque..... so do not be afraid of using those..

There's the acceleration to consider, even if the normal torque does not have to be high. Do you know of any particular pancake stepper that is a good match? The feeder stepper in 3D printers are mostly geared and therefor rather slow afaik?

 

  
Why the same problem ? Independent nozzles would lover nozzle at UpCamera location only for Hight of Nozzle picked up SMT part - so bottom for SMT would always be at the same hight for Up Camera Vision ? 

In OpenPnP, the code that deals with bottom vision, - currently takes one nozzle at a time. So this means simplified: "move nozzle 1 into focus (X/Y/Z)", "take picture", "process picture", "move nozzle 2 into focus (X/Y/Z)", "take picture", "process picture" and so on. 

Since, both for multiple cameras setup, and for fly-by, ALL the  nozzle Z must already have been dealt with before taking the pictures. We cannot move Z between the pictures.

For a machine with 2 nozzles shared axis, the first move will also automatically take care of Z for the second nozzle, so it is handled without any extra Z move. But for machine with more Z axes, the current code is not ideal (and my new code will not cater for this, as is).

 

Yes my Quadro PnP head used 2 Nema 12 for 4 axis Z movement ... but I am not testing ELP Camera  for my machine - Which you have in mind - but I sold it ... Not my any more... 

Aha! So are you building a new machine now?

  - Micael

[Mike Menci]

The way I see this can not work with shared Z always - it might work when you have two SMT parts (one each nozzle) of the same hight. 

Once you have different heights of parts - bottom of parts will not be at the same hight with shared nozzles! 

You would will need two Z drive motors to achieve proper hight of parts at camera view window. I not than this two cameras do not add to productivity… 

Dne 3. nov. 2025 ob 15:10 je oseba vespaman <micael....@gmail.com> zapisala:



--
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/846aaa32-1895-437f-be04-40c492ce615cn%40googlegroups.com.

[vespaman]

The way I see this can not work with shared Z always - it might work when you have two SMT parts (one each nozzle) of the same hight. 

Once you have different heights of parts - bottom of parts will not be at the same hight with shared nozzles! 

Yes, it works. You just have to make sure your camera setup is correct. I.e. your field of depth is big enough to give good focus on both components. (this normally means carefully selecting the lens and a longer distance between the camera and the components).

The software knows the current Z of both nozzles and the height of both components, so it is just a matter for the "size test code" to take that into consideration.

 -  Micael

[Mike Menci]

Noted - For Steppers see attached Pancake Nema14 (not 12) look for longer size of axe -5mm there are some..