Hello @knebb, as @ntd wrote there is no need to use the Evok (which is, basically a bridge between Modbus server and several web-service interfaces). The simplest option for direct access from a C/C++ application should be the sysfs interface. Of course, a Modbus client connected to the internally running Modbus server can be used also.

OK, now it is a bit clearer. You probably did not insert TCP port while you have been asked for it during the installation process. Default values within the file are:

upstream evok {
        server localhost:8080;
}

server {
	listen 80 default_server;
	server_name  _;

	#ssl on;
	#ssl_certificate      /etc/nginx/democert.pem;
	#ssl_certificate_key  /etc/nginx/democert.key;

	#access_log  /var/log/evok.access.log;
	access_log  off;
	root /var/www/evok;

	location / {
	    index index.html;	    
	}
	
	location /favicon.ico {
		alias /var/www/evok/favicon.ico;
	}

	location /ws {
		proxy_pass http://evok;
		proxy_set_header Host $host:$server_port;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_buffering off;
		proxy_cache off;
		proxy_read_timeout 180;
	}

	location /rest {
		proxy_pass http://evok;
		proxy_set_header Host      $host:$server_port;
	}
	
	location /json {
		proxy_pass http://evok;
		proxy_set_header Host      $host:$server_port;
	}
	location /bulk {
		proxy_pass http://evok;
		proxy_set_header Host	$host:$server_port;
	}
	location /rpc {
		proxy_pass http://evok;
		proxy_set_header Host	$host:$server_port;
	}
	
}

Hello @tsandrini ,

first of all, we appreciate your effort which confirms us the open-source approach is the best way :-).

To your question:

1. Yes, you have to apply the appropriate overlay(s) to the "base" device-tree in order to tell the unipi kernel modules what kind of hardware (I/O boards) is present. Every model of the PLC (e.g. S103, L523, ...) has a separate overlay located in the package unipi-os-configurator-data. In a standard OS Image, this stuff is invoked automatically by unipi-os-configurator based on the identification stored in the internal EEPROM (and accessible via unipi-id module - see /run/unipi-plc/unipi-id, this module should be preset on all our units). Typically, this process needs two reboots - after the first of them only unipi-id is loaded in order to get the PLC model and apply the right overlay. After the next reboot, the previously selected overlay is loaded and all of the peripherals (inc. /dev/unipichannel*) should be available.

2. Anwer is in the previous text - appropriate driver(s) for Unipi-specific hardware are loaded automatically based on the devicetree (devicetree overlay) nodes.

3. Yes, the /dev/unipichannel* represents the main communication channel between the Linux and I/O boards (the second one is sysfs). This kind of device is created dynamically by the Unipi kernel modules based on values given in devicetree overlays. It is used by unipitcp as well as by the firmware upgrade tool.

Has this answer got you forward?

Hello @Unify,

prior to starting Docker on our Debian 10-based OS Images, you have to update alternative for iptables e.g.:

update-alternatives --set iptables /usr/sbin/iptables-legacy
update-alternatives --set ip6tables /usr/sbin/ip6tables-legacy

As an alternative solution, you can compile the appropriate module from the source by yourself.

The reason is that the current Linux kernel does not contain full nftables support. The next released OS Image generation (Debian 11) will have it by default.

Hello @Vesa-Kauppinen,

this has been subject to change between Linux kernel versions - the older one

cat /sys/devices/soc0/soc_uid

comes from the original iMX kernel and has been removed by NXP in newer releases. In our kernel image, we additionally preserve it for backward compatibility.

However,

cat /sys/devices/soc0/serial_number

is a "Linux standard" provided by recent NXP kernels that we recommend using as a unique identification.

Hello @Vesa-Kauppinen,

The 'dev' field describes an object type (similarly to di or relay) so the key has to be constant regardless of the PLC series. You are right, this can be a little bit confusing - it's a piece of history ;-).

Now, we will add the new field of a family containing Patron/Neuron/Axon string.

The 'dev' field fix is a breaking change of the existing API and will be subject to change within an upcoming new Major version.

Hello @romainletendart ,

as the first point, let me briefly describe the device architecture:

1. Every Neuron device consists of one, two or three coprocessor boards. In the device-tree overlay, the full three-boards configuration is always supposed.
2. During the driver-load phase (probe), the driver tries to contact all three boards (messages in the syslog come from this phase). In case of success, the driver creates the sysfs structure for every responding board (called io_groupX).
3. This routine is invoked at driver load only - ie. at the boot time.

To your questions:

1. There is no way how to check the presence of a non-coprocessor board. These boards are just simple I/Os without any "intelligence".
2. In case a co-processor board does not present at the boot time, no sysfs structure is created for this io_group.
3. This status is a link to the currently loaded device tree. As mentioned above, all three boards are still active there, so you always read the "okay" string.
4. In case the board is not found during the boot phase, no sysfs structure is created.

Maybe standard Linux SPI subsystem statistics can be useful for you, e.g.:

/sys/devices/platform/unipi_plc/io_group1/driver/spi0.1/statistics

If you provide more details about your application, I can try to give you some more specific tips.

Hello @marioverhaeg,

sorry for the very late reply. Have you already solved the issue? If so, can you please share the solution?

Thank you so much!

Hello @emomiilol ,

can you please share a set of all SW you are using for this test with its configuration?

The main reason can be the sampling rate of the A/D converter. For full resolution, there are 2-4 samples per second only. See excerpt from the MCP3422A0 datasheet:

The issue was caused by a combination of 64bit Linux kernel and bundled pigpio subsystem (used for peripheral access). After pigpio updating, Evok works on a 64bit platform properly. This change will be part of the next release.

Hello @marioverhaeg,

I have replied you on your email - please provide us with more info. Then, I copy the right solution to this topic.

Hello @PythonRunner ,

it seems weird. There should be no traps - just one MCP23008 in the "typical" schematic.

Do you have a power supply for the EMO board strong enough?

Have you checked the functionality even with the Unipi software (e.g. Evok)?