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.

Hello @pascal37,

thank you for the information sent. Unfortunately, based on it, we are not able to determine the exact source of the issue.
Can you please check the following:

1. Again, make sure you have the latest firmware in the I/O board flashed. Type:

/opt/unipi/tools/fwspi -i 0

2. Can you confirm that the i2c-0 error in the dmesg log appears always in the moment of communication goes wrong? It seems there is a correlation (863475 seconds is almost exactly 10 days).

3. Are you sure that no other running processes access the interface (/dev/ttyNS0)? Please check also your time-scheduled tasks (e.g. executed from cron).

4. Are you sure that no noise or interference from the environment or power supply can infiltrate the unit?

As the last resort, we are able to simulate your application with the same HW, but it will be pretty time-consuming. In the meantime, please use another RS485 interface.

Hello @ktanghe,

unfortunately, on the UniPi 1.1 series (including Lite version) this feature is not supported now. We will consider adding the feature in the next version of Evok. You should prefer a user-naming (aliasing, labelling...) of selected I/Os in the upper-layer software instead of the API tool.

Hello @ktanghe

What is the PLC platform and OS Image used? Node-RED needs some other processes running on the machine to work properly. Can you check if e.g. Evok and UnipiTCP run on your PLC?

The best "quick start" is using our ready-to-use OS Images with Node-RED and all necessary tools integrated:

https://kb.unipi.technology/en:sw:03-3rd-party:nodered

Hello @janjoris,

thank you for your question. xG18 is a standard Modbus RTU device, so the simplest way is to use the generic Modbus node available in Node-red.

All necessary documents including the Modbus register map can be downloaded from the product page.

Moreover, we are working on a series of tutorials aimed at open-source tools used on Unipi products. Using Node-red together with our extension will be definitely one of the topics. The first part should be available on our website soon. Stay tuned :-).

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 @juntiedt,

it seems that the evok site configuration file has not a valid content.

1. What version of Evok are you running?
2. Did you follow the installation guide on Evok github page (section Legacy installation process using a shell script)? Note that the .deb package installation is not available for Unipi1.1[lite].
3. Can you send us the content of your /etc/nginx/sites-enabled/evok file?

Hello @Achilleas-Kotsis,

the issue is caused by kernel-headers version mismatch because one of the kernel versions has been "stashed" by the author. Therefore, the apt versioning got a little confused by this.

Please make sure you have the latest all the related packages - kernel, headers, unipi-kernel-modules-dkms:

root@UNIPI1-sn1:/home/pi#dpkg -l *kernel*
...
ii  raspberrypi-kernel         1.20190925+1-1      armhf        Raspberry Pi bootloader
ii  raspberrypi-kernel-headers 1.20190925+1-1      armhf        Header files for the Raspberry Pi Linux kernel
ii  unipi-kernel-modules-dkms  1.36                all          UniPi Neuron/Axon kernel modules - DKMS source
...

If you upgraded kernel, reboot the system. Check the appropriate version of your headers:

root@UNIPI1-sn1:/home/pi# uname -r
4.19.75-v7+
root@UNIPI1-sn1:/home/pi# ls /usr/src/
linux-headers-4.19.75+  linux-headers-4.19.75-v7+  linux-headers-4.19.75-v7l+  unipi-1.36

Then, remove the package:

apt purge unipi-kernel-modules-dkms

And install it again

apt install unipi-kernel-modules-dkms

Have you been successful with the procedure?

Hello @cvrcejir,

this item is associated with a Modbus extension. The extension can contain "emulated" UART-Over-Modbus port with this index.

However, there is no such kind of extension currently available and therefore this value has no meaning now.

Hello @pascal37,

the issue has been caused by the old version 1.62.0 of libboost-system. Our newly deployed Mervis packages 2.2.x.x are based on the Debian Buster distro where the version 1.67.0 of the package is used. It should be fixed in the dependency list now.

Can you please do apt update and try to install the package again?

Hello @derinex,

as I do not know any details about your system, there is hard to help you. B37 is a standard PID regulator without any advanced features (such as integrator limiter - anti-windup, derivation filter nor any kind of auto-tuning). You can try the following:

1. Tune-up PID parameters - e.g. try to turn off the integration (I) and derivation(D) parts or change proportional(P) gain. As an inspiration, you can see the old well-known tuning method by Ziegler-Nichols (https://en.wikipedia.org/wiki/Ziegler–Nichols_method). Unfortunately, these methods may not be sufficient for systems with significant transport delay (which is probably your case).

2. Use a regulator with more advanced structure. But, this kind of FUPLA blocks is not a part of the current version of Mervis IDE. Therefore, you have to compose it of basic blocks (or extend the B37). This approach requires a deep knowledge of the problematic.

I am sorry, but there is probably no simple ready-to-use (or plug-and-play) solution.