So, here's a slightly more technical question for RAPID programming. (RW 6.12)
I have a robot with a long move (over a meter) from Home to Pounce. At Pounce position, which is just short of colliding with the fixture, I have a WaitDI to confirm that the fixture is actually in the correct state for the robot to enter.
This works, but... even when the fixture is closed (and the DI sent) well before the robot reaches Pounce, the robot still treats Pounce as a Fine move (despite being programmed with a decent Zone value).
I realize it's because the program pointer gets ahead of the motion pointer. Is there a firm definition for how far the program pointer gets ahead? Is it in number of motion commands, time, or something else?
One idea I've had (but haven't yet had time to try implementing) is to break up the Home->Pounce motion into a series of Zone motions along the robot's "natural arc" of motion. That way, if the "advance run" of the Program Pointer ahead of the Motion Pointer is measured in Move commands, I could prevent the WaitDI from being evaluated until after the DI has been received, and thus claw back a small amount of cycle time.
(of course, if the fixture was delayed for any reason, the WaitDI would still prevent a collision).
Is there a "best practice" method in RAPID programming to achieve this kind of thing?
On a related note: I've gotten a handle on using a MoveJSync/MoveLSync command to call a subroutine to set multiple DOs "on the fly", but I'm wondering: if a Move-Sync calls a subroutine that includes a WaitDI or similar statement, how does that get handled? I wondering if that might be a different way to get the robot to approximate through Pounce position, instead of always doing a Fine stop&go.