John Harris wrote: > Hi Jim, > I'm very interested in your proposed project, of moving the > 'Real Time' out of the box and into a USB replacement for the parallel port > breakout board. > > I design motorized microscope XY stages and focus knob drives for Z, with a > 3-axis controller running from a USB port. I also have two mills that are > potential targets for a EMC2 based CNC upgrade. > > When Microsoft (can I use that word?) upgraded to Win3.x and became > multi-threaded with the added feature of latency, I moved all my real-time > stuff out of the box. A FIFO command buffer takes care of the latency and a > bunch of FPGA code allows complete parallel control of the three axis. > > I have been thinking some time, that a similar solution could be made for > EMC2, to switch to USB when there are no more parallel ports > > So where would you divide EMC2 to split off the latency susceptible > real-time stuff, and what would be the software to software interface > through the USB port? > > I have not done box software other than LabVIEW since Win95, so I'm a little > reluctant to dive into the EMC2 source code on my own. > > John Harris >
This subject seems to come up every month or two. The answer is and will probably always be the same. Yes, it is possible to make a box that lives outside the PC and can queue up enough motion "in advance" that it doesn't require realtime performance from the PC. The problems start when you start asking yourself how much is "enough"? A hundredth of a second? A tenth of a second? A second? Five seconds? If all you are doing is following a path that doesn't depend on anything external, then sure, queue up 10 seconds or even 10 minutes of motion. But what if the user hits stop? Do you stop now, or after you've executed the 10 seconds of queued motion? What if they turn up the feed override (or turn it down)? What if they are doing a probe move, where the distance traveled isn't fixed, but depends on when the probe hits something? What about threading, where the movement needs to slow down or speed up if the spindle speed changes, and needs to start just as a specific spot on the spindle goes by? EMC is designed doing all of these things in the PC, because the PC (when running Linux with a realtime kernel) is capable of doing realtime control. If you try to take "realtime" out of the PC, it isn't enough to just move step generation, or simple motion, out to some dedicated hardware - you have to move EVERYTHING that EMC currently does in realtime out of the PC. You can do that if you want, but you lose one of the big benefits of PC based control. On a PC based control, it is easy to find problems, add features, and update the software. If you embed everything in some external box with no keyboard, no screen, no development tools, etc, you are rather locked down. It's one thing to embed simple stuff that can be tested and proven robust, and that is unlikely to change. It is much tougher to embed complex code that will need to be debugged and changed to meet evolving needs. Regards, John Kasunich ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
