@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

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.

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

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.

Hello,

Unfortunately, so far we only have Neuron S103 with RPi4. This is due to higher cooling requirements and due to the different layout of connectors on RPi4.

The difference in communication speed between the variant in one box and the variant with Extension is not so important for most applications and it always depends on the optimization (number of read registers, reading period, etc.).

In general, you can assume that the speed for internal communication is 115200 bps (and higher) and the communication speed via RS485 is according to the settings, but 19200 bps is used by default due to the excellent ratio between speed and stability.

Best regards,
Antonin

Small update: check out my blog for the solution I did create https://blog.mhemeryck.com/2021-11-16/modbusbackup

Hi @romainletendart,
the serial number is available in the hostname of the PLC, which is set by the unipicheck service.

The serial number is unique per model, e.g Neuron S103, Neuron M103 and Axon L505 can have serial number 10.

Best regards,
Martin

Hi Martin,

Just for the record, we successfully menderized neuron-opensource-os_image-20210806.0 and the PLC now boots up. There seems to be an issue with u-boot 2020.01 that mender uses by default. Using version 2019.01 works just fine.

Best regards,

Romain

@knebb Try running it on lower voltage, or put another resistor in series and do the recalculation in the software.

Martin

@Martin-Kudláček :

Of course. Here you are. I set the registers and am measuring the AO port during the sleep() cycle.

#include "header.h" #include "vars.h" void main(int argc, char* argv[]) { modbus_t *modbusglob; union { uint16_t word[2]; uint32_t dword; float fl; } counter,direct; int n[9],mode; /********************************* Function **********************************/ void fieldbus_free(modbus_t *modbus) { if (modbus != NULL) { modbus_close(modbus); modbus_free(modbus); } } /********************************* Function **********************************/ modbus_t * fieldbus_new(void) { int err; modbus_t *modbus; char host[15]; int port; strcpy(host,"127.0.0.1"); port = 502; modbus = modbus_new_tcp(host, port); if (modbus == NULL ) { fieldbus_free(modbus); exit (55); } err = modbus_connect(modbus); if (err == -1) { fieldbus_free(modbus); modbus = NULL; exit (55); }; err=modbus_set_slave(modbus, 0); if( err == -1) { fieldbus_free(modbus); modbus = NULL; exit (60); } else { return modbus; } } /********************************* Function **********************************/ int setvoltage(float wish) { int errlvl; union { uint16_t word[2]; uint32_t dword; float fl; } wert; uint16_t ao; wert.fl=wish; errlvl=modbus_write_registers(modbusglob, 3000, 2, (&wert.word[0])); if (errlvl == -1) {printf("ERR1 modbus_write_register, %s\n",modbus_strerror(errno));} else { printf("Register set to %f\n",wert.fl);} return errlvl; } modbusglob=fieldbus_new(); mode=1; setvoltage(1.3); sleep(60); setvoltage(3.5); sleep(60); setvoltage(5.7); sleep(60); setvoltage(7.9); sleep(60); setvoltage(10.0); sleep(60); setvoltage(0); sleep(60); setvoltage(5.0); fieldbus_free(modbusglob); exit (0); }

Just as an update.

I was struggling with multiple registers which are used i.e. for the AO1.1 port of my Neuron M103.

So for the AO registers 3000 and 3001 are given as "real".

I extended the above union as follows:

union { uint16_t word[2]; uint32_t dword; float fl; } counter;

And I am reading the register like this:

modbus_read_registers(modbusglob, 3000, 2, &counter.word[0]);

It reads 2 registers starting at 3000 and writes the result in the word array where it is automatically converted to "float" by the union structure.

Works fine!

/KNEBB

The firmware update from 4.6 to 5.56 made the trick and the /dev/ttyNS0 now works as expected, therefore it can be used as Modbus master as intended.

nipi@M203-sn21:~$ sudo /opt/unipi/tools/fwspi --auto Board on /dev/unipispi firmware=4.6 hardware=0.1 (B-1000) (spi 6MHz) New firmware 5.56 for device id=0 fw=4.6 REBOOTING... Board on /dev/unipispi firmware=4.6 hardware=8.1 (E-16Di_U-14Ro) (spi 6MHz) New firmware 5.56 for device id=1 fw=4.6 REBOOTING...

thanks @Martin-Kudláček for your help!

That looks like a bug, @cvrcejir, thanks for pointing that out! I was able to replicate it and pushed the issue to the devs for a fix.

Thanks,
Martin

Hello @JakubCh,
yes, the SLC cards are significantly better, yet the Patron's eMMC is even better, because it doesn't suffer from the power outages.

Best regards,
Martin

Hello @Petr-Helebrant, despite the "disable" option being present in the configuration, the option cannot be disabled. The build of the solution will fail.

@Petr-Helebrant Thanks for your reply.

in the end, I did indeed end up putting in a separate series of relays to control the blinds. I did use relays from Eltako though, which were a lot more expensive than the solution you did provide. Thanks anyways for the tip, I can imagine it to come in handy for a future project.