Trouble Shooting

The FESA crashes with a segmentation fault during startup on ppc4

Segmentation faults when trying to read a non-existent Persistent Data xml file on ppc4 have been observed, when the FESA class was compiled with strong optimization (-O3). Compiling the sources in the COMMON folder with optimization however seems to work.

omniORB: To endpoint: giop:tcp:[::ffff:140.181.129.4]:53689. Send GIOP 1.2 MessageError because a protocol error has been detected. Connection is closed.

If your FESA class gives you this error message and the client tells you, that your CMW server is down (also you know it is not), then you are exceeding the maximum data size which can be transmitted. The maximum size of the data packet, which can be transmitted by CORBA is set via the giopMaxMsgSize parameter. The default value in omniORB is 2 MBytes. The value can be changed by editing the omniORB configuration file /etc/omniORB.cfg on the FEC. According to the omniORB 4.1 User's Guide it can also be changed via environment variables (export ORBgiopMaxMsgSize=xxxxx) or command line parameters. These two possiblities have not been tested yet. Furthermore there seems to be an absolute maximum value. Setting giopMaxMsgSize to 30 MBytes or 100 MBytes always resulted in a maximum size of 20000000 (i.e. twenty million bytes) used by the CMW server.

Undefined device name in FESA navigator

In the FESA navigator you get an error message:

IOError Exception.
Category :: FESA_FWK
Code :: -1
Details :: null
Message :: AbstractEquipmentInterface::getEqpIntfFromDeviceName: undefined deviceName <...>

In this case, the device name specified in the file classDeviceData.xml, which is read by your class on the FEC, does not match the one in the database. This means, you got the wrong DeviceData.xml file. Recreate the file with Fesa Instantiate. If you are working with multiple FECs, see also Deploying on multiple FECs in the HowTo section

Compiler errors in GENERATED code

If the compiler issues errors in code generated by Fesa, usually when accessing fields, there most probably is a name clash between a data name in your design and a member in the Fesa classes. For example, having a two-dimensional character array with the id 'name' in the design resulted in errors under Fesa 2.10.

You can't subscribe to a property via RDA

In the 'SimpleClient' example from Alex, it is shown how to subscribe to a Fesa property via RDA within C++. It is important, that the firewall is turned off, on the computer running the C++ program.
I experienced the behaviour, that the subscribe was succesfully done, but a value sent by Fesa (or the middleware?) was not accepted by my computer, because the firewall was on. It seems, that different ports are used, so turning off the firewall is the easiest solution to avoid this problem.
Rainer