@CKB
Not sure it this might help you. But I have configured my OS to run "read-only". It helps for longer lasting SD cards and it will usually not corrupt upon power outage.

If you are interested, you might search for "Raspbian Read only".
See below my filesystems (just the main parts):

tmpfs on /run type tmpfs (rw,nosuid,noexec,relatime,size=99612k,mode=755) /dev/mmcblk0p2 on / type ext4 (ro,noatime) tmpfs on /run/lock type tmpfs (rw,nosuid,nodev,noexec,relatime,size=5120k) tmpfs on /var/cache type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /tmp type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /var/tmp type tmpfs (rw,nosuid,nodev,relatime) tmpfs on /var/log type tmpfs (rw,nosuid,nodev,relatime) /dev/mmcblk0p1 on /boot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,errors=remount-ro)

And this is /etc/fstab:

PARTUUID=7965901e-01 /boot vfat ro,defaults 0 2 PARTUUID=7965901e-02 / ext4 ro,defaults,noatime 0 1 # a swapfile is not a swap partition, no line here # use dphys-swapfile swap[on|off] for that tmpfs /tmp tmpfs nodev,nosuid 0 0 tmpfs /var/log tmpfs nodev,nosuid 0 0 tmpfs /var/tmp tmpfs nodev,nosuid 0 0 tmpfs /var/cache tmpfs nodev,nosuid 0 0

Greetings

/KNEBB

@AVsetula Ok perfect thanks you !

@Martin-Kudláček said in Upgrading to Bullseye?:

Hello everybody,
the upgrade to bullseye is planned for March.

Best regards,
Martin

March has been gone now since two months.

So I am getting the feeling there is no effort put into getting it lifted to current stable?

Would be a pitty....

/KNEBB

@Petter Using a patron M567

Hi Tad,

When making a complaint or repair, follow the complaint procedure: https://www.unipi.technology/return

In this case, however, it may not be a faulty HW, but only an inappropriate output setting:

The digital outputs on the Unipi units also enable the so-called PWM mode, where the output is controlled in a different way than during normal on / off switching. Another function that could affect the outputs in this way is the so-called DirectSwitch function.

If you work in Mervis SW, you can upload the default configuration simply by creating a new project in the Mervis IDE, assigning a PLC and uploading the Unipi module configuration.

For other SW solutions, I recommend checking the values in the Modbus registers.

To check that PWM is off, check registers 16 to 19, all of which should contain a value of 0. To check that the DirectSwitch function is turned off, check register 1014, it should also contain the value 0.

@HPC
Ok, you are right. My fault... I checked -(0.05)^0.78 instead of (-0.05)^0.78

The Mervis behavior is correct.

Thank you
Jan

P.S. Maybe it will be great to add this information into documentation. Now there is IN1 ANY_REAL which seems to me that also negative numbers are accepted.

Seems that this was a newbee error. I had the example flow still active in the project, and used a second instance of the websocket in my own flow. But seemingly, those instances conflict with each other causing only parts of message to arrive.
If I have only one instance of the listening websocket in the project, everything seems to work smoothly.

The firmware upgrade problem, however, remains. I have fw 5.58, the OS has upgraded the firmware package to 5.60 but I can't upgrade the actual firmware as the fwspi --auto command doesn't start the upgrade.

Hi,

How can i ask the holding register 1003 with mbpoll?

@AVsetula said in Reading the ModBus bus with the Patron:

To verify communication with all our Modbus devices, I recommend asking the holding register 1003, which is available for all Modbus devices Unipi and whith contains a unique identifier, according to which the device can also be recognized.

Thank you!

/Vesa

@rob
I just upgraded to unipi-kernel-modules 1.112.1.20220308~buster-1 and it looks like they fixed the error.

@Martin-Kudláček Hello Martin, I followed this tutorial and have same results as klaschudi - https://docs.docker.com/engine/install/debian/

And broken it is.

I found out I had many SPI CRC2 errors in my kernel logs.
Looking around I found this post

It turns out the stock image 20220412.0 for nodered actually ships with the broken revision 1.108 of the kernel module.
Thanks to @knebb 's instructions I was able to downgrade to v1.106 and my neuron seems to be working fine again.

I hope someone from the customer support gets to see this post and fixes the image quickly.
Guys, you have a terrific product line (I bought two neurons and some accessories over the years and I am a very happy customer), but you should really improve the regression testing before releasing: it is not the first time I have problems when trying to use an official image: see here

I might be able to provide you with some logs in case you need help in troubleshooting on older hardware (S103 S/N 109 from 2017): just contact me in the next couple of days - then I'll have to put the system back on the field.

rob

@Achilleas-Kotsis

Thanks for your hints about downgrading. Worked for me, too.

For reference the commands here:

apt install unipi-kernel-modules=1.106.1.20220308~buster-1

I got the version by apt-cache policy unipi-kernel-modules.

/KNEBB

@Martin-Kudláček

Hello Martin,

Is it possible to have while waiting for the repository, the kernel source archive 5.10.35 as well as the config file.

Regards,
Damien

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.