Align then rotate VERSUS rotate then align

[BendRocks]

Jason et al, what is the reason for aligning a part and then rotating it before placement? It seems you'd eliminate all eccentricity issues if you rotated prior to hitting the up camera for alignment. With 0.5mm pitch being common, and 0.125mm of runout being "really good", the placement accuracy is significantly degraded even on a good machine by rotating after aligning. 

[Jason von Nieda]

Hi Matt,

The idea has been raised many times, but no one has implemented it yet. We did API for it a while back, so if someone wants to tackle it all the framework is there. The API that was added was the ability to return a pre-rotated result from PartAlignment.

Jason

On Mon, May 22, 2017 at 8:53 PM BendRocks <mwtse...@gmail.com> wrote:

Jason et al, what is the reason for aligning a part and then rotating it before placement? It seems you'd eliminate all eccentricity issues if you rotated prior to hitting the up camera for alignment. With 0.5mm pitch being common, and 0.125mm of runout being "really good", the placement accuracy is significantly degraded even on a good machine by rotating after aligning. 

--
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 post to this group, send email to ope...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/78360aac-f223-4817-aa04-53f29bfd66aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Anton]

I still think all that needs to be done is to determine where the rotation axis is, and then the runout doesn't matter.  So, then you could image to determine current angle and center, rotate to position, and the center of the part should still be known, since you know the center that the part was rotated around.  Whether or not the nozzle wobbled shouldn't factor into it.

Probably it is aligned first, as you need to know the angle to rotate to. Otherwise, you would have to determine the rotation angle first, rotate to the desired angle, and then determine the center.  This would probably take longer since multiple image captures would be required.

[BendRocks]

Michael, the reason I think pre-rotating gets you most there there is that the runout is highly correlated to your current rotation and almost unknowable the further you get from your current rotation.

So, if you pick at 0 deg, and have to place at 180 degrees, if you pre-rotate to 180 before alignment, then it doesn't matter if if alignment tells you the actual angle is 185 or 175. In either case, your runout is almost the same. Yes, you could get more clever. But at this point, I think the aim would be to get rid of most of the error.

Jason, at the top of doPlace you are iterating over the nozzles and getting the board location. Could that same logic be trimmed a bit and replicated above at the end of doFeedAndPick() right after the pick() and movetosafeZ() around line 589? So, after you pick and retract, you get the board locations for each nozzle and blindly rotate to the indicated angle via MovableUtils.moveToLocationAtSafeZ()?

[Michael Anton]

I agree with what you are saying, but what I was proposing should get rid of all runout error.  Other than complicating calibration of the camera offsets, I don't see any other negatives.  The rotation center also happens to be an average of the runout error, so I think that would be the better pick point to use regardless.

[Jason von Nieda]

Hi Michael,

If I understand what you are saying, what you are referring to is what I call nozzle tip runout calibration. There is an issue filed for it here: https://github.com/openpnp/openpnp/issues/235

I implemented a first pass at this a while back, and while I was able to find the center of rotation well enough I couldn't get the code to actually apply the offsets working correctly. I'd like to revisit it eventually.

There is one major downside, which is what you have to re-run the calibration process every time you change a nozzle tip, unless you have some way of indexing it. You also need to, or at least should, run it every time you home or restart the machine.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/c2343a50-1374-45a2-a30a-d624da7f328c%40googlegroups.com.

[Jason von Nieda]

Matt,

Wouldn't that leave out the angle returned by the alignment step?

In any case, as I said, we've already got code in place to do this. The only real change that needs to be made is to change ReferenceBottomVision to rotate to the final rotation angle before performing alignment. If you look at line 675 of ReferencePnpJobProcessor that is where the "preRotated" logic is applied. This API was added to support mechanical alignment, but will also work for pre-rotated visual alignment.

There is more information about this in https://github.com/openpnp/openpnp/issues/401

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/9e8aa713-1832-4d8f-94a4-a49bf8e54b10%40googlegroups.com.

[Cri S]

This is not exact. There is a lot of vision process involved in order that this works and placement processor must support it.
If speed is not a concern, this can be simplified. If it's true that placement processor align part correctly and you can program and if you need it,
 i could make a initial scetch of vision stage that you verify and complete.

[Michael Anton]

Hi Jason,

I don't think we are talking about the same things.  If I understand your nozzle tip runout calibration correctly, it looks like the intent is to measure the center of the nozzle at a bunch of different angles, and then use those values to come up with the actual nozzle position based on the rotation angle.  As a result, you need to use a different set of values for each nozzle, and the initial nozzle orientation is important, unless you want to do the calibration on every nozzle change.

What I am proposing, is to use an average of the nozzle positions at multiple rotations (probably 3 or 4 positions would be enough), which would give the rotation center, rather than the actual nozzle position.  This wouldn't depend on which nozzle is installed, as the rotation center would be the same for all of them.  When not using bottom vision, the error will be dependent on how far the center of rotation is off the center of the the part.  The rotation will still occur around the rotation center, but the placement can have an error that depends on how far off the center of the part is when you picked it.  This is still independent of nozzle runout, but will obviously lead to higher placement errors than when using bottom vision.  When you are using the bottom vision, it would eliminate runout.  The nice thing is, that since it is independent of the nozzle runout, you don't care which nozzle is loaded, or what its orientation is.

I think the actual calibration might look something like this:

1) Lock the theta axis, by enabling the stepper driver, so the motor can't rotate easily

2) Plunge the nozzle into something like Silly Putty, to make a mark

3) Align the down looking camera to the mark

4) Move the nozzle to the up looking camera, and determine the center of the nozzle.  It may be necessary to move the nozzle to the center of the camera image, or onto crosshairs to get a good value.

5) Based on the two measurements, we now know the position of the two cameras relative to one another

6) Determine the center of rotation, by determining the nozzle center positions at 4 angles at 90 degree increments

7) Calculate the rotation center by averaging the the 4 positions from step 6

8) Calculate the offset between the center of rotation, and the down looking camera based on the result from step 5.  We may need to move the center of rotation to the same position as the nozzle was in in step 4 to get an accurate value, which would eliminate any camera distortion.

I haven't actually tried any of this yet, since I haven't built a machine.  It makes sense to me that this should be possible, as the only reason that nozzle runout matters is that we are not using the rotation center, and are instead assuming that the nozzle is at the center.  Alas, the nozzle is not at the center unless the runout is zero.

[Slava zzz]

Rotation center can be determined with only two angles, say 0 and 180. It will be exactly in the middle of two nozzle positions. It is true the center will be independent of the nozzle. That however is not very useful, since for many reason you have to pick up parts with the center of the nozzle, not with the center of rotation.

[alex]

Fully agree with Michael Anton.

Nozzletip runout really doesnt matter. What really maters is an axis of REAL rotation of the part. It should be known exactly.
When I'm calibrating my machine I'm setting up the bottom camera position not to the center of the nozzle, but to the point about which the nozle rotates - this point is usually a bit off the center on the nozzle and I'm rotating nozzle manually to see this point (not really precice though).

[BendRocks]

>> In any case, as I said, we've already got code in place to do this. The only real change that needs to be made is to change ReferenceBottomVision to rotate to the final rotation angle before performing alignment. If you look at line 675 of ReferencePnpJobProcessor that is where the "preRotated" logic is applied. This API was added to support mechanical alignment, but will also work for pre-rotated visual alignment.<<

OK, I got ya, so are you thinking that right after the camera is created in findOffsets() in RefBottVis something like this to pre-rotate:

MovableUtils.moveToLocationAtSafeZ(nozzle,camera.getLocation().derive(null,  null,  null,  placementLocation.getRotation()));

But I'm not clear in your #401 about the "final rotation" flag. Do you see this as always-enabled, or do you see "pre-rotate" as having a checkbox to enable some place? I can't really think of a reason NOT to pre-rotate when aligning. If that is the case, the the line above and the flag set to "true" in the ctor on PartAlignmentOffset would make sense and would enable pre-rotate always.

[Michael Anton]

Yes, it is true that the nozzle position may matter, especially for smaller parts.  It will obviously help if the runout is not too bad.  Like for instance, if the runout was in the 0.2mm range, you probably wouldn't have any difficulties picking 0402 parts, as at a worst case the rotation center would only be 0.1mm off the center of the nozzle, and the part is 0.5mm wide.  Now dropping down to 0201, might start to pose a problem, but then these would be difficult for DIY machines anyhow.

[Matt Brocklehurst]

Hi

I added the preRotate stuff - I've a mechanical rotation stage which has centering jaws on.

Part is picked, no rotation, placed on centering stage

Jaws pneumatically centre part

Platform is rotated to the final angle via a stepper to desired angle 

Part is picked up from platform and placed on the pcb

Matt 

Sent from my iPhone

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/eeef46da-5999-4768-b07c-199c404f52d8%40googlegroups.com.

[Jason von Nieda]

Hey Matt,

No, the angle will need to come from Utils2D.calculateBoardPlacementLocation, as this will also include the rotation of the board. 

I was thinking this would be a flag you enable, but if there is no downside in always doing it this way I'd be okay with making it a permanent change. I haven't had time to think it all through, so if you do want to make this change I'd appreciate if you give it some thought and determine whether this would negatively affect a traditional setup. Or just make it a flag. The flag would be on ReferenceBottomVisionConfigurationWizard.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/eeef46da-5999-4768-b07c-199c404f52d8%40googlegroups.com.

[Cri S]

If you have big nozzle runout and don't compensate it on SW,
you win a lot doing closed loop vision always.
If you don't have that problem you loose a lot cph and have more
limits about components
you can assembly and more position error is introduced.

T

>> <https://groups.google.com/d/msgid/openpnp/eeef46da-5999-4768-b07c-199c404f52d8%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .

>> For more options, visit https://groups.google.com/d/optout.
>>
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/iFQVZyUgnlA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/CA%2BQw0jwO9_Cymuf3ubpX8VT9Td378n5isa3_87FpdCSBCwN6qA%40mail.gmail.com.

[BendRocks]

Discussion continued here

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

[SMdude]

Awesome, I will try this out tonight.
Currently downloading...

I think this will make a big difference. I have tried hard to eliminate nozzle runout, but it is near on impossible, especially if you intend to use an auto nozzle changer and multiple nozzles per adaptor.

This change has happened just in the nick of time! I have just finished setting up my machine to do a run of boards that have that .3mm bga on them amongst other fine pitch components..

Will report back after I have tried it.

Thanks!

[SMdude]

Oh, silly question, where do I find this new checkbox?

Cheers!

[Jason von Nieda]

It's not merged into the release yet. Working on that now. Will report back once it's merged and can be downloaded.

Jason

On Sun, May 28, 2017 at 9:46 PM SMdude <spiteri...@gmail.com> wrote:

Oh, silly question, where do I find this new checkbox?

Cheers!

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/4e399057-965e-4291-8f79-d7c67a5edba0%40googlegroups.com.

[Jason von Nieda]

It's merged now. Give it 10 minutes from the timestamp on this email to build and then you can find it in the Latest release in Downloads, or via Auto Update. Look under Machine Setup -> Vision -> ReferenceBottomVision for the checkbox.

Many thanks to Matt for adding this feature!

Jason

[alex]

Thanks Matt and Jason, this is important feature!

[SMdude]

Nice!

What a difference that made! Thanks Matt and Jason!
Check out the alignment of the bga..

I do however get an error when in parts tab, after I have picked a part and when I click on test alignment, see attached error message.
However, this has been broken for the last few days for me and I'm not sure if it is an update(I'm sure originally I got an error when I clicked "pick part" in parts tab, but test alignment still worked).

Thanks :D

[Cri S]

Just as note, the current code don't take fiducial aligment into
account for rotation,
it does fiducial offset compensation. This is not a problem of the
aligment stage, it is just the
way jobProcessor calls the aligment stage.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/iFQVZyUgnlA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/13a23273-1b0f-48fd-8a44-788398e769ae%40googlegroups.com.

[Jason von Nieda]

Good catch Cri. The code to look at is in ReferencePnpJobProcessor:657. This is where fid overrides are applied. They also need to be applied to the value sent to the alignment. It would probably be better if we handle this in the planning stage and update the JobPlacement so we don't have to duplicate this code. Bendrocks, are you interested in taking this on? I've added an issue for it at https://github.com/openpnp/openpnp/issues/575

Jason

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CAJGcfUhOtApPf5OkwpufzX4thGyO1MjCtFzb9QjeSr5q_v-FwA%40mail.gmail.com.

[BendRocks]

> Bendrocks, are you interested in taking this on?

Right now I cannot as I have some deadlines coming up that will consume the next few weeks. 

Is the error dlg that smdude shows related to the change I made or is that something else?

[Jason von Nieda]

Ah, thanks for reminding me. I forgot to check. It's from your code. When the wizard calls the alignment for a test there is no board location to test with, so it throws an NPE when trying to access it. The code just needs to check if boardLocation is null and if so, skip the preRotate option. I'll throw a fix in now.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/5ca15545-fd3e-4259-acdc-9acfa837208a%40googlegroups.com.

[Jason von Nieda]

The NullPointerException that SMdude was getting is fixed now.

Jason

[Jason von Nieda]

Hi Bendrocks,

I'm having trouble understanding how your code compensates for translation on the nozzle tip. Maybe I am missing something, but in my testing I'm not seeing it happen, either. Does your code / concept only handle rotational errors? What if the part is not perfectly centered on the nozzle tip? The code seems to ignore the X,Y portion of the result.

Jason

[Jason von Nieda]

The fiducial compensation issue that Cri raised is now fixed: https://github.com/openpnp/openpnp/issues/575

Jason

[Peter Betz]

On Monday, May 29, 2017 at 8:52:36 AM UTC-7, Jason von Nieda wrote:

Hi Bendrocks,

I'm having trouble understanding how your code compensates for translation on the nozzle tip. Maybe I am missing something, but in my testing I'm not seeing it happen, either. Does your code / concept only handle rotational errors? What if the part is not perfectly centered on the nozzle tip? The code seems to ignore the X,Y portion of the result.

Jason

This would be critical as well, as the parts obviously move around a bit in their tape pockets, tape isn't perfectly straight etc..... Excited to see these changes moving forward, I need to connect my bottom camera!!

Peter.

[BendRocks]

> Does your code / concept only handle rotational errors

Yes, the aim is to pre-rotate and then let the vision zero out the runout induced by the rotation. 

Here's the original return line at line 120:

return new PartAlignmentOffset(offsets,false);

What's now at line 123 is

return new PartAlignmentOffset(offsets.derive(0d,  0d,  0d,  preRotateAngle), preRotate);

Now I think this is a bug because it zeros what was just computed for XY and rotation. What it should be (I think) is:

return new PartAlignmentOffset(offsets.derive(null, null, null, offsets.getRotation() + preRotateAngle,false);

In other words, the offsets would have a small value of, say, -1.23 degrees based on vision, and the pre-rotate angle might be (as an example) 182.5 degrees (180 placement rotation + 2.5 degrees of PCB alignment). And thus, the final return would be

Thus, the code in there right now is ignoring vision updates completely it looks like. 182.5 - 1.23 = 181.27.

That 181.27 value (and the XY updates) would be returned, and the calling would update the XY and the rotation, and the rotation which was previously at 182.5 (from line 78 in ReferenceBottomVision) would be moved slighly to 181.27.

Is that thinking correct and would it work as you expected?

[Jason von Nieda]

Uh oh! So if I am reading this correctly, this disabled bottom vision completely, in both the pre-rotate and post-rotate case.

I'm reverting this change until this is sorted out. Will respond more fully to your question when I have a bit more time.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/61af770d-4c78-401d-a16b-a0881bae64b4%40googlegroups.com.

[Jason von Nieda]

I've reverted the final line of the function to return just the offsets, as the original code did. https://github.com/openpnp/openpnp/commit/2c467e2d90578b584858bbd135a7b97cbe6bb9ec

I'll revisit this in a few hours. I'm first going to see if I can add an automated test to the system that includes bottom vision so that we have some test coverage, then I will re-apply the changes, add in your revision above and see if the tests all still pass.

Jason

[Jason von Nieda]

Okay, I've made the change BendRocks proposed and all looks good: https://github.com/openpnp/openpnp/commit/a6b2478e69708d944c98a1ec63b8d887babaa608

I think we're in good shape now. Regular bottom vision is working as it did before, and pre-rotate seems to be working as expected.

Jason

[SMdude]

Awesome, thanks Jason, will check it out tonight..

[Peter Betz]

On Monday, May 29, 2017 at 5:10:15 PM UTC-7, Jason von Nieda wrote:

Okay, I've made the change BendRocks proposed and all looks good: https://github.com/openpnp/openpnp/commit/a6b2478e69708d944c98a1ec63b8d887babaa608

I think we're in good shape now. Regular bottom vision is working as it did before, and pre-rotate seems to be working as expected.

Jason

So does this change capture the X / Y offset as well after rotation?

Peter.

[Jason von Nieda]

Yes, in short, the code rotates the part to the expected final placement location, performs vision, adds the angle of the part and returns the offsets. The placement then happens at the indicated rotation and offset from the nominal placement location by the vision offset.

There's something that's been bugging me about this code, though, and after writing the above, I realize what it is. I think we actually need to perform vision twice for this to be any use. 

The first will get us the rotation at the nominal angle, along with the offsets, and we currently return that. But that placement is still going to include nozzle runout when we rotate by the additional amount indicated by vision.

The second will take the rotation indicated by the first, rotate to that amount (what will be the final rotation at the placement) and then capture the offsets. We need to know the offsets at the final rotation, not the rotation minus the error, otherwise when we rotate to the final rotation we add additional offset error from the runout.

So, basically, I think we need to change the preRotate option to:

1. Perform vision at the nominal placement rotation.

2. Get the rotational error from 1 and rotate to the nominal + error.

3. Perform vision a second time. This time we expect the rotational error to be close to 0 and we just need the offsets.

4. Return the offsets + the nominal + rotational error.

We could probably allow the user to specify a number of times to perform vision, as each one will provide a slightly better result.

BendRocks, what do you think?

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/33a191e3-9fea-43c4-8dd6-e9e6bf0d3590%40googlegroups.com.

[Paul Kelly]

Whilst I admire your pessimism, surely the additional error introduced by a small amount of rotation to correct for a slightly wonky pick would be negligible?  I mean there has to be some minimum amount of runout required.

I guess if you were picking from a loose parts feeder then it might be different….

My concern here is that we end up doubling the vision time on every pick without improving anything for most parts.

 

Perhaps a feeder/part specific option for double vision?

 

PK

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jwOq2Fz_vk5wuyxPp0NaaEmQpD7VTyJ%3D%2BE4FOa3Qv2adw%40mail.gmail.com.

[SMdude]

Hi Jason,
As Pk said, can this be made on a per part basis?
And yes, it would be nice to pre rotate, then correct rotate, then correct offset.
This will then correct for the worst mispicks or nozzle run out.

[Cri S]

On per part, just add the vision stage that does closed loop vision to
the vision pipeline..
There are hovewer (speed) differences.
Closed loop vision stage rotate part after part is moved above camera,
the alignment code rotate the part during part is moved to camera.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/iFQVZyUgnlA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/1b3a7bde-afe9-4e06-a451-29d87a3ab7ad%40googlegroups.com.

[dzach]

@Cri-s which "closed loop vision stage" are you refering to?

[Jason von Nieda]

Yea, I think it would make most sense to treat it like the other settings. The default will be on the Bottom Vision and you would be able to configure it on a per-part basis as well. I think it might make sense just to remove the checkbox for preRotate and add an integer text field like "Closed Loop Vision Cycles", where 0 would be standard bottom vision and anything greater than 0 would run the preRotate cycle that many times.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/1b3a7bde-afe9-4e06-a451-29d87a3ab7ad%40googlegroups.com.

[BendRocks]

> BendRocks, what do you think?

> Jason

First, let me say sorry for the bad submission. I have wrestled with the null versus zero issue once before on the derive function and I can't believe I missed it again. Sorry about that. 

Re doing it twice or more, if I understand the thread above I think it depends on the worst-case pick error. If it's a QFP or BGA part from a tray, the pick error is very small (+/- 2 degrees) and thus the runout difference between subsequent vision checks would be small (since the max vision correction will be bounded to +/- 2 deg). But if it's an RC you are doing vision on, then the pick error can be +/-20 degrees, and the runout difference between the preRotate and the first result from vision could be improved a lot.

I drew some pictures in the github pull request thread that were helpful if someone wants a picture of the items below. I think a starting summary might be this:

Consider 3 rough classes of machines:

<5 mils/0.125mm runout: this would be considered a "good" home machine. A juki nozzle with a good holder can meet and even exceed this. At this level of performance, you can usually go down to 0402 without any vision, even with +/- 20 degrees pick error, on a well tuned machine. For BGA/QFP (aka fine pitch) parts in tray, molded tape carriers, you need vision mostly to fix runout. 

<10 mils/0.250mm runout: This would be an OK home machine (my current performance on TVM920). At this level, you can usually place 0402 without vision, and 0603 certainly without vision. Vision is needed for finer pitched parts always.

> 10 mils/0.250 mm runout: This would be nozzles made from a variety of sources (eg needles), designs with mechanical mounting problems, etc. This would probably needs vision for just about every placement up to and including 0603. 0805 is probably OK, unless really bad.

I think a good machine placing 0402 without vision and fine pitch parts with vision would see little benefit from several vision passes. But a looser machine definitely would, especially on the R and C.

[Cri S]

It is a bsh stage, and it must be the last stage in pipeline.
It does closed loop vision, read the result stage and if angle is outside limit rotate nozzle and call pipeline.process again.

[Matt Brocklehurst]

I might be being stupid but don't you want to

Capture image to detect the initial rotation (pickup rotation error)

Calculate final rotation (placement rotation + board rotation - error detected at the vision stage)

Rotate

Capture image again to make sure we are at the right angle

If at right angle great go place
If not rotate by - error, capture again, repeat until at right angle


Sent from my iPhone

> On 31 May 2017, at 08:32, Cri S <phon...@gmail.com> wrote:
>
> It is a bsh stage, and it must be the last stage in pipeline.
> It does closed loop vision, read the result stage and if angle is outside limit rotate nozzle and call pipeline.process again.
>

> --
> 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 post to this group, send email to ope...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/83fa142b-69c1-43ff-ac54-b1524d756624%40googlegroups.com.

[Paul Kelly]

We’re putting the covers back on our machine and are presently pondering how to control the traffic light indicator.

Is there a script that’s called periodically, or on state change?

And what do y’all think is the best way to fetch the state of the machine.  We essentially need “Offline/non recoverable error”, “Ready but not running” , “running”, and “recoverable error”

 

Cheers

PK

 

From: ope...@googlegroups.com [mailto:ope...@googlegroups.com] On Behalf Of BendRocks
Sent: Wednesday, 31 May 2017 3:02 PM
To: OpenPnP
Subject: Re: [OpenPnP] Re: Align then rotate VERSUS rotate then align

 

> BendRocks, what do you think?

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/810386a8-a110-4781-a339-a0a3a5ea1ade%40googlegroups.com.

[Jason von Nieda]

See https://github.com/openpnp/openpnp/wiki/Signalers#actuator-signaler. It was specifically added for traffic lights.

For fetching state, I don't have a good answer for you there. There are variables that contain that state but they aren't readily exposed.

Also, Paul, I'd like to ask you a favor. Please don't reply to threads to start a new thread by changing the title. This is how we get threads mixed up. If you are starting a new thread, please just click the new post button or send the email to ope...@googlegroups.com. In this case you've responded to "Re: [OpenPnP] Re: Align then rotate VERSUS rotate then align" with a new thread but this will confuse Google's poor little brain.

Thanks,

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/019201d2d9e8%246779a0b0%24366ce210%24%40com.

[Jason von Nieda]

Thanks Matt, you are likely right. I think we can put this to rest. The code as it stands now should be a very good improvement in many cases. If we find down the road that we want to further close the loop we'll have this thread to reference. I think there will be some benefit in getting some feedback from users before we spend more time on it.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/810386a8-a110-4781-a339-a0a3a5ea1ade%40googlegroups.com.

[SMdude]

Ok, so, it looks like bottom vision is now really broken!

It seems that when bottom vision is turned on(I didn't try unchecking pre-rotate), the rotation in the placement table is ignored.
When I turn off bottom vision, I can then change the rotation in the pick and place table and it works as expected.

Cheers

[Jason von Nieda]

SMdude,

>Ok, so, it looks like bottom vision is now really broken!

>It seems that when bottom vision is turned on(I didn't try unchecking pre-rotate), the rotation in the placement table is ignored.
>When I turn off bottom vision, I can then change the rotation in the pick and place table and it works as expected.

Are you running the most recent version? There was about a 12 hour period where it was completely broken, but I believe it's working correctly now. Also, do you have the Pre Rotate option turned on or off?

Jason

[SMdude]

Pre-rotate on and version a6b2478.

[Jason von Nieda]

Okay, try turning pre rotate off and see if things look basically right, accounting for possible runout.

Jason

On Wed, May 31, 2017 at 9:16 AM SMdude <spiteri...@gmail.com> wrote:

Pre-rotate on and version a6b2478.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/383f6f49-4a8d-4d92-a9a1-d211b7a0f89c%40googlegroups.com.

[SMdude]

Hi Jason, I'm packed up for the night. Got to be up for work in 6hrs.
Will try it out tomorrow evening.

[Jason von Nieda]

Okay, thanks. I will try to find some time to add some tests today. I am pretty sure regular bottom vision is now working fine, but pre rotate may be broken. Unfortunately my test machine is in pieces at the moment, so I can't test this stuff physically. I'll need to add simulation code for it.

Jason

On Wed, May 31, 2017 at 9:37 AM SMdude <spiteri...@gmail.com> wrote:

Hi Jason, I'm packed up for the night. Got to be up for work in 6hrs.
Will try it out tomorrow evening.

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cfeef08e-b306-4470-8dc3-9aaec8ee6d2a%40googlegroups.com.

[SMdude]

Ok, just walked past the board I tested on last night.
All of the components are facing the same direction.
I have passives placed at 0 and 90 and they have all mounted at 90 deg. All the ic's were at the same rotation too.
I think it is placing at the boards calculated rotation, not calculated board rotation + part rotation.
I think this was not happening with Mats original/2nd release as the first board I did with prerotate 3 days ago had the passives rotated correctly.

Thanks

[Jason von Nieda]

Thanks SMdude, I'll have a look at the code tonight and see if I can see what's up. In the mean time, when you have a chance, please try a run with pre-rotate turned off and see if it's better.

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e635f43f-b3a1-45ca-a866-3d3c2cc05173%40googlegroups.com.

[Paul Kelly]

Again, with the “I’ve looked everywhere, I’ll post to the list” -> “You idiot, here’s the wiki page that shows you exactly how to do it”  thing !….

 

I’m not angry… Just disappointed..

 

Anyhow there’s another video topic for us wiki-inept types..

 

PK

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jweWJTh3ru8%3DtuRyMTRXWRQCTFeQc_tY%2BtS1uNqdeZKpQ%40mail.gmail.com.

[Jason von Nieda]

Don't be too hard on yourself. That one is pretty well hidden. It's never been linked into the main documentation pipelines. I'll resolve that :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/00ed01d2da7f%243f8c5970%24bea50c50%24%40com.

[Paul Kelly]

So I’m not understanding something.  I’m guessing that it’s the application of the machine-state field.

Here’s what we have

 

<signalers>

         <signaler class="org.openpnp.machine.reference.signaler.ActuatorSignaler" id="tl1234" actuator-id="ACT1496295014322" job-state="STOPPED" machine-state="ERROR"/>

         <signaler class="org.openpnp.machine.reference.signaler.ActuatorSignaler" id="tl1235" actuator-id="ACT1496295000155" job-state="RUNNING" machine-state="ERROR"/>

         <signaler class="org.openpnp.machine.reference.signaler.ActuatorSignaler" id="tl1236" actuator-id="ACT1496295020995" job-state="ERROR" machine-state="ERROR"/>

  </signalers>

 

What we get is one light (ACT1496295020995) on all the time….

Any tips?

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/CA%2BQw0jy8UoLmrWU%2BHyWPNBmoWhJMuikXd9KdVaTxsWmU0OWccw%40mail.gmail.com.

[SMdude]

Hi Jason,

Tested without pre-rotate 3 times it it all worked as expected with the exception of one of my diodes, that placed correctly on the first run, then incorrectly on the following! That one could be pipeline related.
When prerotate was enabled again, all the ic's that were previously placing correctly were rotated 90 degrees.

FYI my board rotation is set at 89.955, which is correct.

Cheers

[SMdude]

Also, while it was running in prerotate, I'm fairly sure it did pre-rotate to the correct angle, then after the vision stage it would rotate to the wrong angle.

[SMdude]

Right, re-tested with board rotation set to 0 and it aligned mostly as it should.
So then retested at +10 degrees,
Part moves to bottom cam at correct placement rotation
vision done, move to board and rotate in opposite direction

Retested with board at -23 degrees and same results.
After the vision stage the part is rotated wrong.

See picture.
Passives were already placed, its just the ic's that are of interest..

[Peter Betz]

On May 31, 2017, at 11:10 PM, Paul Kelly <te...@caswa.com> wrote:

So I’m not understanding something.  I’m guessing that it’s the application of the machine-state field.

Here’s what we have

 

<signalers>

         <signaler class="org.openpnp.machine.reference.signaler.ActuatorSignaler" id="tl1234" actuator-id="ACT1496295014322" job-state="STOPPED" machine-state="ERROR"/>

         <signaler class="org.openpnp.machine.reference.signaler.ActuatorSignaler" id="tl1235" actuator-id="ACT1496295000155" job-state="RUNNING" machine-state="ERROR"/>

         <signaler class="org.openpnp.machine.reference.signaler.ActuatorSignaler" id="tl1236" actuator-id="ACT1496295020995" job-state="ERROR" machine-state="ERROR"/>

  </signalers>

 

What we get is one light (ACT1496295020995) on all the time….

Any tips?

 

PK

Pro tip: Start a new thread ;) 

[Jason von Nieda]

Thanks SMdude, this is really helpful. I verified last night, as well, that the standard bottom vision is working correctly and I spent some time writing tests for these algorithms. As soon as I have more time, which will probably be next week due to a busy weekend coming up, I will validate the pre rotate stuff and figure out what is going on.

Jason

--
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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/aa71a7fd-24cb-4b22-ba94-ab500190f18d%40googlegroups.com.

[Jason von Nieda]

Hi Paul,

I have not really used this feature - it was added by Friedrich Mäckle. Let's see if he pops in and can help over the next day or two and if not I'll dig into the code and see what is going on.

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/021d01d2da9d%24bf6a48a0%243e3ed9e0%24%40com.

[Cri S]

Can you test #577 .
This uses the rotation as it is and include offset support (xy) for prerotate.

>> <https://groups.google.com/d/msgid/openpnp/aa71a7fd-24cb-4b22-ba94-ab500190f18d%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .

>> For more options, visit https://groups.google.com/d/optout.
>>
>

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/iFQVZyUgnlA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to

> openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/CA%2BQw0jyOW1eTg61fE5NEycEcbS327wd8qfLp%2BmF-Yp22-vC3vQ%40mail.gmail.com.

[SMdude]

Will test more over the weekend after I have other work done..

Also, worth noting that I am populating the bottom side of that board. I need to test and see if it works ok on the top side...

[Cri S]

bottom or top side don't change anything in this case.
if you can please test PR #577 or if you need help with it just ask.
The last bsh stage should work with PR #577 , at least with preRotate off.

> --
> You received this message because you are subscribed to a topic in the
> Google Groups "OpenPnP" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/openpnp/iFQVZyUgnlA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> openpnp+u...@googlegroups.com.
> To post to this group, send email to ope...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/openpnp/23025ed5-b116-4c29-8feb-688f819423cd%40googlegroups.com.

[SMdude]

Hi Cri,
Yes I will try that as soon as I can.
Might be tonight or tomorrow.
Thanks

[SMdude]

Cri, I found #577, but how do I compile/use it?
Sorry, I have not been down this path with openpnp yet..

[SMdude]

So I tested Cri s version.
It still rotates to the wrong angle, but the logging that he set up I think pinpoints where the problem is.

I have attached the log file for anyone interested.
Ignore the first placement, it was a mispick and I have not done anything to handle them yet.

[SMdude]

Just another quick update,
Cri has done some more work on it, now rotation is perfect and so is placement!
I even put a really large offset on one of my ic's(bumped it over on the way to the bottom cam) and it placed perfectly.
Still a few little bugs to iron out, but a lot of good progress has been made.

Ignore the passives, they were placed a while ago now, I only placed the diode and 2 ic's in the picture..
And that is with the board rotated to -21.891 degrees..

[Jason von Nieda]

Nice work to both of you. Please post the code or a PR when it's solid.

Thanks,

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/eceff380-3c5c-4d7c-ab5b-c3f866a11313%40googlegroups.com.

[Peter Betz]

On Saturday, June 3, 2017 at 6:27:53 AM UTC-7, SMdude wrote:

Just another quick update,
Cri has done some more work on it, now rotation is perfect and so is placement!
I even put a really large offset on one of my ic's(bumped it over on the way to the bottom cam) and it placed perfectly.
Still a few little bugs to iron out, but a lot of good progress has been made.

So excited to try this!!!

Peter.

[PK]

Is this code available?  We're seeing some offsets on placement with 2017-05-18-13-14 and I'd like to test current code before we get too much further into it.

[SMdude]

Unfortunately Cri-S hasn't pushed his changed through to his Git repository, I was only testing the .Jar build file.
We went from having some trouble with parts picked/placed at certain rotations(something to do with the way openpnp handles nozzle rotations going past 360) while others at different rotations came in perfect. And set to camera was storing the wrong locations.
Then, that was fixed, but the correction rotation was inverted, so flipping the camera would get the correct rotational alignment, but the xy offsets are calculated wrong.
Cri was also experimenting with a closed loop stage in the pipeline
Then the closed loop vision stage needed other things added to the build, and it has all turned to poo!

I have not heard from Cri for a few days, he is probably busy doing what he does..??

So if someone feels so inclined?
The potential of this feature when all bugs are removed and it works correctly is amazing.

Cheers

[PK]

Does that not assume that you have runout but the part rotation axis is still parallel with the rotational axis of the nozzle?

Bending a tip is a fairly common thing..

PK

On Tuesday, May 23, 2017 at 12:27:03 PM UTC+8, Michael Anton wrote:

I still think all that needs to be done is to determine where the rotation axis is, and then the runout doesn't matter.  So, then you could image to determine current angle and center, rotate to position, and the center of the part should still be known, since you know the center that the part was rotated around.  Whether or not the nozzle wobbled shouldn't factor into it.

Probably it is aligned first, as you need to know the angle to rotate to. Otherwise, you would have to determine the rotation angle first, rotate to the desired angle, and then determine the center.  This would probably take longer since multiple image captures would be required.

On Monday, May 22, 2017 at 7:53:12 PM UTC-6, BendRocks wrote:

Jason et al, what is the reason for aligning a part and then rotating it before placement? It seems you'd eliminate all eccentricity issues if you rotated prior to hitting the up camera for alignment. With 0.5mm pitch being common, and 0.125mm of runout being "really good", the placement accuracy is significantly degraded even on a good machine by rotating after aligning. 

[PK]

This message may appear twice because I replied via email about 8 hours ago..

Given that Cri-S seems to be off having a good time somewhere. Any chance you could share that JAR file. We're a bit stuck at the moment not sure where the errors are and it would be good to rule out the software before we start going to town on the hardware...

Cheers

PK

[SMdude]

Hi PK,

Cri is back, but now his laptop is giving him a hard time, which he hoped to have working again today.
I sent him some log files from his latest build last night, so hopefully things will start to behave for him...

I'll ask the question about the JAR file(sorry not my work to share), but even though that one was close, it still wasn't good enough to run a job and have it turn out better than just normal old bottom vision.

Are you running prerotate or just normal bottom vision?

Do you move the nozzle to the bottom cam and make sure it is centred properly each time you start your machine? (homing not always exactly the same spot) If not, this coul cause you errors.

Oh, and another thing(though, yours was a retrofit of a commercial?) the bottom camera Z alignment. I lower my parts down to placement height to image them. If I image them at z=0 there is a .25mm xy offset. My Z is square to the bed, so it must be my camera mounting that is not quite right. I fiddled with that one day and decided I could handle the time penalty lowering the part to placement height for imaging!

Cheers

[PK]

On Tuesday, June 13, 2017 at 4:30:57 PM UTC+8, SMdude wrote:

Hi PK,

Cri is back, but now his laptop is giving him a hard time, which he hoped to have working again today.
I sent him some log files from his latest build last night, so hopefully things will start to behave for him...

I'll ask the question about the JAR file(sorry not my work to share),

Yep, understand. I'm slowly getting to a point where I can make changes myself, but we're a bit busy at the minute.

 

but even though that one was close, it still wasn't good enough to run a job and have it turn out better than just normal old bottom vision.

Are you running prerotate or just normal bottom vision?

Just normal bottom vision. 

Do you move the nozzle to the bottom cam and make sure it is centred properly each time you start your machine? (homing not always exactly the same spot) If not, this coul cause you errors.

Haven't checked that, but I'd be surprised if it was a problem. We've run test jobs comming back against a dial gauge for over an hour to check for encoder noise and found none. Our machine is ground ball screws and precision machined bits..

 

Oh, and another thing(though, yours was a retrofit of a commercial?)

Correct.

 

the bottom camera Z alignment. I lower my parts down to placement height to image them. If I image them at z=0 there is a .25mm xy offset. My Z is square to the bed, so it must be my camera mounting that is not quite right. I fiddled with that one day and decided I could handle the time penalty lowering the part to placement height for imaging!

That's a really good thing to check, thanks!

 We got 6 panels through today :-(((  But hey, that's better than yesterday, and it is starting to place well enough that we are dialing in more speed..   

PK

[SMdude]

The other thing to make sure of is that the bottom vision pipeline is imaging all your parts reliably.
If you turn on debug in the log settings, I think it then stores the images from your bottom vision, so you can check them.
C:\Users\Home\.openpnp\log\vision

Another thing worth checking, if you do have runout on your nozzle, make sure your bottom camera is centred on the centre of rotation not the centre of the nozzle.
And then same for nozzle offsets to top cam.

[PK]

On Tuesday, June 13, 2017 at 6:26:54 PM UTC+8, SMdude wrote:

The other thing to make sure of is that the bottom vision pipeline is imaging all your parts reliably.

Yeah, we're reasonably happy with this.  When we see an error, it's a consistent one. Sure there are the occasional mistakes, but we are comfortable tuning the default pipeline.

 

[Cri S]

Tomorrow I could send file for prerotate for testing.
It is however slower.
For the code, I was going back to older code with a modification as asked by SMdude as hi have tested the code seems to work with that modification.
The code requires two image capture because the nozzle center of rotation is unknown and nozzle calibration is not applicable, this adds 0.22 sec
for usual setups per part and naturally lowers cph.
Closed loop do more pipeline loops and terminate if angle delta is less then 0.11 degree or if there is sign inversion of resulting delta angle.

[Marek T.]

Hi CriS,

"Prerotate" option is the same option as "Final Rotation" #401?
As I understood Final Rotation means second (and more) check to verify if the part is alligned properly after the bottom vision process used today.
"Prerotation" smells more like rotation to proper position before the today bottom vision (what really makes sense same as above).
Anyways, not sure how you will publish the test version - I'm also very waiting for it trusting it will solve a bit my problems with runouts.

[Cri S]

Actually it is named prerotation and closed loop.
The final code uses a vision stage for both type.
Two image capture are necessary because rotation center is not known.
As rotation center changes with different part height it is really difficult to estimate, nozzle tip calibration don't help.
Checking part at angle zero implies automatically that nozzle offsets are calibrated on that position and that nozzle tip center is at image center using up looking camera.
Using nozzletip rotation center is wrong in this case as it produce wrong align offsets.
The picking and placing offsets are compensated from nozzletip calibration that compensate nozzle bending if used.

It prerotate to final position. Capture, calc angle, update rotation, capture again,
Update offset only.

Closed loop instead checks the results and continue vision processing until the accuracy is good enough.

[Marek T.]

It's salvation from my problems I think (worth shit Chinese copy of Juki nozzles chosen to use). I think that many people here will bless you waiting for this update...
I hope that you will add there, as Jason has mentioned about #401, some counter and checkbox to allow decide how many times the acuracy maybe corrected and for which part. To don't land in some dead loop instead of closed loop or shortcut the vision time in case of the parts non requiring so high accuracy...

[Cri S]

No counter or checkbox is planned.
Accuracy for closed loop is tailored to 16 microsteps direct drive nozzle, 3200 steps per rotation.

[Marek T.]

Ok, maybe it's really not needed if you say so... But ley us play with your work of art :-).

[PK]

Still no code from Cri S?  Are you out there Cri S?   Someone turn on the bat light!

PK

[Marek T.]

I'm on vacation now and can't test anything with machine. But there is an update from June.14 and new option in machine setup_vision_bottom visible as prerotate. Only Jason has not updated the change.log and last changes are shown at May.18 what's not real.

[PK]

Ahhh, the old, "I'm on vacation so your problems are unimportant to me" caper!  

Enjoy your break:-) and thanks Marek.. At least it wasn't a Wiki page I missed this time..

[Marek T.]

I'm on vacation but still think about this :-). And it's boring tho rest only :-)

[SMdude]

Well did a run just using develop branch and prerotate off after spending a lot of time very carefully setting the offsets for N1 and N2 to the top cam and confirming it on the bottoma camera.
Also the pipeline needed some tuning up to reliably get most things most of the time, and my left over problems seem to be from lighting reflections.

Anyway, after a lot of fiddling I was able to place 2 boards boards today with .5mm pitch ic's on it and 0603 and apart from a few of the caps that did not recognise properly on the bottom vision, everything placed pretty much perfectly :D

The more I think about prerotate, the more I think it is more of a bandaid fix for nozzle offsets not correctly set, and bottom camera position not properly set to the nozzle centre of rotation.

Something that would be more worthy of a lot of thought and effort is nozzle runout calibration and compensation.
If this is done then we can get very good results picking and placing even the smallest of components.

[Marek T.]

Sorry for my bad English... So you have used this added prerotation option or set it off and focused on as perfect as possible tuning the nozzles ofsets instead?

[PK]

The more I think about prerotate, the more I think it is more of a bandaid fix for nozzle offsets not correctly set, and bottom camera position not properly set to the nozzle centre of rotation.

I'm not sure I agree. As I see it, an off center pick is indistinguishable from nozzle runout. 

 PK

[BendRocks]

Agree with PK. Software to automate the location of a pick (before job has started) is much more valuable to me than runout calibration. Being able to push a button at the start of a job, and the pick location of every feeder is verified with vision would be an enormous time saver. 

[Jason von Nieda]

Hi folks,

I have temporarily disabled this feature in the main branch since it's not working correctly and having it enabled is causing confusion. See my comments at https://github.com/openpnp/openpnp/issues/401 if you are interested. I will re-enable the checkbox once we have a working solution.

Also, Cri, I would appreciate it if you would please post the source code for your changes, or push them to a Github branch, rather than posting binaries to a Google drive. I would be happy to merge them to the official test branch if you like, which will allow them to be automatically built and downloaded from http://openpnp.org/test-downloads/. You could also create a pull request with the test branch as the target and I will merge it, which will accomplish the same thing. The test branch is at https://github.com/openpnp/openpnp/tree/test.

Thanks,

Jason

--

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 post to this group, send email to ope...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/cb9112c2-5d71-467f-abc1-c798417f920c%40googlegroups.com.

[Cri S]

Why you need to verify the position of feeder before job? do you have homing problems ? or i don't understand you'r statement.

Maybe you mean, you need top vision for part , but this is before feeder picking, not before job.