On Thu, Mar 17, 2011 at 10:19:13PM +0100, Michael Haberler wrote: > it seems some machines have a lock pin which disables spindle movement when > inserted and needs to be explictely removed; others might have a brake which > may engage in any rotational position > > so M19 would cause two different processes depending on machine: > a) essentially 'probe' the lock-engaged pin by slowly rotating the spindle, > stopping when lock-pin switch opens > b) take orientation and direction from M19, hand over to PID controller until > angular postion == orientation, engage brake, release PID control > > M20 would in scenario > a) activate unlock mechanism (magnet, whatever) and make sure lock-pin switch > is closed > b) release brake
There should be HAL pins that tell HAL which mode the interpreter requests, and a loopback saying when it's done, and that's all. Things like lock pins, polling a pin, pid controllers, making sure a switch is closed, waiting for the spindle to stop, etc etc are machine-specific and very definitely taken care of by HAL setup and/or ladder as the integrator sees fit. In the spirit of iocontrolv2 there may also be a pin signaling an error (failed request). I just want to make sure I understand what you're proposing, because pretty much none of these things you mention above are the job of the interpreter or any code you will write to add this feature. NGC says the NML interface should be ORIENT_SPINDLE(double degrees, DIRECTION direction) and doesn't mention unorient. For unorient you could make a new call or could possibly use STOP_SPINDLE_TURNING() which reflects what someone has already pointed out: M20 and M5 seem to do the same things. The HAL interface should be pins showing degrees and direction (+-1 like is used elsewhere) and a loopback like the rest: motion.spindle-orient -> motion.spindle-oriented ------------------------------------------------------------------------------ Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d _______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
