On Dec 27 2015 11:04 PM, Neil Whelchel wrote: > 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.
Then it looks like they may be violating the GPL (unless they roll all their own apps, which might be the case). >> 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. makes sense. >> >> 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. There are a number of those operations that would be of interest to me (like gluing, board/part ID, optical placement, part pallets, accounting, as well as integrating a line scan camera). I still need to get several of my current projects off the table before I start something new... >>> 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. Then how does the place list differ (internally) to something like: o100 sub g00 z0.5 ; move to clearance height g00 x#1 y#2 ; move to placement position g01 z#3 ; drop down to z-height -- spring loaded, force feedback, or variable air pressure g00 z0.5 ; move to clearance height o100 endsub o100 call [x1][y1][z1] o100 call [x2][y2][z1] ... It does not solve all the issue you want, but then again ISO 10303 STEP (aka STEP-NC) would likely be a better fit for the control than g-code. Other than that you use API to move into place and run the cycles as needed. Not all machine ops are suited to a given operation (ie PnP). EBo -- ------------------------------------------------------------------------------ _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
