@ntd said in Internal ModBUS problem:

I will update this thread when I will have some news.

Well, I installed the new SD card a couple of months ago and received no complaints ever since, so I suppose this update solved the problem.

@Martin-Kudláček: thanks again for your support .

@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.

@martin-kudláček Many thanks for your reply.

# dpkg -l | egrep "neuron|unipi|raspberrypi-kernel"
ii  raspberrypi-kernel                 1.20180417-1                 armhf        Raspberry Pi bootloader

Unfortunately I do not have the fwspi binary under /opt/unipi-bin and the one I can have (manually built from neuron-tcp-modbus-overlay, commit 8db93c8f1350) does not have the -i/--index option. This is probably due to the fact I installed the system using the (now legacy) script.

If you think a new SD card updated to latest would likely solve my problem, I will prepare that card. I just need some time.

Just to be on the safe side: I would follow this instructions on a bare Raspbian Stretch Lite image.

Hi all,

I am using a UniPi Neuron L203 on a quite small industrial automation machinery. The software communicates with the hardware via the internal ModBUS/TCP server listening on the 502 TCP port. I'm using a periodic cycle spawned every 20 ms (50 Hz).

All is working fine but sometime (spanning from once per day to once per month!) the machinery got stuck. Today for the first time I have been able to perform some test while in that condition.

1. My software suddently stops working because every call I make to libmodbus (modbus_read_registers or modbus_write_register) returns always Illegal data address.
2. systemctl restart neurontcp.service did not solve the issue: after that I got a bunch of errors in the logs (Broken pipe).
3. After a reboot the prolem did not vanish either: I got another bunch of errors in the logs (this time was Target device failed to respond).
4. After a power off and power on cycle, all is working as expected.

In particular, point 3 made me think that the problem is hardware or firmware related. Anyway I have no problems in sharing my code or whatever else needed to be able to get rid of this (really nasty!) problem. Also, any suggestion in hardening the hardware side would be appreciated.