Modbus problems?

[nikolauskrismer]

Maybe this is the wrong place to asks this (since I really think that this is related to libmodbus), but maybe you do have some experience with the following problem :-)

I opened /dev/ttyr00 using a Moxa NPort 5110 to my heating (watercotte Ai1+ with WPCU) sucessfully. So after calling WpgetVal.pl I get the following output:

./WPgetVal.pl OutdoorTemp
./readModbus -f3 -a433 -s2 -t1
T outdoor = 19.363539°C

However, when I call WPgetAllValues.pl the output looks like this:

./WPgetAllValues.pl 
./readModbus -f4 -a3537 -s2 -t1
Read register failed Illegal data address
./readModbus -f1 -a4145 -s16 -t7
readModbus failed with exit code 256
[root@server bin]# Read register failed Illegal data address

I noticed that sometimes (do not know exactly when, but I think that the first call after some time of waiting fails, while subsequent calls - without waiting for more than some seconds - all work) WPgetVal also fails (although it works most of the time). The output of a failing call looks like this:

./WPgetVal.pl OutdoorTemp
./readModbus -f3 -a433 -s2 -t1
Read register failed Connection timed out

What is the problem here? Can I do anything against it?

[mfechner]

Ok you have another heating model then I have which seems not to have all registers available to read as mine. Check the file bin/WPMemoryMapping.pm you have on the first column the name of the value to read, e.g. RTCTime. If you execute now:

./WPgetVal.pl RTCTime

you should see the output. Mark the line with a # that gives you an error message.

[nikolauskrismer]

Trying that for all values. How should I handle values that sometimes work and sometimes do not work? Is that handeled somewhere in the code?

I recognized that some value retrievals seem to work only after the third query. For example:

[root@server bin]# ./WPgetVal.pl HeatReturnTempNominal
./readModbus -f4 -a1217 -s2 -t1
Read register failed Connection timed out
T return target = °C
[root@server bin]# ./WPgetVal.pl HeatReturnTempNominal
./readModbus -f4 -a1217 -s2 -t1
Read register failed Connection timed out
T return target = °C
[root@server bin]# ./WPgetVal.pl HeatReturnTempNominal
./readModbus -f4 -a1217 -s2 -t1
Read register failed Connection timed out
T return target = °C
[root@server bin]# ./WPgetVal.pl HeatReturnTempNominal
./readModbus -f4 -a1217 -s2 -t1
T return target = 21.000000°C

[mfechner]

Do you access the heating with another software? Make sure that only one software access the heating, otherwise one connection will fail. That also counts for the crontab entry. If the crontab is reading values from the heating in the moment you execute the command manually, one connection will fail.

[nikolauskrismer]

Temporarily deactivated crontab entry, so that should not be the problem. There is no other software accessing the Moxa NPort and/or the heating.

[nikolauskrismer]

Hmm... could this be a problem with the moxa box connected to the pc using a switch (no direct connection)? Do you have the box connected directly to your system?

[mfechner]

No, I have connected it to a switch, too. But I had problem with the firmware on the moxxa and I had to upgrade it to current version. My Model is NPort 5110A and Firmware 1.1 Build 11080114. Port 1 is set to 9600, 8 Bit, 1 Stop, no parity, DTR/DSR, FIFO enabled and Interface rs232. Operating settings is RealCOM, TCP alive 1, Ignore jammed IP no, allow driver control yes, length 0, delimiter 1 0, delimiter 2 0 (both disabled) delimiter process nothing and force transmit 0.

Driver version on Linux is MOXA Async/NPort server family Real TTY driver ttymajor 33 calloutmajor 38 verbose 0 (1.18.1 Build 12051018) with kernel 3.0.35.

[nikolauskrismer]

Ok... I tried it with your settings (mine were slightly different), and the problem seems to happen less often, but is still there.

I have a moxa 5110 box (without the A) and my firmware is also build 11080114 (although it's calld version 2.4).

At the moment my kernel is 2.6.32 (I use centos 6.5). I noticed that when using crontab and the WPgetAllValues script thing seem to work , so this really is no major issue (at least not at the moment) :)

[mfechner]

good to hear. Would you like to close this issue then?

[nikolauskrismer]

Thats ok for the moment If the problem becomes important again, I will investigate and do some more research (and fill a new issue if necessary)