Hi Colin, One idea that might be worth pursuing is to build a timing regenerator. By this I mean a chip that would accept quadrature output signals (step type 2) from an EMC box with lousy latency numbers. The chip would then re-time the signals limiting the acceleration to some programmable amount. This would help avoid the deadly stalls in stepper systems from momentary variations in the timing from the PC. This would not help PC's with really bad latencies > a couple of hundred thousand nanoseconds.
The chip could output step/dir or quadrature signals to whatever drives are being used. Step/dir is a major pain as there is a huge variation in acceptable timing required by various drives. I would not bother with USB... its a bitch to program for and unless you get deep into USB2 internals, has a very poor performance. Also, there are not many micro controllers that do USB2. Just some thoughts from the great white north. Lawrence On Sat, 2011-01-15 at 14:14 -0500, Colin Kingsbury wrote: > Since I started posting my Arduino-EMC interface work I'm getting an > email every week or so from someone asking how to use this to do step > generation. I've generally given the WC Fields "go away kid, you > bother me" reply but at some point my day-job "if the users keep > asking for it maybe I should listen" mentality kicked in. > > I've been reading the wiki and mail archives about previous assaults > on this particular windmill and want to throw an idea out there for > criticism (feel free substitute your preferred microcontroller for the > Arduino): > > 1. EMC would generate control signals as it does for software step gen > now, except instead of bit-banging them out to the parport, would > marshal them into six arrays (assuming step and dir for three axes) > and throw them over the wall to the Arduino board. > > 2. The Arduino would buffer control sequences and latch them out to > the motor driver pins as necessary. The Arduino would be set to > generate steps on the same base frequency as EMC is set to "think" so > that the commanded feed rates come out right. > > 3. The Arduino would also maintain an internal absolute position > counter for each axis, kind of like a virtual encoder. This would be > squawked back to EMC as time permits. EMC would use this to update its > internal state of the machine's position. > > The obvious catch with this (or any outboard step-generation scheme) > is the phase shift introduced between commanded, actual, and reported > positions. Obviously this would preclude any type of closed-loop > control, but I am wondering whether it could work with open-loop > control where EMC is just spraying control signals out to the world > without real knowledge of the machine's position. Likewise, I don't > know whether the virtual-encoder-counter idea adds anything useful, or > whether it's better to just accept that what the EMC GUI displays for > the machine's position and the actual position will be up to N > milliseconds out of sync whenever the machine is in motion. > > While there are some significant limitations (I think USB bus speed > would limit the step rate non-trivially as well) in this, it would > still seem to be a useful option for the lowest end of the entry level > like a tabletop Dremel router or mini-mill. I'm wondering if something > like this would allow to run on machines without a parport and with > uncertain latencies? > > What I'm really not yet qualified to judge is whether there's some > other gotcha in the architecture of EMC that means that this approach > would fundamentally *not work*, or whether it's doable so long as one > can live with specific shortcomings. > ------------------------------------------------------------------------------ > Protect Your Site and Customers from Malware Attacks > Learn about various malware tactics and how to avoid them. Understand > malware threats, the impact they can have on your business, and how you > can protect your company and customers by using code signing. > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ Emc-developers mailing list > Emc-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-developers -- ===================================================================== Lawrence Glaister VE7IT mailto:ve...@shaw.ca 1462 Madrona Drive Nanoose Bay, B.C. http://members.shaw.ca/swstuff Canada V9P 9C9 http://gspy.sourceforge.net ===================================================================== ------------------------------------------------------------------------------ Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
