Use of feed hold with Move() etc.

[SJHardy]

Hi Tom,

A long time ago (on the old Yahoo server) I instigated a thread of the same subject. Basically, the issue was resolved well enough, but now that we are in the process of safety certification, some deficiencies have come to light.

To cut a long story short, it turns out that MoveAtVel() does not resume at the correct velocity after feed hold then resume. It seems to revert to rapid motion. The destination seems OK, but it tries to get there too fast. Source of the feed hold is pc issuing StopImmediate0 then resuming with StopImmediate1.

We need to use that in our tool change routine, and have a work-around which is to capture the F/H release ASAP then issue a repeat MoveAtVel() according to parameters that were saved in some static variables. So any rapid movement is such short duration that it is not noticeable. It's a bit ugly how we check for f/h release, which is basically polling the state of CS0_StoppingState and looking for transition to 0, but at least it works.

So what I am really asking is if the MoveAtVel() resume at rapid is a known problem in the kflop firmware (BTW, we are on 4.33q) or a misunderstanding/snafu on my part.

Bit of extra background: our machine has an access door with a switch, so we want the machine to reliably stop what it's doing whenever the door is opened, whether that is running coordinated motion or doing tool change or probing.

Regards,
SJH

[TomKerekes]

Hi SJH,

You are correct that is a bug/issue in our current DSP Firmware. With independent motions only the Destination is saved and if stopped/resumed a normal Move() is re-commended to the original Destination at the normal axis velocity. We could fix this if necessary.

The only other workaround I can think of would be to change the velocity for the axis channel when you want to move the Axis slowly. Of course you would need to restore the original velocity before moving at the original velocity or before doing coordinated motion with that axis.