Use of feed hold with Move() etc.
Posted: Thu Oct 03, 2019 4:17 am
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
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