@knebb, I have been successful with my Axon device couple months ago.

Here is my /etc/apt/sources.list.d/unipi.list:

deb https://repo.unipi.technology/debian bullseye main

These are the steps I followed:

sudo apt update sudo apt upgrade sudo apt full-upgrade

I didn't remove any packages after full-upgrade and simply rebooted with a backup in place. After restart, I removed all obsolete packages but those which had unipi or axon in name (see later).

Currently, I'm still using the kernel from Buster because the kernel packages in Bullseye appear to be broken. If I understand correctly, we should be able to use unipi-kernel-modules-dkms with the normal Debian kernel. Unfortunately, it currently has broken dependencies, namely the unavailable unipi-kernel-headers and unipi-os-configurator-data.

Here is the list of obsolete Buster packages I have left on hold:

unipi-kernel-modules unipi-common axon-kernel-headers axon-kernel-image

Since I don't currently need a new kernel, I'm not in a rush to resolve this. However, it would be great to receive an official update.

@arolli Hello Antonio,
depends on what the project is. Neuron is cheaper and more suitable for smart home/home automation projects. Patron line is more expensive, but is built to full industrial standards. As for longevity I definitely recommend Patron, in case you decide to use Neuron longevity mainly depends on used SD card, check our eshop for SLC uSD cards, they help a lot.

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