I was heading up Altium hardware development in 08 when a push was made for Altium to pursue this objective. The idea was to tie in the source CAD data and the 3D PCB visualization technology with a desktop pick and place machine to make assembly a one press operation, complete with a 3D simulation of the boards assembly progress (being a PCB in 3D with components appearing as they were placed). A dry run could be simulated, showing the order and path in which components were positioned onto the board prior to commencing final pnp assembly.
The backlash we received from pick and place manufacturers was horrific - far from interested in any partnership. They clearly have software, profitable software, that a desktop PNP would make redundant. They take CAD data and make new saleable "manufacturing IP". Dont expect an easy ride to desktop pick and place, or for machines to turn up any time soon. Not without a few aggressive acquisitions first.
Altium dropped the desktop pick and place project, but 3D moved onto becoming standard.
Sorry for the late reply. I was traveling and prefered to spend the time with the family over being on the computer ;) I appreciate your thoughts and would love to heare some of your experiences that you had in looking at your machine.
As to looking at motors, this actually plays into the cost, size and weight considerations. If one can use hobby motors, this would open up a lot of doors as well as keep cost low. Hobby BLDC motors tend to have higher power to weight ratios than other motors, though, there are some other considerations that make them not as desireable.
Once again, thanks for sharing, and I hope that you share more about your experiences.
I worked on a similar PnP design many years ago, and used a grid to store components, that worked fine. IMO, you should choose a gantry/carriage design before comparing motors etc. There's some designs of XY arms where all the motors are static, so the arm is very lightweight. For low volume PnP, the capital cost of the system is more important than speed, so I think steppers+belt are OK (all low-end 3D printers use steppers).
I am familiar with the feedforward terms from when I designed a high cycle fatigue rig for simulating flight loads for composite rotor blades. It was a hydrauliclly controlled system that used a Delta Motion controller. That was a fun rig. I understood the mechanical needs of the rig, but had no clue about the hydraulics. We hired a company to help us, and they failed miserably. We ended up learning a lot about hydraulic design and control in a very short time (about 2 months). The rig ended up being very successful.
We were able to run at just over 1Hz with about 6" deflections on a fully reversing ~1700lb load. In total there were 4 axis of control and the highest one had 17,000lbs of load. The limiting factor ended up being that the feedback control was based upon load cells and not displacement. Because of the mass of the system, this caused it to get unstable at higher speeds of operation. Unfortuantly my boss would not let me get actuators that had linear encoders in them. So because he did not want to spend about $2000 more, we ended up spending $20,000+ more because we could not up the cycle rate.
I like to think of it as funnelling down to the end position, if you are aware you are in the top part of the funnel then you need more braking, if you are in the bottom part you need less.
It's a bit like staying on a glidescope for an ILS landing , as this also funnels you into touchdown.
The "quasi open loop model " you describe can be integrated into the trapezoidal trajectory. So if you consider that maintaining a target velocity that is some constant value above the measured velocity results in a constant acceleration (and a target velocity below actual results in deceleration). Then you take the trapezoidal trajectory , and add a constant amount to the upslope, and subtract a constant amount from the downslope. So the resultant motor motion (from using the open loop modified trapezoid , without feedback ) will be very close to that required to get the exact move position. Now all the closed loop has to do is mop up the difference. The "model" is basically just accounting for the extra force required to accelerate the mass of the carriage, so the constant offset is proportional to mass and acceleration. You do this all the time when driving and don't notice, you need to squeeze the pedal more when the car is heavier to keep up with the traffic when the lights change.
I would normally call these model terms "feedforward" , most of them can be pre-calculated before the move. You can also calculate them on the fly. You might end up with 75%control effort from the feed-forward terms and 25% from closed loop. The other feedforward model term to add is to shift the aim point slightly, you will find that the control algorithm/ settings that produce the most repeatable, smooth stable trajectories will consistently overshoot or undershoot, so simply shift the aim point temporarily, then when you are almost at the destination, set it back again. No different to aiming a dart high so it hits the bullseye. Expect to use maybe 4 or 5 parameters at most to describe some simple feedforward terms.
I guess that there is another way than by going completly open loop, and that would be a quasi open loop mode that would rely on a model of the motor and go open loop in velocity, but stay closed loop in the displacement. In this it would control velocity based upon this model estimating the needs, and then once the move is made, checking with the position side of things to see if the target was hit within a certain accuracy.
@Adam , I saw the hackaday article about a month ago.
Seemed to me to more difficult than the toner-transfer method, it's only viable if you happen to have a laser cutter/etcher lying around.
I did a bit of messing around with a 500mW IR laser diode last year, trying to see if I could cut a stencil with it, but it would only melt (not properly vaporise) thin black plastic , wouldn't touch clear mylar :(
Another mate bought vinyl plotter and uses it as stencil cutter, So I get him to do the one off proto stencils for me.
Not withstanding all the above, there is no reason not to mount a laser on your PnP machine at some later stage. Although you need to think about laser power and wavelength.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...