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.
martin_triska
@martin_triska
Best posts made by martin_triska
-
RE: Need Some sort of Jumpstart
-
RE: nginx not running
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; } }
Latest posts made by martin_triska
-
RE: Hardware mappings on a non-debian distro
Hello @tsandrini ,
first of all, we appreciate your effort which confirms us the open-source approach is the best way :-).
To your question:
-
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 byunipi-os-configurator
based on the identification stored in the internal EEPROM (and accessible viaunipi-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. -
Anwer is in the previous text - appropriate driver(s) for Unipi-specific hardware are loaded automatically based on the devicetree (devicetree overlay) nodes.
-
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?
-
-
RE: Install docker on a Unipi Patron
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.
-
RE: Patron: Get CPU serial number
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.
-
RE: Wrong device model in EVOK (Patron)
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.
-
RE: Retrieve PLC coprocessor board status programmatically
Hello @romainletendart ,
as the first point, let me briefly describe the device architecture:
- Every Neuron device consists of one, two or three coprocessor boards. In the device-tree overlay, the full three-boards configuration is always supposed.
- 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).
- This routine is invoked at driver load only - ie. at the boot time.
To your questions:
- There is no way how to check the presence of a non-coprocessor board. These boards are just simple I/Os without any "intelligence".
- In case a co-processor board does not present at the boot time, no sysfs structure is created for this io_group.
- 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.
- 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.
-
RE: EVOK shows no I/O - Neuron L513
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!
-
RE: Latency measurements
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:
-
RE: Problem with running Evok on Unipi 1.1 + RPI4
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.
-
RE: Problem with running Evok on Unipi 1.1 + RPI4
Hello @marioverhaeg,
I have replied you on your email - please provide us with more info. Then, I copy the right solution to this topic.
-
RE: How to use EMO-R8 directly ?
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)?