Greg Bentzinger wrote: >[snip] >I am not proposing using an encoder for coordinated movement feedback >like a servo would require, that would still be handled by counting the >stepgen output. What I propose would be having an aux input for the >encoders and a separate DRO display on the GUI like XA/YA/ZA. With the >proper ini file setting an "in position check" could be done (with a >acceptable tolerance factor) after each G00 or fixed cycle position >move. If an out of tolerance position is detected an alarm could occur >(the easy way) or a correction move could be applied (much more >difficult). Normally if a G00 is issued the tool is free of the work so >applying a correction should be as safe, if the tool failed to clear >the work, then the damage was all ready done. > > EMC2 already supports using an ecoder for feedback, and will stop if a following error is detected. This happens during moves and while stopped. It is trivial to connect an encoder to appropriate hardware (parallel port and software counting for low pulse rates, more advanced devices for high step rates). The motion controller already compares actual position to expected position, so if you connect an encoder, this will work with steppers. The only difference between stepper systems and servo systems is that with stepper systems, the feedback is usually synthesized by the step generator - the motion controller basically sees how many steps were output instead of where the motor actually is. To use real feedback, just use the encoder input to the motion controller feedback input instead of the faked feedback from the step generator.
>I'm guessing this would be very resource intensive. So a alternative >might be to use a non-modal user defined M or G code to compare and/or >reset position. This option would be handy for people using Step/dir >servo drives where they are unable to adjust the in-drive following >error such as Gecko 320/340 drives. Geckos allow 128 count error before >tripping a servo fault. > > It's not so resource intensive, it's already done ;) I think all you need to do to reset the commanded/expected positions is to hit F2/F2 - machine off, machine on. When the machine is in the off state, command position is set to feedback position continuously, so you can do things like jog and not get a following error as soon as you go back to machine on. To match a gecko, you'd want to set the EMC2 following error tolerance a little less than the gecko I think (so EMC2 will detect a problem before the drive faults and has to be reset). >This won't help a machine fighting mid-band resonance, or one >overloaded in a cut. That is a hardware/software issue where the >builder needs to know the weakness and limits of the machine. However >these comparisons if logged could help the builder tweak accel & max >vel settings to an acceptable range that will run error free 95+% of >the time. > > Right, you can't fix mechanical issues this way. You can plot the difference between commanded and actual position using halscope. - Steve ------------------------------------------------------------------------------ _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
