Hi everyone,

In the current version of Mervis OS 2.4.2.4, writes to the card already occur at least, according to the set interval for storing retain variables.
For a similar reason, the history is newly stored in RAM (data is lost after the power is disconnected or restarted), which does not matter in combination with the cloud-based Mervis DB.

If you disable writes to the internal storage (SD card), there are two possibilities of what can happen (depending on how you disable the writes):

Mervis RT always unlocks the storage when writing retain variables, writes and locks the storage again for writing (basically the same behavior as now) Storage will be permanently locked and retain variables will not be writable. Likewise, it will not be possible to upload a new assembly (program) from Mervis IDE.

In general, I recommend purchasing an SLC card with a longer lifespan and resistance to random power outages, etc., for the operation of the controller.
You can read more about this issue in this article.

Best regards,
Antonin, Unipi

@AVsetula Thanks for your reply. To help troubleshooting, I made up an RJ45 connector breakout and viewed the 'data out' pin on an oscilloscope. It soon became clear that the problem is one of intermittent connection. I connected the scope at the end of the device chain (socket 8 on the hub) and if I connect all the intermediate sensors, and tape their cables to the bench so there is no strain on the RJ45 connector, all is well. I can see nice sharp 0V to 5V data transitions on the scope.

But, any movement on the cables causes an intermittent loss of contact, immediately apparent from the 'illegal' voltages that appear on the scope display.

I have disassembled the hub and buzzed out all the solder joints: no problems. The issue seems to be either with the RJ45 plug/socket connection, or with the sensor cable/RJ45 plug crimp integrity.

It doesn't help that the insulation on the temperature sensor cables is extremely stiff, so that any movement of the cable puts strain on the RJ45 connector.

I think I will need to arrange for cable clamps to hold the sensor cables in place. The hub will be mounted in a plastic box, so this is feasible: I should be able to 3D-print something.

Hi everybody,

It has been fixed with a new version of the unipi-kernel-modules package.
At the same time, we increased the output testing of packages.

Best regards,
Antonin

Hi @AllanL,

From your description, I assume it's a wrong connection. The digital inputs on our units are not potential-free, but instead respond to voltages in the range of 7 to 35 VDC. At the same time, it is necessary that the negative pole of the voltage source is connected to DIGND.

More information can be found in the article dedicated to digital inputs:
https://kb.unipi.technology/en:hw:02-neuron:description-of-io:01-description-of-di

Best regards,
Antonin

Hello everybody,

we have good news!
All packages from the Unipi repository already have their version for Bullseye (Debian 11).

Unfortunately it took a little longer as it was not as easy as it first seemed, but now our packages can be used on all Unipi controllers with Debian 11.

We are now working on Bullseye OS images that we will release in the coming months. OS images will not be released immediately because we are working on a new unified approach to information about the controller and its peripherals.

For Unipi Neuron and Unipi 1.1 it is now possible to use the RaspberryPi OS image.

Best regards,
Antonin

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.

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