Struggling with Bottom Vision - Test Alignment

[David Moorhouse]

I've followed through the Issues and Solutions wizards to dial in my machine.

I've got a TSSOP20 footprint part loaded into a strip feeder and have successfully set the coordinates so this part can be picked for a job.

However I notice it is never placed quite accurately on the PCB, usually a slight skew or small offset - most likely from the fact that the plastic tape carrier pocket is a little larger than the part.

So I'm looking to use bottom vision to improve the placement. I've followed along the wiki instructions for bottom vision, to the point where I need to perform the Test Alignment.

The machine scans the part and then displays an error:

Part TSSOP20-STM32F042 bottom vision offsets length 3.906 larger than the allowed Max. Pick Tolerance 0.750 set on nozzle tip NT4.

I've tried increasing this setting for the tip (my understanding is that it is the area that is excluded from the vision pipeline to speed things along)

This makes no difference.

What should I be trying next ?

[David Moorhouse]

SO I bumped up the Max Pick Tolerance for that nozzle to 5mm. The Test Alignment does not show an error, but it also does not centre or align the part.

And if I run a test placement on the part it is skewed by about 10 degrees cw and offset in both x and y directions by around 5mm.

Very odd.

[mark maker]

Hi David,

Do not unduly increase the Pick Tolerance, i.e. reduce it. There seems to be a different problem.

In order to diagnose from afar, please send log at TRACE level and machine.xml

https://github.com/openpnp/openpnp/wiki/FAQ#where-are-configuration-and-log-files-located

Also send some native camera images of the alignment:

https://github.com/openpnp/openpnp/wiki/FAQ#how-can-i-get-a-native-camera-image

_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/060a3965-33ea-4840-89fc-f52baf395ebcn%40googlegroups.com.

[David Moorhouse]

I changed the Pick Tolerance back to 1mm. There is still an error getting the TSSOP20 to centre, I would expect the cross hairs to be between pins 5 and 6 (it has settled on one of the pins)

I'm attaching images (from snapshot, also screenshot showing cross hairs) and the machine config.

Thanks for your assistance - it is very much appreciated.

[David Moorhouse]

And the log. The snapshotted image file was too large to upload onto the google board. Let me know if I should send it another way

Many thanks

[David Moorhouse]

There's this line near the bottom of the log (after I have picked a part and then tried to do the "Test Alignment" on the part)

2023-10-21 14:35:55.831 ReferenceBottomVision DEBUG: Alignment result: TSSOP20-STM32F042F6P6TR | X:-0.156 Y:0.083 C:0.476 ?:0.177

Are those X and Y values showing how much it needed to be moved, or is that how far out the part is ?

[David Moorhouse]

As a work around (because I really want to start assembling boards, not debugging my machine) I've gone back to the Package|Bottom Vision settings and enabled the asymmetric vision offsets, entering values in there until the part is centered correctly in the bottom camera view. Does that tell me there is something weird going on with the detection of the pins ? I.e. I can only get the part correctly centred to be between pin 5 and 6 when I put an "X" offset of 0.3mm.

[Jan]

Hi David!
This offset is for parts, where the center of what you see using bottom
vision differs from the parts location. Eg rectangular connectors might
be setup like this in the pcb library. I'd remove this offset as it will
very likely cause move issues then it currently solves.
I don't know how to check your machine.xml so I can just put some more
things in, that you might wont to check. TSSOP20 is a symmetric part
with shiny legs on all edges. That makes it easy to detect - suppose the
field of view is large enough. Is the "Max. Part Diameter" for the
nozzle tip you're using large enough?
For more debugging you may open the pipeline editor by clicking the
"Edit" bottom in the "Pipeline" line and go trough the list to see whats
actually going wrong. Suppose you're using the latest test version
(which is recommended) and using the "- Default Machine Bottom Vision -"
or a descendant you have two sliders to change "Threshold" and "Min.
Detail Size". If play with them, you'll see detection results and can
optimize them. For older OpenPnP versions or different pipelines you'll
have to use the pipeline editor to analyze and fix the issue.

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/38d7f44d-d5c7-45d8-8492-fed010c6a51cn%40googlegroups.com <https://groups.google.com/d/msgid/openpnp/38d7f44d-d5c7-45d8-8492-fed010c6a51cn%40googlegroups.com?utm_medium=email&utm_source=footer>.

[mark maker]

Hi David

as Jan already pointed out do not use the vision offsets, they are only used in very exotic cases.

From your log it becomes evident, that the threshold (between dark background and bright pins) is not right:

2023-10-21 14:35:54.201 MaskHsv TRACE: Fraction actually masked = 0.990929459600556

This means that almost the whole image is being masked, i.e. it does not actually recognize just the pins.

First make sure to use the newest test version of OpenPnP. It has the best support for bottom vision.

Then make sure you have the new stock settings and pipelines for bottom vision, as described here:

https://github.com/openpnp/openpnp/wiki/Bottom-Vision

If you come from an older machine configuration or OpenPnP version, chances are you don't have them yet.

Then you should be able to adjust the threshold, as shown in this animation:

_Mark

[David Moorhouse]

Thanks for the feedback and help guys. I can confirm I'm using version 2023-08-20_11-22.37 beb77a7

I though I was on the wrong track with the offsets so will follow up with you suggestions.  I feel like I'm so close but still so far - so feeling a little lost and frustrated.

I'll follow through the steps you have suggested

[David Moorhouse]

OK, following through the pipeline steps was very helpful - thanks.

The image masking step showed a large bright artefact to the left of the chip. This turned out to be the pulley for the rotation (on the Liteplacer). So I have cut a piece of black foam and zip tied this to the head just below the pulley which has cleaned up the images and now only the pins of the TSSOP20 are detected.

The placement accuracy has improved although it is still about 1/2 a pin width of to the right (so approx 0.15mm) I'm not sure if this is a problem (i.e. will the reflow pull the chip into alignment) or whether this is a limit to the accuracy of this machine.

My next test is a QFN48 - this has a 0.5mm pitch so I'll feedback on how this goes.

[David Moorhouse]

I've just placed and reflowed a test board. I'd also set up SOT23-5 and SOT23-6 packages. All were placed with acceptable accuracy with the surface tension pulling the parts into final alignment.

Thanks for the help.

P.S. I've got another issue with picking (rather than placing) parts - I'll start a new topic.

[mark maker]

> The placement accuracy has improved although it is still about 1/2 a pin width of to the right (so approx 0.15mm)

May points to either

• Nozzle tip to camera offset inaccuracy (recalibrate using I&S)
• or backlash compensation problem

_Mark

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/eb82d15b-edeb-4995-b08c-d41f5dbd1cb2n%40googlegroups.com.

[David Moorhouse]

Thanks Mark

I had checked the nozzle to camera, looks to be ok. I'll check the backlash.

[David Moorhouse]

The backlash is within spec, close to zero in X and less than 0.05mm in Y.

However I think there was an error with the setup for the GCode settings for the TinyG driver.

The distance per revolution had been changed from the theoretical 40mm per revolution. Based on some actual measurements along the axis of a board that I measure with a micrometer to two decimal places:

The X axis was
               <text><![CDATA[$2tr=40.0539]]></text>

I've changed it to

               <text><![CDATA[$2tr=40.075]]></text>

And the Y axis was

               <text><![CDATA[$1tr=40.102]]></text>
I've changed it to
               <text><![CDATA[$1tr=39.965]]></text>

The Y axis discrepancy explains why component placement further away from the origin was offset.

Interestingly the Issues and Solutions does not help with this part of the calibration.

[tonyl...@gmail.com]

>The Y axis discrepancy explains why component placement further away from the origin was offset.

The exact scaling of your axes shouldn't really matter assuming you are using three or more fiducials on your boards. The fiducial check automatically compensates for any scaling differences between your machine and the PCB.

Tony

[David Moorhouse]

 I'm using strip feeders so the more accurate the scaling the better the picking will be.

[mark maker]

Tony is right and the Strip Feeder should also continuously recalibrate itself using sprocket hole vision. Even if not, bottom vision should compensate for any pick inaccuracy.

> Interestingly the Issues and Solutions does not help with this part of the calibration.

Such a scaling calibration, including axis squareness was/is being discussed, and Tony even already made the algorithm. 

However it is not so easy. Unless very carefully and strictly made safe, it would very likely create more problems in "real life" than it would solve. Especially when used from an easy to use UI such as I&S, where people don't actually need to know what they are doing. 😇

Changing the machine scale like that, essentially renders all coordinates already captured in OpenPnP invalid. So it would only be allowable at the very beginning of a machine build, where you have no stored coordinates yet (or just a few that are known and could be adjusted by OpenPnP). 

But the experience doing support here on the list tells me that such a strict limitation to the very beginning is utterly unrealistic/useless. People do shortcuts in I&S, reuse old or bad machine.xml from other people, where I&S is already done or dismissed, only realize they need to improve the accuracy when the machine is already finished and all feeders already setup, etc. Or they have a bad machine crash, or a modification of the machine, and need to re-calibrate.

So to be useful, this scaling and squareness calibration would need to be available at all times. Therefore, if we ever wanted to introduce it, we would need to have functionality that is able to enumerate all stored coordinates, and apply a before-and-after-transformation. Until then we better leave it as it is. 

This is acceptable, because all the most critical "absolute scale" areas in OpenPnP have their own local Affine Transformation calibration or similar: the PCB/Panel with fiducials, BlindsFeeder array with fiducials, Strip Feeders with sprocket holes vision, PushPullFeeder with sprocket holes vision, nozzle tip changer template image vision, etc. pp. This "local area" calibration also covers any errors when things are mountable/pluggable on the machine, including tinkering. The overall absolute machine scaling and squaring therefore becomes mostly irrelevant, i.e., any absolute scaling or squaring error is already present when you capture a coordinate so it does simply not matter, when you later position back to it. PnP is much more lenient that way than other NC applications.

_Mark

On 29.10.2023 06:30, David Moorhouse wrote:

Yeah nah. I'm using strip feeders so the more accurate the scaling the better the picking will be.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/8b3f4c4a-6005-4437-8da7-ea1e4a5dc3a6n%40googlegroups.com.