Two development models virtual and real

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

2.5. Two development models - virtual and real

When trying out a custom application, you can either use a virtual robot controller or a real robot system. This section provides information on how to use both development models. Virtual robot technology

The virtual IRC5 of ABB’s RobotStudio allows the IRC5 controller software to execute on a PC, and supports RAB application developers with a purely virtual environment to be used for development, test and debug.

When you start the virtual IRC5 in RobotStudio, a virtual robot cabinet along with a virtual FlexPendant will appear on the PC screen.

As a real robot controller is normally not readily at hand for application development, virtual technology is very valuable.

Requirements for virtual environment

The following software components must be installed to develop, test and debug using the virtual environment:

• ABB RobotStudio (including the virtual IRC5 and RobotStudio Online)

• ABB Robot Application Builder

• Microsoft Visual Studio 2005 or 2008

Controller option PC Interface or FlexPendant Interface may not be needed in the virtual environment.

Requirements for real environment

The following software components must be installed to develop, test and debug using a real robot controller:

• ABB RobotStudio (RobotStudio Online is needed to create the robot system)

• ABB Robot Application Builder

• Microsoft Visual Studio 2005 or 2008

• Controller option PC Interface or FlexPendant Interface

• Network connection between PC and robot controller

For information about how to set up the network, see How to set up your PC to robot communication on page 27.

Virtual test and debug

Using the virtual environment a FlexPendant application executes on the Virtual FlexPendant as an assembly (dll). You start the application from the ABB menu of the Virtual FlexPendant just like you start it on the real FlexPendant.

A PC application, on the other hand, will run as an independent executable (exe). Using the virtual environment it targets the virtual IRC5 instead of a real robot controller.

Debugging is easy using the virtual IRC5 and Visual Studio. You attach the application process to Visual Studio, set a break point in the code and step through it as it executes. See

Debugging the virtual FlexPendant on page 282 for further information.

2.5. Two development models - virtual and real © Copyri ght 200 7 - 2009 ABB . All ri ghts res erved.

Real tests necessary

The virtual environment is a very convenient choice, especially for testing and debugging. You should be aware, however, that the virtual FlexPendant is more forgiving than the real device. Using only the virtual FlexPendant, it is very easy to neglect the restraints on memory consumption imposed by the real device. Images, for example, can easily consume all the FlexPendant memory available for custom applications!

This means that potential problems may be hard to detect until you test the application using a real robot system. It is almost as easy to debug code running on the real FlexPendant device. See Debugging the FlexPendant device on page 286 for detailed information.

You should also be aware that your application shares CPU, memory and application host with all other FlexPendant applications. This means that a custom application can impact the overall performance of the FlexPendant.

NOTE!

Before shipping a FlexPendant application, it has to be tested properly, using a real system. Relying only on the virtual environment is far too risky. Also study the chapter Robust FlexPendant applications on page 181 carefully.

Porting the application from virtual to real IRC5

As for a PC SDK application, you will hardly notice any difference when using it with a real IRC5 controller. The only real difference is that the communication between the application and the controller will now be done over a network, which may have an impact on

performance.

A FlexPendant application, on the other hand, may run perfectly on the Virtual FlexPendant, but not work at all on the real device. There may be a lag in response time due to TCP/IP communication, but the main problem is limited resources on the device, both memory and processor power.

The FlexPendant SDK does not slow down performance. Therefore your application is supposed to perform like any standard application of the FlexPendant. See Performance on page 188 for some advice on how to speed up a slow FlexPendant application.

Deployment to customer

During development, deployment to the controller is done manually. When the development phase is over and the application needs to be deployed to the customer, this should be done differently.

For information about how this should be done, see Packaging RAB applications on page 309.

2.6. Conversion of VS 2005 projects to Visual Studio 2008 © Copyri ght 200 7 - 2009 ABB . All ri ghts res erved.

2.6. Conversion of VS 2005 projects to Visual Studio 2008

Converting an existing RAB Visual Studio 2005 project to Visual Studio 2008 is simple. When you open a VS 2005 project in VS 2008, the Visual Studio Conversion Wizard will automatically appear. The procedure which converts the project to VS 2008 is easy to follow. It consists of a few dialogs providing information about what will happen.

NOTE!

If the RAB project is an FP SDK projects, you need to manually edit the post-build event that builds the *gtpu.dll. Find Build Events in the Project Properties and adapt the path to vcvarsall.bat to the new development environment.