> 2011/4/1 Stephen Wille Padnos <spad...@sover.net>: >> >> It's probably not the interpreter that needs improvement, actually. HAL >> can handle as many actuators as you want (subject to some execution time >> limits that nobody has come close to yet). One could easily write a >> very very simple motion control HAL component, which can have multiple >> instances. This might be something like a limit3 that takes into >> account multiple inputs simultaneously. If there were a userspace >> component to feed positions (think like halsampler/halstreamer or >> something), then you'd be all set. >> >> This is probably closer to what the original question was, since it's >> unlikely that any pick&place machine cares what the next one is doing. >> It's also not necessary to use G-code to command a pick&place - it only >> needs 2(.5)D coordinated motion and some I/O. >> > > Please correct me, if I am missing something: > 1) the only way I imagine, how one can describe the "2(.5)D > coordinated motion", is by g-code. > 2) if You want several coordinated motions simultaneously, then You > need several instances of trajectory planner (or other module that is > responsible for coordinating the moves), because AFAIK currently EMC > cannot simultaneously control more than one tool, it can execute only > one coordinated motion at a time.
The language that we call "G-code" is only one flavor of machine control codes, and it's a relatively complex one. The G-code used for PCB files (gerber files) is significantly simpler, and is closer to what is needed for a pick&place machine. What should be needed for a P&P machine is to have a set of "macros" for picking up various parts, probably some set of macros for centering the part (or detecting center with e.g. a camera), and a set of macros for placing the part (ie, SMT parts are just mashed into place, through hole (if anyone still uses those :) ) used to have little circular jog motions until the pins caught in the holes, etc). You then might have a "language" that has a form something like this: <feeder #>, <pickup orientation>, <pickup macro code>, <centering macro code>, <Target X>, <Target Y>, <target orientation>, <placement macro code> [, <movement speed>] The pickup, centering, and placement macros could also be defaulted by feeder, since a feeder only supplies one type of part for a given build. Movement speed and pickup orientation are also feeder/part dependent, so they could be left out. In the end, you get something like what a PCB program spits out for a pick&place file: Designator Footprint Mid X Mid Y Ref X Ref Y Pad X Pad Y TB Rotation Comment R8 0402_RES 4078mil 2625mil 4078mil 2625mil 4078mil 2644mil T 270.00 56K 1% R4 0402_RES 3277mil 2567mil 3277mil 2567mil 3277mil 2548mil T 90.00 33K 1% R3 0402_RES 3814mil 2350mil 3814mil 2350mil 3833mil 2350mil T 180.00 33K 1% R2 0402_RES 3000mil 2680mil 3000mil 2680mil 3019mil 2680mil T 180.00 100 ohm R1 0402_RES 3000mil 2616mil 3000mil 2616mil 3019mil 2616mil T 180.00 100 ohm (sorry about the word wrapping) An "interpreter" that takes in this file format or similar would be a much better match for this kind of machine. The HAL layer would need to have all the stepgens and hardware drivers loaded as a single realtime system, but the stepgens would be fed by a custom interpreter and simplified state machine (for the pickup/place macros). There is no need for a coordinated motion controller, since all movements are like G0 - it's irrelevant what path is taken to get to the endpoint, what matters is that you get there (without hitting anything). RS274NGC is overkill and inefficient for this kind of machine. IMO, IANAL, YMMV, etc. - Steve ------------------------------------------------------------------------------ Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users