Panelization - how should it work?

[tonyl...@gmail.com]

This is a continuation of some of the discussion on this thread.  

I've been looking at the panelization feature and have added the ability to set more than two fiducials on the panel.  I also changed it so that the individual board Affine transforms get set appropriately when the panel's fiducials are checked - that way, if your boards don't individually have fiducials, they can still benefit from any x-y scaling and shear corrections that were calculated for the panel (in addition to the rotation and location corrections).  Of course, if the boards do have fiducials, they can still be checked as well.

I've tested this on a top panel that I purposefully introduced scaling and shear errors using my CAD program, and it worked well to remove the errors I induced.  However, bottom panels are a bit of a mess right now because they are handled somewhat inconsistently with respect to boards.

Here is how a board is currently handled:

To populate the bottom of a board, you just need to flip it over and you're pretty much good to go as OpenPnP calculates the bottom placement's X coordinate by adding the board's width to the boards location and subtracting the placement's x coordinate. 

Now here is how a panel is currently handled:

Notice that on the top panel, everything is consistent, but on the bottom panel, the direction of the panel's x-axis is opposite the board's x-axis, that the panelization numbering is inconsistent with the top panel, and that if the panel is left-right asymmetric, the panel location has to change when flipping it from top to bottom.

 

I propose to change the panelization to allow for an offset between the panel origin and the root board origin, to add a panel width (and height although not used), and to make the numbering consistent between top and bottom panels. Panel coordinates would be defined to work just like board coordinates (always defined by viewing through the board/panel from the top side). this would allow panels to just be flipped over (like a single board) for populating the bottom.  Here is how it would look:

This makes all the math a lot easier to keep consistent and I think also makes the feature easier to use - any comments or strong pushback on this?

Tony

[mark maker]

👍👍👍

--
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/205de278-a074-4ca9-9810-b3fd3d1b6793n%40googlegroups.com.

[Jan]

Hi Tony!
I like the idea! Will it work with multiple PCB designs in a panel?
Will x-outs work for the bottom side? I'd expect that I can select the
boards viewing the panel from the bottom side (while loading into the
machine).

Jan

PS: I've a few designs and old PCBs to test with.

On 08.02.2022 00:21, tonyl...@gmail.com wrote:
> This is a continuation of some of the discussion on this thread

> <https://groups.google.com/g/openpnp/c/BxV6MObRA9M>.

>
> I've been looking at the panelization feature and have added the ability
> to set more than two fiducials on the panel.  I also changed it so that
> the individual board Affine transforms get set appropriately when the
> panel's fiducials are checked - that way, if your boards don't
> individually have fiducials, they can still benefit from any x-y scaling
> and shear corrections that were calculated for the panel (in addition to
> the rotation and location corrections).  Of course, if the boards do
> have fiducials, they can still be checked as well.
>
> I've tested this on a top panel that I purposefully introduced scaling
> and shear errors using my CAD program, and it worked well to remove the
> errors I induced.  However, bottom panels are a bit of a mess right now
> because they are handled somewhat inconsistently with respect to boards.
>
> Here is how a board is currently handled:

> boardTopBottom.png
>
> To populate the bottom of a board, you just need to flip it over and
> you're pretty much good to go as OpenPnP calculates the bottom
> placement's X coordinate by adding the board's width to the boards
> location and subtracting the placement's x coordinate.
>
> Now here is how a panel is currently handled:

> currentTopBottomPanelization.png
> Notice that on the top panel, everything is consistent, but on the
> bottom panel, the direction of the panel's x-axis is opposite the
> board's x-axis, that the panelization numbering is inconsistent with the
> top panel, and that if the panel is left-right asymmetric, the panel
> location has to change when flipping it from top to bottom.
> I propose to change the panelization to allow for an offset between the
> panel origin and the root board origin, to add a panel width (and height
> although not used), and to make the numbering consistent between top and
> bottom panels. Panel coordinates would be defined to work just like
> board coordinates (always defined by viewing through the board/panel
> from the top side). this would allow panels to just be flipped over
> (like a single board) for populating the bottom.  Here is how it would look:

> proposedTopBottomPanelization.png
>
> This makes all the math a lot easier to keep consistent and I think also
> makes the feature easier to use - any comments or strong pushback on this?
>
> Tony
>

> --
> 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/205de278-a074-4ca9-9810-b3fd3d1b6793n%40googlegroups.com

> <https://groups.google.com/d/msgid/openpnp/205de278-a074-4ca9-9810-b3fd3d1b6793n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[tonyl...@gmail.com]

>Will it work with multiple PCB designs in a panel?

Not at this time - it will still be a single PCB design per panel but that is certainly an option for future updates.

>Will x-outs work for the bottom side? 

My intent is that you can x-out a board from either side and when flipping the board, any previously set x-outs will still be in effect (the same boards will be x'ed-out regardless of which side of the panel is being placed).

>I'd expect that I can select the
boards viewing the panel from the bottom side

You will be able to view (and set) the x-outs from either side, and when viewing the x-outs from the bottom, the column numbering will change to right-to-left.  For example, on an n by m panel the numbering would be shown as:

Top:

(n,1),     (n,2), ...,   (n,m)

(n-1,1), (n-1,2), ..., (n-1,m)

.

.

.

(1,1),     (1,2), ...,   (1,m)

Bottom:

(n,m),     (n,m-1), ...,   (n,1)

(n-1,m), (n-1,m-1), ..., (n-1,1)

.

.

.

(1,m),     (1,m-1), ...,   (1,1)

[Dave McGuire]

Oh I'm very much looking forward to that test build!

-Dave

On February 7, 2022 6:21:18 PM "tonyl...@gmail.com" <tonyl...@gmail.com> wrote:
> This is a continuation of some of the discussion on this thread

> <https://groups.google.com/g/openpnp/c/BxV6MObRA9M>.

> --
> 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/205de278-a074-4ca9-9810-b3fd3d1b6793n%40googlegroups.com.



--
Dave McGuire
McGuire Scientific Services, LLC
New Kensington, PA

[fxframes]

This looks awesome, can’t wait to try it out.

One question, though. As jobs get longer shouldn’t there be a “re-homing” routine that can be added as if it were a fiduciary or a part, to reset the accumulated error on the machine? I’ve been running a 185-placement job lately and even though OpenPnP leaves the larger parts to the end it’s noticeable that the placement precision does accumulate some errror.

Thanks.

[fxframes]

Fiducial* damn autocorrect

[tonyl...@gmail.com]

>As jobs get longer shouldn’t there be a “re-homing” routine that can be added as if it were a fiduciary or a part, to reset the accumulated error on the machine? 

Well, that was sort of covered in the original thread - when I brought up adding local fiducial checks for only certain placements, everyone crapped on it.  I think it's still a good idea but out of scope of the current panelization changes.

Tony

[mark maker]

> I brought up adding local fiducial checks for only certain placements, everyone crapped on it.

If you're referring to what others and me said about thermal expansion, I just meant thermal expansion, not local fiducials per se. There was a post earlier from a user with a linear encoder where he could show cyclic (sinusoidal) errors by belt idler runout. In his case the errors were still small enough to be ignored, but I can imagine that sort of error to become significant.

So I do think that local fiducials for particularly sensitive parts could make sense. And I argued for a 2D mesh interpolation to make the resulting local coordinate adjustments continuous to surrounding areas. So e.g. these 0201 caps near the big MCU's pins are placed nearly as precisely.

In fact once a 2D mesh interpolation is available, one could throw all fiducials into one big model: Panel fiducials, board fiducials, part fiducials, it would take whatever is available (including, remember, that user's small boards with just one fiducial, which is not supported today) and provide the best coordinate system fit available.

If the model is made updatable, the local part fiducials could just be added/updated near the time when that part is assembled. So any creep in the board position (or whatever can happen) is caught.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f28ea925-b2de-4218-8366-197751b6a7b1n%40googlegroups.com.

[Jan]

Hi Tony!

On 08.02.2022 17:10, tonyl...@gmail.com wrote:
> >Will it work with multiple PCB designs in a panel?
>
> Not at this time - it will still be a single PCB design per panel but
> that is certainly an option for future updates.
>

I don't need it at present. So for me its absolutely ok, if that's not
supported.

That sounds cool! I already benefited a lot by your
3-fiducial-per-panel-xml "hack" and I'll have a double sided panel
design in the next weeks. So if you'd implement that, I'll be very happy
to test it and report. (I have a couple of older double sided panel
designs laying around, that I can immediately use for testing...)

Jan

> <https://groups.google.com/d/msgid/openpnp/205de278-a074-4ca9-9810-b3fd3d1b6793n%40googlegroups.com?utm_medium=email&utm_source=footer
> <https://groups.google.com/d/msgid/openpnp/205de278-a074-4ca9-9810-b3fd3d1b6793n%40googlegroups.com?utm_medium=email&utm_source=footer>>.

>
>
> --
> 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/a339e272-9980-48e0-bd26-3615e2c402e3n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/a339e272-9980-48e0-bd26-3615e2c402e3n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan]

Hi fxframes!
Would you please tell me how you accumulate errors over the run? I'm
wondering if there is readly a need for multiple fiducial checks per
run, but can't see it at present. Do you have mechanical issues? How do
you handle feeder locations if you accumulate errors?

Jan

> <https://groups.google.com/d/msgid/openpnp/205de278-a074-4ca9-9810-b3fd3d1b6793n%40googlegroups.com>.

>
>
>
>
> --
> Dave McGuire
> McGuire Scientific Services, LLC
> New Kensington, PA
>
>

> --
> 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/51385a1f-f061-4365-a764-c2c185cc7f02n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/51385a1f-f061-4365-a764-c2c185cc7f02n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jan]

Hi Mark! Hi Tony!
Please keep in mind, that the more math you put in, the more errors
might arise from it. Remember what happens if a single measurement of
the nozzle to camera calibration, advanced camera calibration or the
nozzle tip calibration fails. Please pay special attention to the error
propagation within the model. If there is something like 1/x or (x1-x2),
with x, x1 and x2 measurement values, in, their errors can strongly
amplify invalidating the entire model.
Vision operations are proven to errors in input data and pipeline
setup. However, calibration work is only done once, so it would be ok to
take multiple measurements and make sure the results are consistent even
though this slows the process down.

Jan

On 09.02.2022 08:53, mark maker wrote:
> /> //I brought up adding //local fiducial checks for only certain
> placements, everyone crapped on it. /

>
> If you're referring to what others and me said about thermal expansion,
> I just meant thermal expansion, not local fiducials per se. There was a
> post earlier from a user with a linear encoder where he could show
> cyclic (sinusoidal) errors by belt idler runout. In his case the errors
> were still small enough to be ignored, but I can imagine that sort of
> error to become significant.
>
> So I do think that local fiducials for particularly sensitive parts
> could make sense. And I argued for a 2D mesh interpolation to make the
> resulting local coordinate adjustments continuous to surrounding areas.
> So e.g. these 0201 caps near the big MCU's pins are placed nearly as
> precisely.
>
> In fact once a 2D mesh interpolation is available, one could throw all
> fiducials into one big model: Panel fiducials, board fiducials, part
> fiducials, it would take whatever is available (including, remember,

> that user's small boards with/just one/ fiducial, which is not supported

> today) and provide the best coordinate system fit available.
>
> If the model is made updatable, the local part fiducials could just be
> added/updated near the time when that part is assembled. So any creep in
> the board position (or whatever can happen) is caught.
>
> _Mark
>
> Am 08.02.2022 um 21:50 schrieb tonyl...@gmail.com:
>> >As jobs get longer shouldn’t there be a “re-homing” routine that can
>> be added as if it were a fiduciary or a part, to reset the accumulated
>> error on the machine?
>>
>> Well, that was sort of covered in the original thread

>> <https://groups.google.com/g/openpnp/c/BxV6MObRA9M> - when I brought

>> <https://groups.google.com/d/msgid/openpnp/f28ea925-b2de-4218-8366-197751b6a7b1n%40googlegroups.com?utm_medium=email&utm_source=footer>.

>
> --
> 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/13c2a227-541c-3332-69ac-d7a1b6478db3%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/13c2a227-541c-3332-69ac-d7a1b6478db3%40makr.zone?utm_medium=email&utm_source=footer>.

[mark maker]

Hi Jan,

I can't follow you there.

In my experience these vision operations are quite reliable. Remember, I explained the "fitness test" character of these calibrations a while back? If you can't get 100% reliable fiducial locator success on a simple printed fiducial, then you must fix the underlying problem (in your case I believe it was about lighting). I also explained the relationship between obtainable vision precision and mechanical precision a while back for the case of the fiducial locator, so throwing vision at a problem, is almost always "good".

I've implemented vision calibration multiple times now, and I've helped improve pre-rotate bottom vision and nozzle tip calibration, plus I made most of the Issues & Solutions calibrations, most notably the backlash calibration, and the precision nozzle head offsets calibration, where the relationship between mechanical motion, precision and vision is very nicely laid out.

In all these vision applications I can observe very consistent and robust operation on my Liteplacer. That's a simple extrusion + stepper + belt machine, affordable ELP camera, cheap LED ring + paper diffuser lighting, which I consider close to a "minimum" DIY configuration, i.e. everybody should be able to achieve that or better. I observe excellent convergence of measures when using vision to improve precision. So when you say "the more math you put in, the more errors might arise from it", I must disagree strongly.

The real problems in vision application, according to my experience are

a) underlying machine problems that users think they can somehow ignore for the moment and (maybe) solve later,

b) bad cameras with "Auto" settings that cannot be switched off, leading to unstable pipelines,

c) users (understandably!) being out of their depth in the pipeline editor.

Needless to say,

a) the real underlying machine problem must be solved. I'm talking about stuff that simply needs to be fixed, or bad components that simply need to be replaced, because they are flawed in a fundamental, unfixable way, like the Auto-only-cameras in (b). Note, I'm not talking about supporting simple/affordable/everybody's-DIY-skills solutions, even knowing they are not as good as the Übermechanic's super-duper/expensive/need-a-pro-workshop solutions. In fact I've improved and added many features to support exactly these smart make-do solutions, and often by "putting more math in".

b) users just need to replace these cameras (or live with the errors),

c) pipeline editing should become unnecessary for all but the most exotic circumstances. I'm working on a set of pipelines that need no more tuning. I believe that is already the case with the DetectedCircularSymmetry stage. I already have a DetectRectlinearSymmetry stage in prototyping that does the same for all (semi-) symmetric parts in bottom vision, working on asymmetric parts now. Some vision applications (feeders) also need to be smartened up semantically, i.e. they should know where stuff can or cannot be in the image.

To sum it up: More math = progress 😁

_Mark

[Jan]

Hi Mark!
I'm sorry, if I said something that might sound like I would blame you
for any issues I might had and still have.
As you said, there are a lot of pitfalls you have taken, analyzed,
documented and fixed. This is extremely helpful for the entire project
and everyone willing to read and try to understand them will make a huge
progress with their machines. However, each math operation takes inputs
to compute some output and in the physical world we're in each input has
an associated error which is propagated to the output through the math.
Hence after applying math, the output depends on the errors of it's
inputs. For someone with your knowledge and understanding it's likely
easy to minimize most of this input errors. If the math is robust with
respect to input errors, this will likely result in a system where the
effect of the input errors on the output is negotiable. However, for
someone like me, how is still trapped in some pitfalls, this might be
not the case and the results might look quite bad and hide the true
issues. So, the only thing I'd like to ask you for, is, please try to
detect input errors and report them before you apply fancy math to
correct them or use them for something else.
As you said, all the calibration work you've done, makes a huge
progress for the machine reliability and placement quality, however, it
can never be better then the vision that's used as it's input. If the
camera setup is bad, the calibration will be too.

Jan

On 09.02.2022 11:30, mark maker wrote:
> Hi Jan,
>
> I can't follow you there.
>
> In my experience these vision operations are quite reliable. Remember, I
> explained the "fitness test" character of these calibrations a while
> back? If you can't get 100% reliable fiducial locator success on a
> simple printed fiducial, then you must fix the underlying problem (in
> your case I believe it was about lighting). I also explained the
> relationship between obtainable vision precision and mechanical
> precision a while back for the case of the fiducial locator, so throwing
> vision at a problem, is almost always "good".
>
> I've implemented vision calibration multiple times now, and I've helped
> improve pre-rotate bottom vision and nozzle tip calibration, plus I made
> most of the Issues & Solutions calibrations, most notably the backlash
> calibration, and the precision nozzle head offsets calibration, where
> the relationship between mechanical motion, precision and vision is very
> nicely laid out.
>
> In all these vision applications I can observe very consistent and
> robust operation on my Liteplacer. That's a simple extrusion + stepper +
> belt machine, affordable ELP camera, cheap LED ring + paper diffuser
> lighting, which I consider close to a "minimum" DIY configuration, i.e.
> everybody should be able to achieve that or better. I observe excellent
> convergence of measures when using vision to improve precision. So when

> you say /"//the more math you put in, the more errors might arise from
> it"/, I must disagree strongly.

>
> The real problems in vision application, according to my experience are
>
> a) underlying machine problems that users think they can somehow ignore
> for the moment and (maybe) solve later,
>
> b) bad cameras with "Auto" settings that cannot be switched off, leading
> to unstable pipelines,
>
> c) users (understandably!) being out of their depth in the pipeline editor.
>
> Needless to say,
>
> a) the real underlying machine problem must be solved. I'm talking about
> stuff that simply needs to be fixed, or bad components that simply need
> to be replaced, because they are flawed in a fundamental, unfixable way,

> like the Auto-only-cameras in (b). Note, I'm *not *talking about

> supporting simple/affordable/everybody's-DIY-skills solutions, even
> knowing they are not as good as the Übermechanic's
> super-duper/expensive/need-a-pro-workshop solutions. In fact I've
> improved and added many features to support exactly these smart make-do

> solutions <https://makr.zone/tag/openpnp/>, and often by /"putting more
> math in"//./

>
> b) users just need to replace these cameras (or live with the errors),
>
> c) pipeline editing should become unnecessary for all but the most
> exotic circumstances. I'm working on a set of pipelines that need no
> more tuning. I believe that is already the case with the
> DetectedCircularSymmetry stage. I already have a
> DetectRectlinearSymmetry stage in prototyping that does the same for all
> (semi-) symmetric parts in bottom vision, working on asymmetric parts
> now. Some vision applications (feeders) also need to be smartened up

> /semantically/, i.e. they /should /know where stuff can or cannot be in

> https://groups.google.com/d/msgid/openpnp/60b4cf3b-9aa6-37f9-7c63-87e70258f63d%40makr.zone
> <https://groups.google.com/d/msgid/openpnp/60b4cf3b-9aa6-37f9-7c63-87e70258f63d%40makr.zone?utm_medium=email&utm_source=footer>.

[fxframes]

Hi Tony,

Sorry for hijacking your thread...

> Hi fxframes!
Would you please tell me how you accumulate errors over the run? I'm
wondering if there is readly a need for multiple fiducial checks per
run, but can't see it at present. Do you have mechanical issues? How do
you handle feeder locations if you accumulate errors?

Hi Jan,

I see the discussion here being heavily centered on the initial fiducial check, but my concern is more related to long runs of placements.

My understanding is that once the initial fiducial check is performed at the beginning of a job, the head moves around causing the inherent errors of this being a real, mechanical system to accumulate. Bear with me for a moment, please. Let's start a job, so the fiducials are checked and the head goes out to find the first part. The inaccuracies of the machine together with the tolerance accepted for the backlash algorithm imply that when the head reaches the index hole on that first tape there's absolutely no way the head is exactly where OpenPnP thinks it is, regardless of compensations. Granted, though, that error should be very small and negligible for all intents and purposes. Let's continue, so the head moves to the bottom camera and the part – not the nozzle tip – is checked against bottom vision and is then taken to its placement position where it's lowered down and placed. The two extra movements also have inherent positioning errors that are only partly compensated with backlash and other settings, so the error accumulates. For as long as we don't change the nozzle tip, unless I'm missing something here – which is not unlikely :) – the head's position isn't being checked against a fixed reference so positional errors are accumulating. Again, even after a dozen placements the erros is likely to be negligible, but what about after 100 placements?

I can see that when a nozzle tip is changed, the newly equipped one would be re-centered about the bottom camera position which is a fixed reference so that seems to take care of "restarting" the head.

In my case I have some longer jobs, one of them having 185 placements. The last one is a 128-pin TQFP which uses nozzle tip #5 and even though it's not bad, it's just not as repeatable as the first 0603s at the beginning of the job which are "perfect" every single time. When I force OpenPnP to start the job with Nozzle #5 there seems to be a bit more consistency. The fist thing that I though is that the the vision pipeline isn't perfect but it actually seems to be spot on every time, I always keep an eye on it which led me to think accumulating errors might be a factor after 184 previous placements, when that part is placed last. What I do sometimes is break the job into two parts and that seems to give me a bit more repeatability and consistency but I have no measurements to back that up.

Anyway I could be totally wrong about this but I don't see how adding an option to allow the user to insert a mid-way fiducial check would hurt. It would be a conscious decision to sacrifice a few seconds of job time for a hypothetically more reliable job. 

Sorry for the long post and thanks.

[Niclas Hedhman]

On 2022-02-09 14:53, fxframes wrote:

> My understanding is that once the initial fiducial check is performed
> at the beginning of a job, the head moves around causing the inherent
> errors of this being a real, mechanical system to accumulate.

The errors for backlash, skew, pixel inaccuracy and so on are "static",
i.e. they don't (or shouldn't) add up "per cycle". If they do, then you
are probably having missed steps in stepper/servo motors (or worse).

> Anyway I could be totally wrong about this but I don't see how adding
> an option to allow the user to insert a mid-way fiducial check would
> hurt. It would be a conscious decision to sacrifice a few seconds of
> job time for a hypothetically more reliable job.

So, even though this sounds like a reasonable request, perhaps looking
at the mechanical reasons for increasing errors is better spent time?

Cheers
Niclas

[Jan]

Hi fxframes!
As Niclas already said, we're usually using controller and motors, that
position the machine to an absolute coordinate every time. So there is
no inherent error that can add up over time. However, you still have
errors that manifests in the difference between actual and requested
position. This should be small compared to the required precision by
design and don't care for this discussions.
I agree, there is nothing wrong in adding inter-job-fiducial-checking.
It's just I'm not convinced, because it probably hides the actual
problem. And solving the underlying problem would be better then
spending valuable programmers time implementing a workaround.
However, I you feel, you're affected by long run error accumulation,
you can measure it already today: just repeat the PCB fiducial check and
compare the numbers to the previous measurement. Make sure you make
yourself familiar with the residual errors of the method by repeating
the measurement a few time. The mean and rms over this measurements are
a good indication for its quality. The rms value gives you (assuming you
have done infinite measurements and the error is statistically
distributed) the probability, that 67% of all measurements are better
then this value (see https://en.wikipedia.org/wiki/Standard_deviation
for details). This means on the other hand, that 33% of all measurements
are outside the band mean +- rms. I'd say, you're affected if you find a
measurement that is more then five time the rms value away from the
mean. And even then, one has to keep in mind, that such a measurement is
not impossible, just unlikely...
If you don't change nozzle tips in the runs, you can also repeat the
nozzle tip calibration and take this numbers as measure for the
head-to-bottom-camera position error. If change nozzle tips, you would
measure the sum of nozzle tip removal and insertion error and
accumulated head position error. Hence this sum is less relevant because
you probably can't disentangle the two components.
What ever you find, I'm curious to hear!

Jan

On 09.02.2022 14:53, fxframes wrote:
> Hi Tony,
>
> Sorry for hijacking your thread...
>

> > /Hi fxframes!

> Would you please tell me how you accumulate errors over the run? I'm
> wondering if there is readly a need for multiple fiducial checks per
> run, but can't see it at present. Do you have mechanical issues? How do

> you handle feeder locations if you accumulate errors? /
>
> Hi Jan,
>
> I see the discussion here being heavily centered on the /initial/

> fiducial check, but my concern is more related to long runs of placements.
> My understanding is that once the initial fiducial check is performed at
> the beginning of a job, the head moves around causing the inherent
> errors of this being a real, mechanical system to accumulate. Bear with
> me for a moment, please. Let's start a job, so the fiducials are checked
> and the head goes out to find the first part. The inaccuracies of the
> machine together with the tolerance accepted for the backlash algorithm
> imply that when the head reaches the index hole on that first tape

> there's absolutely no way the head is /exactly/ where OpenPnP thinks it

> --
> 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/faf51bbd-3361-4a63-bbbd-3e5c2e0ee966n%40googlegroups.com
> <https://groups.google.com/d/msgid/openpnp/faf51bbd-3361-4a63-bbbd-3e5c2e0ee966n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[tonyl...@gmail.com]

>Please keep in mind, that the more math you put in, the more errors

might arise from it. 

That is rather specific - I'd generalize it to be the more <insert your favorite bugaboo here - math, software, firmware, hardware, etc.> you put in the more error that might arise from it.  While that's true, we mitigate it by reviewing and testing. And adding more <whatever you inserted here before> can also have great benefit as well - if that's not so, then we would all be hand placing our parts instead of using a pick-and-place machine - there's already a lot of math, software, firmware, and hardware that got added at some time or another. 

>Remember what happens if a single measurement of
the nozzle to camera calibration, advanced camera calibration or the
nozzle tip calibration fails.

I didn't personally write the nozzle to camera offset calibration so I can't speak for it.  I did write the advanced camera calibration and it does handle missing data points and it also checks for and remove outliers from the data it does collect. Nozzle tip calibration also has the capability to handle missing data points although it could stand to have some robustness added to check for and ignore outlier points - it just needs a bit more math and software to do it😉

Tony

[dennis bonotto]

Hi Jan,

Thanks for the constructive reply.

> As Niclas already said, we're usually using controller and motors, that position the machine to an absolute coordinate every time. So there is no inherent error that can add up over time.

I’m sorry but this is just not true. There’s nothing ever “absolute” about a real-world system. There’s a long chain of errors that stem from the power supply and pass through the controller, the motors and all the mechanical errors on the machine. In the end it might as well be the case that the total error accumulated is not significant to the job, but it’s not like they’re not there.

Let’s take the DRV8818s that are on the TinyG which controls my Liteplacer, for example. The current control accuracy is specified to be between +/-5% to +/-10%, and that’s presuming all the other components that control the symmetry of the current outputs to the coils are to great precision.

Then there’s the motor itself, you’re assuming that a $10 motor has perfectly symmetrical coil windings, no detent error, no shaft alignment issues. Common stepper motors are specified as having around a 5% position error which can be reduced with micro stepping, but again it’s not like they just vanish.

And finally, all mechanical components of the machine are manufactured to a certain precision, of course.

But again, none of that matters too much as long as the combined, total error is below what’s acceptable for placement.

> I agree, there is nothing wrong in adding inter-job-fiducial-checking. It's just I'm not convinced, because it probably hides the actual problem. And solving the underlying problem would be better then spending valuable programmers time implementing a workaround.

I never said I needed something done, let alone needing it done quickly or at any time, in fact. I obviously don’t control or influence the programmers’ time or schedule. I was merely asking questions and seeking advice, so I don’t really understand when an answer is unnecessarily dismissive. This discourages people wanting to help and test new features out, as well as questions and observations from me and others.

> However, I you feel, you're affected by long run error accumulation, you can measure it already today: just repeat the PCB fiducial check and compare the numbers to the previous measurement. Make sure you make yourself familiar with the residual errors of the method by repeating the measurement a few time. The mean and rms over this measurements are a good indication for its quality. The rms value gives you (assuming you have done infinite measurements and the error is statistically distributed) the probability, that 67% of all measurements are better then this value (see https://en.wikipedia.org/wiki/Standard_deviation for details). This means on the other hand, that 33% of all measurements are outside the band mean +- rms. I'd say, you're affected if you find a measurement that is more then five time the rms value away from the mean. And even then, one has to keep in mind, that such a measurement is not impossible, just unlikely...

   If you don't change nozzle tips in the runs, you can also repeat the nozzle tip calibration and take this numbers as measure for the head-to-bottom-camera position error. If change nozzle tips, you would measure the sum of nozzle tip removal and insertion error and accumulated head position error. Hence this sum is less relevant because you probably can't disentangle the two components.

Thanks, I’m an engineer and understand statists, right now I have a large batch to run but when I find the time I will go back and take the measurements.

[mark maker]

Others have already brushed it, some facts:

1. In general, if an error is repeatable, when you capture a position e.g. by using computer vision and later go back to it, the error is eliminated. By using local interpolation, like between calibrated fiducials, the same is true for any position in between, and only relative/cyclic errors within that interpolation remain.
   
2. Stepper motor or servo+encoder machines with belts or lead screws do not accumulate errors. Both the steps/encoder pulses and the belt teeth/lead screw threads are physically attached to absolute angular and then linear positions. They may not be 100% accurate in the sub-division of one motor revolution, or for belts/screws along their length, but these errors are repeatable, they do not accumulate, belts can't slip whole teeth in the pulley, lead screws can't jump threads, stepper motor stators don't move in the housing.
   
3. Micro-steps are subject to outside forces, so they may not be accurate, or at least not up to the full micro-step resolution. But these errors again do not accumulate, rather they are partly random and partly repeatable. They can be made more repeatable by using a more conservative backlash compensation, like the OneSided method with a large offset.
   
4. We drive Gcode with absolute coordinates (not relative like in 3D printing), so even if the controller is using float coordinate representation internally, or if the G-code fractional decimal representation is converted to non-decimal integral representation, we will still not accumulate any numerical errors.
   
5. Even if you still assume some accumulative/growing positioning error, with bottom vision that error is simply cancelled out, because the same accumulated error would be present, both, when the part is held over the camera and when the part is placed, seconds later.
   
6. So only relative/cyclic and random errors remain. And these - so experience shows - are tolerable.
   

So if somebody is seeing accumulative placement errors, I would check anything that can slip. For instance, if the PCB is held tight enough. I've seen user PCB holder designs with magnets, conveyors merely clamping boards weakly etc., and I could imagine that repeated placements nozzle pokes could slowly make the PCB creep into one direction.

_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/BD2D7441-7E83-48A7-8AF7-E9D0ABD91E41%40gmail.com.

[fxframes]

Alright Mark, you've always been so helpful and respectful so I'll just drop out of this topic. =)

Sorry again @Tony for hijacking it.