error after fiducial alignment

[Peter Chaisty]

Hi 

Progressing along with the liteplacer setup.

Strange issue with alignment.

I have the x and Y axis to better than 0.1mm over 300mm in the x and 260mm in the Y. 

In the end the graph paper I had originally was inaccurate andI used a long steel rule.

I set the squareness factor again using a A3 size grid.

If I align on Fidicial at 9,9mm and 87,106mm it finds them and locks on.

If I tell it to put the camera over the 87,106mm , its off as per the image.

As its the centre of the camera I am  using and unless my squareness factor I set is off.

I've ordered some fine pitch accurate graph paper .

Other than squareness factor  what else could it be ?

Peter

[ma...@makr.zone]

On Thursday, July 12, 2018 at 3:56:17 PM UTC+2, Peter Chaisty wrote:

If I align on Fidicial at 9,9mm and 87,106mm it finds them and locks on.

If I tell it to put the camera over the 87,106mm , its off as per the image.

Hi Peter

What do you mean by "If I tell it to put the camera over the 87,106mm"? Do you mean jogging? Or the console?

Can you please post your log?

For now (without the log) two guesses:

1. It could be a misunderstanding: the fiducial is there to calibrate the board position and orientation. So there is an offset between the theoretical fiducial position (as it would be if your board was perfectly aligned to the position given in the job) and the actual fiducial position. The offset and its compensation in the part placement commands sent by OpenPNP is the very purpose of the fiducial. But the compensation does only take place in the part placement during the job or if you expressly tell it to go to part so-and-so from the parts list. It does not take place when you jog or use G1 commands through the console.
   
2. It could be excessive backlash. But this would also be visible when you jog left and then right.
   

_Mark

[Peter Chaisty]

Hi Mark

I'm doing a fiducial align.

Then clicking on the fiduciual in the job list and saying put camera over the part.

I then get the result where is off slightly.

Peter

--
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/qL6tzKHOP6U/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/f74594f3-e7f6-4be6-9342-e54237a75cf5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Mark]

Hmmm.. what happens, if you chose another part?

 

Maybe the fiducials are specially treated as their purpose is to find the offset not being placed at the offset?

 

I had a quick look at the code but I couldn’t find it in reasonable time.

 

_Mark

[Marek T.]

Two thoughts:

- I had 3 different calipers and two of them (cheap) was for nothing. The same technical checkered paper, many of them have rectangles not squares.

- I don't know how it is in Liteplacer. Is there some motion controller like Smoothie? Have you tune fully properly steps/mm ?

[Peter Chaisty]

Hi Mark

If I say move camera to part (0805) near the fudicial it has the same offset.

All I can think is my squareness is off somehow as this is camera only .

Peter

--

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/qL6tzKHOP6U/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/019601d419ee%24db15d920%2491418b60%24%40makr.zone.

[Peter Chaisty]

Log

I did  fiducial align

then put camera over fiducial

Peter

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/fbb6835a-80f9-45ea-b9a3-278475d80fda%40googlegroups.com.

[Peter Chaisty]

I should add after selecting the fiducial in the component list and saying put camera over selected component.

Peter

[Mark]

Yeah, but if the non-squareness is off, this would be mostly compensated by the fiducials too.

 

 

With reasonably small non-squareness this should be a very small offset. It should only become an issue with very large PCBs or large feeder arrays, where extrapolated coordinates far from the reference fiducials will be off.

 

_Mark

[Peter Chaisty]

I thought that.

Also if it aligns on that fiducial I would expect it to find it's way back regardless of squareness.

I'm confident x and y are very accurate.

Peter

--

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/qL6tzKHOP6U/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/01ad01d419f1%24ce0f29e0%246a2d7da0%24%40makr.zone.

[Mark]

Hi Peter

 

First I see a non-squareness factor of almost -0.89mm over 117mm = approx. -0.0076, is that correct?

 

Have you divided with the correct units? Have you double checked the sign?

 

2018-07-12 15:49:10 ReferenceCamera DEBUG: moveTo((91.609388, 117.164987, NaN, -0.501933 mm), 0.75)

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(G0 X90.7206 Y117.1650   F750, 5000)...

 

The fiducial was located at 92.273082, 117.975703:

2018-07-12 15:48:55 ReferenceFiducialLocator DEBUG: FIDUCIAL-1X2-FIDUCIAL1X2 located at (92.273082, 117.975703, 0.000000, -0.468732 mm)

 

But the compensated position is 91.609388, 117.164987

2018-07-12 15:49:10 ReferenceCamera DEBUG: moveTo((91.609388, 117.164987, NaN, -0.501933 mm), 0.75)

 

That’s way off. It seems OpenPNP has “least-squared” away a hefty error in the three fiducials.

This could perhaps result if you have a sign inversion of the non-squareness factor.

If not, are you sure the fiducial coordinates in the parts list are correct? How good is the PCB?

 

 

Finally (I am not sure) but could it be that you haven’t done axis mapping?

See here:

https://github.com/openpnp/openpnp/wiki/FAQ#my-nozzle-moves-in-z-when-the-camera-is-moved

https://github.com/openpnp/openpnp/wiki/GcodeDriver#nozzle-is-moving-or-turning-when-camera-is-moved

It seems your camera is moving with Z only moves (I could be mistaken).

 

2018-07-12 15:49:10 ReferenceNozzle DEBUG: N1.moveToSafeZ(0.75)

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(G0   Z-1.0000  F750, 5000)...

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(COM3 G0   Z-1.0000  F750, 5000) => [{r:{gc:"G0   Z-1.0000  F750"},f:[2,0,20]}]

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(null, 250)...

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(COM3 null, 250) => [{qr:32,qi:0,qo:1}]

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(null, 250)...

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(COM3 null, 250) => [{sr:{line:0,posx:3.594,posy:11.931,posz:-1.000,posa:-0.502,feed:750.00,vel:0.00,unit:1,coor:1,dist:0,admo:1,frmo:1,momo:0,stat:1}}]

2018-07-12 15:49:10 ReferenceCamera DEBUG: OpenPnpCaptureCamera.moveToSafeZ(0.75)

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(G0   Z0.0000  F750, 5000)...

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(COM3 G0   Z0.0000  F750, 5000) => [{r:{gc:"G0   Z0.0000 

 

This should be irrelevant for the problem here, though.

 

_Mark

 

[Peter Chaisty]

Hi Mark

For squareness I used 290mm and it was off by -2.2mm (I have ordered some more accurate graph-paper ).

I have optical homing as well which seems very repeatable and stable (1mm white circle).

I think my axis mapping is ok as when I move so say 290,290 the cross-hair is still aligned horizontally and vertically and no move in Z.

It does seem to find  different board origins at times based on using the two fiducuials I chose (using the do fid alignment button)

6,6 and 87,106.

I read the co-ordinates in my pcb file and manually entered into the job in pnp.

The pcb is very accurate and I verified using a steel rule and also Mitutoyo calipers.

I'm running the latest release by the way.

This is the result of an X move of 400mm (starting at the 5mm mark on the ruler) 100mm steps

It returns to 0 fine and its repeatable back and forth.

Peter

--

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/qL6tzKHOP6U/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/01ca01d419f8%241dd26ae0%24597740a0%24%40makr.zone.

[Peter Chaisty]

Hi

I should say the camera is fixed on the Z axis main plate.

It doesn't move vertically.

The nozzle is the only thing that can move up and down and rotate.

Peter

To unsubscribe from this group and all its topics, send an email to openpnp+unsubscribe@googlegroups.com.

[Mark]

Yes but OpenPNP doesn’t know that unless you tell it using Axis Mapping.

 

https://github.com/openpnp/openpnp/wiki/GcodeDriver%3A-Axis-Mapping

See also here:
https://github.com/openpnp/openpnp/wiki/FAQ#my-nozzle-moves-in-z-when-the-camera-is-moved
https://github.com/openpnp/openpnp/wiki/GcodeDriver#nozzle-is-moving-or-turning-when-camera-is-moved

Jason and I are just discussing a possible solution for adding this per default. See here:

https://groups.google.com/d/msg/openpnp/ReY9_ZdwcWw/EOjwKlsjCgAJ

 

_Mark

[Mark]

> I think my axis mapping is ok as when I move so say 290,290 the cross-hair is still aligned horizontally and vertically and no move in Z.

 

You would not notice it, unless when doing pickups.

 

Just check your machine.xml to make sure. Search for “<axes” It should contain “N1” mappings (multiple if you have multiple nozzles):

 

<axes class="java.util.ArrayList">

            <axis name="x" type="X" home-coordinate="210.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>*</string>

               </head-mountable-ids>

            </axis>

            <axis name="y" type="Y" home-coordinate="600.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>*</string>

               </head-mountable-ids>

            </axis>

            <axis name="z" type="Z" home-coordinate="0.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>N1</string>

               </head-mountable-ids>

            </axis>

            <axis name="rotation" type="Rotation" home-coordinate="0.0">

               <head-mountable-ids class="java.util.HashSet">

                  <string>N1</string>

               </head-mountable-ids>

            </axis>

         </axes>

 

_Mark

[Mark]

> For squareness I used 290mm and it was off by -2.2mm (I have ordered some more accurate graph-paper ).

 

OK, that’s right. Just to make sure: you moved 290mm in Y and were off -2.2 mm in X, right?

 

> I have optical homing as well which seems very repeatable and stable (1mm white circle).

 

That tells us nothing about non-squareness, as it is a single point. But it rules out Vision as the source of the error.

 

Well, I’m at the end of my Latin, as they say (if I knew Latin J). Perhaps somebody else has an idea. Sorry.

 

_m

 

 

 

[Peter Chaisty]

Hi Mark

I had "*" in the Z and rotation entry.

What difference does that make (only 1 head later multiple nozzles).

I changed them both to N1

I altered the focus so the Fiducial is sharper (never change 2 things at once), now I cant get it to recognise the Fiducial.

Peter

--

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/qL6tzKHOP6U/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/01fa01d419fd%24d3b1eb60%247b15c220%24%40makr.zone.

[ma...@makr.zone]

Hello Peter
Hello Jason (if you’re tracking this)

I think the Wiki is wrong, it says

5. Use the formula in the image above to calculate the Non-Squareness Factor and enter it into the GcodeDriver settings panel.

https://github.com/openpnp/openpnp/wiki/GcodeDriver#non-squareness-compensation

But looking at the code, the nonSquarenessFactor is added not subtracted.

  command = substituteVariable(command, "X", x + nonSquarenessFactor * y);
  command = substituteVariable(command, "BacklashOffsetX", x + backlashOffsetX + nonSquarenessFactor * y); // Backlash Compensation

https://github.com/openpnp/openpnp/blob/0bfe717a8a0bf8fd34b88edba95f314c72cddb7a/src/main/java/org/openpnp/machine/reference/driver/GcodeDriver.java#L567

So if I am not mistaken, the non-squareness would actually be doubled and not compensated!

I remember, I had to reverse the sign for my machine, after checking the outcome. I thought it was my mistake and didn't realize the Wiki was wrong.

Jason, if you could quickly confirm this, I'll change the Wiki.

BTW. the last paragraph of this section seems wrong too. You don't have to change your MOVE_TO_COMMAND for this. This seems to be ad edit fragment from backlash compensation.

_Mark

[Peter Chaisty]

Hi Mark

I reversed the sign on squareness.

As my homing Fiducial works but the board ones don't anymore (after I altered the focus)  I manually set the board 0,0

I set relative on the DRO

jogged to the first Fiducial at 9,9 and that was quite close.

I then jogged to the second one at 87,106.

This is very close and allowing for board alignment probably correct ?

It seems Jog uses the squareness factor and reversing the sign has fixed it.

Peter

--
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/qL6tzKHOP6U/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/fd0d83a8-0b30-4855-884b-841b4d110a3a%40googlegroups.com.

[Mark]

> I had "*" in the Z and rotation entry.

> What difference does that make (only 1 head later multiple nozzles).

 

When OpenPNP tells your camera to go to the part it will give it all three coordinates X, Y, Z. So without the mapping it would lower the nozzle just for doing vision. This is dangerous as the nozzle has an offset and will potentially crash into nearby obstacles. Sometimes it is also just wasting time, you can see the effect in your log:

 

2018-07-12 15:49:10 ReferenceNozzle DEBUG: N1.moveToSafeZ(0.75)

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(G0   Z-1.0000  F750, 5000)...

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(COM3 G0   Z-1.0000  F750, 5000) => [{r:{gc:"G0   Z-1.0000  F750"},f:[2,0,20]}]

…

2018-07-12 15:49:10 ReferenceCamera DEBUG: OpenPnpCaptureCamera.moveToSafeZ(0.75)

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(G0   Z0.0000  F750, 5000)...

2018-07-12 15:49:10 GcodeDriver DEBUG: sendCommand(COM3 G0   Z0.0000  F750, 5000) => [{r:{gc:"G0   Z0.0000 

 

You should have noticed Z going up and then immediately 1mm back down. That is completely unnecessary and just comes from a 1mm Z offset in your nozzle to camera offset.

 

> I altered the focus so the Fiducial is sharper (never change 2 things at once), now I cant get it to recognise the Fiducial.

 

I do not believe this is the solution of the problem we’re discussing. In your log it was apparent that vision worked before. It did find the fiducial reliably and repeatably. Nota that focus is not very relevant to fiducial finding. In fact the vision pipeline adds blurriness as the first stage.

 

Please try inversing the non-squareness factor to +

 

_Mark

[Mark]

>It seems Jog uses the squareness factor and reversing the sign has fixed it.

 

Yes this seems to confirm that the Wiki is wrong.

 

Can you tune the fiducial pipeline? It’s probably just a threshold that needs tuning. Can’t help you there right now. Not at the machine.

 

_Mark

[Peter Chaisty]

Hi

I'll give that a try

Latest log 

after the Z and C changes you suggested,

Peter

--

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/qL6tzKHOP6U/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/021b01d41a04%24773fd390%2465bf7ab0%24%40makr.zone.

[Mark]

So he find another dot on the PCB?

 

2018-07-12 18:23:08 ReferenceFiducialLocator DEBUG: FIDUCIAL-1X2-FIDUCIAL1X2 located at (82.693667, 107.730947, 0.000000, 0.000000 mm)

 

2018-07-12 18:23:09 MessageBoxes DEBUG: Error: java.lang.Exception: Located fiducials are more than 1% away from expected.

 

_Mark

[Peter Chaisty]

Hi

Ok somehow it had started looking for squares.

It works now

By the way again the instructions...

I have attached images of my part and package settings for 1mm Fiducials.

The instructions are unclear in the wiki (to me anyway)

https://github.com/openpnp/openpnp/wiki/Fiducials

it says 

Set the X and Y position of the Pad to 0, and set the Width and Height to the diameter of the Fiducial. If the Fidicual is round set the Roundness to 100%. For example, a 1mm round fiducial would be defined as X = 0, Y = 0, Width = 1, Height = 1, Roundness = 100%.

In fact I set the package length and width to 1 and roundness to 100%

In the Part I set the height to 1mm.

You can also see now on the part R10 (I zoomed ) I only have a small error.

This is near the Fiducuial (mm away) at the moment I think I have to blame my squareness for this ?

Thanks for all the help.

I hope when I can place a part with a single nozzle I will give my machine.xml as an example of the most basic liteplacer setup with the new cameras.

Peter

--

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/qL6tzKHOP6U/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/022601d41a06%24ab119850%240134c8f0%24%40makr.zone.

[Jason von Nieda]

You're right, the Wiki is confusing. I think at some point I changed the text from "height" to "length" in the table but the Wiki didn't get updated. It's been updated now :)

You can set the Height in the Parts tab to 0, or leave it as it is. It's not used for fids.

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/CAGLOruTzjzM%3Dr8FtQtgA2BCAANHvwU36cm%2B%3DbtLXmUK6r3PSyg%40mail.gmail.com.

[ma...@makr.zone]

Hi Jason

thanks!

Could you please also look at the first and more important Wiki issue?

After a nights sleep I'm still convinced the Wiki formula is wrong (sign inversion) and results in doubling the non-squareness instead of compensating it. But I'd still like to have your second opinion before changing it.

See here:

https://groups.google.com/d/msg/openpnp/qL6tzKHOP6U/1DDQkNxCCgAJ

Thanks,

Mark

[Peter Chaisty]

Hi All

Sometimes it just helps for someone to work from scratch and follow the instructions.

Once someone has their machine setup they have no reason to go back !

So next measuring squareness alignment.

I have tried various types of graph paper up to A3 on Mylar with 1mm grids (paper ones especially were terrible by 250mm)

What I have found is none of them are accurate enough.

In the end the setup I ended up with was two steel rules and a sheet of accurate 1mm grids .

I laid one rule along the base line of the x and another along the 250mm x axis point vertically

I then moved the head in 100mm where possible then 10mm for the final 50mm steps to get to 250 on each axis.

I found the steel rule was the only reliable measurement then using the grid on the graph paper as a relative measurement to that.

Peter

[ma...@makr.zone]

paper ones especially were terrible by 250mm

Funny it never occurred to me to check. What do you mean by "terrible"?

This is my Favorit A3 Millimetre paper against a plastic "Geo Triangle" (whatever they are called). They are in agreement over 220mm as far as I can tell (surprisingly hard to photograph):

Because of picture size limitations this post will continue in a second part...

[ma...@makr.zone]

... (continued from the first part).

Not so sure about my steel ruler. Seems ~0.3mm off over 390mm (pics below). Even if the steel ruler is right and both the plastic ruler+millimetre paper are wrong, it still seems acceptable for a normal size PCB and 0402+0.5mm pitch parts. Thanks to surface tension! It is scary to watch the DFN/QFN parts girate and wobble in the oven when the solvents evaporate and want to escape from underneath ... and then the parts still settle down on their pads. Much talk of ridiculous "over-precision" in this forum.

_Mark

[SMdude]

I find it is best to just set the steps/mm based on pcb size.

When I initially set up my machine, I set it with various rulers, which all agreed with each other, however, every time I would set up a board, the board was not scaled correctly and the second fudical would never line up where it was meant to.

In the end I adjusted the step/mm to make the pcb's correct. I populate pcb's, not rulers!

Precision is not overrated.. Get a part .3mm out, waste time reworking by hand..

[Mark]

> I find it is best to just set the steps/mm based on pcb size.

 

Hmmm… then I guess you don’t have permanent feeders and nozzle tip changers. J

 

Doesn’t Jason’s affine transform solve the issue?

https://www.youtube.com/watch?v=Plz1_8DFCnI

You’d need to roll your own OpenPNP with this merge, though:

https://github.com/openpnp/openpnp/commit/bc4f0e25a0b4d14ea444be93de126b253a8a0116

 

NOTE: I have never actually placed a PCB or even used fiducials…  totally stuck in designing the new PCB… :(

 

But still…

 

> Precision is not overrated.. Get a part .3mm out, waste time reworking by hand..

 

… OK, but I  said “normal size” PCB so perhaps a third (~130mm) of the full 390mm, giving an absolute error of 0.1mm. With fiducials, only the “inter-PCB” distances are relevant and they are spread out symmetrically so the error will be ±0.05mm which is fine on the smallest 0.25mm pads, methinks. With the mentioned affine transform even this error is eliminated.

 

Of course errors from different sources do add up and I agree that one must remain vigilant. But I also think it is one of OpenPNP’s main objectives and achievements(!) to effectively use clever computer vision to get away with a cheap, noob*-made hobby machine.  

 

(*talking about me)

 

_m

 

 

[SMdude]

I found that just about all of my pcb's were out by about the same factor, that is why I chose to reset my steps/mm. It would have been no good if they were all over the shop as changing per job is not really a solution, unless just re-scaling the pcb area.

As yes, this would throw all feeder locations out. But if you are not changing steps/mm each job, then feeders stay put, provided you have visual homing.

The affline transformation would do the trick. There must be a reason that it is not currently implemented.

[Jason von Nieda]

Yep, I'll have a look over the weekend. 

--

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/e5c4fc47-706c-43c7-8474-1ba4d7dbe5ee%40googlegroups.com.

[Jason von Nieda]

The affline transformation would do the trick. There must be a reason that it is not currently implemented.

The reason is: It's not done :) It was just a proof of concept to see if the idea worked - not production code.

There is an issue filed with some discussion: https://github.com/openpnp/openpnp/issues/648

 Jason

[SMdude]

Hi Jason,

Well that sounds like a good enough reason to me! :)

It sure looks like it worked nicely in the video.

Cheers!

[Marek T.]

Hi Mick,
What when you get the board from some client to populate and it's made in other factory with other discalibration? Then you recalibrate the machine for it? :-)

[Jason von Nieda]

Yep, the idea is definitely sound and I think it would be a big improvement, but the code was trash. I just threw it together to try the idea. If it were deployed it would basically break every machine :)

Thanks for reminding me, though. I do want to finish this feature up and I don't think it will be too much work.

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/9abb3b8b-c02c-4db7-b0eb-0b93bf4a29a1%40googlegroups.com.

[Marek T.]

Hi Jason,

Second big improvement that worth to reminde you is the planner...

;)

[Jason von Nieda]

Yea, now if only there were 500 hours in the weekend :)

Jason

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/fc52f064-c266-4c6c-b9a3-42b79776d650%40googlegroups.com.

[Marek T.]

Yes the weekends are definitely too short :-)

[Jason von Nieda]

Hi Mark,

I think you are correct. Here's my workup of it:

So, based on this, I think the image in the wiki has the wrong sign, and the text "Positive factors mean a machine leaning right, negatives ones leaning left." is backwards. 

If you agree, please feel free to update the Wiki as you see fit, or let me know where I've gone wrong :)

Thanks,

Jason

On Fri, Jul 13, 2018 at 3:15 AM ma...@makr.zone <ma...@makr.zone> wrote:

--

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/e5c4fc47-706c-43c7-8474-1ba4d7dbe5ee%40googlegroups.com.

[ma...@makr.zone]

On Sunday, July 15, 2018 at 8:41:53 PM UTC+2, Jason von Nieda wrote:

Hi Mark,

I think you are correct.... If you agree, please feel free to update the Wiki as you see fit, or let me know where I've gone wrong :)

Thanks,

Jason

Thanks for looking at this.

Updated the image and wiki.

https://github.com/openpnp/openpnp/wiki/GcodeDriver/_compare/a6d244949e43c80adf07548fdbd535ed451291e4

New version:

https://github.com/openpnp/openpnp/wiki/GcodeDriver#non-squareness-compensation

_Mark

[Peter Chaisty]

Hi Mark

I checked the link.

Looks correct to me 

Peter

[Trampas Stern]

When I was working on my PnP I wrote a custom Python based program. One of the things I did was do an affine (least squares) fit to multiple points.  For example I could align board using multiple part locations. The software would then spit out the rotation and scale parameters to get the fit.  From these I could determine if the machine was square, and if the steps per mm were correct, etc.  Sure it was over a small area of the PCB but it worked amazing well.

I also found out several things, like EVERYTHING needs to be square/perpendicular.  The camera to the build plane, the head to build plane, the X and Y axis the Z axis.  Also everything needs to be rigid, if you can move the camera due to soft mounts, it will cause issues. same for everything else.  I finally removed all my plastic parts and replaced with aluminum before getting a real machine. 

I also learned that you should build your machine up side down, that is the linear rails (Hiwin) rails should be on the bottom (this helps keep dust off). It also helps because you can put diagonal braces on the on top of the unit to hold Y rails square and parallel.  These little things start adding up to make big differences long term. 

At the end of the day quality has to be designed and built into the machine, it can not be added latter.  It is like trying to support your house on field stones, that is without a good foundation you will never keep the system square and stable.  

I would really love to see the results of a machine shoot out. That is everyone take their PnP machines with some 0402 parts and then print out on some paper a build (or use PCB) then add double stick tape. Then everyone try to place parts for the build (no changing/tweaking the build program). This way we could see and compare quality of various builds.   Basically  the idea is to come up with some metrics on how good a build is (speed, accuracy, repeatability, etc).  This way as a group we can start looking at what makes a good machine design, and learn from others mistakes.  I know my first few designs were junk. Even the last one I still used a wooden platform which flexed and caused errors. 

 

[Peter Chaisty]

[Peter Chaisty]

Hi

I think your right.

For one thing you said Hiwin's so that's on cause of backlash eliminated. I'm a big fan of these .

What size did you use ?

I also agree all the critical mounts need to be aluminium

I'm thinking of using 80 or 100mm extrusion and buildup up on a 12.5mm thick aluminium plate I already have.

Just for tonight I'm going to have one last try with my Liteplacer as I have a friend over / fresh set of eyes.

I need to see 0.1mm repeatably I think.

Peter

On Monday, 16 July 2018 12:27:49 UTC+1, Trampas Stern wrote:

[Trampas Stern]

I had a Shapeoko machine using the maker slides, I ended up giving it away I could not get any repeatability from the maker slides, especially on milling with a load. 

The I was using 12mm hiwin on my design following from Anthony: 

https://hackaday.io/project/9319-diy-pick-and-place

I found if you invert the design it was much better.  However I never finished my design. 

If I was to do it again I would spend $5k on a Chinese machine and convert to OpenPnP.  If really wanted to build something I would start with some good aluminum tool base: https://www.midweststeelsupply.com/store/castaluminumplateatp5 

Then I would design in the RoboDigg Yamaha feeder plates, I found that around 80 feeders is a good start.   Then I would use large hiwin rails and ideally ball screws. However if not ball screws I would use as wide of belts as I could get, 25mm belts good 

I would do an on-the-fly up looking dual head. The heads would be multiple of feeder widths apart, such both nozzles could pick parts at same time. 

I would do the whole design in CAD before building anything... 

Trampas

[Peter Chaisty]

Hi Trampas

I had a shapeoko too.

I gave it away to a friend and I bought a cnc machine thats weighs about 800Kg and is about 2m high.

Its much more rigid :)

Peter

--
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/qL6tzKHOP6U/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/f9ae2b42-706c-48e1-9a59-65dd39bdcc61%40googlegroups.com.

[Mark]

@Trampas

> If I was to do it again I would spend $5k on a Chinese machine and convert to OpenPnP.  If really wanted to build something I would start with   some good aluminum tool base: https://www.midweststeelsupply.com/store/castaluminumplateatp5 

> Then I would design in the RoboDigg Yamaha feeder plates, I found that around 80 feeders is a good start.   Then I would use large hiwin rails and ideally ball screws. However if not ball screws I would use as wide of belts as I could get, 25mm belts good 

>I would do an on-the-fly up looking dual head. The heads would be multiple of feeder widths apart, such both nozzles could pick parts at same time. 

 

I’m sure throwing muscle at the problem will help a lot. And in fact I even agree this might not cost more in the end, especially if you even start thinking about putting a price on your own work hours.

 

But while I’ve still not really placed my first real board with my machine, I’m still convinced one can throw brains at the problem instead. OpenPNP is the visionary enabler of this. Pun intended, as clever use of computer vision plus some linear algebra are the means.

 

In fact this very proposition is the main lure of this project for me. Everybody can solve problems with a lot of resources. The cool thing is solving them without.

 

_Mark

[Peter Chaisty]

Hi Mark

I was quite happy with a pillar drill and file until a mechanical designer friend said I needed a lathe and milling machine.

I started off with the chinese ones (warco) and great to learn on but very poor build quality.

Scared me to death at first using them !

Now they complement the electronics side of my business.

I have an industrial unit so lucky enough to have the space and to be able to accept larger machines.

I now have some very accurate 1970's machines that no one else wanted (machines are cheap the tooling on the other hand !)

What this does mean for me is that I can make my own open pnp hardware.

I have been disillusioned with Chinese products , be they death trap electronics or poorly built hardware made to the lowest possible price.

I would be very wary of the quality of the components used let alone the electronics.

At the moment I am in the same position as you I havn't been able to place a board.

My philosophy is that it needs to place the QFP's I use along with 0808, 0603 if I have to place these manually it becomes a real pain.

I want it to work properly or its not worth having.

I normally build boards by hand mostly using a stainless steel stencil that comes free with the boards and then I have a modified Chinese IR reflow oven for soldering.

Or I just solder by hand , bent over a benchtop  magnifying lamp.. not fun .

I just about manage by hand  but I desperately need my pick and place working.

 I am also designing a vapour phase reflow oven as soldering is now as big of a headache as placing parts.

They are getting smaller , more and more parts have pads under them and I am getting older.

I think I will be able to get the liteplacer working but soon after I might abandon it and build my own hardware.

To be fair the Liteplacer is a great concept and it cant be expected to do more than it does for the price.

I think lots of other people have had good results from it.

For me its been good to learn whats right and wrong with a design and I have started using the open pnp software and really like it .

The support and help from other people is superb as well.

Peter

I

--
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/qL6tzKHOP6U/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/00b101d41e78%243aab7150%24b00253f0%24%40makr.zone.

[Mark]

>At the moment I am in the same position as you I havn't been able to place a board.

 

Just to make it clear: my problem now is not with the machine. I’m stuck designing the new PCB and changing to a new MCU.

 

I just don’t have enough time. This is 100% hobby for me.

 

_m

 

[Mike Harrison]

Might have potential for loose part feeding :
https://hackaday.com/2018/07/22/a-3d-printed-bowl-feeder-for-tiny-smd-parts/

[Jason von Nieda]

That is so cool! I've always wanted to see vibratory bowl feeders used for PnP. Sounds like the creator has ideas for auto sorting different parts with it too. 

Jason

On Sun, Jul 22, 2018 at 9:19 AM Mike Harrison <mi...@whitewing.co.uk> wrote:

Might have potential for loose part feeding :
https://hackaday.com/2018/07/22/a-3d-printed-bowl-feeder-for-tiny-smd-parts/

--

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/ii49ldlgeuo4m0eim1h99numqjbh42h5e1%404ax.com.