Moving PP to Main Upon Moving Upon Switching to Auto

suffq
suffq Wales
Hi all,
I'm relatively new to ABB RAPID programing and Robot studio as a whole but I'll do my best to describe my current issue.

I've been tasked with creating a piece of code for an IRC5 controller that upon switching the robot to auto mode will prompted the operator (or engineer) if they would like to run the program from it's current pp or pp to main.
I have managed to make this work using an event routine connected the event "reset" wth the following code:

(variable defined)
...
PROC PPtoMain()
    TEST OpMode()
    CASE OP_AUTO:
        TPErase;
        TPReadFK ud_confirm,"Robot has been switched to auto and is about to start, would  you like to PP to main?","No","","","","Yes";        
        TPErase;
        IF ud_confirm=5 THEN
            ExitCycle;
        ENDIF
    CASE OP_MAN_PROG:
    
    CASE OP_MAN_TEST:
    
    ENDTEST
ENDPROC

This works for all cases except for when the user in manual mode uses the debug tab to move pp to routine. when this happens the command "ExitCycle" now only seems to move pp to the start of the selected routine instead of the main routine.
I've explored the possibility of using the "Auto Condition Reset" and enabling AllDebugSettings. However, this isn't possible for our specific use case due to scenarios debug conditions need to remain true.
Is there an alternative to enable and then disable AllDebugSettings via code? this would allow me to keep the prompt to give users the required flexibility.

Any feed back, comments or alternatives would be greatly appreciated!

I've explored the use of trap routines and have failed to understand/ apply this to my specific use case.

Kind regards,
QD 
Tagged:

Answers

  • As long as you are using RW 6 you could experiment with using the system parameter System Input PP to Main. 

    E.g. (EXTREME CAUTION MUST BE OBSERVED!!) Create a virtual output and and input for PP to Main activities, cross connect the output to the virtual input and set the cross connected virtual input as the trigger for PP to Main.  

    There is nothing in the Limitations section about the control's operating status, just usage is confined to normal tasks..

  • lemster68
    lemster68 United States ✭✭✭
    Read up on the function PPMovedinManMode.  It may be of use in your endeavor.
    Lee Justice
  • suffq
    suffq Wales
    SomeTekk said:
    As long as you are using RW 6 you could experiment with using the system parameter System Input PP to Main. 

    E.g. (EXTREME CAUTION MUST BE OBSERVED!!) Create a virtual output and and input for PP to Main activities, cross connect the output to the virtual input and set the cross connected virtual input as the trigger for PP to Main.  

    There is nothing in the Limitations section about the control's operating status, just usage is confined to normal tasks..

    Great suggestion! Unfortunately when I tried this the action to PP to Main was ignored due to the robot already being in motion (can remember the exact wording of the error message).

    I should be mentioned that when I tested this I connected a used the event ("reset") routine to trigger a digital output that then triggered a digital input (via the cross connection) to trigger a pp to main.
  • suffq
    suffq Wales
    lemster68 said:
    Read up on the function PPMovedinManMode.  It may be of use in your endeavor.
    Thanks! I'll explore this option more as it will at least give the user an additional chance to manually pp to main via a prompt.
  • suffq
    suffq Wales
    suffq said:
    lemster68 said:
    Read up on the function PPMovedinManMode.  It may be of use in your endeavor.
    Thanks! I'll explore this option more as it will at least give the user an additional chance to manually pp to main via a prompt.
    I've tried using this however, this same issue is still present. If I was to PP to Main, switch to manual mode, use the debug section to PP to Routine and then switch back to auto and run the program the robot still continues normally!

    Here is the code that I used:

    PROC PPtoMain()
        TEST OpMode()
        CASE OP_AUTO:
        IF PPMovedInManMode() THEN
            TPErase;
            TPReadFK ud_confirm,"PP isn't starting from start of main. Would you like to continue?","Yes","","","","No";
            TPErase;
            IF ud_confirm=5 THEN
                TPErase;
                TPReadFK ud_confirm, "PP is about to be removed. Please PP to Main.","","","","","Acknowledge";
                TPErase;
                EXIT;
            ENDIF
        ENDIF
        CASE OP_MAN_PROG:
        
        CASE OP_MAN_TEST:
        
        ENDTEST
    ENDPROC
  • lemster68
    lemster68 United States ✭✭✭
    The EXIT command leaves the program and there is no program pointer.  Go back to using ExitCycle.
    Lee Justice
  • suffq
    suffq Wales
    lemster68 said:
    The EXIT command leaves the program and there is no program pointer.  Go back to using ExitCycle.
    I know that is the case. However, the PPMovedInManMode() function doesn't seem to to be acknowledged in the specific use case that I have described in my prior comment
  • lemster68
    lemster68 United States ✭✭✭
    So you do not see any of the dialogues?
    Lee Justice
  • suffq
    suffq Wales
    lemster68 said:
    So you do not see any of the dialogues?
    No, none of the TPReadFK functions are being executed in that one case/ example that I described earlier 
  • lemster68
    lemster68 United States ✭✭✭
    I went back to your original post in which you said that you connected the routine to reset event.  Use Start or Restart instead and let us know if that is better.
    Lee Justice
  • suffq
    suffq Wales
    lemster68 said:
    I went back to your original post in which you said that you connected the routine to reset event.  Use Start or Restart instead and let us know if that is better.
    Hi there,
    I've connected the routine via restart event and have had some made some good progress but it seems there is still issues within that one specific example where I PP to Routine in manual mode and then switch to auto.  
    I've been trying to understand the reasons why this is the case and I have deduced that this only occurs when you PP to Routine and nothing else (this is happens with either Start or Restart for the event routine). If I was to step the pointer or PP to curser the event routine is triggered.

    I've also found that "ExitCycle" seems to only PP to the the Top of the routine when I PP to routine via the debug. The only way to PP to Main is if I were to manually press "PP to Main" on the FlexPendant.
  • lemster68
    lemster68 United States ✭✭✭
    I have never seen that behavior with ExitCycle.  From the manual:
    ExitCycle is used to break the current cycle and move the program pointer (PP)
    back to the first instruction in the main routine.

    If you are certain about this behavior you might want to make a product defect document report with ABB.  That is a serious flaw for those who use and will use the ExitCycle instruction.
    Lee Justice
  • suffq said:
    SomeTekk said:
    As long as you are using RW 6 you could experiment with using the system parameter System Input PP to Main. 

    E.g. (EXTREME CAUTION MUST BE OBSERVED!!) Create a virtual output and and input for PP to Main activities, cross connect the output to the virtual input and set the cross connected virtual input as the trigger for PP to Main.  

    There is nothing in the Limitations section about the control's operating status, just usage is confined to normal tasks..

    Great suggestion! Unfortunately when I tried this the action to PP to Main was ignored due to the robot already being in motion (can remember the exact wording of the error message).

    I should be mentioned that when I tested this I connected a used the event ("reset") routine to trigger a digital output that then triggered a digital input (via the cross connection) to trigger a pp to main.
    If the problem is solely attributable to robot motion perhaps experimentation with the StopMove (stops motion, program execution continues) instruction may be in order.

    I've never tried this, however knowing ABB it would not be at all surprising if usage is prohibited in regular routines.