Memory management

An important feature of the .NET runtime environment is the garbage collector, which reclaims not referenced memory from the managed heap. Generally, this means that the programmer should not have to free memory which has been allocated by the use of new. A drawback, when memory is limited, is that the execution of the garbage collector is non-deterministic. There is no way of knowing exactly when garbage collection will be performed.

The IDisposable interface, however, represents a way to obtain deterministic deallocation of resources. You should therefore call Dispose() on all disposable object when they are no longer needed, as this will free up valuable resources as soon as possible.

Moreover, objects used to access robot controller resources, must be released by the custom application by an explicit call to their Dispose method. SignalBindingSource and RapidDataBindingSource objects, as well as all other objects located in the components pane of the Visual Studio Designer must also be explicitly disposed of, or else your application will have a permanent memory leak.

Note
The creator of an object implementing the IDisposable interface is responsible for its lifetime and for calling Dispose.

Tip

You may wonder why the .NET garbage collector cannot ensure that all objects no longer referenced are finally destroyed? The FlexPendant development team have tried hard to remove any remaining objects of an SDK application at application shut down, for example implemented finalizers for the TpsControl, RapidDataBindingSouce and SignalBindingSource classes. Due to Microsoft’s implementation, however, the .NET runtime nonetheless refuses to destroy these objects unless their Dispose method is called. This behavior is under debate. If you are curious to find out more about this, these community articles may be of interest. Dispose, Finalization, and Resource Management (Joe Duffy) Garbage Collection: Automatic Memory Management in the Microsoft .NET Framework (MSDN-magazine) Finalization - cbrumme's WebLog

The application framework TAF, which hosts the controls that make up a FlexPendant application, offers some mechanisms that should be used by client applications. For more information about TAF, see Understanding the FlexPendant application life cycle. .

Your application view class should implement ITpsViewSetup and ITpsViewActivation . For general information on these interfaces, see ITpsViewSetup and ITpsViewActivation and to learn how to use to improve performance, see Application Framework usage - ITpsViewActivation. .

The ITpsViewSetup interface has two methods: Install and Uninstall. Install is called when the view is being created, right after the constructor has been executed.

Uninstall is called when the client view is closed down. After Uninstall has been called, TAF will also call the Dispose method of the view class. These methods thus offer the last opportunity for you to clean up and release memory and system resources held by the custom application

Note
You should close down the application by using the close button, [x], in the upper right corner of the display, in the same way as the Program Data or other standard applications are closed. Never implement a close button on the first view. When the application is closed the correct way, first Deactivate, then Uninstall and finally Dispose will be called by TAF.

When starting a new FlexPendant project in Visual Studio a skeleton for the Dispose method is auto generated. You should use it to add code for cleaning up as shown in the following screenshot:

Note
Error handling should be added to the Dispose method (left out in the figure).

Note
Ensure you have unsubscribed to any events from the robot controller before you call the Dispose method of a Controller API object. If it has been done in the Deactivate method, which is what is usually recommended, you should not do it again in the Dispose method. Also ensure you do not try to access an object after it has been disposed.

When your application interacts with the robot controller, unmanaged objects are created under the hood. If you forget to call Dispose on such objects there will be memory leaks.

You are recommended to test the memory consumption of your application. Use a controller console window on your PC and the command fpcmd_enable_console_output 3 to enable printouts. Then use the "-memShow" command with a period argument that produces a printout every 500 second for example, like this:

-> period 500, fpcmd, "-memShow"

For more information on console window, see Exception error codes.

Result:

task spawned: id = 0xba7f3b8, name = t2value = 195556280 = 0xba7f3b8-> [fp]: Available memory: 20881408 (tot 40394752), disk: 737148 (tot 1728512) load: 54(261955)[fp]:

The load component indicates the amount of used RAM memory on the FlexPendant (expressed in percentage of the total amount) and the number in the parenthesis indicates the time taken in ms after start-up. For example in the perceding Result , 54 is the percentage of used memory in the FlexPendant and 261955 ms is the time taken after start-up.

Test all functions of your application with several other FlexPendant views visible in the task bar and possibly one or several RAPID tasks executing. Observe how your implementation affects memory. Close your application and make sure the same amount of memory is available as before opening it.

The following procedure shows yet another way of checking that your application cleans up correctly:

Note
You must use the real FlexPendant device when verifying memory consumption and looking for memory leaks in your code.