Maybe this will help you. I had this problem regularly with one cheap Chinese AI reader (water valve controller). Then this controller died and I bough better quality valve (twice expensive). This error disappeared and did not occur for 3 months.
So, it looks like this error may occur due to a low-quality device in the network.
Is there any method to view the ModBus queue for error analysis. Any sniffer for /dev/ttyS1 device?
I want to display the "Off" status on Axon. When we switch OS to shutdown mode (shutdown -h now), I want to turn on the green LED when the user can switch power off. So I will avoid violating the flash card and the os file system.
Can't find a solution, maybe there are some standard solutions?
Yep, thanks, found it
unipi ~ $ sudo /opt/unipi/tools/fwspi -i 0
Boardset: 0 B-1000 (v1.0)
Baseboard: 0 B-1000 (v2.0)
Firmware: v5.36
unipi ~ $ dmesg | grep UNIPISPI
[ 2.454608] UNIPISPI: UniPi Board B_1000 (L:0 U:0 C:0) at CS0 (nspi0 12000kHz) detected.
[ 2.467983] UNIPISPI: 16 User LEDs detected at nspi0
[ 2.475954] UNIPISPI: UniPi Board E_16Di_U_14Ro (L:3 U:2 C:8) at CS1 (nspi1 12000kHz) detected.
[ 2.495803] UNIPISPI: Probe did not detect a valid UniPi device at CS2
[ 2.496119] UNIPISPI: SPI Driver Registered, Major Version: Version 1.34:2019:10:03
[ 2.496737] UNIPISPI: ModBus/SPI interface /dev/unipispi (245:0) created.
[ 158.661036] UNIPISPI spi0.0: SPI transfer failed: -110
[ 2148.754015] UNIPISPI spi0.1: SPI transfer failed: -110
[ 3297.270834] UNIPISPI spi0.1: SPI transfer failed: -110
[ 3618.798812] UNIPISPI spi0.1: SPI transfer failed: -110
[ 6489.035355] UNIPISPI spi0.1: SPI transfer failed: -110
[ 8414.343493] UNIPISPI spi0.0: SPI transfer failed: -110
[12400.512183] UNIPISPI spi0.1: SPI transfer failed: -110
[12481.452324] UNIPISPI spi0.0: SPI transfer failed: -110
[13153.014346] UNIPISPI spi0.1: SPI transfer failed: -110
[14039.157003] UNIPISPI spi0.0: SPI transfer failed: -110
[15105.415528] UNIPISPI spi0.0: SPI transfer failed: -110
[16545.011297] UNIPISPI spi0.1: SPI transfer failed: -110
[16546.771363] UNIPISPI spi0.1: SPI transfer failed: -110
[18041.752730] UNIPISPI spi0.1: SPI transfer failed: -110
[20890.498278] UNIPISPI spi0.1: SPI transfer failed: -110
[21524.030638] UNIPISPI spi0.1: SPI transfer failed: -110
[23903.903012] UNIPISPI spi0.1: SPI transfer failed: -110
[24528.342008] UNIPISPI spi0.0: SPI transfer failed: -110
[24859.480110] UNIPISPI spi0.0: SPI transfer failed: -110
unipi ~ $ fwspi -i 0
-bash: fwspi: command not found
unipi-common/stretch,now 1.2.12~stretch arm64 [installed,automatic]
unipi-firmware/stretch,stretch,stretch,now 5.40 all [installed]
unipi-firmware-tools/stretch,now 1.2.12~stretch arm64 [installed,automatic]
unipi-kernel-modules/stretch,now 1.34.1.20190926~stretch arm64 [installed,automatic]
unipi-mervis-tools/stretch,stretch,stretch,now 2.1.3.16~stretch all [installed]
unipi-modbus-tools/stretch,now 1.2.12~stretch arm64 [installed]
I have a regular problem in the logs. See the message "SPI transfer failed". Occurs on AXON and Neuron. Looks like it's related with ModBus devices, maybe with modbus timeouts.
But tonight I got a completely broken system, heating and the system is halted. Received 2 Gb (Two Gigabytes) log with the same messages:
Nov 19 06:26:11 kernel: [2021088.218536] UNIPISPI spi0.0: SPI transfer failed: -110
Nov 19 06:26:11 kernel: [2021088.218574] spi_master spi0: failed to transfer one message from queue
Nov 19 06:26:11 kernel: [2021088.242536] spi_master spi0: spi0.1: timeout transferring 6 bytes@12000000Hz for 24(20)ms
Any recommendations tuning the system?
FIxed in EVOK 2.1.6. Thanks.
But all aliases were deleted. I had to configure all aliases again.
After upgrade Neuron M103 (apt-get upgrade) with 8 real relays appeared new relays in EVOK. Now I see unworked relays 2.09-2.16, additional Analog Input 1.02 and 8 ULEDs. Looks like all ports mirrored. When I enable relay 2.01 the relay 2.09 automatically turns on.
Any idea how to fix that?
neuron-kernel/stretch,now 1.34.1.20190819~stretch-1 armhf [installed]
evok/stretch,now 2.1.4~stretch armhf [installed]
unipi-common/stretch,now 1.2.12~stretch armhf [installed]
unipi-firmware/stretch,stretch,now 5.40 all [installed]
unipi-firmware-tools/stretch,now 1.2.12~stretch armhf [installed]
unipi-modbus-tools/stretch,now 1.2.12~stretch armhf [installed]
unipiap/stretch,stretch,now 0.2 all [installed]
Neuron, after apt-get upgrade
$ sudo /opt/unipi/tools/fwspi -i 0
Boardset: 0 B-1000 (v1.0)
Baseboard: 0 B-1000 (v0.6)
Firmware: v5.27
sudo /opt/unipi/tools/fwspi -i 1
Boardset: 1 E-8Di8Ro (v1.0)
Baseboard: 1 E-8Di8Ro (v0.2)
Firmware: v5.27
It was the last year with all versions. Just now want to fix this, because all the logs with these errors. Neuron and AXON have the same latest versions, the difference is only in the packages "axon-kernel-*".
dpkg -l | egrep "unipi|mervis|evok|axon|neuron"
ii axon-kernel 4.14.20190801 arm64 transitional package
ii axon-kernel-image 1.20190926~stretch arm64 Linux kernel for UniPi Axon controller
ii evok 2.1.4~stretch arm64 UniPi API based on the Tornado webserver
ii mervis-runtime 2.1.3-9 arm64 Mervis runtime for Arm on Debian systems
ii unipi-common 1.2.12~stretch arm64 Common utilities for Unipi/Neuron/Axon
ii unipi-firmware 5.40 all Firmware files for UniPi Neuron/Axon boards
ii unipi-firmware-tools 1.2.12~stretch arm64 Firmware utilities for UniPi Neuron/Axon controllers.
ii unipi-kernel-modules 1.34.1.20190926~stretch arm64 UniPi Neuron/Axon kernel modules
ii unipi-mervis-tools 2.1.3.16~stretch all Unipi support tools for Mervis runtime on Debian systems
ii unipi-modbus-tools 1.2.12~stretch arm64 Modbus server for UniPi Neuron/Axon controllers.
$sudo /opt/unipi/tools/fwspi -i 0
Boardset: 0 B-1000 (v1.0)
Baseboard: 0 B-1000 (v2.0)
Firmware: v5.36
$ sudo /opt/unipi/tools/fwspi -i 1
Boardset: 8 E-16Di_U-14Ro (v1.0)
Baseboard: 3 E-16Di (v2.0)
Firmware: v5.36
sudo /opt/unipi/tools/fwspi -i 2
Unable to create the arm[2] context
In the Neuron and AXON I have a lot of the same errors (1000+ per day) in /var/log/messages
Oct 11 14:47:05 control kernel: [183869.394758] spi_master spi0: spi0.1: timeout transferring 4 bytes@12000000Hz for 24(20)ms
Oct 11 15:10:30 control kernel: [185274.808880] spi_master spi0: spi0.1: timeout transferring 16 bytes@12000000Hz for 24(20)ms
Oct 11 15:20:23 control kernel: [185867.652716] spi_master spi0: spi0.1: timeout transferring 16 bytes@12000000Hz for 24(20)ms
Any idea, how to fix that? Can't find any info in web...
I have found trouble with nodered "UniPi output" block in connection with Analog Output mode.
I use Analog Output 1.01 with Current configuration, where sending 4-20mA to the valve. But in "UniPi output" block we see the limits:
Details for the Analog output input msg:
Number - in the interval <0;10> returns the input number, <0 returns 0, >10 returns 10.
So, when I send a 20mA to fully open a valve, this valve received only 10mA, because your module has limits.
How can I fix that?