Updated Eagle ULP to allow double sided operation

[berniwa]

Hi Nate,

after reading your series of articles on sparkfun I just went ahead an bought a CHM36VA (arrived yesterday). I used your ULP for the first test runs and it worked great - thanks a lot for that!

Unfortunately most of our designs have SMD parts on the bottom (or double sided), so I decided to work on your ULP a little and added the following stuff:

a) Added GUI to review part placement and feeder configuration b) Allow usage of local and remote spreadsheet for feeders c) Added column autodetection for feeder configuration d) Added board statistics e) Added automatic offset correction -> Only positive coordinates will be in the final file (machine will output errors if coordinates go negative) -> An additional offset, for example for a frame, can be specified f) Output top and bottom placement data -> Bottom data can either be mirrored horizontally or vertically e) Settings will now be saved automatically to the ULP folder

If you like the changes, pull it to your git ;-)

I plan on working on fiducial and tray handling, but that depends on my time.

Greets Berni

[nseidle]

This is superb. This is not a bug fix it's a full rewrite - thank you! Looks very good.

A few things I noticed:

• The human-readable feeder name is not getting into the work file. I should be able to fix that.

• This requests loses the feature that asks user where they want to save the output. I'll try to re-implement it. It would be good to store their preferred location in your new, very good idea, cfg file.
• Storing the feeder file location (g-sheet) in the cfg is excellent and the right thing to do but I need to shield our feeder key from git. I'll add to the gitignore.

[nseidle]

Oh man, I should have tested better. This merge breaks a handful of things.

[berniwa]

Hey,

1) Human readable name: I'll have a look on the weekend to see whats wrong there. 2) Output file: I actually prefere it to be autosaved to the project directory, but I guess we could do a project specific config file, that would allow you to set and save the filenames on a per project basis. 3) Jep sounds like a good idea

What does it break? - just shot ;-) I tested with your sample file and the output look good and also the placement tests I did with my machine worked ok. You have much more experience with the machine, so I'd be happy to correct any problems.

A few things will be different from your output:

• The ulp handles the vision/vac flags as well as speed
• Placement data for "new" feeders wont be written into the file
• Component length/width can optionally be specified

So feel free to unmerge the stuff for now, and I have a look over the weekend to fix it.

[nseidle]

Thank you so much for this contribution! It is very very helpful.

I think I have fixed all my concerns. Please see the closed issues and commits to see what I was breaking ;)

Let me know when you populate your first boards. It is a fun machine!

[berniwa]

Ahhh, i wasn't notified about the issues, so I didn't really see what was going on! (and its bedtime here already so I didn't pay to much attention)

Sorry that I broke so much for you.

Just reviewed your changes and they look good to me, but I have two questions (why I probably implemented it wrong in the first place) a) Setting width/length of the part to 0mm per default will basically disable vision and (at least in my tests) this leads to lost parts not beeing detected (mainly doing 0402s) b) Why are you using the center of all pads instead of the origin of the part as reference? All Eagle passives should have the origin in the center. The problem i see with your algorithm is that it will behave unpredictable if you have unsymetric parts like SOT-223 for example with different pad sizes. (as you only take the pad position, not the size intl account)

I did some dry runs with double sided tapes so far, to get everything working first. So far the machine is pretty fun, and the thing is pretty speedy. Now the days of placing thousand 0402s per hand are finally over 😀

[nseidle]

Sorry that I broke so much for you.

No no! We're good. Your refactoring and feature additions were excellent.

a) Hmm, really? I have done a fair amount of testing and always had failure with anything but 0x0. I asked CharmHigh (back when they were answering my emails) and they said to set at zero. I got the impression that 0x0 would force the CV to auto-detect the bounding box. I will try a 0.1x0.1 box on Monday.

b) Good question. When users create a FP that is not perfectly centered then the placement will be very wrong. Finding the center of the component is imperative. Please see image in issue. The method I used comes from Eagle's own mountsmd.ulp.

I did some dry runs with double sided tapes so far, to get everything working first.

Indeed - run a few more boards and you will see more things break. That's why we've made so many changes (see part b above ;).

So far the machine is pretty fun, and the thing is pretty speedy.

I know! We love to watch it. It's just fun to run.

Now the days of placing thousand 0402s per hand are finally over

I completely agree. 0603 LEDs were really what pushed me over the edge.