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. The motion controller generates a new position every millisecond, it's up to HAL and hardware drivers to get the machine to move to that position. In the case of an outboard step generator, you could just send the differences (as a number of steps) to the device, or "absolute" positions. > 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. This isn't really necessary. If you maintain a current position and a target position (the target always being for the next millisecond), then you know how many steps to output and how fast they need to be. There's no need to sync to the PC servo thread. (By default, the device will be somewhat synchronized anyway, since the commands will come at the servo rate) > 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. I don't think it's necessary to send this back to EMC. The data would be out of date by the time it arrived at the motion controller, so I bet it would do more harm than good. > 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. Phase shift can be a problem, but it's less of an issue if you always deal in absolute numbers instead of step/movement rates. "Move to 1.023 by the end of this cycle" always means the same thing. "Move at 16.230 in/s for this cycle" gives different results depending on the duration of the cycle. > 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? The USB bus can carry plenty of data, so I wouldn't worry about the amount of information that needs to travel. The big issues are latency and "hiccups". Latency problems would prevent any kind of spindle synchronized motion from working correctly. By this I mean that cutting a thread on a lathe would not be possible using real feedback. If the cuts are light enough and the spindle stiff enough (questionable on a low cost machine, which this hardware targets), then it might work, but there's no guarantee.
USB hiccups are another issue. The motion controller doesn't queue up a lot of motion and then spool it out. It calculates a new position every servo cycle (ie, just as it's needed), taking into account the current state of the machine (ideally from real feedback) and user controls (feed override, feed hold, adaptive feed override ...). I don't think you can guarantee that you will be able to get a data packet to the device every millisecond, so you need to buffer several milliseconds of motion. I believe they buffer between 250 and 700 ms on some of the USB devices used with Windows. Doing this means that either (a) the machine will not respond to overrides or emergency situations quickly, or (b) you have to create a command language that includes commands that will get executed immediately, such as "STOP!". > 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. The motion controller is already a "set it and forget it" kind of program. It relies on other components to make the motion happen. It does monitor feedback, but that can easily be defeated by looping the position command outputs back to the position feedback inputs. The main thing you lose by going to a truly disconnected step generator (which I consider this to be, given that the feedback latency is likely to be 4 or more servo cycles) is realtime control based on the machine. You suddenly can't use jog wheels (except in userspace, which isn't as smooth as realtime), you can't thread, tap, or use CSS or FPR feed modes (reliably). You probably can't get immediate response to feed overrides, etc. There's also the "minor" issue of not having access to standard Linux devices from within the RT execution context. There was a start on an RT-USB driver, but I think there hasn't been any work on that in a few years. - Steve ------------------------------------------------------------------------------ Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
