Controller events and threads

© Copyri ght 200 7 - 2009 ABB . All ri ghts res erved.

4.3. Controller events and threads

A controller event is a message from the controller that something has happened. Events can be caught and acted upon by RAB applications.

Controller events use their own threads. This means that user interface threads and controller event threads can get into conflict. This section gives information on how to prevent this. Controller events

RAB applications can subscribe to a number of controller events. These are all described in the reference documentation for the SDKs.

The table shows some events that exist both in the PC and FlexPendant SDK.

The event... occurs when...

StateChanged the controller state has changed.

OperatingModeChanged the controller operating mode has changed. ExecutionStatusChanged the controller execution status has changed. Changed the value or the state of the I/O signal has changed. MessageWritten the EventLog has a new message

ValueChanged the value of a RAPID data has changed.

4.3. Controller events and threads © Copyri ght 200 7 - 2009 ABB . All ri ghts res erved. NOTE!

There is no guarantee you will get an initial event when setting up/activating a controller event. You need to read the initial state from the controller.

GUI and controller event threads in conflict

You should be aware that controller events use their own threads both on the FlexPendant and PC platform. If a GUI thread and a controller event thread get into conflict, deadlocks or overwritten data may occur. This may happen when a controller event is succeeded by an update of the user interface, which is indeed a very common scenario.

You then need to take action in your code to control that the user interface update is executed by the GUI thread and not by the controller event thread. This is done by enforcing a thread switch using the Invoke or BeginInvoke method. See Invoke method on page 68 for information on how this is done along with code examples.

On the other hand, if the controller event should NOT cause any update of the user interface, you should not take any special action. Using Invoke / BeginInvoke is performance demanding and should not be used more than necessary.

NOTE!

Thread conflicts often cause hangings. The FlexPendant touch screen or the PC application UI then stops responding and the application has to be restarted.

Examine what exception has been thrown when you encounter such a situation. The exceptions System.NotSupportedException (FlexPendant platform) and

System.InvalidOperationException (PC platform) indicate thread conflicts. See the next section for information on how to use Invoke to solve the problem.

Invoke method

All PC application windows and FlexPendant views must inherit Control / TpsControl, which implement Invoke and BeginInvoke. These methods execute the specified delegate/ event handler on the thread that owns the control's underlying window handle, thus enforcing a switch from a worker thread to the GUI thread. This is precisely what is needed when a controller event needs to be communicated to the end user of the system.

Invoke should be called inside the event handler taking care of the controller event. Notice that you have to create a new object array for the sender and argument objects:

VB:

Me.Invoke(New EventHandler(AddressOf UpdateUI), New Object() {sender, e})

C#:

this.Invoke(new EventHandler(UpdateUI), new Object[] {sender, e});

Continued

4.3. Controller events and threads © Copyri ght 200 7 - 2009 ABB . All ri ghts res erved.

Also notice that if you use EventHandler in the Invoke method and not the specific delegate class, e.g.DataValueChangedEventHandler, you need to typecast the argument in the delegate which updates the user interface. How this is done is shown by the example below:

VB:

Private Sub UpdateUI(ByVal sender As Object, ByVal e As System.EventArgs)

Dim Args As ExecutionStatusChangedEventArgs

Args = DirectCast(e, ExecutionStatusChangedEventArgs) Me.Label1.Text = e.NewStatus.ToString()

End Sub

C#:

private void UpdateUI(object sender, System.EventArgs e) { ExecutionStatusChangedEventArgs args; args = (ExecutionStatusChangedEventArgs) e; this.label1.Text = e.NewStatus.ToString(); } NOTE!

The difference between Invoke and BeginInvoke is that the former makes a synchronous call and will hang until the GUI operation is completed, whereas BeginInvoke executes the specified event handler asynchronously. Which method you want to use depends on the logics of your program. The recommendation is to choose BeginInvoke whenever possible.

NOTE!

If your code tries to access a GUI control from a background thread the .NET common language runtime will throw a System.NotSupportedException (FlexPendant platform) or a System.InvalidOperationException (PC platform).

TIP!

If you are using the FlexPendant SDK there is further information about threads in Thread affinity on page 196 and Invoke on page 196.

4.4. User Authorization System © Copyri ght 200 7 - 2009 ABB . All ri ghts res erved.

4.4. User Authorization System

In the robot controller there is a system controlling user access: the User Authorization System (UAS). If this feature is used each user needs a user name and a password to log on to a robot controller via the FlexPendant or RobotStudio. If the controller connection for any reason is lost, the user has to log on again.

The controller holds information on which operations different users are allowed to perform. The UAS configuration is done in Robot Studio.

TIP!

To learn more about UAS use the help function in Robot Studio.

Accessing UAS from custom applications

Before sensitive controller operations are performed, a FlexPendant SDK application should check that the user currently logged on has the corresponding UAS rights.

Accessing UAS is done by using the property AuthorizationSystem on the controller object:

VB:

Dim UAS As UserAuthorizationSystem = Me.AController.AuthorizationSystem

C#:

UserAuthorizationSystem uas =

this.aController.AuthorizationSystem;

Grants and Groups

UAS rights are called Grants. The specific user belongs to one of several defined Groups, where each group has a number of specified grants.

To ensure that the user has the necessary grant to perform an operation, you use the

CheckDemandGrant method on the AuthorizationSystem object. The grant to check is passed as an argument: VB: If UAS.CheckDemandGrant(Grant.ModifyRapidProgram) Then ATask.LoadModuleFromFile(ALocalFile, RapidLoadMode.Replace) End If C#: if (uas.CheckDemandGrant(Grant.ModifyRapidProgram)) { aTask.LoadModuleFromFile(localFile, RapidLoadMode.Replace); }