Extra Z Move, why?

[Jan]

Hi exports!
I'm currently debugging some enhancements to the job processor and
therefor very carefully watched the generated G-Code. I now found an
unexpected Z movement while moving the second nozzle to the bottom
camera. Filtered for "Parsed Gcode" I see the following sequence:

2024-07-17 11:57:13.639 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S18704 G1 X61.81 Y23.09 Z9 A-90 B-90 F132231
2024-07-17 11:57:13.642 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S14250 G1 Z29.6 F32490
2024-07-17 11:57:13.650 GcodeServer$Worker DEBUG: Parsed Gcode: M400
2024-07-17 11:57:13.994 GcodeServer$Worker DEBUG: Parsed Gcode: M114
2024-07-17 11:57:15.430 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S13807 G1 Z10.9 F30500
2024-07-17 11:57:15.431 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S6397 G1 Z9 F6547
2024-07-17 11:57:15.433 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S4892 G1 X86.78 Y23.26 Z-9 F23285
2024-07-17 11:57:15.435 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S14250 G1 Z-29.6 F32490
2024-07-17 11:57:15.438 GcodeServer$Worker DEBUG: Parsed Gcode: M400
2024-07-17 11:57:15.817 GcodeServer$Worker DEBUG: Parsed Gcode: M114

Right in the middle, the nozzle is send to Z = 10.9mm and directly
afterwords to Z = 9mm. (No other axis is moving.). I've configured a CAM
style shared Z axis, so from the G-Code I assume that Z = [-9 .. 9 mm]
is my Safe-Z zone (including the components on the nozzles), and as
expected, the next move in the sequence actually moves in X and Y and Z
to -9mm in order to lower the second nozzle down to the bottom camera.
(The full trace log is attached).
I generated the log sequence stepping through a job where both nozzles
just picked the same part by clearing the log. Then I stepped twice to
align both parts and pasted the result into the attached log. So the log
just contains everything that happens when aligning both parts.
Can the move to Z = 10.9mm be related to safe-z without component (part
height is 0.56mm but due to the CAM style, the effect on Z is not
obvious to me)? Tracing the source, the sequence is generated by
MovableUtils.moveToLocationAtSafeZ() in ReferenceBottomVison.java line
561 which is called via pipelineShot.apply() on line 589.

Jan

[mark maker]

It could happen if 

a) you have dynamic Safe Z configured

b) the sum of the picked part heights is larger than your Safe Z Zone (headroom)

If you set the Max. Part Height correctly on the nozzle tips (i.e. honestly larger than any part heights that you pick with that nozzle tip) then I&S should complain. Please report first if that is the case. Note, as far as I remember the Max. Part Height is not enforced, i.e. you need to be honest.

Or... it is a bug.

_Mark

[Jan]

Hi Mark!
Many thanks for your quick response.
According the the rest of the G-Code I've seen, Z = [-10.9 .. 10.9 ] is
the safe-z zone for empty nozzle tips. Center is at z = 0. Unfortunately
I can't claim true mm values for my safe-z zone because due to the CAM
style, this values are translated into angles and are now only available
as such. Max. Part Height is configured to 1mm on one nozzle tip and 5mm
on the other. I've only ever looked at the same sequence in which the
nozzle tip with 5mm Max. Part Height is the one that requires lifting to
safe-z.
(To fix an other issue) I've added nozzle.moveToSafeZ() after align()
in the job processor which brings the nozzle correctly up to z = 9mm
(without the extra stop at z = 10.9). This for me points into the
direction that nozzle.moveToSafeZ() works as expected (taking the part
the nozzle is holding into account), while
MovableUtils.moveToLocationAtSafeZ() does something else...
Just to be clear: IMHO, this is not a bug, rather a missed optimization
as the XY move does not start before the nozzle (incl. part) is
correctly at safe-Z. Its just, that there is an extra stop in Z at a
location where the tip itself is just at safe-z, while the parts bottom
its holding is not yet. An other move is then required to bring the
entire part into the safe-z zone.

Jan

On 17.07.2024 13:00, 'mark maker' via OpenPnP wrote:
> It could happen if
>
> a) you have dynamic Safe Z configured
>
> b) the sum of the picked part heights is larger than your Safe Z Zone
> (headroom)
>

> If you set the*Max. Part Height* correctly on the nozzle tips (i.e.
> /honestly/ larger than any part heights that you pick with that nozzle

> tip) then I&S should complain. Please report first if that is the case.

> Note, as far as I remember the *Max. Part Height* is not enforced, i.e.

> --
> 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 on the web visit
> https://groups.google.com/d/msgid/openpnp/bcfbd801-4f43-4d70-ae54-38606fc74a71%40makr.zone <https://groups.google.com/d/msgid/openpnp/bcfbd801-4f43-4d70-ae54-38606fc74a71%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

MovableUtils.moveToLocationAtSafeZ() must bring all its attached HeadMountables to safeZ (obviously) before it can move the head. It does so by moving each into the safe Z Zone. With Dynamic Safe Z this adds the part height. 

With shared Z axes (cam etc.)  it does this twice, for both nozzles. But because it checks whether a nozzle is already in the save Z zone, it should either do nothing on first or do nothing on the second nozzle. They can't be both down, right?

This promise is broken if you have dynamic safe Z and the sum of part heights is greater than the safe Z zone. It will then bring up the first and the the second, resulting in two moves.

Another reason could be that you have another HeadMountable with non-virtual Z axis, that is moved first. Actuators should not act up, as they should come after the nozzles (or it would be a bug). But if you misconfigured a camera with non-virtual Z axis, that would explain it, I guess, they come first as far as I remember. (I haven't looked at code, no time).

I trust you asked I&S?

A full log at TRACE will tell us. Please send one. 🙂

Or like I said, maybe it's a bug. It is certainly not supposed to happen, and it has nothing to do with the job processor per se.

_Mark

[Jan]

Hi Mark!

On 17.07.2024 20:43, 'mark maker' via OpenPnP wrote:
> MovableUtils.moveToLocationAtSafeZ() must bring *all* its attached

> HeadMountables to safeZ (obviously) before it can move the head. It does
> so by moving each into the safe Z Zone. With Dynamic Safe Z this adds
> the part height.
>

In my testcase that Z = -9 .. 9 with identical parts on both nozzles and
Z = -10.9 .. 10.9 with both nozzles empty.

> With shared Z axes (cam etc.)  it does this twice, for both nozzles. But
> because it checks whether a nozzle is already in the save Z zone, it
> should either do nothing on first or do nothing on the second nozzle.
> They can't be both down, right?
>

That's true. PCB-Z = +-29.6.

> This promise is broken if you have dynamic safe Z and the *sum of part
> heights is greater than the safe Z zone*. It will then bring up the

> first and the the second, resulting in two moves.
>

As you can see from the number above, the safe-z zone is still large
with the test-components loaded.

> Another reason could be that you have another HeadMountable with
> non-virtual Z axis, that is moved first. Actuators should not act up, as
> they should come after the nozzles (or it would be a bug). But if you
> misconfigured a camera with non-virtual Z axis, that would explain it, I
> guess, they come first as far as I remember. (I haven't looked at code,
> no time).
>

I'm not aware of any other actuator that could void that. My
down-looking camera virtual Z and rotation axis assigned.

> I trust you asked I&S?
>

Actually I&S has a lot to complain, because I'm using a simulation
machine with a lot of settings tailored for debugging. I can assure you,
that there is no complain about Max. Part Height for the two nozzles I'm
using. Also the number in the logs indicate, that the safe-z zone it not
empty.

> A full log at TRACE will tell us. Please send one. 🙂
>

Please find a fresh log attached.

> Or like I said, maybe it's a bug. It is certainly *not* supposed to

> happen, and it has nothing to do with the job processor per se.

> Unfortunately I can't see in the debugger where the move in question is
generated. The G-code appears when MovableUtils.moveToLocationAtSafeZ()
is executed but when stepping the code, I can identify the line in
question because the G-Code seems to be generated asynchronously.
As I was debugging the pre-rotate all nozzles PR, I notices that after
alignment one nozzle is still down. This voids the idea of the
pre-rotation and I therefor added nozzle.moveToSafeZ() to retract the
nozzle as is done in the pick step already. This is actually a fix for
the PR but also hides the problem, that the move sequence generated by
the alignment procedure is not optimal.
As I mentioned, IMHO this is not a bug, just a missed optimization...

Jan

> https://groups.google.com/d/msgid/openpnp/3bc0d050-5653-4a78-9d77-6f557ecf2f5f%40makr.zone <https://groups.google.com/d/msgid/openpnp/3bc0d050-5653-4a78-9d77-6f557ecf2f5f%40makr.zone?utm_medium=email&utm_source=footer>.

[Mark]

> I generated the log sequence stepping through a job where both nozzles just picked the same part by clearing the log.

I must have misunderstood this sentence. 

The double Z  is not at the picking, it is at the alignment?

Are you trying out the have a camera focal plane higher than Safe Z, as discussed elsewhere?

Then yes, there could well be a bug.

Can you point a a timestamp in the log, I haven't found the scenario...?

Could you send the machine.xml?

_Mark

[Jan]

On 18.07.2024 01:17, 'Mark' via OpenPnP wrote:
> /> I generated the log sequence stepping through a job where both
> nozzles just picked the same part by clearing the log. /

>
> I must have misunderstood this sentence.
>
> The double Z  is not at the picking, it is at the alignment?
>

Yes, the alignment stage: its executed twice, once per nozzle. On first
pass all nozzles are clear to move because pick as retraced them. On
second pass the nozzle that was just used for bottom vision, is still at
bottom cameras Z and needs to be retracted first. This retraction is
where the extra move happens. (Actually the extra move is to a location
where the empty nozzle is clear, but the nozzle is not empty. The second
move clears the nozzle incl. the parts its caring.)

> Are you trying out the have a camera focal plane higher than Safe Z, as
> discussed elsewhere?
>

No, I was debugging nozzle pre-rotation (PR #1654) with bottom camera
explicitly at PCB Z.

> Then yes, there could well be a bug.
>
> Can you point a a timestamp in the log, I haven't found the scenario...?
>

In the last log I send, there are multiple instances of the problem
(again filtered for "Parsed GCode" to indicate the two Z only moves):

2024-07-17 23:26:27.302 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S13807 G1 Z10.9 F30500
2024-07-17 23:26:27.303 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S6397 G1 Z9 F6547

2024-07-17 23:30:01.276 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S13807 G1 Z10.9 F30500
2024-07-17 23:30:01.277 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S6397 G1 Z9 F6547

2024-07-17 23:30:05.724 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S13807 G1 Z10.9 F30500
2024-07-17 23:30:05.726 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S6397 G1 Z9 F6547

2024-07-17 23:30:10.135 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S13807 G1 Z10.9 F30500
2024-07-17 23:30:10.136 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S6397 G1 Z9 F6547

Side node: To me this looks in particular unpleasant because the two are
using different accelerations. However that is interpreted and executed
by the controller...

> Could you send the machine.xml?
>

Please find it attached. (I've used it in combination with PR #1654 so
it might suffer from excessive elements if used with the current test
build.)

Jan

> https://groups.google.com/d/msgid/openpnp/daab3418-0885-465f-82e3-f95274bada2e%40makr.zone <https://groups.google.com/d/msgid/openpnp/daab3418-0885-465f-82e3-f95274bada2e%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

Hi Jan,

turns out it is has multiple issues. I fixed them. Described in the PR:

https://github.com/openpnp/openpnp/pull/1656

Please test immediately.

Only after testing it, should you change your machine configuration! 

Then...

• You might consider removing the Jerk limit on the Z axis (set to zero), this usually doesn't make sense with a spring-loaded nozzle tip. Having it at zero would have solved the issue for real controllers, i.e., the extra Z move would have been folded into one (but not for the simulated GcodeServer, this one just simulates simple move segments one by one 😉).
  
• You might consider setting a bottom camera Roaming Radius to allow for more generous above-camera moves without going via Safe Z. Also applies to CameraView mouse-click jogging.
  

Side note: I don't currently have much time, even this fix turned out to take way too long. 😭 The PR reviews will have to wait... I'm sorry. 

_Mark

[Jan]

Hi Mark!
Many thanks for trying to fix that. Unfortunately it seems to not work:

2024-07-18 15:17:03.198 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S27585 G1 Z-10.9 A-90 F120872
2024-07-18 15:17:03.200 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S13495 G1 X61.81 Y23.09 Z9 B-90 F95402
2024-07-18 15:17:03.204 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S100000 G1 Z29.6 F60000
2024-07-18 15:17:03.209 GcodeServer$Worker DEBUG: Parsed Gcode: M400
2024-07-18 15:17:03.677 GcodeServer$Worker DEBUG: Parsed Gcode: M114
2024-07-18 15:17:05.809 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S100000 G1 Z-10.9 F60000
2024-07-18 15:17:05.810 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S3978 G1 X86.78 Y23.26 Z-9 F18935
2024-07-18 15:17:05.812 GcodeServer$Worker DEBUG: Parsed Gcode: M204
S100000 G1 Z-29.6 F60000
2024-07-18 15:17:05.820 GcodeServer$Worker DEBUG: Parsed Gcode: M400
2024-07-18 15:17:06.078 GcodeServer$Worker DEBUG: Parsed Gcode: M114

As you can see from the generated G-Code, one nozzle arrives at Z = 9
(2nd line), goes to to Z = 29.6 (3rd line) for vision and is then
retracted up to Z = -10.9 (6th line). This is far more then required and
actually outside the valid safe-z for the other nozzle, which ends at Z
= -9. On the last line, the second nozzle is pulled up into its safe-z
zone to Z = -9 and finally lowered to Z = -29.6. (as you can see, the
numbers are symetric for both nozzles, >0 for one goging down and <0 for
the other going down.)
I'd assume that the move to safe-z is calculated for the wrong
nozzle but applied to the one in question resulting in a longer move
then required. Going up to z = 9 would be desired.
Please find the full log (align steps only) attached.

Jan

PS: From time to time I'm very busy myself, so please take your time.
PPS: Many thanks for the tips concerning Z jerk and camera rooming
radius. That's very much appreciated and reminds me, that I have to
setup a todo list to take advantage of the latest enhancements on my
real machine.

On 18.07.2024 15:00, 'mark maker' via OpenPnP wrote:
> Hi Jan,
>
> turns out it is has multiple issues. I fixed them. Described in the PR:
>
> https://github.com/openpnp/openpnp/pull/1656
>
> Please test immediately.
>

> Only *after* testing it, should you change your machine configuration!
>
> Then...
>
> * You might consider removing the *Jerk* limit on the Z axis (set to

> zero), this usually doesn't make sense with a spring-loaded nozzle

> tip. Having it at zero would have solved the issue for /real
> controllers/, i.e., the extra Z move would have been folded into one

> (but not for the simulated GcodeServer, this one just simulates
> simple move segments one by one 😉).

> * You might consider setting a bottom camera *Roaming Radius* to allow

> https://groups.google.com/d/msgid/openpnp/8badc624-ba79-450f-a09f-df447ac457eb%40makr.zone <https://groups.google.com/d/msgid/openpnp/8badc624-ba79-450f-a09f-df447ac457eb%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

Hi Jan,

Oops, took the wrong end of the Safe Z Zone. Some of the old code mistakenly left over. Fixing it.

https://github.com/openpnp/openpnp/pull/1657 (will merge as soon as sure)

Sorry 😳

_Mark

[mark maker]

Merged.

To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f7aa12e0-a902-42ca-8cbe-c377461c5418%40makr.zone.

[Jan]

Hi Mark!
That works very well now!
Many thanks for fixing this!

Jan

> https://groups.google.com/d/msgid/openpnp/f7aa12e0-a902-42ca-8cbe-c377461c5418%40makr.zone <https://groups.google.com/d/msgid/openpnp/f7aa12e0-a902-42ca-8cbe-c377461c5418%40makr.zone?utm_medium=email&utm_source=footer>.