Thanks, but I need native images, as explained in the other thread:
And while you're at it, please proceed as described heren and send native image and units per pixel, and report the fiducial diameter:
https://github.com/openpnp/openpnp/wiki/FAQ#how-can-i-get-a-native-camera-image
And please provide a full log and machine.xml.
And please state the board Z.
As you have the Default Working Plane Z not equal Units per Pixel Z I guess you've calibrated these by hand? You do know Issues & Solutions can calibrate this for you, right?
https://github.com/openpnp/openpnp/wiki/Issues-and-Solutions
_Mark
Dne neděle 28. května 2023 v 14:44:42 UTC+2 uživatel Josef Plasil napsal:
Dear OpenPnP enthusiasts,
--
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 on the web visit https://groups.google.com/d/msgid/openpnp/cee37e26-7cb5-49c4-b1a7-3d5267bbb727n%40googlegroups.com.
Hey Josef
if you want help, please also follow the instructions I sent earlier.😁
- And while you're at it, please proceed as described heren and send native images, and report the fiducial diameter:
https://github.com/openpnp/openpnp/wiki/FAQ#how-can-i-get-a-native-camera-image
And please provide a full log and machine.xml.
And please state the board Z.
_Mark
--
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 on the web visit https://groups.google.com/d/msgid/openpnp/c0817921-173a-4c2d-9610-f8d24965d6dbn%40googlegroups.com.
openpnp/org.openpnp.vision.pipeline.stages.ImageWriteDebug
", but unfortunately I am not able to send pictures from this folder, as there is no such directory in my computer.To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/85465b94-12cc-0b2e-70e0-bc4f145cbc2d%40makr.zone.
I don't see any such pictures in previous messages or online.
If you want to get them during the process, then go into the
pipeline and enable the "deb0" stage (see you earlier
screenshot).
Then restart the process.
After that, they should be in the openpnp/org.openpnp.vision.pipeline.stages.ImageWriteDebug
Also you still haven't sent the log.
https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAFPGrag%3DLobtvoPs4XFEM-M5F-Omk4wS4GYMBh5BQr71Lhaqmg%40mail.gmail.com.
Hi Josef,
> BTW I have got board really fixed to my machine at that angle I also tried yesterday advanced calibration for camera (top one) yesterday, again with failure :-( and the angle of camera was again modified by this process ...
If Issues & Solutions preliminary camera calibration or Advanced Camera Calibration tell you there is a camera rotation angle, then there is very, very likely in-deed such a camera rotation angle. It is almost inconceivable how it could be wrong about that.
The rotation and flipping of the camera must be as follows.
Through your "Top" camera view you are looking down onto
the XY plane, towards Z-negative.
So what is X-positive must be "right" on the camera view, what is
Y-positive must be "up". Your rotation C axis goes
counter-clockwise.
Through your "Bottom" camera view it is like looking through your
nozzle onto an imaginary mirror under your machine table, the
reflection looking up at the underside of the X/Y
plane, towards Z-positive, i.e. at the underside of your part held
on your nozzle tip. Because you are looking at the underside, i.e.
back at you, either X or Y, and rotation C would be going the
wrong way, hence we need the mirror. In reality, the camera view
is mirrored/flipped either in X or Y (depends which way the
bottom camera is mounted). It's a bit like a selfie-camera, it too
points back at you, and it too is mirrored, otherwise you would
hardly be able to align the camera.
This is all done automatically for you, if you use the Issues
& Solutions steps, and do not change
things afterwards.
Why is all this important?
If the camera has the wrong angle (you reported 100°, let's assume 90° for simplicity), and it sees the fiducial for example 1mm to the right, then it will move the head with the camera 1mm to the right, to better pinpoint it. But because of the camera angle, the fiducial will now move approx. 1mm towards the top of the camera view instead. The fiducial is then further away than before! It does that a few times to try and center in on it, then finally gives up, because the wrong camera rotation leads it stray:
We see something like that in your log:
2023-05-28 18:52:03.483
ReferenceFiducialLocator DEBUG: Looking for
Fiducial_1mm_Mask2mm-Fiducial at (319.767988, 275.744950,
-44.000000, 38.405595 mm)
2023-05-28 18:52:05.057 ReferenceFiducialLocator DEBUG:
Fiducial_1mm_Mask2mm-Fiducial located at (321.978824,
274.436128, -44.000000, 38.405595 mm)
2023-05-28 18:52:05.842 ReferenceFiducialLocator DEBUG:
Fiducial_1mm_Mask2mm-Fiducial located at (324.515286,
272.800100, -44.000000, 38.405595 mm)
2023-05-28 18:52:06.516 ReferenceFiducialLocator DEBUG:
Fiducial_1mm_Mask2mm-Fiducial located at (326.948919,
274.126144, -44.000000, 38.405595 mm)
2023-05-28 18:52:06.772 MessageBoxes DEBUG: Error:
java.lang.Exception: Fiducial Fiducial_1mm_Mask2mm-Fiducial
detected too far away.
Conclusion: Let Camera Calibration adjust the camera rotation angle!
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/13e03d7c-303b-4fb2-b61d-21ca6fab8e51n%40googlegroups.com.
Added that to the Wiki too, for future users.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e3aab9f3-0700-91f0-8854-653c3d4946be%40makr.zone.
Just to be sure:
You said earlier
> I had to change camera (on head) orientation after that, because it has automatically changed to approx. 100 degrees (and picture was rotated)
This did no longer happen, right?
You did not change the rotation back, right?
_Mark
Dear Mark,
finally I completely setup newly machine, everything went (during guides) well, top camera is now in advanced mode, but the problem with fiducials on the board remained :-(. I am totally unaware of reason. The interesting thing is machine can find homing fiducial without any problems, despite it is on surface of desktop (below focus = blured), but when machine should find fiducials on the board (very sharp and clear picture), there is problem in both fiducials and they are located incorrectly, i.e. board is virtually moved to incorrect position :-(. I am sending the settings again and selected pictures (couple of them, others are similar with circles on various positions ... :-o) from debug folder. If something go to your mind, please, just let me know. I am thinking about the color of mask (black) in my case, isn't it problem for fiducials recognition? Have a nice evening. Kind regards, Josef
--
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 on the web visit https://groups.google.com/d/msgid/openpnp/9a4ee193-c31d-4a8c-a07c-390a21e64c51n%40googlegroups.com.
Dear Mark,you are right ... the unexpected rotation didn't happen again. Perfect. Thank you for advise to setup everything newly. But unfortunately the issue with defect PCB fiducials detection remained.Also (independent issue) I would like to let you know, that it would be perfect to have nozzles in safe position (safe Z level) between homing and calibrating of nozzles above bottom camera, you know, I have got the feeders on the way and in case of not having safe Z there is problem with all the homing process and nozzles can crash into feeders (see picture, please).And I have got the suspicion the compensation of components position in axis Y by bottom camera are in opposite way, I don't know why ... But it is still unconfirmed. The bottom camera was setup automatically (newly from yesterday evening) and except exposure (it was need, because the message about differences between measurement occurred and there was impossibility to continue with job PnP process) it seems to work well ...Unfortunately I will leave tomorrow and will be back on June 14th, therefore I will be unresponsive from tomorrow :-(.Regards, Josef.
--Dne středa 31. května 2023 v 9:24:44 UTC+2 uživatel ma...@makr.zone napsal:
Just to be sure:
You said earlier
> I had to change camera (on head) orientation after that, because it has automatically changed to approx. 100 degrees (and picture was rotated)
This did no longer happen, right?
You did not change the rotation back, right?
_Mark
On 5/30/23 20:58, Josef Plasil wrote:
Dear Mark,
finally I completely setup newly machine, everything went (during guides) well, top camera is now in advanced mode, but the problem with fiducials on the board remained :-(. I am totally unaware of reason. The interesting thing is machine can find homing fiducial without any problems, despite it is on surface of desktop (below focus = blured), but when machine should find fiducials on the board (very sharp and clear picture), there is problem in both fiducials and they are located incorrectly, i.e. board is virtually moved to incorrect position :-(. I am sending the settings again and selected pictures (couple of them, others are similar with circles on various positions ... :-o) from debug folder. If something go to your mind, please, just let me know. I am thinking about the color of mask (black) in my case, isn't it problem for fiducials recognition? Have a nice evening. Kind regards, Josef
--
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 on the web visit https://groups.google.com/d/msgid/openpnp/9a4ee193-c31d-4a8c-a07c-390a21e64c51n%40googlegroups.com.
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 on the web visit https://groups.google.com/d/msgid/openpnp/f334991d-0a66-47c0-9995-5d32744c079bn%40googlegroups.com.
Dear Josef,
please read this carefully. Try to answer/check/configure
exactly what I'm describing.
> The movements on the bottom camera are following:
when I press the UP arrow (of Y axis) on jog panel, the picture
goes up, means indicating box is going down on the picture (to
Y-) ..., when I press left arrow of (X axis) on jog panel,
picture is going left, means indicating box is going to the
right.
> These actions are completely reversed on top camera.
> All of these settings are result of Issues &
Solutions steps, except exposition I didn't change anything
Is this right, please?
I don't understand what exactly you mean by "picture" and
"indicating box". Maybe this is a translation engine artifact?
In the bottom camera view the visible nozzle must go up,
when you press the "up arrow". It most go right when you press the
"right arrow". It must rotate as the rotate arrow indicates.
https://github.com/openpnp/openpnp/wiki/Setup-and-Calibration_General-Camera-Setup#bottom-camera
In the top camera, it is not the subject (the nozzle)
that is moved by the head, but the camera is moved
by the head. So yes, it is inverted so to speak.
If you look at a fiducial, it must go down when you press the "up
arrow", it must go left when you press the "right arrow".
But if this is appearing correctly in the camera view, it is not surprising, because as I said, the calibration will make it so, even if you have the physical axis reversed.
Therefore I asked about how the head goes, physically.
When you press the "up arrow" the head must physically (not in the camera) move away from you (Y axis positive).
When you press the "right arrow" the head must physically (not in the camera) move to the right (X axis positive).
> Safe Z level is really not achieved after homing to fiducial. Immediately after homing to homing fiducial the nozzles go to the bottom camera to calibrate them, means Z is increasing from reference position (approx. -62 in my case) to -47 mm (the focus of bottom camera in my machine) together with axes X and Y to achieve target position above the camera. Could I solve this by some setting?
According to your log, that is not so, the move to safe Z is done:
2023-05-30 20:19:22.331
ReferenceFiducialLocator DEBUG: FIDUCIAL-HOME located at
(3.014084, 2.185289, -45.200000, 0.000000 mm)
2023-05-30 20:19:22.332 AbstractHeadMountable DEBUG:
Top.moveTo((3.014084, 2.185289, -45.200000, 0.000000 mm), 1.0)
2023-05-30 20:19:22.351 GcodeDriver DEBUG: [serial://COM9]
>> M204 S54 G1 X5.4908 Y2.132 F139 ; move to target,
20000
2023-05-30 20:19:22.353 GcodeDriver DEBUG: [serial://COM9]
>> M400 ; Wait for moves to complete before returning,
20000
2023-05-30 20:19:22.447 GcodeDriver DEBUG: [serial://COM9]
>> G92 X4.2606 Y2.0000 ; reset coordinates, -1
2023-05-30 20:19:22.449 ReferenceNozzle DEBUG: N1.home()
2023-05-30 20:19:22.450 ReferenceNozzle DEBUG: N1.home() nozzle
tip JUKI503 calibration neeeded
2023-05-30 20:19:22.452 ReferenceHead
DEBUG: H1.moveToSafeZ(1.0)
2023-05-30 20:19:22.453 AbstractHeadMountable DEBUG:
N1.moveToSafeZ(1.0)
2023-05-30 20:19:22.454 AbstractHeadMountable DEBUG:
N2.moveToSafeZ(1.0)
2023-05-30 20:19:22.455 AbstractHeadMountable DEBUG:
Top.moveToSafeZ(1.0)
2023-05-30 20:19:22.455 AbstractHeadMountable DEBUG:
Top.moveTo((1.783863, 2.053480, 0.000000, 0.000000 mm), 1.0)
2023-05-30 20:19:22.458 AbstractHeadMountable DEBUG:
N1.moveTo((323.554000, 50.667631, -30.000000, -180.000000 mm),
1.0)
2023-05-30 20:19:22.463 GcodeDriver DEBUG: [serial://COM9]
>> M204 S511 G1 X302.2804 Y132.767 Z-30.000 A-180.00
F10016 ; move to target, 20000
2023-05-30 20:19:22.468 GcodeDriver DEBUG: [serial://COM9]
>> M400 ; Wait for moves to complete before returning,
20000
2023-05-30 20:19:25.041 AbstractHeadMountable DEBUG:
N1.moveTo((323.554000, 50.667631, -47.000000, -180.000000 mm),
1.0)
2023-05-30 20:19:25.052 GcodeDriver DEBUG: [serial://COM9]
>> M204 S298 G1 Z-47.000 F4273 ; move to target, 20000
2023-05-30 20:19:25.056 GcodeDriver DEBUG: [serial://COM9]
>> M400 ; Wait for moves to complete before returning,
20000
2023-05-30 20:19:25.536 ReferenceNozzleTipCalibration DEBUG:
[nozzleTipCalibration]starting measurement; angleStart: -180.0,
angleStop: 180.0, angleIncrement: 60.0, angleSubdivisions: 5
However, it seems your physical controller Z homing seems to
leave the nozzle lowered. That is unexpected, normally it be left
balanced on a dual head machine. So OpenPnP thinks it is already
at Safe Z and does not move it.
This means the Home Coordinate is not configured right in
OpenPnP on the Z1 axis. Enter the raw controller coordinate the Z
axis has after homing:
If you don't know it, enter
G28
M114
in the Console of the driver, and read the reported Z, and enter
it in the Home Coordinate of the axis:
Note if you continue following the Issues & Solutions
suggestions into the Advanced Milestone, you will be
guided to enable advanced motion control and Location
Confirmation, which will (as a side effect) automatically
get the reported location after homing, i.e. OpenPnP will always
be in sync with the controller and this will not happen, even if
the Home Coordinate is not correct.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e9fd2ddc-6192-4c5c-aef3-90f807b4d07fn%40googlegroups.com.
See the other answer about this.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/129ad374-60c3-4504-afd6-f9cb428a34ban%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/700ba212-f9c8-595a-e359-10de61c95466%40makr.zone.
Well, I'm out of ideas, sorry.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAFPGragR2nVjeG9VNhW0rfPFx2rMW97%2BqWG-d-YhLm%2BhJ_pWFA%40mail.gmail.com.
Yes, good idea, Tony.
Using Josef's latest machine.xml and source image, I was able to reproduce it:
Turns out, there a barely visible shadow artifact in the
background that the plain CircularSymmetry stage finds more
attractive:
I think this happens due to an unlucky combination of effects:
As you see in the original and contrast enhanced pics above, the inner darker fiducial reflection is uneven. Could be the HASL surface that is uneven, or the hole in your diffuser is too large or asymmetric, or your diffuser is not diffusing enough (HASL is generally difficult).
You can reduce the relevance of the inner reflection, by
reducing the innerMargin property of the pipeline from 0.4
to 0.2:
This did nail the Fiducial, but as you see in the heat map, there
is still quite some "attractiveness" (yellow) in the background
shadow:
There is also another problem. It seem the Units per Pixel at
given Z are not right. At your stated PCB height (-44mm) the
maxDiameter is 14 px. But the actual fiducial diameter in the
image (once detected) is exactly 14 px, so there is no space left
(outerMargin) to actually detect the edge contrast of the
fiducial.
If I set the Working Plane (acts as PCB Z) to -38mm then the
minDiameter and maxDiameter appear about correct and the match
becomes more robust (four times better score than the shadow).
Finally, there are new symmetryScore methods, that I
added lately, albeit for feeder vision:
Turns out these help here too, if you set it to RingMedian it will better reject the shadows:
See also:
https://github.com/openpnp/openpnp/wiki/DetectCircularSymmetry#general-properties
So this should be the setting for HASL:
I will think about making this the new stock default, or a
separate HASL setting. The smaller innerMargin needs more
accurate Units per Pixel at PCB Z, but I believe we can now assume
this a given. Hmmm...
@Josef, once you come back, adjust the pipeline as shown above and double-check your PCB Z. Tony's advice of setting the maxTargetCount to 2 or 3 is another valid method that you can combine with the above.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d7f8c859-448c-4074-9d7a-7bf9ecfd880cn%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f731f78d-9bd9-1796-131b-eaf0d8d6569a%40makr.zone.
Your sentence is a bit confusing 😉
It has nothing to do with "Z safe" or "Safe Z" as we
usually call it. Safe Z is when the nozzle is retracted to a safe
height, so when you move around in X/Y it will not collide with
anything on the machine table, including with parts already
placed.
But yes, what I was talking about, is the Z coordinate indicated in the DRO when your nozzle tip barely touches the PCB.
But of course this will only work correctly, if you did not in any way change the camera mounting, the camera video mode, the PCB mount, the way the Z axis is homed, etc. since you last calibrated the camera.
Also, please ask Tony about your advanced camera calibration (the
machine.xml is in this thread somewhere). I see errors in Y that
seem large to me. So maybe the scaling of the fiducial is wrong
because of that.
_Mark
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAFPGrag2FAgEG535teWhKcPfsqboYv2iiyb3WnbHBG-rfvkACA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/d866c99e-96ef-e09e-5378-6e53ef4d6958%40makr.zone.