Help with WAIT TIMEOUT

  • I'm working with a R30iA Mate Controller and a R-1000iA robot. I'm having trouble with the following TP code, and I can't understand why.


    1: RO[4:GRIPPER CLOSE]=ON ;
    2: WAIT .75(sec) ;
    3: WAIT RI[5:GRIPPER CLOSED]=ON TIMEOUT,LBL[6] ;


    If I remove line 2, then the WAIT on line 3 seems to immediately jump to label 6. I also have the following command in my main program, which I understand is supposed to make the WAIT command timeout after 3 seconds.


    $WAITTMOUT= 300


    Can anyone tell me what I might be doing wrong?


    Thanks in advance,


    Eric

  • Place your Ad here!
  • That happens a lot when you are using pneumatics and fast pressure-sensors.
    Due to the stick-slip and the small initial volume of the cilinder, the pressure-sensor will give a small spike at the start.
    This is enough to release the wait.


    A solution is to restrict the flow to the sensor. (a long thin hose to the sensor is most of the time enough)


    If it is not that, then look for other sort of possible spikes.

  • They are using a pneumatic cylinder with a proximity switch at the end of travel. Could this configuration cause a spike like that?


    Anyway, if my code looks alright, then I guess I need to explore other scenarios. I'd sure like to get rid of that hardcoded wait, this really hurts the cycle times.

  • Don't forget the program using the last $WAITTMOUT always, maybe you have more than one?
    Also you can check the spark like this:
    1: RO[4:GRIPPER CLOSE]=ON ;
    2: WAIT RI[5:GRIPPER CLOSED]=ON
    3: WAIT 0.1 sec
    4: WAIT RI[5:GRIPPER CLOSED]=ON TIMEOUT,LBL[6] ;


    If this way it works, than you can start investigating for the spark.

  • I agree with moln4r about making sure the $WAITTMOUT is set to the value you desire at that point in the program. I usually set that variable to the desired time near every Wait Time Out that I use in the program to be sure. I don't think a spike is causing you the issue because like what kluk-kluk mentioned below, the ON signal will release the wait and will not jump to LBL[6]. Try to set the variable above the Wait and see what happens. Are you getting a good signal from RI[5]?

  • I only set $WAITTMOUT once, at the start of the main entry point program. I do have multiple subprograms that I call though. When I get back to the customer's site, I'll try putting a $WAITTMOUT right before the actual WAIT commands.


    The sensor has a status light on it, and it seems to work pretty well without any glitches.


    After looking at my code more, I do have the following sanity check a few lines later in the program:


    IF RI[4:GRIPPER OPENED]=OFF AND RI[5:GRIPPER CLOSED]=ON,JMP LBL[5] ;


    I've done this to make sure my sensors are adjusted correctly. If the WAIT releases, but this IF is not seeing the current state because of a spike, then this could be a problem. I'll end up falling through to LBL[6]. I think I'll just remove this line and give it a try.

  • It turns out the IF statement was messing me up. Maybe it's not seeing the current state at the same time that WAIT does? Nonetheless, thank you guys for giving me ideas!

  • I had the same experience with a WAIT...TIMEOUT.


    I found out that when i have WAIT DI[x]=ON AND DI[y]=OFF,TIMEOUT LBL[z] the WAIT jumps directly to LBL no matter if the whole condition is true or not. and no matter what is in $waittmout.


    WAIT DI[x]=ON, TIMEOUT LBL[z] works fine

  • Just FYI, your original TP might not have been working the way you want because $WAITTMOUT should be in milliseconds.


    So $WAITTMOUT= 300 was only waiting 0.3 seconds and was probably why it was jumping to the label.

  • That is not correct. $WAITTMOUT is in hundredths of seconds. So 300 = 3 seconds.


    Anyway the OP said it was a IF statement logic error that caused his problem, not a timing issue.


    I have had zero issues with "wait timout, lbl" commands. If you structure the code correctly then it works perfectly.


    For example, In DonDizzy situation he has a syntax error. He is not wrapping his multiple conditions in parenthesis. Should be like this:


    WAIT (DI[x] AND !DI[y]),TIMEOUT LBL[z]


    I have used mixed logic wait timeouts exactly like that many times and has never failed.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account
Sign up for a new account in our community. It's easy!
Register a new account
Sign in
Already have an account? Sign in here.
Sign in Now

Advertising from our partners