Daniel Lee wrote: > If we allow for a hartbeat between external boards ( your servo time > 1 ms ) we can > expand the system to any size and mix servos,steppers and other types > of hardware. If we allow motion commands to be qued > in advance by the pc EMC can operate in user space only. But, that is the problem, the current scheme requires real-time round-trip communication between EMC and the motion controller, and we have strong reasons to want to keep it that way. You can't have the PC handling the servo PID loop if anything is queued or buffered. > We could move the stepping funtions into > loadable drivers. All trig funtions as well as kenetics would be > handled in user space with simple intiger math used in the kernal > space. I have found that many floating point libarys are not > completely reenterant and should never be used in interrupts. > Also depending on the hardware platform the floating point libs > contain differnet transidental funtions as well as some intel > processors require software patches to work around bugs in the > floating point processor. All these issues make realtime > floating point unrealiable or at least difficult to work with. I > would like to help devlope a system that is hardware independent. > It could run on a MAC, ARM9, or other linux hardware. In the near > future there will not be printer ports on PCs. It is hard to > spend time on new software that can not be run on new PCs or > notebooks. I have a toughbook that can handle a coolant spill. > It would be good to be able to run the code on that PC as well as a > desktop. > Yes, and we could also convert EMC into Mach. That's what Art Fenerty did some years ago, we mostly wished him well, but we had specific and we feel QUITE valid reasons for staying with the real-time servo model.
We have a huge amount of floating point arithmetic in our various drivers and other RT-mode modules, and have not found them to be unreliable at all, at least for these desktop PC systems (that should include x86, Mac and power PC). Due to the dependence on a real time environment, we are not free to move to any arbitrary embedded platform that claims to support some Linux-derived kernel. I know some people have attempted a Mac port, I believe they did get something running, but I don't know the details. I don't recall what processor that system had, but vaguely think it was PPC. The printer port is not as much of a limitation as it seems. For a number of reasons, laptops are not ideal for EMC, mostly having to do with real time. We need to work some more on PCI-e parallel ports to make sure all our drivers work with them. As long as desktop motherboards have SOME kind of slots, this shouldn't be a problem. If you want to attempt to port EMC to an Arm9 or similar embedded CPU, go ahead, but I think you will be in for a VERY long haul. There are a large number of software dependencies that you will need to solve. Some may be fairly simple, I fear a few of them are going to be major. I can't speak for the rest of the EMC community, but if you want to move EMC2 to a totally non real-time environment, I don't think this is going to get a lot of developer support! (I can almsot hear the guffaws now!) Of course, there IS a way to run EMC entirely non-real time, that is the "sim" environment. Jon ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
