3 Run-time environment. 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
3 Run-time environment
3 Run-time environment
2.6. Conversion of VS 2005 projects to Visual Studio 2008
3HAC028083-001 Revision: D 35
3 Run-time environment
3.1. Two platforms - PC and FlexPendant
3.1. Two platforms - PC and FlexPendant
About this chapter
There are two different platforms that a custom application may use: PC and FlexPendant.
Accordingly, RAB consists of two platform dependent SDKs the PC SDK and the
FlexPendant SDK.
This chapter provides an overview of the run-time environment of custom applications, including illustrations of the software architecture of the FlexPendant and PC SDK respectively.
How communication is carried out between the client and the robot controllers is explained, as well as how clients access controller resources.
Application configuration is detailed as well as deployment of a FlexPendant application to a robot controller. The life cycle of a FlexPendant application is also explained.
Most of the contents of this chapter is separated in PC and FlexPendant specific sections, as their respective run-time environments considerably differ.
Selecting the platform your application should use
Before you start developing a custom application, you must know which platform is best suited for meeting the needs of the customer. The platform choice depends on what tasks should be performed using the application, whether these tasks must be done at the robot cell and whether there is a PC at hand where the job needs to be done.
If the application should be used at the robot cell and there is no PC available, there evidently is no choice. It has to be a FlexPendant application. On the other hand, if the tasks can be done from a PC this is often a convenient platform, provided that the PC SDK offers the required functionality.
36
Continues on next page
3HAC028083-001 Revision: D
3 Run-time environment
3.1. Two platforms - PC and FlexPendant
Continued
Local vs remote client
One difference between the two platforms is that a FlexPendant application is a local client, whereas a PC application is a remote client.
Remote clients do not have all the privileges of a local client. Both PC and FP applications can reset the program pointer and start RAPID execution, for example, but for a PC SDK application to do this there are certain restrictions. Mastership of the Rapid domain must be requested explicitly by the application programmer and the IRC5 controller has to be in automatic operating mode.
An advantage of a remote client, on the other hand, is the possibility to monitor and access several robot controllers from one location. As for large applications the PC platform is also less limited than the FlexPendant as regards memory resources and process power.
NOTE!
A minimum response time for a real controller should be expected to be in the order of 10-
100 milliseconds, meaning that hard real time demands cannot be met on any platform. See
Communication between PC and controller on page 46
FlexPendant and controller on page 51
for further information.
Software architecture
The FlexPendant is an integral part of IRC5, yet a complete computer in itself. It has been developed with Microsoft's latest software technology for embedded systems, Windows CE and .NET Compact Framework, which is a subset of the full .NET Framework that the PC uses.
Simple illustrations of the software architecture of the two SDKs are shown below. As you can see the two run-time platforms, PC and FlexPendant, have a lot in common.
PC platform
3.1_1
Figure 1 - PC platform. Two PC SDK applications developed on top of the PC SDK. The PC
SDK CAPI is the public API offering controller functionality. A PC SDK application can control many robot controllers on the network. All communication with these is done via the internal RobApi.
3HAC028083-001 Revision: D
Continues on next page
37
3 Run-time environment
3.1. Two platforms - PC and FlexPendant
Continued
FlexPendant platform
CAPI
3.1_2
Figure 2 - FlexPendant (SxTPU-2) platform. Two FlexPendant applications, one using VB and the other C#, developed on top of the FlexPendant SDK. The FlexPendant SDK CAPI is the public API offering controller functionality. All communication with the robot controller is done via the internal RobApi. The FlexPendant SDK provides ABB made UI controls suitable for the FlexPendant.
Both SDKs offer controller functionality through a public application interface called CAPI.
The interface can be seen as a specification of the controller services available.
Part of the controller services provided by the PC and FlexPendant SDK are the same. This means that part of the specification is also common (identical method signatures). The internal implementation of these controller services may differ, but for an external client, such as a RAB application, these methods are platform independent and work for both PC and
FlexPendant applications.
As illustrated below, however, only a small part of the PC and FlexPendant SDK is common.
Therefore, you cannot port a PC application to the FlexPendant platform or vice versa.
3.1_3
38
Continues on next page
3HAC028083-001 Revision: D
3 Run-time environment
3.1. Two platforms - PC and FlexPendant
Continued
Figure 3 - Common CAPI methods can be used for both platforms. The other CAPI methods are platform dependent. As you can see the FlexPendant SDK is more extensive than the PC
SDK. This is mainly due to the fact that the FlexPendant SDK offers its own GUI controls.
In this figure these would be in the FlexPendant circle outside of the CAPI circle.
3HAC028083-001 Revision: D 39
3 Run-time environment
3.2.1. Licence verification - applies only to versions earlier than RAB 5.10
3.2 Running PC Applications
3.2.1. Licence verification - applies only to versions earlier than RAB 5.10
Overview
A PC SDK application runs as a .NET executable, started either by double clicking the exefile or by browsing to the program using the Windows Start menu.
Deployed PC applications do license verification during execution, checking that all application assemblies have been built on a PC with a valid PC SDK license key. If the key is missing some functions in the PC SDK will raise an exception during execution.
NOTE!
The license verification was removed in the 5.10 release. So the licx file detailed in the next section is no longer needed.
Licenses.licx
The license key should be placed in a “Licenses.licx” file, which should be added to your project as an embedded resource. For your convenience, such a file is included in the RAB installation at C:\Program Files\ABB Industrial IT\Robotics IT\Robot Application
Builder\PC SDK. The key for the PC SDK in VS 2005 is:
ABB.Robotics.Controllers.Licenses.PCSdk, ABB.Robotics.Controllers
TIP!
The License Compiler (Lc.exe) is a .Net Framework tool. It generates a .license file from a
.licx file. Search in MSDN (licx , lc.exe) if you want more detailed information.
40 3HAC028083-001 Revision: D
3 Run-time environment
3.2.2. Mastership
3.2.2. Mastership
Controlling controller resources
Controller resources must be controlled by a single client at a time. Several people can be logged on to the controller, but only one person at a time can run commands or change RAPID data. This is for security reasons as well as for protecting data from being accidentally overwritten.
When logged on to a controller you can have either read-only access or write access. Read only is the default access right. To get write access the client needs to request mastership of the controller resource it wants to manipulate.
NOTE!
In addition to the access right system, there is the User Authorization System, which restricts
what each user is allowed to do with the robot. See
User Authorization System on page 70
for further information.
Manual and automatic mode
When the controller is in manual mode, the FlexPendant has priority to write access, and mastership will not be given to a remote client unless an operator explicitly allows this via the FlexPendant. At any time, the operator can press Revoke on the FlexPendant to get the write access back.
In automatic mode, the client who first requests write access will get it. If a remote client has taken mastership of a domain other remote clients will not be allowed write access, but will get an exception if they try. For the operator there is no way to revoke mastership to the
FlexPendant, but to switch the operating mode of the controller to manual.
As for FlexPendant SDK applications, requesting and releasing mastership is handled internally by the FlexPendant SDK, and the application programmer does not need to worry about it.
As for a remote client, such as a PC SDK application, however, it has to be carefully implemented by the application programmer.
PC SDK mastership domains
The PC SDK domains which require mastership are:
•
Rapid
• Configuration
3HAC028083-001 Revision: D
Continues on next page
41
3 Run-time environment
3.2.2. Mastership
Continued
Start program execution on page 208
NOTE!
Operations that require mastership are more resource demanding. Mastership should therefore be released as soon as an operation is completed.
Remote privilege in manual mode
Most of the time, it is not very convenient to have a PC SDK application perform operations that require mastership when the controller is in manual mode. Starting program execution for example is not even possible.
In manual mode when a remote client, e.g. RobotStudio or a PC SDK application, requests mastership a dialog box will appear on the FlexPendant. It enables the operator to grant mastership to the requesting client.
If mastership is granted, the remote application has the privilege to access robot controller resources. Meanwhile, the FlexPendant is locked and cannot be used until the remote application releases mastership or mastership is lost for any of the reasons mentioned in
.
Losing mastership
Remote clients have to be prepared that mastership may be lost without a warning for a number of reasons. Among these are:
• change from automatic to manual mode
• controller restart
• lost communication
• in manual mode forced revocation of mastership by another client with higher priority
- for example the FlexPendant
If mastership is lost, it has to be taken back explicitly by the client. The controller does not store the information.
NOTE!
The FlexPendant may also lose mastership without any warning. This may happen in automatic mode, when a RobotStudio user or a PC SDK application asks for write access to the controller, for example. The status bar of the FlexPendant will then indicate “Remote
Access in Auto”.
42 3HAC028083-001 Revision: D
3 Run-time environment
3.2.3. PC application configuration
3.2.3. PC application configuration
Application configuration file
All .NET Winform applications are designed to read configuration from an App.config file in the application directory. It is not mandatory to use such a file in a PC SDK application, but it is sometimes a handy way to add application flexibility.
For your convenience an App.config file that you can use is included in the RAB installation.
The default values, which the PC SDK uses if there is no configuration file to read, are entered in the file. To modify application behavior you thus need to change the values of the attributes of this file.
NOTE!
Even if you use the App.config file to specify which controllers to work with you must still use the netscan functionality to be able to establish a connection from your PC application.
Add App.config to the project
Start by copying the App.config file at C:\Program Files\ABB Industrial IT\Robotics
IT\Robot Application Builder 5.xx\PC SDK to the directory of your .csproj file. Then add the file to the project by right-clicking the project icon, pointing to Add and selecting Existing
Item.
NOTE!
The Copy Local property of the PC SDK references used by your application must be set to true to make use of the App.config file. (In the Solution Explorer in Visual Studio, right-click the reference and select Properties.)
Section tag
The
<section>
tag in the
<configSection>
part of the App.config should specify that there is a capi section in the file. It should also specify which type is to be used as the configuration container object as well as the assembly that this type belongs to:
<section name="capi" type="ABB.Robotics.Controllers.ConfigurationHandler,
ABB.Robotics.Controllers"/>
Capi section
The PC SDK application specific configuration data should be added to the
<capi>
section.
<capi>
...
</capi>
3HAC028083-001 Revision: D
Continues on next page
43
3 Run-time environment
3.2.3. PC application configuration
Continued
The following tags are implemented in the PC SDK:
<defaultSystem>
If there is a controller (robot system) in the network that you connect to often, you may want to use the
<defaultSystem>
tag. It has an id
attribute containing a string embraced by curly brackets. It is the system’s globally unique identifier (GUID), which can be find in the
system.guid file in the INTERNAL folder of the robot system.
<defaultSystem id="{469F56DF-938E-4B06-B036-AABBB3E61F83}" />
Using this mechanism enables you to use the default constructor to create a
Controller object for the specified controller:
VB:
Dim aController As Controller = New Controller()
<remoteControllers>
It is possible to add controllers outside the local network when scanning for available controllers. One way of doing that is to add the IP address of these controllers in the
<remoteControllers>
tag:
<remoteControllers><controller id="192.168.0.9" />
<controller id="192.168.0.19" />
</remoteControllers>
<discovery.networkscanner>
You can configure how long (in ms) a scan operation will last, and increase the value if netscanning fails. The default value is 200, but if you have a slow PC longer time might be needed.
<discovery.networkscanner delay="400" />
<defaultUser>
C#:
Controller aController = new Controller();
The
<defaultUser>
tag holds information about user name, password and an optional application name for the default user. It is used by the
UserInfo
class to log on to a controller. If an application name is not supplied, the process name is used.
<defaultUser name="user name" password="password" application="application"/>
<rmmp>
When mastership is requested in manual mode by a remote client such as RobotStudio or a
PC SDK application, a dialog is launched on the FlexPendant asking the operator to confirm that mastership should be passed from the FlexPendant to a remote client. As long as there is no confirmation on the FlexPendant the PC SDK application is not given mastership. The time-out parameter is the time in seconds that the PC SDK application will wait for someone to confirm remote access in the FlexPendant dialog. The cycle parameter is the time in ms between poll calls from the PC SDK to check whether mastership has been granted.
<rmmp cycle="550" timeout="65" />
44
Continues on next page
3HAC028083-001 Revision: D
3 Run-time environment
3.2.3. PC application configuration
Continued
<controllerCall>
<eventStrategy>
You can add a time-out in ms and a multiplicand for slow calls to the controller. The time-out parameter is the maximum time a call through the Controller API will be permitted. If no answer is returned within the time specified, an exception is thrown. A slow call is a call that takes longer than usual, usually operations which require a UAS grant:
<controllerCall timeout="27000" slow="2.1" />
The default way to handle events from the controller is to use asynchronous delegates
(
AsyncDelegate
), applying the
Invoke
method to synchronize events and GUI.
By using an
<eventStrategy>
tag, you can choose to use a windows postback delegate instead. To make this work you must also implement a subscription to the event from a windows form, or else the event handler will not receive the event:
<eventStrategy name="WindowDelegate" />
NOTE!
Using this strategy for event handling may affect the performance of your application.
3HAC028083-001 Revision: D 45
3 Run-time environment
3.2.4. Communication between PC and controller
3.2.4. Communication between PC and controller
COM technique
The PC SDK uses an internal Controller API based on COM technique to communicate with
the controller. This API uses sockets and the local TCP/IP stack (see
) towards both real and virtual controllers.
NOTE!
You should be aware that the .NET garbage collector does not collect COM objects, but these
need to be disposed of explicitly by the application programmer. See
Memory management in PC applications on page 213
Resource identification
All controller resources, both real and virtual, are described using object based hierarchy.
Each resource is uniquely identified, including information about which controller owns the resource by use of the unique system id or IP address of the controller.
The controller is the top object of the hierarchy:
TIP!
"/<Controller>/<Domain>/<SubDomain1>/<SubDomain2>/etc"
Error messages including such a path indicate where to look for the problem.
Hard real-time demands
You should be aware that the PC CAPI cannot meet hard real-time demands. This is for several reasons:
• Part of the API executes on a non-real-time operating system.
•
Communication is performed with TCP/IP over a network
• The controller sometimes has tasks to perform that have a higher right of priority.
NOTE!
A minimum response time for real controllers should be expected to be in the order of 10-100 milliseconds.
46 3HAC028083-001 Revision: D
3 Run-time environment
3.3.1. Components, assemblies and dlls
3.3 Running FlexPendant Applications
3.3.1. Components, assemblies and dlls
Building blocks
The .NET Framework is a library of components and supporting classes and structures, designed to make component development easy and robust. Components are packaged in assemblies, also called dlls.
Assemblies are the building blocks of .NET applications. An assembly is a reusable collection of types and resources, which are built to work together and form a logical unit of functionality. The simplest assembly is a single executable.
One or several assemblies
A FlexPendant project compiles to a dll, which cannot run as an independent application, but needs to be started by the Teach Pendant Application Framework (TAF), the application manager of the FlexPendant. (See
Understanding FlexPendant application life cycle on page
for further information about how this works.)
In a normal case, a custom application for the FlexPendant is developed as a single component, but it is also possible to separate functionality into several components. This way the application will consist of several dlls. The reason for doing so might be one of the following:
•
The amount of code is substantial. A modular design with small and well tested building blocks put together is one way of handling complexity.
• Different developers are working on the same custom application. For reasons of efficiency, they can split the functionality between them and work on one component each.
NOTE!
It is possible to use different programming languages for different components.
3HAC028083-001 Revision: D 47
3 Run-time environment
3.3.2. Deployment of FlexPendant application to a robot system
3.3.2. Deployment of FlexPendant application to a robot system
Proxy assembly
When you compile a FlexPendant SDK application an additional assembly named *gtpu.dll is automatically created. This is done by a tool, the ABB Compliance Tool, which verifies that the application complies to the FlexPendant requirements. This proxy dll is necessary to run the application on the FlexPendant.
To test the application on a real FlexPendant both assemblies must be downloaded to the
SYSTEM or HOME directory of the robot controller. After this the FlexPendant should be restarted. At startup it loads the application assemblies from the controller.
TIP!
An advantage of deploying the dlls to the HOME directory is that they will be included in a system backup.
Download to real controller
To download your application assemblies to the controller you can use the Online function
File Transfer of RobotStudio.
Another way of downloading the application to the robot controller is using the ABB
Compliance Tool.
Step
1
2
3
Action
Verify that the following requirements are met before starting the procedure:
• A network connection between the PC and the controller has to be configured, either using the controller LAN port or the controller service port. For further information see
How to set up your PC to robot communication on page 27
• The RobotWare option FlexPendant Interface is required to run the application on a real system. Without the option you will not see the application in the ABB menu.
Open Windows Explorer.
Start abbct.exe at C:\Program Files\ABB Industrial IT\Robotics IT\Robot
Application Builder 5.xx\FlexPendant SDK.
48
4
4.3.2_1
Click Browse and locate your Visual Studio project and the application assembly in the \bin\debug (or \bin\release) sub-folder.
Continues on next page
3HAC028083-001 Revision: D
3 Run-time environment
3.3.2. Deployment of FlexPendant application to a robot system
Continued
Step
5
6
Action
Check the Deploy box, enter the IP Address of the robot controller and press
Execute. Deployment is done to the current system of the controller.
Note!
If the application consists of several assemblies you need to repeat the procedure for all of these.
Restart the FlexPendant. See
Restart the FlexPendant on page 49
about different ways to do this.
Using the command window
The ABB Compliance Tool can be used via the command window instead of the graphical interface. To do so you write:abbct.exe /deploy="192.168.8.192"
<PATH>\TpsViewHelloWorld.dll <PATH>\TpsViewHelloWorld.gtpu.dll.
It is also possible to perform build and deployment in one step. To do this the deploy argument should come last: abbct.exe <PATH>\TpsViewHelloWorld.dll /deploy="192.168.8.192"
Both the application and proxy assembly are deployed to the controller after the build.
FTP deployment
You can also use an FTP client to transfer files from your PC to the robot controller.
To use FTP you need:
• FTP client program
•
Configured connection to the controller
• RobotWare option FTP Client
•
Name and password
Step
1
Action
Transfer resources (e.g. icons) and the application and proxy assemblies to the
HOME or SYSTEM directory of the current system of the controller.
Restart the FlexPendant. See the next section for information on how to do so.
2
NOTE!
For deployment to a customer when the application is ready see
Restart the FlexPendant
If you want to restart the FlexPendant device without restarting the controller, choose one of these alternatives:
Alternative Action
1
2
Write the command fpcmd "-restart"
in the controller console window on your PC.
Perform the following sequence while holding the FlexPendant joystick:
Move the joystick three times to the right, once to the left and once down.
Confirm your wish to reset the FlexPendant in the dialog that will appear.
3HAC028083-001 Revision: D
Continues on next page
49
3 Run-time environment
3.3.2. Deployment of FlexPendant application to a robot system
Continued
Alternative Action
3 Unplug and plug the FlexPendant (power on/ power off).
Note! This activates emergency stop.
Deploy application to virtual IRC5
Follow these steps to deploy an application to the virtual FlexPendant:
Step Action
1
2
Copy application and proxy assemblies and images to the HOME directory of the system you want to use on your PC.
Note! Close the virtual FlexPendant first if you are replacing assemblies.
Restart the virtual FlexPendant.
TIP!
If you have problems running your application, try to put all files (dlls, gif files etc.) in the vcbin directory of the robotware your system uses. This setup is as close to the real system setup as you can get.
50 3HAC028083-001 Revision: D
3 Run-time environment
3.3.3. Communication between FlexPendant and controller
3.3.3. Communication between FlexPendant and controller
COM technique
The FlexPendant SDK uses an internal Controller API based on COM technique to communicate with the controller. This API uses sockets and TCP/IP (see
About terms and acronyms on page 18
) towards both real and virtual controllers.
Calls from the FlexPendant SDK to the controller are synchronous, i.e. are done immediately through the COM servers. This increases execution speed and causes less overhead, which is important on a resource limited device.
Resource identification
All controller resources, both real and virtual, are described using object based hierarchy.
Each resource is uniquely identified, including information about which controller owns the resource by use of the unique system id or IP address of the controller.
The controller is the top object of the hierarchy:
TIP!
"/<Controller>/<Domain>/<SubDomain1>/<SubDomain2>/etc"
Error messages including such a path indicate where to look for the problem.
Hard real-time demands
The FlexPendant SDK cannot meet hard real-time demands. This is for several reasons:
•
Part of the API executes on a non-real-time operating system.
• The controller sometimes has tasks to perform that have a higher right of priority.
NOTE!
The FlexPendant SDK does not affect performance in a negative way. You should expect your custom application to perform like any other application on the ABB menu.
3HAC028083-001 Revision: D 51
3 Run-time environment
3.3.4. Understanding FlexPendant application life cycle
3.3.4. Understanding FlexPendant application life cycle
Overview
Understanding the FlexPendant application life cycle improves your ability to design and debug the application.
TAF - Application host framework
The Teach Pendant Application Framework (TAF) is the application service provider that runs on the FlexPendant. It targets .NET CF and is implemented in C#. All applications using the FlexPendant SDK must run as TAF clients, as TAF contains services for hosting controls and for managing applications.
TAF uses a customized configuration file to create the appearance and behavior of the hosted application. It also defines a set of rules that have to be followed.
Starting a custom application
When the FlexPendant starts up TAF is already in the flash memory. Applications that will execute in the TAF container are now loaded from the controller.
If the RAB application is to be started manually by the end-user the application icon and text are placed in the ABB Menu. The other alternative is to have it started automatically by TAF at FlexPendant startup. See
FlexPendant TpsView attribute on page 54
to learn how this is configured.
Application life cycle
TAF handles the life cycle of a custom application, starting by calling the constructor of its
TpsView class. After this, the
Install
method and then the
Activate
method in the same class execute.
During its lifetime, the application switches between the active and the passive state. Each time, either
Activate
or
Deactivate
is executed. In its active state the application is visible in the client view, in the passive state another application may have been opened or the user may have opened another application via the FlexPendant task bar.
When the application is closed via the close button, first the
Deactivate
method runs and then
Uninstall
. After this the
Dispose
method of the TpsView class is called. Then the application instance is disposed of by TAF. See
ITpsViewSetup and ITpsViewActivation on page 58
for further information about how you can implement these methods.
52
Continues on next page
3HAC028083-001 Revision: D
Illustration
3 Run-time environment
3.3.4. Understanding FlexPendant application life cycle
Continued
4.3.3_1
The figure illustrates the life cycle of a FlexPendant application.
Limited resources
As the FlexPendant is a device with very limited resources compared to a PC, you should learn and use the mechanisms implemented to assist you in writing efficient code.
Both process power and memory resources are limited compared to the virtual environment on the desktop. An application may run very well on the virtual FlexPendant, but encounter serious problems in the real environment because of these limitations. See
Technical overview of the FlexPendant device on page 182
NOTE!
You are strongly recommended to read
Robust FlexPendant applications on page 181
in this manual before starting coding. Always keep the limitations of the device in mind when you develop custom FlexPendant applications.
3HAC028083-001 Revision: D 53
3 Run-time environment
3.3.5. FlexPendant TpsView attribute
3.3.5. FlexPendant TpsView attribute
Overview
A custom FlexPendant application must implement the assembly attribute
TpsView
. It is used to determine the visual appearance of the application in the ABB menu, for example.
The
TpsView
attribute is auto generated and located before the namespace definition in the application view class, i.e. the class that displays the first view of a FlexPendant SDK application.
In this section all parameters of the
TpsView
attribute will be detailed.
Project wizard settings
The
TpsView
attribute is auto generated according to your settings in the FlexPendant SDK
Project Wizard in Visual Studio:
54
6.2.2_1
In C# the settings of the figure will render this code:
[assembly: TpsView("MyApplicationName", "tpu-Operator32.gif",
"tpu-Operator16.gif", "TpsViewHelloWorld.dll",
"TpsViewHelloWorld.TpsViewHelloWorld",
StartPanelLocation.Left, TpsViewType.Static, StartupType =
TpsViewStartupTypes.Manual)]
Continues on next page
3HAC028083-001 Revision: D
3 Run-time environment
3.3.5. FlexPendant TpsView attribute
Continued
NOTE!
You can edit your settings directly in the auto generated code if you want to.
Visual appearance
In run-time the most obvious result of this code is the way the custom application is presented in the ABB menu. In this example the first
TpsView
parameter has been changed from
“MyApplicationName” to “Hello World”.
4.3.4_1
Application name
The first parameter of TpsView is the application name as it should appear in the ABB menu and on the task bar. The example uses
“HelloWorld”
as the application name.
Application icon
The second parameter is the file to be used as the application icon in the ABB menu. Usually a customized icon is used for the application.The example uses the default icon: “ tpu-
Operator32.gif"
.
TaskBar icon
The third parameter is the file to be used as the application task bar icon. The example uses the default icon
"tpu-Operator16.gif"
.
3HAC028083-001 Revision: D
Continues on next page
55
3 Run-time environment
3.3.5. FlexPendant TpsView attribute
Continued
Application assembly
The fourth parameter is the assembly name. If you change the name of the application assembly you also need to change this parameter to reflect that change. In the example, the assembly name is
"TpsViewHelloWorld.dll"
.
NOTE!
The assembly name must start with “TpsView” for TAF to identify it as an application to be loaded. If you forget this an error will be generated by the ABB verification tool when you try to build the project.
Class name
The fifth parameter specifies the fully qualified class name of the initial view of your application, which you chose in the New Project dialog box. In the example, the fully qualified class name is
"TpsViewHelloWorld.TpsViewHelloWorld"
.
Application location
The sixth parameter determines the location of the application icon and text in the ABB menu.
In the example these are displayed in the left column: startPanelLocation.Left
.
Parameter value
StartPanelLocation.Left
StartPanelLocation.Right
StartPanelLocation.None
Result
application visible to the left in the ABB menu.
application visible to the right in the ABB menu.
application is not visible at all in the ABB menu.
NOTE!
StartPanelLocation.None
was introduced in 5.11.01. Applications that use it can therefore NOT be run on RobotWare releases older than 5.11.01.
Application type
As you can tell from the two Hello World icons visible in the task bar, two instances of the
Hello World application have been started. To enable this the seventh parameter is changed to :
TpsViewType.Dynamic
. Possible view type values are shown in the table:
Parameter value
TpsViewType.Dynamic
TpsViewType.Static
TpsViewType.Invisible
Result
The user can start multiple instances of the application.
The user can only start one instance of the application.
A background application with no GUI and no icon on the task bar. Can be started automatically or manually. Only one instance is possible.
56
Continues on next page
3HAC028083-001 Revision: D
3 Run-time environment
3.3.5. FlexPendant TpsView attribute
Continued
NOTE!
Unless there is special need for it, you should allow the user to start only one instance of the application:
TpsViewType.Static
. The reason is that working with several instances takes up valuable memory resources.
Startup type
The eighth parameter determines how the application is started. In the example the startup type is
TpsViewStartupTypes.Manual
and the application is started from the ABB menu.
Using the manual startup type it is also possible to have the application started by RAPID or at operating mode change to auto for example. See
System features supporting the use of customized screens on page 78
for information about how to do this.
If TpsViewStartupTypes.Automatic is chosen, the application is started automatically by TAF whenever the FlexPendant is restarted or a new user logs on.
Related information
For information about the Style setting of the Project Wizard, see
To find the FlexPendant SDK Project Wizard in Visual Studio, see
Setting up a new project on page 80
.
3HAC028083-001 Revision: D 57
3 Run-time environment
3.3.6. ITpsViewSetup and ITpsViewActivation
3.3.6. ITpsViewSetup and ITpsViewActivation
ITpsViewSetup
An application that TAF needs to initialize must have a default (empty) constructor and must implement the interface
ITpsViewSetup
, which specifies the two methods
Install
and
Uninstall
.
Install and Uninstall
Install
is called when the application is created in TAF. The parameters are used by TAF and should not be modified. It is recommended to add code for further initiations and allocation of system resources in this method, e.g. load assemblies, open communication channels, etc.
When the user closes the application
Uninstall
is called. This happens right before the application is deleted. It is recommended to add code for disposal of system resources in this method, e.g. unload assemblies, close sockets, etc.
ITpsViewActivation
All custom applications should implement the
ITpsViewActivation
interface, which specifies the two methods
Activate
and
Deactivate
. These are used by TAF to notify applications when they get focus and when they lose it.
Activate and Deactivate
Activate
is run every time the application gets focus. This happens at initialization, after the
ITpsViewSetup.Instal
l method has been run, and when the user presses the application icon in the task bar.
Deactivate
, accordingly, is run every time the application loses focus. This happens when the user closes the application, before the
ITpsViewSetup.Uninstall method has been run, and when the user presses another application icon in the task bar.
NOTE!
It is recommended to activate and deactivate timers in these methods. This way timers will not run when other applications are in focus, thus saving processor power. For the same reason, any subscription to controller events should be disabled in
Deactivate
and enabled again in
Activate
. Note that current values should be read before enabling the subscription.
Simple code examples
This table shows the basic things that the
ITpsView
methods are used for in a custom application:
Method Usage
Install
Create the
Controller
object:
VB:
AController = New Controller
C#: aController = new Controller();
58
Continues on next page
3HAC028083-001 Revision: D
3 Run-time environment
3.3.6. ITpsViewSetup and ITpsViewActivation
Continued
Method Usage
Activate
Deactivate
Remove subscription to controller event:
VB:
RemoveHandler AController.OperatingModeChanged, AddressOf
UpdateU
I
C#:
AController.OperatingModeChanged -= new
OperatingModeChangedEventHandler(UpdateUI);
Uninstall
Add subscription to controller event:
VB:
AddHandler AController.OperatingModeChanged, AddressOf
UpdateUI
C#:
AController.OperatingModeChanged += new
OperatingModeChangedEventHandler(UpdateUI);
Remove the controller object:
VB:
If Not AController Is Nothing Then
AController.Dispose()
AController = Nothing
End If
C#: i f (aController != null)
{
aController.Dispose();
aController = null;
}
3HAC028083-001 Revision: D 59
3 Run-time environment
3.4. Release upgrades and compatibility
3.4. Release upgrades and compatibility
About this section
Why did RAB 5.08 enforce an upgrade to Visual Studio 2005?
Will a RAB application still work if the customer upgrades the robot system with the latest
RobotWare release?
What happens if you develop a RAB application using the 5.11 release and the customer system uses RobotWare 5.10?
Such questions are dealt with in this section.
Platform upgrades
The Microsoft platform that the FlexPendant uses still goes through major improvements, which ABB needs to take advantage of. This may concern performance or other issues.
In RAB 5.08 for example, Visual Studio 2003 was no longer supported. It may seem that this was uncalled-for, but there are always reasons why such changes occur.
The Visual Design support for the FlexPendant SDK, had long been on the wish list. When
Microsoft provided the support necessary to meet this need, with CF 2.0, an upgrade of the
FlexPendant software platform was made. The development of the design support for
FlexPendant controls for RAB 5.08 made a transition to Visual Studio 2005 necessary.
NOTE!
RAB 5.10 supports Visual Studio 2005. RAB 5.11 supports VS 2005 and VS 2008.
Matching RAB and RobotWare release
You should be aware that the RAB SDKs are developed and tested for a specific RobotWare release. The general rule is therefore that you develop an application for a certain release.
Compatibility between revisions is however guaranteed (e.g. RW 5.11.01 will be compatible with RAB 5.11).
RobotWare upgrades
At some time during the lifetime of your application, a robot system that your application targets may be upgraded with a later RobotWare version.
As for a FP SDK application this means that the runtime will change, i.e. the FP SDK assemblies located in RobotWare will be different from the ones that were used when the application was developed. Generally, the only way to be sure that the existing application will work with a newer RobotWare version is to compile the source code with the FP SDK version that matches the intended RobotWare version. Normally compilation succeeds without any code changes, as FP SDK 5.09 - 5.11 are fully compatible.
The PC SDK it is normally compatible with a newer RobotWare release. The PC that hosts the PC SDK application at the customer, however, still needs an upgrade of the Robot
Communication Runtime, so that it matches the new robotware release. See
Robot Communication Runtime.msi on page 310
If you decide to upgrade the PC SDK application, you must also remember to upgrade the runtime environment of the customer’s
PC. See
Deployment of a PC SDK application on page 309
60
Continues on next page
3HAC028083-001 Revision: D
3 Run-time environment
3.4. Release upgrades and compatibility
Continued
NOTE!
You find all the details about compatibility between different RAB versions in the Release
Notes.
TIP!
When compiling your project notice any warnings of obsolete methods, as these will probably be removed in the next RAB release.
Prepared for change
To sum up, it is important to keep source code safe and available for maintenance.
TIP!
Ildasm is a Microsoft tool, which comes with the installation of Visual Studio, that you may find useful. It enables you to open the manifest of a specified assembly and quickly find out about dependencies for example.
Find out more about it at http://msdn2.microsoft.com/en-us/library/aa309387(VS.71).aspx
3HAC028083-001 Revision: D 61
3 Run-time environment
3.4. Release upgrades and compatibility
62 3HAC028083-001 Revision: D
Download
Public link updated
The public link to your chat has been updated. You may view and manage your chat links after registration here.
Document public link
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#.