@martin-kudláček Ok, I just finished to prepare the SD card based on latest UniPian. I will update this thread when I will have some news. Thank you for the support so far.

@knebb said in Need Some sort of Jumpstart:

I am unsure about the "status".

According to the documentation, status is the new value of the output and can be TRUE (to enable it) or FALSE (to disable it).

Here I have no clue for what I would need the nb... does it mean it will read nb bits? To be stored in nb*dest? I would always use the value 1, wouldn't I? If using 2 it would return the value of the second DI 2.2 in the second bit, correct?

Yes to all. This mimics the behavior of the underlying protocol: ModBUS has a Read coils function but does not have Read single coil. You can easily provide your own macro for that, if you really want:

#define read_bit(bus,addr,dst) modbus_read_bits((bus),(addr),1,(dst))

@knebb TL/DR: just use uint8_t. This is the right thing to do.

There is no differences (because of integer promotion) only when you use that variable in an expression. Incidentally, and for different reasons [1], reading a single bit will work with whatever 0-initialized integer you throw at modbus_read_bits, although conceptually wrong. But I can assure you that, when reading multiple channels, using anything but uint8_t will give you wrong results.

[1] Raspberry Pi is little-endian. Setting the first byte of any 0-initialized uint* variable to a specific value (e.g., TRUE), makes that very same variable initialized to that value, regardless of its type.

Here is an example that hopefully will shed some light:

#include <assert.h>
#include <stdint.h>
#include <string.h>

#define TRUE 12

int main()
{
    // Using an union to be able to set the first byte of everything
    // with only one instruction (m.byte = ...)
    union {
        uint8_t byte;
        uint16_t word;
        uint32_t dword;
        uint64_t qword;
    } m;

    // Let's set the first byte of 0 initialized memory
    memset(&m, 0, sizeof m);
    m.byte = TRUE;

    assert(m.byte == TRUE);  // Ok
    assert(m.word == TRUE);  // Ok on little-endian machines
    assert(m.dword == TRUE); // Ok on little-endian machines
    assert(m.qword == TRUE); // Ok on little-endian machines

    // Now let's try with random initialized memory
    memset(&m, 3, sizeof m);
    m.byte = TRUE;

    assert(m.byte == TRUE);  // Ok
    assert(m.word == TRUE);  // Error!
    assert(m.dword == TRUE); // Error!
    assert(m.qword == TRUE); // Error!

    return 0;
}

@knebb said:

Would both work?

None of them will. You should really read a ModBUS introduction... I think the wikipedia page should suffice.

The counter is an input register, not a bit, so:

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

if (modbus_read_registers(bus, 103, 2, counter.word) != 2) {
    printf("Error\n");
} else {
    printf("DI2.1 counter is %u\n", counter.dword);
}

Not sure which is the less and the most significant word, so if the above gives wrong results just swap counter.word[0] and counter.word[1].

@cleve Many thanks for the feedback, I'll contact the service repair directly.

Related to that: I have another Neuron M103 of the same age hanging around (2019 circa), but now I don't want to risk updating the firmware. Is there any drawback on using that PLC with latest neuron image while keeping the old firmware?

Any chance to get any feedback? I really need to use that PLC in the near future.

It seems I've been able to update the second unit successfully:

root $ /opt/unipi/tools/fwspi -u 2
Firmware:   7.18 (for 1-1 E-8Di8Ro)
Bootloader: 7.18
Baseboard:   1-1 E-8Di8Ro

Trying to "reset the configuration" (whatever that means) on the first unit shows scary messages without useful results:

root $ /opt/unipi/tools/fwspi -u 1 -PRv
fwspi: Version 2.18.0
WARNING! Bootloader only mode. UPDATE FIRMWARE!
Bootloader: 6.0 (for 0-1 B-1000)
Baseboard: 255-15 Unipi hw
Loading image: /opt/unipi/firmware/00-1.img
Sending 31 pages.
0000 E E E E E Cannot write page 0

root $ /opt/unipi/tools/fwspi -u 1
WARNING! Bootloader only mode. UPDATE FIRMWARE!
Bootloader: 6.0 (for 0-1 B-1000)
Baseboard: 255-15 Unipi hw

Hi all,
I need to use an old Neuron M103, so I downloaded the latest Neuron image (neuron64-base-os_12.20251103.1.img), burned it and booted.
After logging in with ssh, I did an apt update && apt dist-upgrade and the following message appear:

#########################################################################
#########################################################################

                       Firmware upgrade available

Current firmware in your PLC (5.5) should be replaced by
the newly installed one (7.18~bookworm).

Bootloader needs to be updated.

For more information see the built-in help or our KB:
   /opt/unipi/tools/fwspi
   https://kb.unipi.technology/en:sw:04-unipi-firmware#firmware

Reboot the PLC unit after the update.

WARNING: Do not disconnect the power supply during the update,
         as it may lead to a permanent board damage.

#########################################################################
#########################################################################

Trying to follow the instructions, I did an upgrade:

root $ /opt/unipi/tools/fwspi -u 1 -Uv
# The following did not work: that device did not exist
# sudo /opt/unipi/tools/fwserial -p /run/unipi-plc/by-sys/rs485-1/tty -u 15 -Uv

But now, turning back to the update section after a reboot, I get:

root $ /opt/unipi/tools/fwspi -u 1
WARNING! Bootloader only mode. UPDATE FIRMWARE!
Bootloader: 6.0 (for 0-1 B-1000)
Baseboard: 255-15 Unipi hw
root $ /opt/unipi/tools/fwspi -av
fwspi: Version 2.18.0

What am I supposed to do?

I managed to get what I need by compiling a new (hopefully) compatible set of modules and installing by hands only the needed ones. Here are the steps I followed, executed directly on the AXON as root:

v=$(uname -r)

cd /usr/src
wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-$v.tar.xz
tar xf linux-$v.tar.xz
cd linux-$v
gzip -dc /proc/config.gz > .config
apt install libncurses5-dev bc

# Customize the kernel to your needs. In my case I enabled the
# snd-usb-audio module that, in cascade, enabled other sound stuff.
make menuconfig

# Build and install *only* the new modules.
make modules
mkdir -p /lib/modules/$v/kernel/sound/usb
cp sound/usb/*.ko /lib/modules/$v/kernel/sound/usb/
cp sound/core/snd-*.ko /lib/modules/$v/kernel/sound/core/
depmod

# Not strictly needed, but forbidding future axon-kernel upgrades
# could avoid potential hard-to-debug problems.
apt-mark hold axon-kernel

@knebb said in Need Some sort of Jumpstart:

it writes the state as 0 or 1 into each of the uint8_t .

Or, using semantic constants, as FALSE and TRUE.

Directly using bits would be really slow and error prone (and a nightmare for language bindings).

@knebb said:

Would both work?

None of them will. You should really read a ModBUS introduction... I think the wikipedia page should suffice.

The counter is an input register, not a bit, so:

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

if (modbus_read_registers(bus, 103, 2, counter.word) != 2) {
    printf("Error\n");
} else {
    printf("DI2.1 counter is %u\n", counter.dword);
}

Not sure which is the less and the most significant word, so if the above gives wrong results just swap counter.word[0] and counter.word[1].

@knebb TL/DR: just use uint8_t. This is the right thing to do.

There is no differences (because of integer promotion) only when you use that variable in an expression. Incidentally, and for different reasons [1], reading a single bit will work with whatever 0-initialized integer you throw at modbus_read_bits, although conceptually wrong. But I can assure you that, when reading multiple channels, using anything but uint8_t will give you wrong results.

[1] Raspberry Pi is little-endian. Setting the first byte of any 0-initialized uint* variable to a specific value (e.g., TRUE), makes that very same variable initialized to that value, regardless of its type.

Here is an example that hopefully will shed some light:

#include <assert.h>
#include <stdint.h>
#include <string.h>

#define TRUE 12

int main()
{
    // Using an union to be able to set the first byte of everything
    // with only one instruction (m.byte = ...)
    union {
        uint8_t byte;
        uint16_t word;
        uint32_t dword;
        uint64_t qword;
    } m;

    // Let's set the first byte of 0 initialized memory
    memset(&m, 0, sizeof m);
    m.byte = TRUE;

    assert(m.byte == TRUE);  // Ok
    assert(m.word == TRUE);  // Ok on little-endian machines
    assert(m.dword == TRUE); // Ok on little-endian machines
    assert(m.qword == TRUE); // Ok on little-endian machines

    // Now let's try with random initialized memory
    memset(&m, 3, sizeof m);
    m.byte = TRUE;

    assert(m.byte == TRUE);  // Ok
    assert(m.word == TRUE);  // Error!
    assert(m.dword == TRUE); // Error!
    assert(m.qword == TRUE); // Error!

    return 0;
}

@knebb said in How to Read M103 Modbus Doc?:

*dest is supposed to be uint16_t.

No, it is an uint8_t array. Every element of the array contains the value of a single digital channel, set to TRUE (that is, IIRC, 1) or FALSE (that is surely 0).

Here is my untested snippet:

// Reading one channel
uint8_t my_digital;
modbus_read_bits(bus, 108, 1, &my_digital);
if (my_digital) {
    ...
}
// Reading multiple channels
uint8_t my_digitals[2];
modbus_read_bits(bus, 108, 2, my_digitals);
if (my_digitals[0]) {
    ...
}

@knebb said in Need Some sort of Jumpstart:

I am unsure about the "status".

According to the documentation, status is the new value of the output and can be TRUE (to enable it) or FALSE (to disable it).

Here I have no clue for what I would need the nb... does it mean it will read nb bits? To be stored in nb*dest? I would always use the value 1, wouldn't I? If using 2 it would return the value of the second DI 2.2 in the second bit, correct?

Yes to all. This mimics the behavior of the underlying protocol: ModBUS has a Read coils function but does not have Read single coil. You can easily provide your own macro for that, if you really want:

#define read_bit(bus,addr,dst) modbus_read_bits((bus),(addr),1,(dst))