Hi, ----- original Nachricht --------
> What you want to do is look at emccanon.cc and canon.hh (located in > emc2/src/emc/task and emc2/src/emc/nml_intf if my memory serves me right). I have been looking at them a few hours ago as i took a look at the stant alone parser compiled from the rs274ngc part of emc1. > Those are the canonical calls that get called after the interpreter analyzed > the g-code. Yes, but they are before any path planning takes place. I love my usb gadgets t be as cheap and simple as possible and in my scenario i don't think it's necessary to do the actual path planning in the device. The PC has much more power to do this and can send the results to the interface. > So you'll send things like STRAIGHT_TRAVERSE or LINEAR_FEED to the > microcontroller. These won't be a problem, but i'll also see ARC_FEED and the like and that will be too much for a simple microcotroller. > - you need at least from time to time feedback from the motion controller > (machine hit a limit, various error things, etc) Agreed > - the USB side needs to buffer the commands that come from task (they can > be quite many on programs with small segments, etc) Yes > - you need to implement the "motion controller" on the USB device (which > you'll have to do no matter what approach you take, be it emc or something > else). Why can't the PC do this and forward a whole bulk of "do one step here and then one step there and after this time do a step there" commands to the interface? > It might be that the current buildsystem is scary for newcomers, but it > wouldn't be _that_ hard to remove all realtime stuff from it (for example > emc2 builds for non-RT systems using --enable-simulator). That might be a > good place to start. Yes, in fact that's why i asked in the first place. The simulation shows that everything can be done in non-real-time-userspace. And the simulation can probably accelerated to insane speed meaning that alle machanisms to generate the "step by step" information fast than real time already is there. > not quite true, see my description above, and I can provide more indepth > info if you need it. I'll take a look at it. Thanks for that offer. > it's not a control loop in the traditional way, but there are things which > are supposed to go back and forth. > for example the motion controller reports the current position, which gets > displayed in the GUI. My suggestion basically only is: Don' t run the motion controller at a rate provided by the real time kernel, but have it run as fast as possible and have it stalled by the usb layer being stalled having its buffer filled up. > well, the problem with EMC is that it's not a single loop, there are various > interconnected ones, so it won't be a 2-hour hack job to make it work. > The most likely loop you want to embed is inside emc2/src/emc/motion (of > course stripping half of what is there, that you don't need). Thanks, that's exactly the info i wanted. > that depends how you implement it. If you want to implement the motion > capabilities inside de USB controller, > und use the remaining EMC for the interpreter, GUI and IO control, then I > think it's fine.. Hmm, as it said before i'd love to have the PC doing the complex motion planning. Till ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
