RobotStudio event

ActionTriggers in Virtual FlexPendant

The release notes for SM 5.12 state: "Action Triggers are not supported in the Virtual FlexPendant".

I am finding Action Triggers useful for controlling the display of screens from Rapid, but they make my Rapid program difficult to test as I have limited access to a real IRC5.

Is a fix for the VFP scheduled please?

Thanks,

Kevin

Comments

  • Hi Kevin,
     

    I have not installed the latest SM, so I can't verify this.

     

    - Do you ahve a simple app you can share to test this :) ...?

     

    I could check if there is a work-around ...

     

    Best Regards
    Carlos Martinez
    ABB
  • Kevin
    Kevin ✭✭

    Hi Carlos,

    I am running RS 5.12, RW5.12.0138 and SM 5.12.138.0.

    The release notes for SM 5.11 and 5.12 state:
    "5.15 Action Triggers are not supported in the Virtual FlexPendant
    When adding an action trigger to a screen, when the screen is opened in the Virtual FlexPendant there is an object type reference error.
    SPR: 1034832"
    The zip file contains a ScreenMaker project and a Rapid module with a procedure 'TriggerTest' to be single-stepped.

    This should display Screen1 then Screen2.

    It works OK on the real IRC5, but on the VC gives this error:

    image

    webwiz/40/ActionTriggerTest.zip

    Thanks for your help,

    Kevin







  • Hi Kevin,

    Thanks for the example. We did not test running the ActionTrigger by a changed generated by RAPID (and also inside a View requested by RAPID)

    Even though this works for me now, just want to clarify some points which could cause a problem:

    - I used Signals instead of a boolean. If you use a boolean, then you would like to change the default Value of the ActionTrigger. The first time when the MainScreen is opened, ScreenMaker reads the current value of the Controller object (signal or RAPID). If they are different, the screen will open.

    - Assuming that you are in the MainScreen, all changes in the Controller object (from TRUE to FALSE, 0 to 1, and the other way around) will be detected by ScreenMaker and execute the ActionTrigger. My point here is the ActionTrigger will be fired as long as the new value is different to the previous one

    - Assuming that you are NOT in the MainScreen, all changes in the Controller object will not be listened in the Screen (since it is not activate). When the Screen is activated, the values will be read and it follows the same rule: ActionTrigger will be fired as long as the new value is different to the previous one. In case the value changes more than one, the only thing that matters is the one when the Screen is being activated.

     

    Kind Regards ...
    Carlos Martinez
    ABB
  • Kevin
    Kevin ✭✭
    Hi Carlos,

    Thanks for the clarification. It may explain some problems I am having with my real ScreenMaker project not behaving as expected. I need to experiment some more.

    You do not mention my original problem of ActionTrigger not being supported in the Virtual FlexPendant. Do you have any information on when this might be fixed?

    Thanks,

    Kevin

  • I found the bug which causes this to not be supported in the Virtual Felx Pendant. I have made teh changes, so we just need to wait for the next release.
     

    Best Regards
    Carlos Martinez
    ABB
  • Kevin
    Kevin ✭✭
    Good news Carlos.

    Thanks a lot,

    Kevin

  • Kevin
    Kevin ✭✭
    I am having a frustrating time trying to use ActionTriggers to control the display of sub-screens using either booleans or signals. I am getting inconsistent behaviour with different projects while using the same methods and don't know whether this is due to a misunderstanding on my part or a bug in the ScreenMaker system. Testing is slow due to limited access to a real IRC5. I am so looking forward to the next ScreenMaker release which should fix the bug detailed above and allow testing on the VC!

    This is a simplified description of a project which does not work:

    My Screen1(main) and Screen2 have ActionTriggers which should display Screen3 when triggered.

    The Screen1 and Screen2 triggers are bound to a digital output which is on (1) when Rapid is running and off (0) when Rapid is stopped. The desired behaviour is that if Rapid stops executing, screen3 should be displayed.

    I use a UIShow instruction to display Screen1. At this point Rapid is obviously running so the digital output is on. I understand from Carlos' explanation above that the state of the output is recorded at this point, and that a change of state to off while Screen1 is still displayed should result in Screen3 being displayed.

    In addition to the bindings, the ActionTrigger Behaviour may have a default value of TRUE or FALSE, and the Data field may have a value, which defaults to zero.

    It is not clear to me how these values interact with the state of the bound signal, so I have tried different values:

    image

    Either the action to display Screen3 is triggered as soon as UIShow is executed, or Screen1 is correctly displayed but then the trigger fails to activate when the output switches off.

    Thanks for any advice,

    Kevin

  • Kevin
    Kevin ✭✭

    RS 5.12, RW5.12.0138 and SM 5.12.138.0.

    The zip file below contains a simple ScreenMaker project and a Rapid module containing a simple routine.

    webwiz/40/TriggerTest.zip

    When the routine runs, Screen1 should be displayed. The Rapid routine then remains in a continuous loop. Screen1 has an action trigger which should display screen2 when the system signal 'doCycleOn' changes state. When the rapid routine is stopped by pressing the stop button on the FlexPendant, 'doCycleOn' changes from 1 to 0 so screen2 should be displayed.

    On my IRC5, Screen2 is displayed as soon as the instruction
    [CODE]
    'UIShow "TpsViewTriggerTest1.gtpu.dll", "ABB.Robotics.SDK.Views.Screen1";'
    [/CODE]
    is executed, while 'doCycleOn' is still in its original '1' state.

    Please would somebody look at the files and tell me what I am doing wrong, and if the files are OK, test them to see whether the same result is obtained on another system.

    Thanks,

    Kevin