Daniel, I am glad that someone is picking this up. It is something I had considered doing myself and this project has never climbed up high enough on my priority stack to actually do more than play with it.
I would still like to seriously contribute to this effort and have the following pieces/parts to contribute: I have spent a fair bit of time programming the Atmel AT91SAM7X256, and have written an Linux interface to the Open Sound Control (OSC) over USB. OSC is an extensible interface which will accommodate bidirectional transfer of floating point, integers, and arbitrary bit-streams. I would recommend you look at OSC for a remote interface. There are people who have already developed stepper and servo motor interfaces for the Arduino, Sanguino, the Make Microcontroler, etc. Most of these stepper/servo interfaces are seriously lacking, but they would be more than willing to accept rewrites of the basic control if it they are genuine improvements. Oh, as a note, OSC also works easily over ethernet. I also have some example code I wrote using the high-resolution timers on Free-RTOS <http://www.freertos.org/> on the AT91SAM7X256. Rewriting this into the stepper control is one of the things on my ToDo list (if I get unburied enough). In addition I have a runtime polymorphic RS274* parser written in Spirit++ (see http://www.boost.org/doc/libs/1_38_0/libs/spirit/classic/index.html). This experimental parser allows me to overload commands, or add new ones, on the fly. This originally was an experiment to develop a single modular parser which would allow programs written for OLD controllers which had their own little quirky implementations without having to recompile the parser. Part of the original design was to separate out the geometry engine so that I could *eventually* write a NURBS implementation of the kinematics and trajectory planner. This needs to get cleaned up, but was functional last time I looked at it. The only other immediate thought is that your movement speed is off by an order of magnitude. Many, even hobby class CNC machines, can move at least 1000 in/min, so I would shoot for something more like 1000 to 3000 in/min for servo's. I'll contact you off-list tomorrow with more info... EBo -- Daniel Lee <[email protected]> said: > Thank you for your feedback. Because your desire is to keep the control > loops in the PC > I will proceeds on my own. > > I think what I will do is start with the EMC2 code base > and put together some ideas. If the only support I get is some > peer review and specification feed back that is fine. > When I am done if you are interested in merging the code that will be > up to the EMC group. > > I think the steps I will proceed in is to > > 1. Put the rtos and some of the processes on an ARM7 platform > This will include the PID routines. > I will look at the verious ARM7s, some include USB and Ethernet, and > find some off the shelf so that I > don't have to develope custom hardware. At least untill I know the > complete requirements. > > 2. Write a translating interface from the current rtos interface to a > tcp/ip,serial, or usb interface to the new remote rtos. > This will allow your current User interfaces to think it is talking to > your rtos on the pc. > > 3. Define a remote interface that can handle stepper and servo motor drivers > as well as sensors ( encoders, swtichs etc ). > I own a Mazak SQT15MS with mitsubishi drivers and a mazatrol controller > my goal is to design a comparable > control system where I can move a G code program from one machine to the > other. > > My guess for the first stage hardware goal will be, unless you can give me > some inputs. > > a. USB/serial interface > b. 4 axis stepper controls Z,Y,X and tool changer as well as at least 16 > general purpos I/Os > c. Max step rate ( I need some feed back here ) if we use 200 steps per rev > and 10 revs per inch and 100inch/min will this be O.K. ? > d. Spindle sync pulses for treading as well as spindle voltage speed > control. > > olimex makes an ARM7 board for $62 I will start with this board for my > tests. It uses an Atmel AT91SAM7S256 processor. > > It also has an interface for a sdio flash card. I will not be running linux > this require much more memory and I don't need it to > test the rtos and pid software. I all ready have an rtos for ARM7s it would > not make sense to run linux the put an rtos under > linux if I can just run the rtos direct. > > Thank You. > > Daniel > > > ----- Original Message ----- > From: "Jon Elson" <[email protected]> > To: "EMC developers" <[email protected]> > Sent: Friday, March 06, 2009 8:46 PM > Subject: Re: [Emc-developers] EMC3 definition > > > > 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 > > > > > ------------------------------------------------------------------------------ > 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 > -- ------------------------------------------------------------------------------ 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
