Posts made by martin_triska

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)?

Hello @Stoeffel ,

it seems that you access the serial (RS485) line from multiple applications which confuses Evok. Can you try to disable other processes potentially working with HW and leave running Evok only?

Hello @smontosa,

please try to download the current version 2.4.10. The issue should be fixed. Please note that watchdog settings (same as other parameters) are stored in RAM memory by default. To burn it into non-volatile memory (FLASH), use the appropriate coil 1003 or call the separate REST request on the same endpoint with parameter nv_save=1.

Hello @Stoeffel,

the issue should be fixed in the current release. Please upgrade to version 2.4.8.

Hello @DAWaller,

can you please describe your application in more detail? Websocket connection is provided by Evok software. Node-RED uses this type of connection to communicate with the I/Os.

Do you see the connection outages from Node-RED running on the same unit?

What displays the Node-RED debug console?

Hello @mglowinski,

sorry, but this feature is not supported in Unipi 1.1 series products. Please consider buying Neuron/Patron series PLCs which can do it.

Hello,

unfortunately, the Unipi 1.1 does not have a watchdog device. You can see all available devices/circuits in reply to the "all" GET request. Example (can be invoked from your web browser):

http://<your_unit_IP>:8080/json/all

Hello @Achilleas-Kotsis ,

thank you for your detail report!

We check this and will get back. With the previous version of unipi-kernel-modules package, the issue never appears?

How did you simulate the issue in the listing above? By a loopback using the other serial?

Hello @mglowinski,

Pins RXD0 a TXD0 (GPIO14/GPIO15, pins no. 8 and 10) -> primary UART are connected to the RJ connector.

The most simple test is to install a terminal application ( e.g. minicom) and probe the UART in loopback mode.

From RasberryOS, you can manipulate the UART using the raspi-config utility.

Instruction how do disable BT or redirect it to Mini UART can be found on the link above.

Hello @mglowinski,

what OS Image and Rasberry Pi generation do you have?

You have to take into account that UART pins can be shared with Bluetooth and there are two types of UART
available (full-featured and the limited one).
More detail info about the Raspberry’s UARTs can be found here:

https://www.raspberrypi.org/documentation/configuration/uart.md

Hello @mglowinski,

there should not be any problem. I2C devices on the same bus can be accessed from multiple processes (apps or kernel modules).