RobotStudio event

varibles and robotcontroller mode [WebWare SDK]

Hello,

I have two questions. One about events and one about setting a variable in the robot. I'm using 4.0 of the sdk.

Q1.

If you are setting variable in the robot (from the robotcontroller) manually. For example switching an boolean variable from true to false, with the controller in manual. Does this generate an event which my application should be able to catch or does it only catch events when the robot is running in AUTO mode?

The events get fired for sure when I run the robotprogram in AUTO but I can't get my application to catch any events when the robot is in manual mode.

...and

Q2. Should the robots variable change when I write (s4programboolvarwrite) to the robot from my application even if the robot is not running in Auto mode?

/S

 

 

Comments

  • Me again here, I have been testing a bit more now and it seems to me as this is some kind of bug. Because my webware app returns -102 when it tries to write a variable when the robot is in manual AND the controller has the program (execute)window open but when I change the controllers window to display the io my webware app manages to write the variable to the controller even if it is in manual.

    The webware documentation says that:

    -102  Master request rejected.

          - The requested resource is used by another master.

          - Wrong operating mode for requested service. Try again.

    So.. my conclusion is that the varibles are locked is some way (for webware)depending on what window the controller has opened.

    Can someone please let me know if this is the case or am I doing something wrong. This can be a problem if you have two robots that needs to make a handshake though a webware app.

    In my case one robot is saying I'm ready for the handshake and my webware app triggers on this (a boolean) and writes to the second robot a boolean which means a boolean again. But in a senario where this last robot is stopped and put in manual with the wrong window opened it will never get this signal.

    Ideas anyone?

    /S

     

  • This behavior is documented in the online help for the various S4Program<type>VarialbeWrite methods under remarks:

    The S4ProgramStringWrite does not work when the user of the S4 is editing or viewing the program on the teach pendant.

    The S4C+ TPU does exert some elements of mastership over the RAPID domain, though it is nowhere near as structured or documented as that on the IRC5.

    You could encapsulate your handshake logic with a state check to determine if the (other) controller is in automatic or not.

    If the other controller is not in auto, then you could allow the user to operate the other controller in a "standalone" mode if it were safe and practical to do so.

    Russell Drown
  • aha... so where do one find the "online help".

    I don't really like this behavour at all since I would guess that this senario will appear sooner or later. Namely that one robot is stopped and therefore missing out of the handshake (S4programboolwrite). Normally we would do this without the webware app by using pure IO between the robots, and in that enviroment it doesn't matter what mode one or the other is in, this signals will always go through. We could do the same in our latest solution but we have already use up all IO's and don't really feel like buying more IO boards.

    I thought of a workaround like:

    :label

    blnRobOneReady = True

    WaitUntil blnRobTwoReady = True; MaxTime 2

    IF blnRobTwoReady = False THEN

    GOTO label

    END IF

     

    /S

  • The online help is the HTML help file that opens when you press F1 anywhere in Interlink or open "Online Help" from the start menu.

    There are probably numerous ways to handle the case where one controller is not in auto. Here is what I was getting at in pseudocode:

    If OtherControllerState <> "Auto" then

         result = MessageBox("Do you want to run in standalone mode?")

         If result = yes then

              DoStandAlone()

         Else

              DoWaitForAuto()

         End If

    Else

         DoNormalCycle()

    End If

    If you are handling this in RAPID, you could use the StatusChanged event in your PC app to monitor controller mode and write the current status of the opposite controller to a variable.

    RussD38475,133287037
    Russell Drown
  • It says "RAPID program variables cannot be modified via OPC while the robot program is being viewed or edited on the robot controller"

    Via the OPC, hmmmm ...what is OPC?

  • OPC stands for OLE for Process Control, an open communications standard developed to allow devices from different manufacturers to communicate and share data.

    Interlink itself is an OPC1.0/2.0 compliant Data Access and Alarm & Event Server for the S4C+. This means that any OPC client application such as the KepWare Quick Client can connect to, browse, and subscribe to controller data.

    Go to the OPC Foundation web site for more information.

    Russell Drown
  • I still can't get the hang of this because we have been testing a bit more today and we setup a small robot program which just changes a boolean variable. The webware app triggers on this change and writes back to the robot a couple of num variables and one boolean. The robot then after a second writes to the TP window the values of this num and boolean variables and then sets them back to 0 and false.

    If we just run the robotprogram in manual mode in cycles for a while we can see on the TP window that the num variables is updated all the time BUT the boolean variable changes randomly, not in every cycle. And this is why I'm suspious that this might be a bug.

    Both variabletypes should be updated, sholdn't they? I checked the return value of the boolwrite aswell and it returns zero all the time.

    We thought that this might already be a known problem with the boolwrite and fixed maybe in the 4.5 version of Interlink, is that the case?

     

  • How fast are the values changing? If you change values too fast you may not recieve the ChangeEvents.

    What is your poll delay? Try setting it to 200 ms if you haven't done so already.

    I'm not aware of any defects in this area, but then again I'm no longer part of the development team.

    Russell Drown
  • This is still a really big problem for us. The documentation say that all the s4programXwrite method can only be succesfull if you run the robotprogram in AUTO mode. This is a pain in the neck if you want to run the robot program step by step (forward in the controller)and have the Webware app make some writes in between. They will not get through to the robot.

    In our case we trigger a vision camera with a boolean from the robotprogram and in the boolchange event we write back to the robot x, y and angle(num) coordinates of an object that our camera found. Works fine in AUTO but not in step by step (forward)

    Really bad. Anyone got any good workaround on this problem?

     

  • This limitation or whatever one should call it wouldn't be fixed in the latest version of the Webware(4.5) would it? 
  • As far as I know it is the controller that prevents (albeit inperfectly) writing to variables when in manual mode.

    Russell Drown
  • One can only hope that this limitation get changed in the future than. In our case we now had to replace the handshake code we tryed with webware and s4programXwrite to serialcommunication.