devmonkZA / nmodbus

Automatically exported from code.google.com/p/nmodbus
0 stars 0 forks source link

Problem reading holding registers on TCP slave #18

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
<What steps will reproduce the problem?>
1. Create a test program using the "Simple Modbus TCP slave example" code
from NModbus site. Then add some test data for holding registers reading
simulation.
The resulting code is in the attached file "Main.cs".
2. After running the test program, start FieldTalk modpoll 2.4.0 utility to
read 5 holding registers starting from the first one, with the following
command line:
    modpoll -m tcp -t4 -r 1 -c 5 127.0.0.1
The project should crash.
So try to start reading from second holding register:
    modpoll -m tcp -t4 -r 2 -c 5 127.0.0.1
The result should be that test data appears shifted 1 place.

<What is the expected output? What do you see instead?>
Expected output is shown in attached file "Clipboard2.jpg".
Real output is shown in attached file "Clipboard1.jpg"

<What version of the product are you using? On what operating system?>
I used NModbus 1.1.0.1 on Windows 2k.

<Please provide any additional information below.>
The expected output has been obtained modifying lines 60 and 84 of
"DataStore.cs" from
    int startIndex = startAddress - 1;
to
    int startIndex = startAddress;
to fit the 1 place shifting when data has to be read.
I've also attached the modified "DataStore.cs" source file.

Original issue reported on code.google.com by andrea.p...@gmail.com on 24 Jul 2007 at 4:00

Attachments:

GoogleCodeExporter commented 8 years ago
It appears that the problem is with ModPoll.exe as it subtracts 1 from the –r
argument. For example, the command “.\modpoll.exe -m tcp -t 4 -r 101 -c 5 
127.0.0.1”
creates a Read Holding Registers request for address 100, rather than the 
specified 101. 

The NModbus DataStore is a little funky as it is meant to simulate the 1-n plc
address space using 0-n collections. This is why when retrieving or setting a
DataStore address we actually set/get the provided address – 1.

In your example you try and read from address  1 which ModPoll converts to 0, 
then
the DataStore tries to read from the invalid address -1, throwing an exception.

A bug should be logged against the ModPoll tool.

Thanks for the very thorough bug report and let me know if you disagree.

Scott

Original comment by sja...@gmail.com on 25 Jul 2007 at 1:34

GoogleCodeExporter commented 8 years ago
Thanks for your answer.

I agree with You.
The problem is that I thought that modpoll.exe behaviour (subtracting 1 from
specified address) had to define the standard for any modbus master.

Thank You.

Andrea.

Original comment by andrea.p...@gmail.com on 25 Jul 2007 at 2:04