<< to CrossControl homepage

Support & Service Center


The following articles apply to the X86 architecture as used in the CrossTecc Virtual Development Environment and the Hardware-Platforms XM and XL.

Using the ETHCamerasettings library to control ETH Cameras

Target platform

VS/VI2/VC/VA, VM 4.0


  • VS/VI2 or VC/VA
  • Virtual Machine 4.0 or higher
  • IP Camera that supports ISO17215
  • Project and library files, see download link at end of page

How to use the library

How to run the example project

Installing the library

The library files for the different devices are included in the ZIP "ETH cam lib" (see below). To be able to build the test application in the VM, you must install the libraries in build environment. The ZIP contains a simple instruction of the steps that are needed to get this working.

In order to install the library on target, put the library files (so-files) in /opt/lib on your device (VS in this case). Then update the library cache file by executing:

sudo ldconfig -C /opt/etc/ld.so.cache

Alternatively, you can put the files anywhere you want and then set the environment variable $LD_LIBRARY_PATH to that location. For example:

export LD_LIBRARY_PATH=/home/ccs/mylibs

How to use the library

First we need to instantiate the class

#include "ethcamerasettings.h"
ETHCameraSettings m_ipCamSettings = new ETHCameraSettings(m_camIPAddress, m_camPortNumber, m_clientID);

Then we open the API torwards the camera and check the return code for errors

ETHCamStatus status = m_ipCamSettings->open();
if(status != E_OK)
	//Do error handling here

Now we can send our commands to the camera. For example, to get the camera datasheet

//Create a Datasheet struct
Datasheet datasheet;
if(status == E_OK)
	//Process datasheet struct here

Once we are done we need to make sure it is closed and then delete it.

ETHCamStatus status = m_ipCamSettings->close();
if(status == E_OK)
	//It is closed, now we can delete it
	delete m_ipCamSettings;

For a complete list of library functions see the full documentation.

Running the example project

You can download the example project at the top of the article

Extract and open the example project with Qt creator

In the example project, go to main.cpp

At the top of the file enter the camera IP address and its communication port number. Note that the communication port number is not the same as the streaming port!


You can now run the application and should see something like this:


At the top of the application dialog there is a status box where you can see the IP address, port number, what operation you have called and the status code for that operation.

Now make sure your IP camera is running.
For information on how to use gstreamer to view the camera stream see this article on the knowledgebase.

If you for example press Subscribe Index: 0 your dialog should look like this, provided everything went well.


You can now see that our operation SubscribeROIVideo received the status code E_OK which means the operation went well. For a description all the possible status codes, see the documentation. Note that your camera might not support all the methods available in the library, its likely that the camera will return the status code E_UNKNOWN_METHOD if that particular method is not yet implemented.

Package icon ipcamsettingsqmlexample.zip8.87 KB
Package icon eth_cam_lib.zip412.1 KB

Qt - Persistent variables

The posted example below shows how to use the QSettings class in Qt to setup persistent variables. Persistent variables will persist or keep their value past a display restart or shutdown. This is very helpful for variables you want your application to remember or keep past shutdowns. This could be something like a user password or a user profile. You don't want the password a user setup or their profile to be reset at each display shutdown which would require the user to re-enter the values each time the display is shutdown. For these variables you can set them as persistent variables and have the display remember their last value.

To use the example, download and copy the attached .tar file into the Virtual Machine. Extract the files and open the .pro file in Qt. Build and run. This example should work for both ARM and x86 based devices although the x86 kit will need to be added and the application recompiled for x86 devices.

Binary Data persistent_variables_demo.tar_.gz166.98 KB

Qt - Analog Video Example

The posted example below demonstrates how to setup and show an analog video channel on the displays.  This particular example was done on a VA display but it should work on all displays.  As mentioned in code commenting, on the X-series displays, the display can power the video camera by a 5V output.  I have shown how this can be accomplished in code but commented it out.

While the posted example is quite simple and shows how to setup, show and hide a single video channel on a screen there is a lot that can be done with video on the display platforms.  For example, video can be cropped, mirrored, rotated and scaled.  You can also set it to allow for graphics overlays.  For a full list of available video functions please review CCAux documentation, specifically fuctions available in 'Video.h'.

To use this example, copy the attached .tar file to your Virtual Machine, extract files and load the .pro file into Qt. Build and load onto an ARM based display. If using an x86 based display you will need to add the x86 kit and recompile.

Binary Data video_demo.tar_.gz360.28 KB

XM2 CODESYS - Full Screen and removing the mouse pointer

By default, CODESYS on the XM2 will show up as a window and instead of taking up the entire screen.  There will also be a mouse pointer shown.  This article shows how the user can make CODESYS appear full screen and without a mouse pointer.

  • Log into the device
  • Type 'cd /usr/bin'
  • Type 'mount -o remount, rw /'
  • Type 'nano mini-x-session'
  • Scroll down with the arrow keys and modify the last line of the file to say 'exec matchbox-window-manager –use_cursor no –use_titlebar no'
  • Once complete, save the file with ctrl+x. It will ask you if you want to save and overwrite the file.
  • Type 'mount –o remount,ro /'
  • Reboot the display by typing 'reboot'

Once rebooted, CODESYS should appear as a full screen application without a mouse pointer. 

Note: This seems to cause the CODESYS window to be offset slightly.  You can fix this by making the y position of the CODESYS application a negative value.



Environment and Versions: 


Hiding the mouse pointer and window frame on x86 devices (XM / XM2)

On x86 based devices running Qt there is a border that will appear around the main application by default.  If you do not want this border to appear you can add this code to your main.cpp file:

	Application w;
	// uncomment this line to remove window frame

And if you don't want the mouse pointer being shown you can add this to the main.cpp file:

	QApplication a(argc, argv);
	a.setOverrideCursor( QCursor( Qt::BlankCursor ) );
Environment and Versions: 

x86 Devices (XM / XM2)

Valgrind use in the Virtual Machine and ARM platforms

Valgrind is a tool for memory debugging, memory leak detection, profiling and threading bugs.  It is a commonly used tool to check and resolve memory leaks and performance bottlenecks.  We have Valgrind installed in the Maximatecc Virtual Machine by default.  We do not have it installed on the Linux ARM platforms by default but the files and instructions in this article will instruct how to install into the ARM platform.  It should be noted that running Valgrind on the ARM devices is very slow and it will be difficult to perform a full profile and analysis of a sufficiently large application on the ARM device itself.  Due to this, we recommend running and checking the application in the Virtual Machine where it will be much faster.  Pieces of code that must be checked on the display (eg. CAN, IO etc) can be split off from the main application if possible so only a small piece of code is checked.

Attached to this article you will find a PDF 'Profiling application code with Valgrind for Linux' which summarizes the process of checking application code with Valgrind as well as provides some best practices.

Installing Valgrind on the ARM platform:

  • Download the 'valgrind_arm.tar.gz' file attached to this article and copy over to the '/opt' directory of the display (via 'scp' or FileZilla)
  • Extract the file with 'tar -xf valgrind_arm.tar.gz'
  • Download the 'lib_nonstripped_arm.tar.gz' file
  • Re-mount the file system as read write with: 'mount -o remount,rw /'
  • Copy the 'lib_nonstripped_arm.tar.gz' file to the '/lib' folder of the OS
  • Extract the file: 'tar -xf lib_nonstripped_arm.tar.gz'
  • Sync the libraries with the 'sync' command
  • Re-mount the filesystem back to read only: 'mount -o remount,ro /'

After the above commands you should be able to use valgrind as demonstrated in the PDF (eg. '/opt/valgrind/bin/valgrind -tool=callgrind...)


Valgrind will only run applicatinos built for the platform it is installed on.  So, for instance, you will not be able to check applications with Valgrind built for the ARM platform inside the Virtual Machine since these are different platforms.  You will either need to check the ARM binary on the ARM device itself (which as mentioned above is very slow) or rebuild the application for the Virtual Machine and then you can check the application with Valgrind inside the VM.



QML with SocketCAN

There are many ways to work with CAN messages within the LinX software suite. Most customers using Qt will likely want a full J1939 CAN stack with all of the lower level protocols the J1939 stack includes. In this case you will want to check out the FieldBus Access tool developed for the LinX software suite. In some cases though a full J1939 CAN stack is not needed and you may only want to receive a few CAN messages or custom CAN messages that don't adhere to the J1939 stack protocol. In this case you may choose to use the lower level socketCAN interface in the Linux displays to receive raw CAN messages. This demo shows how socketCAN can be used with Qt QML code.

The demo simply takes in raw CAN data from socketCAN, sends to a custom class to be decoded and once decoded is displayed on QML UI. It provides the correct classes to receive and send CAN messages with socketCAN as well as shows how a custom class can be created and interfaced to QML so you can decode the raw CAN data into useful messages and display them on your UI. The code is commented to attempt to explain what each piece is accomplishing.

To use, download the attached file and extract in the LinX Virtual Machine. Open the '.pro' file with Qt and deploy to the display. You will need the updated LinX RT for this to work (it has been tested on ARM based displays although it should work with x86 displays if you add the appropriate kit). The message that is being displayed on the QML UI by default is the 'Engine Speed' message from PGN '61444' in the standard J1939 message list.



Binary Data SocketCAN shown with QML789.88 KB

Showing PDF files in Qt

Showing PDF files in Linux and Qt can be accomplished in several different ways.  One of the more popular ways is to use a program called Poppler to load and view PDF files.  In our experience, using Poppler on the ARM based displays is a bit slow to load and scroll through the file.  Because of this we have designed our demo application to utilize a Linux application called 'pdftocairo' which converts PDF documents to images (or other formats).  Some basic information on 'pdftocairo' can be found here: http://manpages.ubuntu.com/manpages/trusty/man1/pdftocairo.1.html.

In the attached demo application, it will scan for PDF documents in the '/opt' directory of the display.  If there are any PDF documents available in that directory it will list them in the list widget in the application.  Once a document is selected the user will have the option to 'Load' the document.  If this is the first time the document is loaded it will 'cache' the document which means it will use the 'pdftocairo' application to save each page of the PDF as an image.  Depending on the size of the PDF document this may take between 30 seconds and 5 minutes to cache the document.  Once cached the document will show on the screen.  The user can zoom, change pages and scroll through the page by dragging their finger on the document.  Once cached the document will load quickly on successive loads (1-2 seconds) and will not need to be cached again unless the cache is deleted.  There are some comments in the code that suggest how the initial cache time could happen in the background without freezing the display as is done in the application.

To load PDF specific libraries and applications onto the display:

  • Download the 'pdfViewer_v0.0.2.tar.gz' file from the attachments below and copy the file onto the '/opt' directory of the display
  • Log into the display via the terminal, navigate to the '/opt' directory and extract the file with 'tar -xf pdfViewer_v0.0.2.tar.gz -C /opt'
  • Once extracted, type 'ldconfig -C /opt/etc/ld.so.cache' to update the library references

Note: The LinX runtime must be installed for this to work as instructed above.  If it is not installed you can create the required library directories before installation or install the LinX RT first.

To load the PDF demo on the display (The PDF specific libraries and applications must be loaded from instructions above for the demo to function):

  • Download the 'PDF_Test.tar.gz' file and transfer over to the virtual machine
  • Extract the 'PDF_Test' folder and open the '.pro' file within that folder with Qt
  • Build the demo for the display of choice and deploy to the display (note: there is a compiled binary called 'PDF_Test' located in the folder for ARM based displays)

There is also a standalone PDF viewer in the PDF specific libraries and applications.  The 'readme.txt' file briefly describes its use.

Finally, there is a lot of information on the internet and free applications available for viewing PDF files in Qt.  Here is a good resource for free apps for Qt: http://qt-apps.org/ 



IP Address Configuration

By default, the network interfaces of all CCpilot and CrossCore units use DHCP, i.e. they acquire their IP address automatically. The devices broadcast their IP address on the local network (please see here on how to detect the units from your PC).  For the device to aquire an IP address in this mode it requires a DHCP server.  These can be found in all routers and some switches and other devices.  An easy way to have the device aquire and IP address and connect to it with your computer is to hook both the device and your computer to the same router.  This can either be a work network or a single stand alone router. 

If your network policy does not allow those information packets to pass through, you can configure a static IP address instead.

There are a two different ways this can be done:

  1. Attached to this article there is a file 'cc-auto.zip' that will allow you to set the IP address mode (static / dynamic) and settings and insert the file into the display via USB.  The script file will automatically update the IP address settings.  Instructions for use are contained in the file itself (cc-auto.sh).
  2. Connect to the display using DHCP and change the mode manually to a fixed IP address.  In order to do this, you need to access the unit once through the network using DHCP. So you need to connect both the unit and your PC to for example a router or another network which do not restrict the trafic. After connecting to the unit through SSH (an application called 'Putty' is useful here), you can edit the interfaces file and change it according to your requirements. You should contact your IT department to get a dedicated static IP address you should use.

To edit the interfaces file, first unlock the OS with

# mount -o remount,rw /
Then edit the 'interfaces' file using the simple text-editor, nano.
# sudo nano /etc/network/interfaces

Sample of 'interfaces' file, changing from dhcp to static IP address (in this example:

Original (DHCP):

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet dhcp

Changed (Static IP):

auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static

Once the file has been edited, re-lock the OS with:

# mount -o remount,ro /
it is recommended to either reboot the device, or to bring the network
interfaces down and up again, for the IP address configuration to take effect.
# sudo ifdown eth0
# sudo ifup eth0

There is plenty of information on the internet about usage of the interfaces file and how to use it.


Resetting the IP Address to DHCP with USB

Sometimes due to improperly setting the static IP or other issues it may be necessary to reset the IP configuration back to its original state. This will reset the networks file back to a DHCP type network. Once this is done you may use the attached USB file below to change the display back to a static type configuration.

To complete this, download the 'IPAddress_DHCP_Reset.zip' file below. Extract both files in the zip file to the root directory of a USB and insert the USB into the display. When the display reboots remove the USB. Once it has booted back up it should be reset to a DHCP type connection. You may then use the other zip file attached to this article and the instructions above to set the display back to a static address if desired.

Finding the IP address of a CCpilot

Many times, and for many different use cases, you may want to know the IP address of a display on your network.  It is often recommended to set the IP address as a static IP so you will always know the IP address of the display (instructions for this here: http://support.crosscontrol.com/kb/ip-address-configuration).  In cases where the IP address is dynamic, and therefore can change, you may need to find the IP address of a display on your network or may want to display the IP address in a Qt or CODESYS application to your user.  In this article we provide two different tools.  One for finding an IP address of a display on your network and the second for writing the IP address to a text file on the display.

Capturing IP address in file on display (recommended)

The instructions below will describe how to install some scripts onto the display.  Using the USB auto installer these scripts will automatically install when you insert the USB into the display.  When complete the display will beep, at this point remove the USB.

Once installed, a script called 'GetIP.sh' will be placed in the '/opt' folder of the display.  This script will pull out the IP address of the display, if it has one, and put it in a file named 'IP.txt' in the '/opt' folder of the display.  The script is set to auto execute on boot up so when the display boots the text file 'IP.txt' should be updated with the IP address.  The script is only set to run for 30 seconds before quitting to avoid an infinite script execution so if no address is found you may execute the script again manually or from a Qt or CODESYS application.  

Assuming the display has an IP address it will be written to the 'IP.txt' file in the '/opt' folder.  You can then read the contents of this file inside your CODESYS or Qt application to display the current IP address to a user.  Alternately, you can use the 'PullIP.zip' file below to automatically execute the 'GetIP.sh' script and then copy the 'IP.txt' file to your USB drive when inserted into the display.  This is helpful in cases where you are not sure of the IP address of the display and want to find it.

Install the IP Address writer to the display:
  • Download the 'IPScript.zip' file below and extract all contents onto the root directory of a USB drive.  Insert the USB into the display.  After you hear a beep emit from the display, remove the USB.
Find a lost IP:
  • Download the 'PullIP.zip' file below and extract the 'cc-auto.sh' file onto the root directory of a USB.  Insert it into the display.  After you hear a beep emit from the display, remove the USB.  There should now be a file located on the USB called 'IP.txt' which should contain the IP address of the display.  

           Note: You will first need to install the 'IPScript.zip' file described above for this to work

Find display IP from your computer on the network

Each CCpilot unit broadcasts its IP address on the Ethernet network using UDP multicast.  The attached tool 'cc_ipcatcher.zip' lists all those units in an simple interface.

To use the tool, simply download the zip file and extract anywhere on your computer.  Run the tool.  No installation is required.

We have noticed that having Oracle VirtualBox installed may cause the messages to not reach the host PC.
If no units show up and you have VirtualBox installed, please try a different computer or disable the VirtualBox network driver.


Package icon cc_ipcatcher.zip5.07 MB
Package icon ipscript.zip1.42 KB
Package icon pullip.zip303 bytes