<< to CrossControl homepage

Support & Service Center


The following articles apply to the ARM-architecture as used in the hardware platform XC, XA and XS.

VNC server on CC displays

Virtual Network Computing (VNC) allows someone to remotely view and control a computer, or in this case a display. Each of our CCpilot displays can be extended with a VNC server which means you may remotely connect and control the display from a VNC Client. The VNC server has been developed to be a standalone service, without use of Qt or other services.

Attached to this article are installation archives for each of our units. The ZIP-files contains the following:

  • Installation instructions (README)
  • Documentation (WORD)
  • Archive for installation on target

The different display units use the same general SW but needs some specific options to be able to handle the difference in screen sizes. The following options are available:

  • single-touch = only valid for our iMX5 units as they can only use single touch
  • touch-device = touch device to be used (Default: /dev/input/touchscreen0)
  • port = port number to connect to (Default: 5900)
  • passwd = password to view server data (Default: No passwd used)
  • viewonly = no input to server possible
  • verbose = turn on VNC server logging
  • x-scale = x-scaling for the unit (Default: 125)
  • y-scale = y-scaling for the unit (Default: 125)
  • invert = invert x/y scaling (only needed for CCP VC)
  • fps = number of fps (Default: 2)

To connect to the VNC server in the CC display you will need to start a VNC client/viewer on your remote device and connect to the CC display with the IP address. You should see the display screen mirrored on your VNC client and be able to control the display from the VNC client. The documentation shows how to use the VNC viewer in our virtual machine (LinX SW Suite v4).

Known limitations:

Startup delay

When auto starting the VNC viewer at reboot/power up, the touch drivers are not ready to be used. There is a need to add a delay to the startup script. Add the line "sleep 3" before starting the VNC server!


The VNC viewer used in our VM environment will show the screen contents of the VI2 rotated. And as the VI2 has no touch, it is not possible to control the screen contents.


The VNC viewer used in our VM environment will not show the screen contents of the X900, but the mouse presses will be translated as correct touches on the target. But you can’t see what changes on screen. This is due to some configuration in the X900.
Information about this will be added later.


For the iMX8-platform you need to use the vivante-driver (eglfs_viv) that uses the framebuffer to get "our" VNC server to work correctly. The document included in the ZIP will described this in more detail.


The XM2 Linux OS installation contains the service "x11vnc". The service works ok, if it is started from the command line in a terminal. If the service is added to autostart, the first connection from a VNC client works fine. But there is a problem to reconnect, if the client is closed and restarted. The session will then not reconnect.
Information about how to solve this will be added later.

Environment and Versions: 
LinX SW Suite v4

OPC-UA in Qt 5.12

QT Open62541plugin is available under open source license starting from QT 5.13.1.
Our newest non engineering release at the moment is 5.12 and we don’t have the commercial automation package
available in this version. But OPC Open62541 QT plugin has been added in QT 5.12 as a "technology preview".
Though, the plugin is not built by default, it can be built into the Qt 5.12 release.
Follow the instructions below to build the plugin (VI2 used in this example).

In LinX VM 4.0.3, clone the git repo:
ccs@LinX-VM:~/git$ git clone http://code.qt.io/qt/qtopcua.git
Cloning into 'qtopcua'...
warning: redirecting to https://code.qt.io/qt/qtopcua.git/
remote: Counting objects: 7848, done.
remote: Compressing objects: 100% (3881/3881), done.
remote: Total 7848 (delta 4887), reused 6344 (delta 3892)
Receiving objects: 100% (7848/7848), 2.39 MiB | 1.84 MiB/s, done.
Resolving deltas: 100% (4887/4887), done.

Then run qmake to configure the stuff for VS/VI2
ccs@LinX-VM:~/git/qtopcua$ /opt/VI2/sysroots/x86_64-linux/Qt-5.12.0/bin/qmake
Info: creating stash file /home/ccs/git/qtopcua/.qmake.stash
Info: creating cache file /home/ccs/git/qtopcua/.qmake.cache
Running configuration tests...
Checking for Open62541... no
Checking for Unified Automation C++ SDK... no
Done running configuration tests.
Configure summary:
Qt Opcua:
  Open62541 .............................. yes
  Unified Automation C++ SDK ............. no
  Support for namespace 0 NodeId names ... yes
  Namespace 0 NodeIds generator .......... no

Qt is now configured for building. Just run 'make'.
Once everything is built, you must run 'make install'.
Qt will be installed into '/opt/VI2/sysroots/cortexa9hf-neon-poky-linux-gnueabi/opt/Qt-5.12.0'.

It will not detect Open62541 or UA C++ SDK in the VS/VI2 image, which is correct since the libraries are not included in the image.
But the Qt module has 3rd-party library code for Open62541 and will compile this.

Now run "make" and "make install" to install to VS/VI2 SDK folder.
Then use qmake to build examples:
ccs@LinX-VM:~/git/qtopcua/examples/opcua$ /opt/VI2/sysroots/x86_64-linux/Qt-5.12.0/bin/qmake 
ccs@LinX-VM:~/git/qtopcua/examples/opcua$ make -j6 

This seems to work fine for the default Qt 5.12.0 included in the VM and Qt libraries we provide for VS/VI2.
To transfer the built libraries to the target (target IP = x.x.x.x), use the Linux command ‘rsync’:
$ rsync -av /opt/VI2/sysroots/cortexa9hf-neon-poky-linux-gnueabi/opt/Qt-5.12.0 ccs@x.x.x.x:/opt

Link to OPC-UA info on Qt Homepage

Environment and Versions: 
LinX SW Suite v4.0.3 iMX6 (VS/VI2)
Applies to version: 
Qt 5.12 (or higher)

Switching CODESYS Visu page/frame with HW buttons on CCpilot VI2

Default you are able to change between Visu pages by changing the Default Hotkeys in the Visualization Manager settings. For CCpilot VI2 the assigned keys are, C,D,E,F.

This application shows how the state of the hardware buttons on the CCpilot VI2 can be read and used in the GUI. By clicking the different HW buttons a new Visu Frame/page is shown. The project uses the cc-aux interface to handle the states of the buttons. The state is then available from the GUI.

Extract from included PLC_PRG
// Read the state of the hardware buttons from cc-aux api with Button_GetValues.
IF firstTime THEN
	eError := About_GetNrOfButtons(numbuttons=>numberOfButtons );
	firstTime := FALSE;
IF eError = ERR_SUCCESS AND numberOfButtons > 0 THEN
	eError := SoftKey_GetStatus(value=>frontButtonValues);
	CASE frontButtonValues OF
		1: framePage := 0; 
		2: framePage := 1; 
		4: framePage := 2; 
		8: framePage := 3; 
Environment and Versions: 

ARM imx6 Linux

Applies to version: 
OS Image

Stream ETH-Video from Display to Display or VM to Display

It can be useful to stream video from one display to another, or from the VM to a display.

For example, if you want to test that your application processes ETH-Videos correctly, but you don't have the actual camera, you could use one of the following two commands from the Virtual Machine (or from one of the displays used in the setup):

Example 1:

This pipeline will jpeg encode a videotestsrc (a test stream) and send it to on port number 5003

gst-launch-1.0 videotestsrc ! jpegenc !  rtpjpegpay ! udpsink host= port=5003 &

Example 2:

If you instead want to stream a videofile, use this command:

gst-launch-1.0 filesrc location=myvideo.mp4 ! decodebin ! jpegenc ! rtpjpegpay ! udpsink host= port=5003

Note: Streaming a video can be very taxing on your network!

To receive any of the described streams above, use the following command:

gst-launch-1.0 udpsrc port=5003 caps="application/x-rtp,encoding-name=JPEG,payload=26" ! rtpjpegdepay ! jpegparse ! jpegdec ! autovideosink &

NOTE! The service "gst-launch-1.0" is only available on our i.MX6 units (CCP VS or VI2).

Applies to version: 

Sending SubscribeROIVideo through the terminal

Note, the following is only valid for i.MX6-based displays

For ETH cameras following the ISO17215 standard you will sometimes need to send a message to the camera for it to start sending video. The message is called SubscribeROIVideo and it takes an index as a parameter. The index is what Region of Interest the camera will stream.

This is the contents of the message:

Byte 00-01 	SOME/IP header
Byte 02-03 	Method (Subscribe ROI video)
Byte 04-07 	Length of message (only header, method och length fields)
Byte 08-09 	ClientID
Byte 10-11 	Packet nbr (if you send more than one packet in the same message, you mus increase the ID so the camera knows in which order to handle it) 
Byte 12-14 	Should always be \x01\x01\x00
Byte 15-18 	Resolution index you want from the camera

One option is to use the ETHCameraSettings library to send messages with a simple interface.
See the following KB article on how to use the ETH Camera library: Using the ETH Camera settings library

The other way is to use the echo command and add that to a script.

The command we will be using is:
echo -n -e '\x43\x3f\x01\x31\x00\x00\x00\x0c\x12\x34\x56\x78\x01\x01\x00\x00\x00\x00\x00\<Index as byte>'>/dev/udp/<Camera IP>/<SOME/IP communication port>
For example to subscribe to ROI 6, on a camera with IP and SOME/IP port 17215:
echo -n -e '\x43\x3f\x01\x31\x00\x00\x00\x0c\x12\x34\x56\x78\x01\x01\x00\x00\x00\x00\x00\x06'>/dev/udp/

For information on what ROI's are available on your camera and its communication port, check with your camera supplier.

Environment and Versions: 

Using Qt modal popups on CCpilot VS

The iMX6 display computers CCpilot VS and CCpilot VI2 uses a combination of Wayland, Weston and Qt that has a problem with modal popups, resulting in that a Qt application running in Weston cannot set a popup as modal.

It is possible to do a work-around to create a modal popup. A QtWidgets example is attached to this article to show three examples of modal popups on the VS.

Another approach can be to not use Weston and run a Qt application in EGLFS mode instead. A separate article describes how this can be done.

Environment and Versions: 
CCpilot VS 1.2 or higher
CCPilot VI2
Applies to version: 

File Utility Example

This example shows several possibilities of writing and reading files as well as working with directories, synchronous function calls are used.

Applies to version: 
CoDeSys Version 3.5.x or higher

Full screen applications on Qt 5.9.4

A bug in QtWayland 5.9.4 affects how Qt sends fullscreen requests to Wayland. As a result of this bug, functions such as QMainWindow.showFullscreen() does not make the application full screen - only frameless. In order to bypass the bug, the application’s resolution should be fixed to that of the screen. For QWidget based applications, do the following:

QMainWindow view;
view.resize(1280, 800);
A similar approach can be used for QML applications.
Applies to version: 

Using keyboard input in a Qt application in CClinux or newer

On devices running CClinux v1.2.0.0 or newer, Qt applications using keyboard input need to be invoked with the evdevkeyboard plugin flag enabled:

$ ./myApp -plugin evdevkeyboard
Note: In CClinux this flag is enabled by default when running applications after device startup. If invoking an application during startup (e.g. from a script in rcX.c) the evdevkeyboard plugin still needs to be passed on to the application.
Applies to version: 

Startup environment variables

During startup, the environment variables HOME and USER are set as following:

  • USER=””
  • HOME=/

If using these variables in an application which is automatically started using a startup script from any of the rc run levels, the variables might need altering. To do so, simply add the desired variable exports to your startup script. See an example below:

case "$1" in
    export USER=root
    export HOME=/home/root
    myApp &
Applies to version: