I did as shown above. Ended in an Neuron M103 not booting :(

Unfortunately I do not have a possibility to attach a screen to M103 (or can I use the HDMI of the inner Raspi?)

I ended up in restoring the previous image.

So I can not even tell what the issue was- I guess some kernel/ grub based issues.

At current stage I would recommend against the above upgrade procedure.

/KNEBB

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

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