4 Developing RAB applications. ABB RobotWare 5.0
Robot Application Builder (RAB) is a software tool, which enables ABB programmers to develop customized operator interfaces for the IRC5 robot controller. Robot Application Builder is fully integrated with Microsoft Visual Studio, which means that a .NET programmer will recognize wizards for project setup, tools for visual design support, and debug etc.
Advertisement
Advertisement
4 Developing RAB applications
4 Developing RAB applications
3.4. Release upgrades and compatibility
3HAC028083-001 Revision: D 63
4 Developing RAB applications
4.1. Introduction
4.1. Introduction
About this chapter
This chapter deals with analysis, design and implementation of RAB applications.
It also discusses some specific programming issues that are important for both PC and
FlexPendant SDK users:
• thread conflicts and how to avoid them
• controller events and event handling
• errors and exception handling
• the User Authorization System
The chapter does not include hands-on information on how to set up your first project or detailed information on how to use the PC and FlexPendant SDK class libraries, as these topics are covered in dedicated chapters.
Basic approach
In most aspects, using the PC or FP SDK for application development presents no major difference compared to ordinary .NET development. The .NET class libraries are used for everything that is not robot specific. In addition, you use the public Controller API of the
SDKs.
64
NOTE!
When using the .Net class libraries for FlexPendant development, see Version Information to be sure that the class or method is supported on .NET Compact Framework 2.0, which runs on the FlexPendant.
Take this good advice if you are going to program your first RAB application
Step Action
1. Before you start
Learn the basics about RAB programming by reading all relevant sections of this manual. Feel reassured that this is a timesaving activity and do not rush into coding.
If you are going to develop an application for the FlexPendant, a device with limited
resources compared to a PC, studying the chapter
Robust FlexPendant applications on page 181
2. During development
Frequently test application functionality.
Do not wait too long before you test a FlexPendant application on a real FlexPendant device.
3. After development
If you develop a FlexPendant application, set up a long term test before use in production. If not, you risk that the FlexPendant slowly runs completely out of memory and crashes due to your application.
Verify application behavior, performance and memory consumption. Use the services offered by the ABB.Robotics.Diagnostics namespace, e.g. memory
FlexPendant - Debugging and troubleshooting on page 279
for further information.
3HAC028083-001 Revision: D
4 Developing RAB applications
4.2. Analysis and design
4.2. Analysis and design
About this section
The purpose of Robot Application Builder is to provide operator interfaces that fulfill specific customer needs. This section focusses on the development phases preceding the actual coding: analysis and design.
Object oriented software development
.NET is entirely object-oriented. Platform services are divided into different namespaces such as
System.Collections, System.Data
,
System.IO, System.Security and so on.
Each namespace contains a set of related classes that allow access to platform services.RAB, too, is completely object oriented. Its class libraries are organized in different namespaces such as
ABB.Robotics.Controllers.RapidDomain,
ABB.Robotics.Controllers.MotionDomain
etc.
Some experience in object orientation is necessary to start developing custom applications. It is presumed that you feel comfortable with concepts such as objects, classes, methods, inheritance, encapsulation etc.
Object oriented Analysis and Design
Object Oriented Analysis and Design, OOAD, is a popular topic in computer science literature, where the importance of doing a thorough analysis and design before starting coding is commonly accepted. A well designed OO application has a true representation in the real world. Classes have well defined areas of responsibility and collaborate in an efficient way to achieve what is required.
Analysis based on communication and use cases
The main idea of Robot Application Builder is, as has already been pointed out, that custom operator interfaces can be developed close to end-users, taking their specific needs in consideration. It therefore goes without saying that analysis is crucial.
The result of the object-oriented analysis is a description of what we want to build, often expressed as a conceptual model. Any other documentation that is needed to describe what we want to build, for example pictures of the User Interface, is also part of analysis.
The most important aspect for RAB development is communication with end-users.
Activities which support a shared view of what should be developed are strongly recommended. Such activities may include:
• creating and discussing use cases together
• coding or drawing prototypes and get end-user feedback
3HAC028083-001 Revision: D
Continues on next page
65
4 Developing RAB applications
4.2. Analysis and design
Continued
In short, involving end-users from the early stages and keeping them involved throughout the development project is the best strategy.
NOTE!
Customer satisfaction is what has driven the development of Robot Application Builder. Do make sure that you have really understood what the end-users of your application need.
Design is about managing complexity
The result of the object-oriented design details how the system can be built, using objects.
Abstraction is used to break complex problems into manageable chunks. It makes it possible to comprehend the problem as a whole or to study parts of it at lower levels of abstraction.
It takes years to become a skilled object oriented designer. Design theory must be transformed into practical experience and iterated over and over again.
The goal is to produce high quality code, which is cost-efficient and easy to maintain. This is achieved, for example, when adding new functionality will involve minimal changes to existing code and most changes will be handled as new methods and new classes.
Do you need to do design?
There is a huge difference in complexity when creating software such as .NET framework, for example, and a custom operator view for IRC5. Obviously, the more complex a system the more careful design is needed. Accordingly, the larger and more complex a custom application needs to be, the more likely you are to spend time on design.
This table presents some considerations before deciding how well you need to design your application before starting coding:
Consideration Advice
How much code is it going to be?
If it is going to be a very simple application with just one view and a few buttons there is no need even to split the code between different classes and files.
If there will be a substantial amount of code and there might be further extensions later on, spending time on design becomes more relevant.
Will different developers work on different classes/ components? Will you maintain the code yourself, or may it be done by others?
If yes, spending time om design becomes more relevant.
Is the real time aspect of the application important?
If yes, coding efficiently is important. This will much more easily be achieved if you spend some time on design.
Note! You are also recommended to read through the chapter
Robust FlexPendant applications on page 181
coding.
As complex or as easy as you wish
A simple custom application can be created in a day or two using RAB. A large custom application with a number of different views, offering advanced robot system functionality, however, may take months to develop and will require considerable programming skill.The recommendation is to start developing a simple application, which you execute on the target platform, before moving on to advanced RAB programming.
66 3HAC028083-001 Revision: D
4 Developing RAB applications
4.3. Controller events and threads
4.3. Controller events and threads
Overview
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
OperatingModeChanged
ExecutionStatusChanged
Changed
MessageWritten
ValueChanged the controller state has changed.
the controller operating mode has changed.
the controller execution status has changed.
the value or the state of the I/O signal has changed.
the EventLog has a new message the value of a RAPID data has changed.
3HAC028083-001 Revision: D
Continues on next page
67
4 Developing RAB applications
4.3. Controller events and threads
Continued
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
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});
68
Continues on next page
3HAC028083-001 Revision: D
4 Developing RAB applications
4.3. Controller events and threads
Continued
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
.
3HAC028083-001 Revision: D 69
4 Developing RAB applications
4.4. User Authorization System
4.4. User Authorization System
Overview
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:
C#:
If UAS.CheckDemandGrant(Grant.ModifyRapidProgram) Then
ATask.LoadModuleFromFile(ALocalFile, RapidLoadMode.Replace)
End If if (uas.CheckDemandGrant(Grant.ModifyRapidProgram)) { aTask.LoadModuleFromFile(localFile, RapidLoadMode.Replace);
}
70
Continues on next page
3HAC028083-001 Revision: D
4 Developing RAB applications
4.4. User Authorization System
Continued
NOTE!
The RAB application cannot override the UAS configuration. This means that the system will in the end prevent the user from performing an action that is not allowed.
MessageBox feedback
If a UAS grant is missing the user should get information about it. This can be done in a message as shown in this example: msg = "You are not allowed to perform this operation, talk to your system administrator if you need access." title = "User Authorization System"
For the PC platform (VB and C#):
MessageBox.Show(msg,title,MessageBoxIcon.Exclamation,MessageBoxB uttons.OK)
For the FlexPendant platform:
VB:
GTPUMessageBox.Show(Me, Nothing, msg, title,
System.Windows.Forms.MessageBoxIcon.Asterisk,
System.Windows.Forms.MessageBoxButtons.OK)
C#:
GTPUMessageBox.Show(this, null, msg, title,
System.Windows.Forms.MessageBoxIcon.Asterisk,
System.Windows.Forms.MessageBoxButtons.OK);
GetCurrentGrants and DemandGrant
Another possibility is to retrieve all grants for the current user calling
GetCurrentGrants
, then iterate over the grants collection and search the necessary grants.
Yet another solution is to call
DemandGrant
with one of the static
Grant
members as in argument.
If the user does not have the specified grant the FlexPendant SDK throws a
UasRejectException
and the PC SDK throws a
GrantDemandRejectedException
.
TIP!
Learn more about UAS and
Grant
members in the SDK Reference Help.
3HAC028083-001 Revision: D 71
4 Developing RAB applications
4.5. Exception handling
4.5. Exception handling
Overview
The .NET programming languages provide built-in support for exception handling, which allows the program to detect and recover from errors during execution.
In managed code, execution cannot continue in the same thread after an unhandled exception.
The thread terminates, and if it is the program thread, the program itself terminates. To avoid this, accurate exception handling should be used.
Try-catch-finally
Exceptions are handled in try
- catch
(finally
) blocks, which execute outside the normal flow of control.
The try
block wraps one or several statements to be executed. If an exception occurs within this block, execution jumps to the catch
block, which handles the exception.
The finally
block is executed when the
Try
block is exited, no matter if an exception has occurred and been handled. It is used to clean up system or controller resources.
If you do not know what exceptions to expect or how to handle them, you can catch them and do nothing. This, however, may result in difficult error tracing, as exceptions include information on what caused the problem. Therefore, try at least to display the exception message, either by using a message box or the types
Debug or
Trace
. See
for further information.
Typecasting
72
When typecasting
Signal
or
RapidData
values, for example, there is a potential risk of typecast exceptions. To avoid this you can check the object using the is
operator for both value and reference types:
VB:
If TypeOf ARapidData.Value Is Num Then
Dim ANum As Num = DirectCast(ARapidData.Value, Num)
.....
C#: if (aRapidData.Value is Num)
{
Num aNum = (Num) aRapidData.Value;
....
}
In C# it is also possible to use the as
operator for reference types. A null value is returned if the type is not the expected one:
C#:
DigitalSignal di = this.aController.IOSystem.GetSignal(“UserSig”) as DigitalSignal; if (di == null)
{
MessageBox.Show(this, null, “Wrong type”);
}
Continues on next page
3HAC028083-001 Revision: D
4 Developing RAB applications
4.5. Exception handling
Continued
Exception handling for the PC platform
Exceptions thrown from the controller are handled by the PC SDK
ExceptionManager
, which converts the internal HRESULT to a .NET exception with a reasonable exception description, before it is thrown to the custom application layer. The application handling of these exceptions should apply to general .NET rules.
Exceptions are expensive in a performance perspective and should be avoided if there are other alternatives. If possible use a try-finally
block to clean up system and unmanaged resource allocations.
Exception handling for the FlexPendant platform
The FlexPendant SDK provides several exception classes, which are used when errors occur.
If the operation is rejected by the controller safety access restriction mechanism, for example, a
RejectException
is thrown.
If an unhandled exception occurs the application crashes and TAF displays a gray message on the FlexPendant. After confirmation the FlexPendant will restart. To avoid this you should make sure that any potential error situations are dealt with properly by your code.
5.5_1
The message that you get when an unhandled error situation occurs may look like this. Do
NOT contact ABB, but fix the error handling of your application.
3HAC028083-001 Revision: D
Continues on next page
73
4 Developing RAB applications
4.5. Exception handling
Continued
NOTE!
Learn how the exception classes of the FlexPendant SDK work by using the FlexPendant
SDK Reference Documentation. Also see
SDK exception classes on page 194
to get more detailed information about exception handling for the FlexPendant platform.
.NET Best Practices
.The .NET Framework Developer's Guide presents the following best practices for exception handling:
•
Know when to set up a try/catch block. For example, it may be a better idea to programmatically check for a condition that is likely to occur without using exception handling. For errors which occur routinely this is recommended, as exceptions take longer to handle.
• Use exception handling to catch unexpected errors. If the event is truly exceptional and is an error (such as an unexpected end-of-file), exception handling is the better choice as less code is executed in the normal case.Always order exceptions in catch blocks from the most specific to the least specific. This technique handles the specific exception before it is passed to a more general catch block.
74 3HAC028083-001 Revision: D
4 Developing RAB applications
4.6. How to use the online help
4.6. How to use the online help
Overview
The online help comes with the installation of Robot Application Builder and is accessible from Windows Start menu.
The recommendation is to read this user’s guide carefully as you develop your first RAB application. FP SDK Reference and PC SDK Reference are important complements to this manual, as these make up the complete reference to the class libraries of RAB. See
Documentation and help on page 16
for details.
NOTE!
The SDK Reference is NOT integrated in Visual Studio. You must open it from the Start menu.
TIP!
See
Documentation and help on page 16
for the web address to RobotStudio Community,
where RAB developers discuss software problems and solutions online.
3HAC028083-001 Revision: D 75
4 Developing RAB applications
4.6. How to use the online help
76 3HAC028083-001 Revision: D
Download
Advertisement
Key features
Develop custom operator interfaces
FlexPendant SDK
PC SDK
Visual Studio integration
.NET programming
Virtual IRC5
Frequently asked questions
Robot Application Builder (RAB) is a software tool, which enables programmers to develop customized operator interfaces for the IRC5 robot controller.
The supported operating systems are Microsoft Windows XP + SP2 or Windows Vista + SP1.
The supported versions are Visual Studio 2005 and Visual Studio 2008.
The supported programming languages are C# and Visual Basic.NET for FlexPendant applications. For PC applications, any of the .NET languages should work, however, ABB support is only offered for Visual Basic and C#.