Robot Pointer

    Hi everyone,


    I'm working on a RW6.14 controller and (although I never thought I would say this) looking for a way to slow down the robot pointer.


    I've currently come upon the problem that the robot pointer is running too far ahead logic-wise, causing peripheral devices to trigger far too early.


    Is there any other way to stop the pointer from going too far ahead other than using a WaitTime\InPos, 0 ?


    I'm looking for an instruction similar to Kuka's $ADVANCE=0

    Way back in the day, it was generally held that the read ahead was three lines. When the IRC5 was introduced, it seemed to me that the controller began to read ahead more than that. How much? I cannot pinpoint exactly how much.

    You could try decreasing the prefetch time. Read up on it in the system parameter manual.

    This is fear, that it was time based (through the prefetch time parameter) instead of logic based (i.e., 3 lines ahead).


    My problem with changing the prefetch time is that it affects all program execution.

    Since RobotWare 6.12, RAPID execution operates at 44 steps per millisecond, per the release notes. I'm not sure if steps = instructions, but that doesn't seem too unreasonable. From what I have seen, the program pointer and motion pointer remain on the same motion instruction until the TCP reaches a position, based on the prefetch time, that allows the program pointer to start reading ahead. If the program pointer doesn't reach another motion instruction in time, the TCP doesn't know which direction to exit the corner zone, and that's where corner path failures come from.

    For the original question, coordinating motion and logic instructions can be done by using interrupts and triggers. This is the best way to do it because you can still use fly-by points while also having precise control over when I/O based events happen.

    For example, on a project I am currently working on, the robot gripper has 3 additional axes that are completely independent from the robot. When I drop parts off, we needed a way to tell those axes to stop moving before the robot reached its final position, so I implemented this:


    Code
    TriggIO ChainEngaged,10\DOp:=oAtChainEngagePos,1;
MoveL RelTool(p52DropOP154_1,70,0,0),v50,z20,toolhand1\WObj:=wobj2;
TriggL p52DropOP154_1,v50,ChainEngaged,fine,toolhand1\WObj:=wobj2;


    This sets a digital output when the TCP is 10mm away from reaching the fine point. Technically, according to the manual, distance-based triggers are used for fly-by points, but this still works.

    Check out the manual RAPID Overview (IRC5) - Motion and I/O programming - Synchronization with logical instructions. It gives a lot of good information with visual examples that describe exactly when various events happen with relation to positioning.

    In my particular case, I'm dealing with dosing equipment, so I'm already using triggers for the signals that are tied to that.

    But my program has a few routines that it runs to change state between programs (e.g.: make sure the dosing equipment is ready, entering / exiting areas, etc) and only the last point is a fine point. So, once it reaches the last fine point, it's running all the routines, but it's running it too fast and the peripherals are lagging behind.

    I do like the idea you mentioned to use triggers to synchronize some of these routines, though. I'll try sprinkling these around instead of running them all back-to-back to see if it improves.

Advertising from our partners