Hi Micael!
I agree, I also consider pre-rotation a nice feature and I'll do my
best to keep it and fix the issue we're currently facing. I'll put more
comments between the lines.
On 06.03.2025 16:48, vespaman wrote:
> Having thought about this a bit more, is there a reason that the check
> needs to be done at all, if not using dynamic safe Z?
>
You may follow the discussions Marks and me had while developing PR 1654
at
https://github.com/openpnp/openpnp/pull/1654: He at a very early
stage pointed out that "Another problem we discussed as well:
Pre-rotation must only happen when (all) the intertwined HeadMountables
are at Safe Z, i.e. where the subordinate axes are allowed to rotate
freely in the air. Again, taking the shared C axis machine into account."
I agree with this arguments. He later down suggested some code to check
that, which I merged.
> I don't know how the safe zone is meant to work if static Z is selected.
> Is it still used for obstacle issues?
> I used to have dynamic Z for a short while in the beginning, but I have
> since forgotten about the settings.
>
Safe Zone is meant to denote that it is safe to move within. With static
safe Z you just say, if my z-axis is within this range, it is safe to
move everywhere regardless if the nozzle is carrying any part.
With dynamic safe z the part height the nozzle is currently carrying is
taken into account too. This means that a nozzle is retracted such that
the tip plus the part it may carry are both in the safe z zone. This is
more efficient (especially for machines with large Z travel) because eg.
after place, the tip is just raised up into safe-z. In addition some Z
movements can take place while moving in the same z zone. If eg. nozzle
1 just picked a part, it is lifted just until the part can be freely
moved. If next nozzle 2 is to have eg. bottom vision, it can already be
lowered to its safe zone boundary while moving to the camera. (It is
also possible to execute the edges (z going up to xy starting to moving)
as curves to further speed up the motion by allowing z to overshoot
insight the safe z zone.)
> I see in the code, that it is testing if safe zone is active, so I
> checked my settings, and it is. Both safe hi and safe low are set to the
> same value, -0.220 which seems like a bogus value.
> But if I simply try to disable the safe hi and low, machine will stop
> during homing (after finding end stops), with the message "Nozzle N1 has
> no Z axis with Safe Zone Mapped".
>
No, you can't run without a safe z zone. OpenPnP needs to know how much
the nozzle has to be lifted to safely travel to the bottom camera or the
place location.
The recommendation for the safe z zone is to keep it as large as
possible (to avoid unnecessary z moves). Its ok, if you define it
asymmetric. That might be desirable (with static safe z) to assign more
z head room for one nozzle.
> So, maybe your code works, if I somehow can disable the safe zone
> settings. Am I missing a setting somewhere?
>
I've compared the code against MovableUtils:moveToLocationAtSafeZ() and
I'm pretty sure it works - at least in principle.
At least in the SimpleJobTest the issue is that PCB Z = 0 and Safe-Z
zone is [0, 0]. This means, that the nozzle is lifted to z = 0.25 to
place a part of 0.25mm height, which is indeed outside the safe-z zone.
If PCB Z is lowered, I don't see any warnings concerning drained
subordination queue anymore.
I'll try to replicate your safe-z settings in a simulation machine and
see if that causes the issues you reported.
> How have you setup this on your machine? What are your safe hi/low settings?
>
I use dynamic safe z with safe-z zone between z -13.2° .. 13.2°. This
translates to about 6mm clearance above the PCB level.
Jan
> Hi Micael!
> Many thanks for the hint! I can see it here too and found, that the
> feeder is using vision (I suppose you're using vision too) and the
> nozzle is configured for static safe Z (which you have too). Within the
> feed cycle the camera is send to the feeder and the logic tries to
> apply
> the requested nozzle rotation. However, this is subject to current and
> target location to be in Safe-Z for all heads and all their head
> mountable. And this veto is what fails here. The current location of
> the
> nozzle is considered not Safe which prevent anything from being merged.
> On the following coordination point before the camera image is
> captured,
> the queue is then drained, generating the warning.
> Unfortunately I don't know yet how to solve that. The code in question
> (
https://github.com/openpnp/openpnp/blob/
> b8fd4944c584a871ab45c300b9c6c97928923ae8/src/main/java/org/openpnp/
> machine/reference/driver/AbstractMotionPlanner.java#L178 <https://
>
github.com/openpnp/openpnp/blob/
> b8fd4944c584a871ab45c300b9c6c97928923ae8/src/main/java/org/openpnp/
> machine/reference/driver/AbstractMotionPlanner.java#L178>)
> is a suggestion from Mark which I have gratefully accepted. I've
> already
> requested his expertise. If anyone else has a suggestion, please let me
> know.
> Due to the overcautious veto, I'd consider this issue to be no safety
> risk and hence keep the PR in place. If you or anyone else has a
> different opinion, please speak up. I'm open to revert it anyhow.
>
> Jan
>
> openpnp/78b9da2b-70e7-4fce-bb12-a2baebeca56dn%
40googlegroups.com
> <
https://groups.google.com/d/msgid/openpnp/78b9da2b-70e7-4fce-bb12-
> a2baebeca56dn%
40googlegroups.com?utm_medium=email&utm_source=footer>.