Hello EBo, My responses are included below. -Neil-
On Sun, Dec 27, 2015 at 12:35 PM, EBo <[email protected]> wrote: > On Dec 27 2015 10:47 AM, Jon Elson wrote: > > On 12/26/2015 07:59 PM, Neil Whelchel wrote: > >> Hello Jon, > >> It is not a retrofit. MyData has used Linux since about 1993 on all > >> of > >> their machines, > > > > WOW, I'd never heard this! > > I did a little fact checking on the net and could not immediately > verify. If this is truly the case, it is likely one of the oldest (if > not oldest) commercial use of Linux out there (and has a 22 year success > rate running in industrial operations). That would be big PR for both > MyData and Linux. We should verify this and document it on Wikipedia > and elsewhere. I have been using Linux in embedded systems since late 1992. Most of these systems were used in plastic injection machines, and sequence controllers used in manufacturing. In early 1993, I used Linux for an embedded phone switch. I am not sure at what point MyData started working with Linux, but it is possible that my work pre-dates that. MyData, is now MyCronic. I am not sure how many of the old staff is still available, but I don't think that it would be too hard to get ahold of someone. >> for a short time before that they used Xenix, but the Xenix > >> versions never worked well. > > > > I have heard there were problems with the older MyData > > machines just going crazy sometimes. > > > >> The software is called TpSys, it is a > >> collection of C, Perl, and bash programs, about 300 of them. The > >> design is > >> fantastic and well thought out. They are also extremely reliable, > >> and > >> stable both hardware and software. > >> Here is a video of someone setting up a machine, this video is one > >> of the > >> few that allows you to see the UI. > >> https://www.youtube.com/watch?v=UdJxuux0r28 > >> Here is a video of the machine in action. The red flash that you see > >> is the > >> up looking camera. It looks at the parts that the 9 vacuum tweezers > >> (nozzles) are holding as they move past to make a precise > >> measurement of > >> the locations of the pins on the parts so that it can calculate the > >> position offset and rotation of the part when it places it on the > >> board. > >> These machines typically place pins to within 0.0005 inches. > > two things come to mind here. If MyData is Linux based, then we should > be able to request a copy to study and learn what that tells us about > how the UI is designed. > MyData has been quite closed about their software. It is not open source. As I said before, I am extremely familiar with it, and I can provide information about how it works. > Also, you should be able to do something similar with the cameras. If > it were me I would start with, and Nick I know this might touch a button > ;-), to start with OpenCV get the algorithms down and then move onto > something less heavy weight unless we want to keep the power of OpenCV. > Implementing something like a Haar transform to detect edges, etc., is > really not that hard. I would want to do things with it like find the > centroid of a hole, a milled pocket, or fiducial mark. We can use spot > drilling some holes with an end mill to calibrate the camera position... > > Hmm, that sounds really GOOD! I think my repeatability is > > probably closer to .005" or so. Just BARELY good enough for > > anything finer than SOIC lead pitch. > > I think you can probably get much, much better than that. The real > question is what is the precision of all the various components. I > would never expect something like a BlackToe inspired P&P machine > <https://buildyourcnc.com/PickandPlaceMachineTheredFrog.aspx>to do any > better than .005" on the TPI, but a general rule of thumb would be to > have your sensor measure at least 5x (and preferably 10x) what you hope > to achieve. That would mean if the MyData can reliably give you .0005" > that means that the step size of the machine needs to be at least .0001 > or .00005" and the pixel resolution would need to be down in the .00005" > or less range. That is not a problem with macro lenses, and frankly if > we constrain the system that the center pixel is camera(0,0) then you do > not have to worry so much about slight variations in the thickness of > the boards/parts which can/will cause a parallax problem. Anyway, there > are simple fixes for that. We can also look at setting up two or more > cameras and deriving a simple 3D geometry from the parts -- is it flat? > > A big part of the optical accuracy of the MyData machine is that there are two cameras stacked vertically, the lower one has a mirror, the other has a coated piece of glass that acts as a mirror for the upper camera, but the lower camera sees through it. The cameras are single line CCD chips, the same kind that are found in fax machines. The movement of the components above the camera is required to make an image. Both optical sensors are aligned to cover exactly the same area but at a different scale. I have used cameras on projects that require extremely precise measurements. I made this work by moving the camera in small increments and taking several images. The images are combined to get much higher resolution than the camera produces, this is a method that can be used for what you are talking about. > >> https://www.youtube.com/watch?v=M-aWoHl6pyM > >> I have extensive experience with these machines, I am happy to > >> answer any > >> questions that you might have about them, but I am not sure that > >> this is > >> the right place to have this conversation unless the rest of the > >> Linuxcnc > >> developers are interested in listening in on this tangent... > > > > Some may be interested. Anyway, I already have the Philips > > CSM84, and will stick with it until something major breaks. > > Then, I'd have to consider what to do next. Retrofit or a > > whole new (used) machine. > > I would be interested for reasons other than pick and place. I need to > add though that this is a curiosity for me and a major interest. You > have nearly 20 projects in from to capture a non trivial bit of my time. > On the other hand, if this can be combined with other needs... > > >> But since we are here, I will put in my 2 cents worth. > >> I have been following the OpenPnP project for some time, and as far > >> as I > >> can tell, they have some (extremely) good ideas, but they are headed > >> in the > >> wrong direction. It is not likely ever going to be in a position to > >> be a > >> good retrofit tool for anything, it will likely only work good on > >> hobby > >> machines. > > > > Yes, you seem to have the same view as me. > > I am curious about what they got right and wrong in your opinions. I > have heard of the project, but never had a need.. > I will make a list of things that commercial PnP machines require that are not in OpenPnP. 1) Accounting. Every part needs to be tracked. Which board it goes on, and which lot and number the part is. This goes on to the point that the machine knows which parts have been placed on which boards, and communicates this with other machines. This makes it possible for machines to be chained together and if one machine is out of a particular part, the machine can communicate with other machines in the line to place the part if they have it in their feeders. 2) Parts inventory. Look ahead to know when parts in the feeders will be exhausted, so that alternate feeders can be used to allow the machine to run for the longest times between restocking. 3) Feeder position planning. The positions of the parts feeders is calculated so that the runtime is the shortest. (Parts that are used more frequently are located closer.) This goes as far as deciding which machines in a line will place which parts. 4) Placement reorder. This is a big one. If a feeder jams or otherwise runs out of parts, the machine can stop pulling pars from that group of feeders and continue to work while the feeder group is reset. This takes into account the height and inertia of placed parts. (Some parts are heavy, and the machine velocities must be lowered after certain parts are placed, so they are not thrown off of the board. Also, in some cases a tall part may block placing parts around it, or even under it, this is taken into account as well. 5) Acceleration limits. The machine keeps a database of acceleration limits of parts that are placed so the machine does not cause the parts to move or come off of the board after placement. 6) Auto loading and unloading of boards. 7) Placement pressure, and squeeze. This is a big one that is missing from some low-end commercial machines. When a part is placed, the pressure that is applied is measured along with how far the part has moved into the solder paste. Proper pressure and placement speed are critical for proper reflow. 8) Component testing. Each component that is placed can optionally be tested. It is rejected if it is outside of preset limits. The test value is saved to the placement database. 9) Multiple placement nozzles. Many commercial machines have multiple vacuum tweezers, the MyData has 9, it can take 9 parts per trip. 10) Line scan camera. This is a big one that I have never seen in the hobby PnP machines. Many commercial grade PnP machines have a line scan camera that has at least 4k pixels. It is typical to capture images of 8k x 8k. As the shuttle moves over the LSC, it creates an image. Hobby machines must stop and take a picture. 11) Lighting database. The lighting used to image the component is stored in the package database. There are usually several modes of lighting. Direct, diffused, ambient, also differing lighting positions and intensities are used. 12) Feeder groups. Feeders are grouped together, usually in a removable box. This box can be removed while the machine is busy placing parts. The machine will pull from other groups until the group is re-inserted. 13) Palette changer. Parts palettes are swapped automatically when the parts are exhausted. 14) Optical placement check. Some machines visually examine the placed part and can flag the operator when a part is improperly placed. 15) Placement configuration database. Some boards must be assembled with specific options enabled or disabled. 16) Board identification. Read a barcode or label on the board to match it to the database. 17) Panel awareness. Boards are usually in a group on a panel. Panels have marks to identify good and bad boards. The machine reads these marks and can skip placing on a bad board in a panel. They can also deal with panels that have more than one board layout on the same panel. 18) Glue. Many boards that have components on both sides require gluing parts to the board. These are just the ones I can think of at the moment, I am sure that there are more... The issue is not that these features are missing, it is that OpenPnP is moving in a direction that actually blocks many of these features, or makes them get in the way of the intended usage of the project. For example, it is not easy to use analog servos with OpenPnP, it is setup to use steppers. While it is possible to get force feedback with steppers, it adds complexity in comparison to a good analog system. For this to go in the right direction, OpenPnP wold need to close the servo loop in software like Linuxcnc does, and in addition, it would need to look at the pid values in real time to do the squeeze calculations, or detect mechanical collisions. >> The entire concept of using G-code for a PnP machine is not a good > >> idea on > >> any level. > > > > Right. It is what is there, but not a proper fit to the task. > > So what do they use? > > They use a place list. The place list is a database that keeps track of which packages go in which location on which board on which panel. This place list is shared between machines so that multiple machines can place the same panel. > >> However, Linuxcnc can help here. You can control Linuxcnc > >> directly with its Python API, so it would be a good match to use > >> Linuxcnc > >> to handle the realtime robotics and IO, but the PnP logic would have > >> to be > >> created. If someone were to do this (properly), such a project would > >> be a > >> likely retrofit for old PnP machines. > >> > > Yes, this makes a lot of sense. If Linux/HAL/Python was > > handling all the motion-level stuff, it could make a PnP > > program with extensive error recovery a much smaller project. > > Do you have one you could test on? Or something you can set up as a > test bench? I would be interested in following your progress, but I am > unlikely to be free to contribute. I do know of someone that > wants/needs a custom parts machining center. This type of logic process > would likely be more amenable. > > > EBo -- > > > ------------------------------------------------------------------------------ > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers > ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
