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 the development models.

The virtual IRC5 of ABB’s RobotStudio allows the IRC5 controller software to execute on a PC, and supports 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 appears on the PC screen.

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

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

Controller option PC Interface is not needed in the virtual environment.

Note
For more information, see Installing and Licensing RobotStudio in Operating Manual - RobotStudio

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

For information about how to set up the network, see How to set up your PC to communicate with robot.

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 like you start it on the real FlexPendant.

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. For more information, see Debugging the virtual FlexPendant.

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. For more information, see Debugging the FlexPendant device.

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.

A FlexPendant application that runs perfectly on the Virtual FlexPendant, but not on the real device since there can 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. For more information on how to speed up a slow FlexPendant application, see Performance.

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 Deployment of a FlexPendant SDK application.