> Date: Thu, 31 Mar 2016 19:15:29 -0700
> From: neilwhelc...@gmail.com
> To: emc-developers@lists.sourceforge.net
> Subject: Re: [Emc-developers] Properly dealing with spindle faults
>
> Update:
> I setup my machine to assert motion.feed-inhibit when the spindle falls
> below the target RPM. This saved a tool immediately. Within minutes of
> starting the test, there was a power surge that caused the spindle
> controller to go off-line and the machine stopped feed, saving the tool.
Yaay! that's great.
> There is one major downside to this, it added 26 minutes to the program I
> am currently running. The problem is that the machine does not jog to the
> next position until the spindle comes up to speed as it did
> with motion.spindle-at-speed, which allows the spindle to come up to speed
> while it is jogging to the next cut location. I am thinking that there
> needs to be a new pin that behaves like motion.spindle-at-speed with the
> exception that it stops unsynchronized feed should the condition become
> false again. Or at least a configuration variable that changes the behavior
> of the existing pin.
Well I can think of a couple things you could try.
If your spindle drive has a fault output you could connect that to feed-inhibit.
Then you could connect spindle-at-speed back the way it was.
or else you could use a separate component to monitor the spindle speed and
apply feed-inhibit as needed.
The common idea is to separate the spindle-at-speed comparison from the
spindle fault comparison.
Also, another problem that I discovered. During a tap
> cycle, if the spindle stops for whatever reason, all is sort of ok... The
> problem is that you can not manually back out the spindle because the Z
> axis will not back up! The Z axis will only reverse once the tap reaches
> the programmed depth. Or if the programmed depth has been reached, the Z
> axis will only reverse. I am not sure about the reasoning behind this, but
> it seems to me that any time that there is a spindle synchronized movement
> like the tap cycle, the axis should be slaved to the spindle no matter
> which direction it is turning. I am assuming that the reason that the
> slaved axis does not reverse is that it is permitted to use a pulse instead
> of a quadrature on the spindle. This seems broken. Maybe there should be an
> option to indicate that you are using a quadrature on the spindle so that
> direction is accounted for when slaving to the spindle.
> -Neil-
>
I believe a quadrature signal is required for rigid tapping - it needs to know
which direction the spindle is moving.
I would bet this behaviour is because nobody put the extra effort into fault
tolerance. Just getting it to rigid tap would have been a lot of work.
While the behaviour you suggest would be very handy - if you have spindle faults
that often, I would politely suggest that needs to be addressed.
I'm trying to think of another use of truly slaved axis to spindle...
Chris M
------------------------------------------------------------------------------
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471&iu=/4140
_______________________________________________
Emc-developers mailing list
Emc-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-developers
