N2 calibration upper Z position
Jan
I've just run the N2 calibration a few times (I'm trying to understand
how reproducible the results are) and noticed, that the upper Z position
is odd. I've a CAM head and I can see, that the nozzle is lifted up
until N1 goes down a little bit. The position is about the Safe-Z
location of N1 and fare above the Safe-Z of N2. If attached the logs.
Can anyone please tell me why that's happening? Thank You!
Jan
PS: I'm on yesterdays test version.
mark maker
Hi Jan,
It seems as if the wrong end of the Safe Z Zone was used here:
2022-01-20 15:41:39.895 Scripting TRACE:
Scripting.on Nozzle.BeforePlace
2022-01-20 15:41:39.896 GcodeAsyncDriver DEBUG: serial://COM5
commandQueue.offer(M204 S2204.01 G1 Z-6.5624
F16988.33 ; move to target, 10000)...
2022-01-20 15:41:39.896 GcodeDriver TRACE: [serial://COM5]
confirmed M114
2022-01-20 15:41:39.896 GcodeAsyncDriver DEBUG: serial://COM5
commandQueue.offer(M204 S1261.19 G1 Z6.5295 B-90.0000
F4451.25 ; move to target, 10000)...
I did make a small change in the Safe Z handling, but I've looked
at that change again, an again, and I can't find a mistake.
Could you please send the machine.xml?
_Mark
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 on the web visit
> https://groups.google.com/d/msgid/openpnp/6fdd70b0-8939-03fe-d58a-2fdeb5f3bc75%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/6fdd70b0-8939-03fe-d58a-2fdeb5f3bc75%40makr.zone?utm_medium=email&utm_source=footer>.
mark maker
Turns out this is an old bug.
OpenPnP must move all the Head-Mountables of a head to safe Z
before a move in X, Y, C can be done.
This will be done in the order the Head-Mountables are defined in
Machine Setup, i.e. N1 comes before N2.
If N1 is not in the Safe Z Zone yet, it will trigger a move to
Safe Z of N1. The problem: it does this regardless on which side
of the Safe Z Zone it currently is, i.e. it will always move to
the lower Safe Z Zone limit.
Optimizing this means only moving to the nearer limit of
the Safe Z Zone, so if N2 is currently down, and N1 up in the air,
N1 should only move down to the higher limit of the Safe Z Zone.
Will fix it.
_Mark
Jan
Many thanks for checking.
May I suggest that you reconsider the discussion about Z in CAM style
heads we had yesterday? While configuring I had the impression, that a
nozzle was moved down before the XY move. I'd consider this a bug and
would recommend to fix it such, that the nozzle is only moved UP if Z <
Safe-Z and never down to Z == Safe-Z. I think it would be ok to move to
Safe-Z while moving to XY but I don't see any reason why to move DOWN to
Safe-Z first and then to XY. It might be even safer to move with Z >
Safe-Z if the nozzle is already there. This probably only happens as
part of the configuration process where it might prevent the user from
unexpected damages.
Jan
On 20.01.2022 18:34, mark maker wrote:
> Turns out this is an old bug.
>
> OpenPnP must move all the Head-Mountables of a head to safe Z before a
> move in X, Y, C can be done.
>
> This will be done in the order the Head-Mountables are defined in
> Machine Setup, i.e. N1 comes before N2.
>
> If N1 is not in the Safe Z Zone yet, it will trigger a move to Safe Z of
> N1. The problem: it does this regardless on which side of the Safe Z
> Zone it currently is, i.e. it will always move to the lower Safe Z Zone
> limit.
>
> <https://groups.google.com/d/msgid/openpnp/69bab750-293c-be1d-b888-83e0b227a3ee%40makr.zone?utm_medium=email&utm_source=footer>.
mark maker
No worries, it will do the right thing.
mark maker
Jan,
A new testing version will be deployed in ~10 minutes that fixes it.
https://github.com/openpnp/openpnp/pull/1362
https://openpnp.org/test-downloads/
To explain, I simulated the Nozzle offset calibration
pick&place step, where it rotates the confetti by 180°, done
with your machine.xml.
Most importantly, consider your Safe Z Zone:
BEFORE: Because of the bug, N1 would stubbornly move to
its own Safe Z, which is Z-16.6, then N2 would rotate 180°
and go to the N2 Safe Z which is Z+16.6, then down to place the
confetti.
AFTER: N1 realizes it is above the Safe Z Zone,
but not inside it, so it will move to the upper limit of the Safe
Z Zone, which is Z+16.6, then N2 would rotate 180° and go to the
N2 Safe Z which is Z+16.6, i.e. no change, then down to place the
confetti.
Look at the Planned time, to see how much faster it is.
_m
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/db9abc6c-0551-9f79-80db-932fc47cbc74%40makr.zone.
Jan
Many thank for the quick update. Works like charming now! I repeated
the procedure a few time at fast and slow speeds and could not see any
odd moves.
However, I noticed three things:
a) If I move the head to manually change a nozzle with Z above Safe-Z (Z
is set to the balance point of the CAM head to avoid Z errors when
putting the new nozzle tip in) and then press park Z, the nozzle is
moved down. I'd consider this unnecessary as the nozzle is already in a
safe place. (I don't know if the Z park position can be configured
somewhere.)
b) The precise camera to nozzle calibration start at the primary
fiducial calibration and leaves the test object in an offset location.
It seems that the initial offset is amplified by the procedure and not
compensated at the end. If one tries to repeat the procedure this only
works a few times until the test object gets out of sight for the first try.
c) I tried to understand how good the camera to nozzle calibration is
and therefore repeated it a few times. Unfortunately the Reopen-button
reverts to the previous offset, which makes the difference reading of
the result always of the same order of magnitude. I understand that one
sometimes wont's to revert the calibration, but I would like to repeat
it based on current values.
Jan
On 20.01.2022 19:46, mark maker wrote:
> Jan,
>
> A new *testing *version will be deployed in ~10 minutes that fixes it.
> https://github.com/openpnp/openpnp/pull/1362
>
> https://openpnp.org/test-downloads/
>
> To explain, I simulated the Nozzle offset calibration pick&place step,
> where it rotates the confetti by 180°, done with your machine.xml.
>
> Most importantly, consider your Safe Z Zone:
>
> which is Z+16.6, then down to place the confetti.
>
> then N2 would rotate 180° and go to the N2 Safe Z which is Z+16.6, i.e.
> no change, then down to place the confetti.
>
> Look at the Planned time, to see how much faster it is.
>
> image
>
>
> --
> 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/b14dd571-c613-300e-7845-ea69792d0d8b%40makr.zone?utm_medium=email&utm_source=footer>.
mark maker
a) Having seen your machine.xml, I assume you really have a
cam-shared-axis two-nozzle machine, right? So one nozzle being too
high (outside the safe Z zone), means that the other nozzle is too
low, i.e. not at safe Z. It could bump into something on the way
to the nozzle changing location.
b) that is true, but how damn hard is it to nudge the confetti
back onto the primary fiducial, before the next try? 😛
https://youtu.be/md68n_J7uto?t=461
c) The previously configured state is stored on the Issue that you accept (internally a Java object). Pressing Find Issues & Solutions again will create all new Issue objects, throwing away the stored previous state. So pressing Find Issues & Solutions before re-opening the solution, will do what you want.
_Mark
mark maker
When I wrote:
> So pressing Find Issues & Solutions before re-opening the solution, will do what you want.
You need to enable the Include Solved? checkbox on the
Issues & Solutions tab, to be able to re-open the
solution.
> I tried to understand how good the camera to nozzle
calibration is and therefore repeated it a few times.
Please repeat your findings 😎
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/059ccb66-630f-30e5-843a-09d9343bfa35%40makr.zone.
Jan
On 21.01.2022 14:14, mark maker wrote:
> a) Having seen your machine.xml, I assume you really have a
> cam-shared-axis two-nozzle machine, right? So one nozzle being too high
> (outside the safe Z zone), means that the other nozzle is too low, i.e.
> not at safe Z. It could bump into something on the way to the nozzle
> changing location.
>
> b) that is true, but how damn hard is it to nudge the confetti back onto
> the primary fiducial, before the next try? 😛
> https://youtu.be/md68n_J7uto?t=461
>
> *accept* (internally a Java object). Pressing*Find Issues & Solutions
> *again will create all new Issue objects, throwing away the stored
> previous state. So pressing *Find Issues & Solutions * /before/
> re-opening the solution*, *will do what you want.
>
> _Mark*
> *
> <https://groups.google.com/d/msgid/openpnp/059ccb66-630f-30e5-843a-09d9343bfa35%40makr.zone?utm_medium=email&utm_source=footer>.
Jan
Many thanks for your quick response. It's always of enormous value to me!
I'll put my comments between the lines.
On 21.01.2022 14:14, mark maker wrote:
> cam-shared-axis two-nozzle machine, right? So one nozzle being too high
> (outside the safe Z zone), means that the other nozzle is too low, i.e.
> not at safe Z. It could bump into something on the way to the nozzle
> changing location.
>
enabled dynamic Save-Z. I also followed your advice and configured
Save-Z as low as possible. This results in a relative large range, where
Z is > Safe-Z of N1 and > Save-Z of N2. I then configured the manual
nozzle tip change position such, that it at the balance point to avoid
any force onto the motor axis while changing the nozzle tip. At that
position both nozzles are in there upmost position and well above their
Save-Z. I'd say that there is not need for any movement in Z to get onto
the save side.
> b) that is true, but how damn hard is it to nudge the confetti back onto
> the primary fiducial, before the next try? 😛
> https://youtu.be/md68n_J7uto?t=461
>
Then the system should know how to precisely place it back.
> c) The previously configured state**is stored on the Issue that you
> *accept* (internally a Java object). Pressing*Find Issues & Solutions
> *again will create all new Issue objects, throwing away the stored
> previous state. So pressing *Find Issues & Solutions * /before/
> re-opening the solution*, *will do what you want.
>
Jan
> <https://groups.google.com/d/msgid/openpnp/059ccb66-630f-30e5-843a-09d9343bfa35%40makr.zone?utm_medium=email&utm_source=footer>.
mark maker
> Yes, I do have a CAM head with shared axis. I followed
your advice and enabled dynamic Save-Z. I also followed your
advice and configured Save-Z as low as possible. This results in
a relative large range, where Z is > Safe-Z of N1 and >
Save-Z of N2.
Very good.
> I then configured the manual nozzle tip change position
such, that it at the balance point to avoid any force onto the
motor axis while changing the nozzle tip. At that position both
nozzles are in there upmost position and well above their
Save-Z. I'd say that there is not need for any movement in Z to
get onto the save side.
Well it depends where the nozzles are before the move. This is how it should work:
- If the nozzles are currently outside the Safe Z Zone, i.e. one of them below Safe Z, this one should move up first, but no farther than its lower Safe Z.
- Then it should move in a diagonal line to your changer
location, i.e., Z would slowly move further up to the balance
point.
I have tested this and other scenarios yesterday, using your
machine configuration, and using both nozzles, so I'm a bit
surprised if this does not work. I even made a screen-shot:
And I now tested the case where the Z is already in the Safe Z
Zone and goes to Z=0, i.e., the balance point. It seems to work.
If this does not work on your side, please send the log.
_Mark
mark maker
>> https://youtu.be/md68n_J7uto?t=461
> It would be nice to have if the final (extra) step could put it back. Then the system should know how to precisely place it back.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/b0f6ce8c-ee82-168e-04b2-41226d72e431%40makr.zone.
Jan
> Please repeat your findings 😎
>
Here it comes:
0) advanced camera calibration is in operation and verified to work
correctly at PCB level.
a) for reference: I had to find out, that I have to press Find Issues &
Solutions _before_ reopen the precise camera to nozzle offset to start
from current values.
b) I constantly have trouble with the feature diameter. The suggested
value to start with (from previous run) is always to small (200..210,
Auto-Adjust suggests 238).
c) the process seems to start by finding the test object and then moving
to the primary fiducial location to find the object again. That can
result in errors if the test object can not be detect from that
position. The text says "jog [...] over the test object" so I would
expect that I can place the test object anywhere.
d) auto adjust starts at minimum diameter. It would be advantageous to
scan starting at the previous value into both directions as this
converges faster and avoids snapping to a different diameter.
e) the results seem to depend on the lighting. I don't have dedicated
lighting (yet) and there is some noise on the image in darker hours. For
my situation it would be better to average multiple vision passes to
average out some noise. In addition one could reject outliers.
f) I can't claim that the test object is placed exactly where it was
intended. I suspect that a very light object like thin paper could stick
on the larger nozzle tip and slip to a slightly different position. I
don't see, that the blower is operated. If I enable it manually the test
object sometimes gets blown away when on pick-up (the vacuum valve is a
two way, in default position the blower passes thru and if activated the
vacuum sucks on the nozzle. I guess I could enable the blower pump after
pickup...)
g) with a thick object like my 180g/m^2 confetti there is a slow
progress toward the true position after multiple passes. I think that's
not ideal. With a thin test object like 80g/m^2 there is still progress
but more steep. After two/tree passes the difference between multiple
runs is in the order of 1/100mm. However, my thin test object is bent
due to the hole puncher I've take it from. I was not able to make it
entirely flat. I'm not sure if that effect the location on
pick-up/place. Would it be possible to use a chip resistor (eg. 1206) as
test object? Its larger, more heavy, flat and has a known thickness (ok,
probably of no concern as 3d calibration is not in operation at this
point in Issues & Solutions...).
Jan
> On 21.01.22 14:14, mark maker wrote:
>>
>> a) Having seen your machine.xml, I assume you really have a
>> cam-shared-axis two-nozzle machine, right? So one nozzle being too
>> high (outside the safe Z zone), means that the other nozzle is too
>> low, i.e. not at safe Z. It could bump into something on the way to
>> the nozzle changing location.
>>
>> b) that is true, but how damn hard is it to nudge the confetti back
>> onto the primary fiducial, before the next try? 😛
>> https://youtu.be/md68n_J7uto?t=461
>>
>> *accept* (internally a Java object). Pressing*Find Issues & Solutions
>> *again will create all new Issue objects, throwing away the stored
>> previous state. So pressing *Find Issues & Solutions * /before/
>> re-opening the solution*, *will do what you want.
>>
>> *
> --
> 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/4cfa62c3-37c2-5bcb-4100-5cecb7dd0cc5%40makr.zone?utm_medium=email&utm_source=footer>.
mark maker
Very nice report, thanks, Jan!
b) Is it possible that the test object diameter is more
than half across your camera view? If yes, then it is likely too
large. Is your camera view so narrow?
c) I see that it can be misleading. The problem:
Firstly, you need to set the feature diameter and you can only do
that, if the camera is already positioned over the object/primary
fiducial.
Secondly, the calibration process must be at the primary fiducial location, that's why it moves there as the first step. Now instead of moving there and visually reacquiring the test object, I could simply compare the coordinates and complain if too far apart. Good point.
Btw., the reason I want users to do it on the primary fiducial spot, is the known and good Z of that location. The offset must be measured at default Z, i.e. at PCB height, as the nozzle Z axis and the camera viewing axis (also in Z) might be slightly slanted/non-parallel to each other, so we need to do it at the Z that is representative.
> The text says "jog [...] over the test object" so I would
expect that I can place the test object anywhere.
No, that is not what it means, the text also says (earlier) "Place the calibration test object onto the calibration primary fiducial". 😁
I'm open to changes in the text, if you have a better
formulation.
d) Auto adjust only needs to be used once, we must fix b) instead.
e) No. All this calibration stuff is also a fitness test,
and intended to be validated in the right order. It is a good
thing if it fails if there is an underlying problem! Fix that
underlying problem first, in your case add lights. Chances are,
that when you want to add light later, you nudge the camera or
something, or even need to change its mount, and all your
calibration work is for nought. We want to calibrate stuff exactly
as it will be used later, in production. And believe me, you don't
want multi-capture/averaged vision later, it would slow down the
machine a ton.
f) I don't have enough information. I can only tell you
that the calibration is internally done with pick and place
commands. It creates a temporary Part and a Package with the
Blow-off value left at default, i.e. zero so there should be no
blow-off. To be honest, I never thought about the blow-off stuff.
g) Yes, if it is a problem for a light confetti, you may
need to manufacture a heavier test object, or glue it onto a
larger/heavier carrier, like a small piece of metal, or maybe your
1206. The calibration simply needs to see a circular contour
from the top, and it needs to be able to pick and place it, that's
all.
_Mark
Jan
Sorry for not being precise enough in what I wonted to say. First, all
you said is true. I don't see any odd moves on the way to the Z balance
point nor on it way back. It's just that when I press park-Z while Z is
at the balance pint one nozzle is moved _down_. That's unexpected to me.
Please see my log attached. It says Move N1 to safe Z then Move N2 to
safe Z. My expectation is, that parking Z means, that the nozzle goes
into a safe place. I further expected, that a nozzle, that's well within
the safe zone, does not need to be moved, especially not down, to go
into a safe place.
Jan
On 21.01.2022 15:28, mark maker wrote:
> /> Yes, I do have a CAM head with shared axis. I followed your advice
> Save-Z as low as possible. This results in a relative large range, where
>
> Very good./
> /
>
> /> I then configured the manual nozzle tip change position such, that it
> changing the nozzle tip. At that position both nozzles are in there
> upmost position and well above their Save-Z. I'd say that there is not
>
> Well it depends where the nozzles are /before/ the move. This is how it
> should work:
>
> 1. If the nozzles are currently outside the Safe Z Zone, i.e. one of
> than its lower Safe Z.
>
> I have tested this and other scenarios yesterday, using your machine
> configuration, and using both nozzles, so I'm a bit surprised if this
> does not work. I even made a screen-shot:
>
> goes to Z=0, i.e., the balance point. It seems to work.
>
> <https://groups.google.com/d/msgid/openpnp/b0f6ce8c-ee82-168e-04b2-41226d72e431%40makr.zone?utm_medium=email&utm_source=footer>.
mark maker
> when I press park-Z
Ahhh, now I understand.
> My expectation is, that parking Z means, that the nozzle
goes into a safe place.
AFAIK, "Park" means "go to a defined Position". But "Park" has
become somewhat undefined, since we have a Safe Z Zone. A
tool would be left at whatever "lopsided" position it currently
had, as long as it was in the Safe Z Zone. So I wanted it to
become defined and useful again, specifically for
the selected tool. So this is now defined as the minimum
Safe Z for that tool.
I use this feature to define the optimal entry (and exit)
way-point of the ReferencePushPullFeeder, so no extra Z move
is added after the move at Safe Z, and the entry point is as low
as possible, for shortest time to insertion:
https://youtu.be/5QcJ2ziIJ14?t=167
And in action:
https://youtu.be/5QcJ2ziIJ14?t=254
This could also be useful for nozzle tip changer way-points etc.
Alternatively, we could also just add open up Z (and Rotation)
coordinates of the Park Location on the Head. So everybody
can define their P buttons as they like:
_Mark
Jan
Many thanks! I'm very sorry for not responding earlier, family business...
I'll put my commends between the lines.
On 21.01.2022 18:16, mark maker wrote:
> Very nice report, thanks, Jan!
>
> camera view so narrow?
>
small. I designed a ring light, which is in production now. Once its
ready, I'll dismount the camera (I have to, it's housed in a tube) and
try to enlarge it. IIRC it's an 8mm lens with about 55mm focal distance.
It strange, that the y resolution is so much better then x...
> *c)* I see that it can be misleading. The problem:
> Firstly, you need to set the feature diameter and you can only do that,
> if the camera is already positioned over the object/primary fiducial.
>
> Secondly, the calibration process must be at the primary fiducial
> location, that's why it moves there as the first step. Now instead of
> moving there and visually reacquiring the test object, I could simply
> compare the coordinates and complain if too far apart. Good point.
>
> Btw., the reason I want users to do it on the primary fiducial spot, is
> *default Z*, i.e. at PCB height, as the nozzle Z axis and the camera
>
> /> The text says "jog [...] over the test object" so I would expect that
> I can place the test object anywhere. /
> No, that is not what it means, the text also says (earlier) "Place the
> calibration test object onto the calibration primary fiducial". 😁
>
> I'm open to changes in the text, if you have a better formulation.
>
no need, if the (my) underlying issue is results.
> *d)* Auto adjust only needs to be used once, we must fix *b)* instead.
>
Agreed.
> *e)* No. All this calibration stuff is also a fitness test, and intended
> to be validated in the right order. It is a/good/ thing if it fails if
> your case add lights. Chances are, that when you want to add light
> later, you nudge the camera or something, or even need to change its
> mount, and all your calibration work is for nought. We want to calibrate
> stuff exactly as it will be used later, in production. And believe me,
> you don't want multi-capture/averaged vision later, it would slow down
> the machine a ton.
>
a value is nothing without its error (and a unit, for sure). For vision
operations, there might be no direct error available, but one could
still take multiple passes and calculate the average and rms. This would
then allow to set boundaries on the quality of the results.
(Unfortunately one would also have to take other/related errors
(x/y/rotation) into account and even worth, handle systematic errors
(imagine a bend test object that moves slightly while being placed).)
> *f)* I don't have enough information. I can only tell you that the
> a temporary Part and a Package with the Blow-off value left at default,
> i.e. zero so there should be no blow-off. To be honest, I never thought
> about the blow-off stuff.
>
> carrier, like a small piece of metal, or maybe your 1206. The
>
better results. My personal feeling is, that the error in Z is
troublesome. As you respond to *c*, you're starting from the assumption,
that the test object has the same Z as the primary fiducial. This ansatz
is only true if the test object is infinitesimal thin. For real test
object with finite thickness you will always have an error that is
proportional to this thickness / focal distance, always positive and
systematic. For my setup (slightly bend or heavier thicker test object
and rather short focal distance (~55mm)) this is certainly true. The Z
error then translates a) into a larger diameter and b) seems to have a
larger offset. All this is folded with the camera calibration error and
the optical errors, not yet addressed. I personally think, this could be
handled a) by carefully checking how good optical inspections allows to
identify the object (errors below the detection limit can not be
corrected), b) every detected error is only compensated partly (to avoid
overcompensation due to the systematic Z error) and c) run multiple
passes until the result is below a physical limit (set internally or
configured) or below the detection limit or number of allowed passes
exceeded.
I just redid my tests using a forced missconfiguration and advance
camera camera calibration in operation and found very good results. If I
force a 1mm displacement in x or y, this is almost entirely compensated
by the calibration process in its first pass. (In my setup I have about
0.05mm deviation between consecutive runs. That should be fine for 0201
and 0.4mm qfn/tqfp.) Interestingly the correction is always smaller then
the configured displacement.
Jan
> <https://groups.google.com/d/msgid/openpnp/036d657d-c8d5-82de-492f-2ea6f9142bc6%40makr.zone?utm_medium=email&utm_source=footer>.
Jan
I guess this is the difference between two nozzle CAM head and single
nozzle liteplacer designs: a CAM head has naturally almost no Safe-Z and
is parked ideally in the balance point while for the liteplace one has -
as you said somewhere else - plenty of headroom and a slow moving axis.
I think reusing the park button as a configuration/setup feature for
certain feeders is beyond its intention. However, that's just my two
cents and even lowering a nozzle is still safe.
Having a dedicated field to configure a Z position is certainly not
ideal as OpenPnp would have to provide one for each nozzle, which would
be difficult again for shared Z axis nozzles.
Unfortunately I don't have a good suggestion how to handle this in a
general manor beyond my suggestion to not move a nozzle down if it's
commanded to go to Safe-Z.
Jan
On 21.01.2022 18:42, mark maker wrote:
> /> //when I press park-Z/
>
> Ahhh, now I understand.
>
> /> My expectation is, that parking Z means, that the nozzle goes into a
> safe place. //
> /
> AFAIK, "Park" means "go to a defined Position". But "Park" has become
> specifically /for /the selected tool. So this is now /defined /as the
> *minimum Safe Z *for that tool.
>
> I use this feature to define the *optimal* entry (and exit) way-point of
> the ReferencePushPullFeeder, so *no extra Z move* is added after the
> move at Safe Z, and the entry point is as low as possible, for *shortest
> time to insertion*:
> https://youtu.be/5QcJ2ziIJ14?t=167
>
> And in action:
>
> https://youtu.be/5QcJ2ziIJ14?t=254
>
> This could also be useful for nozzle tip changer way-points etc.
>
> coordinates of the *Park Location* on the Head. So everybody can define
> their *P* buttons as they like:
> <https://groups.google.com/d/msgid/openpnp/f42c1bfe-0671-c549-5f8d-9374cdb7a030%40makr.zone?utm_medium=email&utm_source=footer>.
mark maker
> If you say fitness test, do you have any metric for that?
If it fails, it is certainly not fit enough. Remember, you were
asking for multi-exposure etc. to overcome bad lighting.
> This ansatz is only true if the test object is infinitesimal thin. For real test object with finite thickness you will always have an error that is proportional to this thickness / focal distance, always positive and systematic. For my setup (slightly bend or heavier thicker test object and rather short focal distance (~55mm)) this is certainly true. The Z error then translates a) into a larger diameter and b) seems to have a larger offset.
b) Yes and no. When the part is firmly on the nozzle, it forms
one rigid body. The rotation axis goes through the test object, at
whatever tilt the nozzle rotation axis has, and comes out at the
test object underside. So if the pick and place form a good
contact with the underside, this is cancelled out. Even if the
test object is picked up with a slight tilt, i.e. lifting one side
earlier than the other, and creating a little "hinge" offset, that
tilt and hinge offset is the same for the pick and the place. Even
if the nozzle tip front is not planar, that effect is cancelled
out because the pick & place is done at several angles.
If if there is still a slight offset, you must be realistic. You
Z axis might not be 100% orthogonal, but it will be within a few
degrees. Whether your object is 0.01mm or 0.1mm or even 1mm tall
will not matter, the error is about 1.8% per degree, i.e.
"nothing". And btw. the same error happens in placement (part +
solder paste height), so it might even be beneficial in the end
;-).
_Mark
Jan
> /> If you say fitness test, do you have any metric for that?/
> If it fails, it is certainly not fit enough. Remember, you were asking
> for multi-exposure etc. to overcome bad lighting.
>
converges only by sqrt(n), with n beeing the number of measurements
taken. However, taking multiple measurments could provide a good
indication for the variance of the methods involved. The assumption for
all the vision operations is - to my understanding - that the results
are consistent and bettern then the purpose they are used for. So I
would suggest to verify this as part of the I&S help when setting up a
maschine. If lighting/setup/configuration is an issue, this should be
flaged before taking the results for other calculations/calculations
without proper error propagation.
> /> //This ansatz is only true if the test object is infinitesimal thin.
> that is proportional to this thickness / focal distance, always positive
> and systematic. For my setup (slightly bend or heavier thicker test
> object and rather short focal distance (~55mm)) this is certainly true.
> The Z error then translates a) into a larger diameter and b) seems to
> a) No, the diameter does not matter at all: remember, you set it at
> whatever height it has (input = output).
>
> b) Yes and no. When the part is firmly on the nozzle, it forms one rigid
> body. The rotation axis goes through the test object, at whatever tilt
> the nozzle rotation axis has, and comes out at the test object
> underside. So if the pick and place form a good contact with the
> underside, this is cancelled out. Even if the test object is picked up
> with a slight tilt, i.e. lifting one side earlier than the other, and
> creating a little "hinge" offset, that tilt and hinge offset is the same
> for the pick and the place. Even if the nozzle tip front is not planar,
> that effect is cancelled out because the pick & place is done at several
> angles.
>
robust for me, so I will stop complaining, promissed!
> If if there is still a slight offset, you must be realistic. You Z axis
> might not be 100% orthogonal, but it will be within a few degrees.
> Whether your object is 0.01mm or 0.1mm or even 1mm tall will not matter,
> the error is about 1.8% per degree, i.e. "nothing". And btw. the same
> error happens in placement (part + solder paste height), so it might
> even be beneficial in the end ;-).
>
well, but thats an other discussion.
Jan
> <https://groups.google.com/d/msgid/openpnp/783a4aaf-7d6a-2f7d-ad52-7824eb3db1e1%40makr.zone?utm_medium=email&utm_source=footer>.
mark maker
> However, taking multiple measurments could provide a good
indication for the variance of the methods involved. The
assumption for all the vision operations is - to my
understanding - that the results are consistent and bettern then
the purpose they are used for. So I would suggest to verify this
as part of the I&S help when setting up a maschine. If
lighting/setup/configuration is an issue, this should be flaged
before taking the results for other calculations/calculations
without proper error propagation.
Yeah, but that would be a completely different Issues & Solutions step, one that looks at the camera dynamic range/noise/etc. and some settings according to some yet-to-define criteria (not easy). I have something in mind, in connection with White Balance:
https://github.com/openpnp/openpnp/wiki/Camera-White-Balance
But we were talking about the fiducial detection. In my
experience the circular symmetry stage just always worked, when
the diameter was set right. The positional result also never
wavered beyond expected dithering down at resolution, i.e. there
is no point in repeating the process. There is no tell-tale
indicator as to the quality of the detection. Even the symmetry
indicator that I compute in the stage, is all over the place and
seems to be influenced by completely unrelated things, such as the
texture of the paper, the colors and contrasts, etc. but not
posing any problems for the algorithm, or telling you the quality
and reliability of the detection.
If you find such an indicator, please tell me.
_Mark