This project has moved and is read-only. For the latest updates, please go here.

ModBus RTU Laptop to Mutimeter

Oct 28, 2014 at 2:27 PM
Hi. I'm trying to read some data from a multimeter that uses the ModBus protocol, and I came across your library. I've tried running a test program but unfortunately it doesn't seem to be working.

I'm running the CET.IO.DEMOMODBUSS_NET45 solution
Oct 28, 2014 at 3:14 PM
Hello Tweezy.
What do you mean by "not working"? Does not compile? Throws an exception somewhere? The app starts but seems not exchanging data?
Could you describe something better the problem?

Also, did you browse the other posts on this section? In the past seems that other users had some trouble, but then found the solution with ease.
Oct 28, 2014 at 3:24 PM
So sorry, literally the vaguest question ever.

Compiles run, and no runtime errors. When the program enters the "DoTest()" function and get to the
 CommResponse[] result = await Task.WhenAll(
                    .Select(_ => _.ExecuteWriteMulti(portClient))
part of the code, it doesn't seem to execute it (Like what you sometimes get when not invoking on a multi threading application) rather just skips it and displays everything before it.

So, the only thing is displays is:

"TX: 04, 03, 00, 00, 00, 10, 44, 53"

Also displays the same thing if I disconnect from the multimeter. All i'm trying to do is read the holding registers.
Oct 28, 2014 at 3:59 PM
Oh, well...many points to dig into.
First off, you're using the "RTU" version, which means that the data exchange is through the serial (most of the times is RS485). So, could you check if the adapter you're using is working (i.e. issuing the byte-array correctly)? Please, notice that I used an adapter we're producing to perform this test.

Secondly, many Modbus devices (I'd say legacy, but not always) are using the ASCII protocol, which is not supported by my library.

Thirdly, be sure to check the slave address is matching the one specified in the code.

Fourthly, I'd suggest to limit the (first) test to just one command at time, that is limit the clients (whose running in parallel) to just one. It's clearly useless yet evil trying to "bombarding" a device with many messages, when none is actually working.

Finally, the string displayed in the console is useful for a "manual checking". "TX" means the data outgoing the PC (i.e. the serial port), then you should check byte-per-byte whether the composed stream can be recognized by the device. I suppose you should have a minimal register-map of the multimeter, so this check might be the very first thing you can do.

Let me know.
Oct 28, 2014 at 4:08 PM
Yep, the multimeter uses the RTU version (Woo for more data being sent!), it also has two com ports at the back, one for RS232 (Which I am using) and for RS485.

I shall check to make sure the slave address is correct. I take it
var portSetting = new SerialPortParams(
                    rtsEnable: false);
Where 9600 = baud rate
N = no parity
8 = data bits
1 = stop bits

if my slaveAddress is 1, then
                        new TestModbusRtuClient
                            Name = "Modbus client #" + _,
                            Address = 0x01,
The address is set like that?

Which also prints out a hell of a lot more data. Time to figure out what it actually is! Thanks for the response and the things I need to check.
Oct 28, 2014 at 4:18 PM
Edited Oct 28, 2014 at 4:19 PM
Right! Forgot to mention the serial settings...

Yes. The Address property defines the slave address: the latest snippet is correct.

I bet the only wrong thing in your previous test was the address. At first glance the output stream looks fine...
Oct 28, 2014 at 4:19 PM
Yeah I just double checked everything, seem to be getting the data I desire now, i'll just sive through it all to find out what I'm after!! Thank you for the quick support response, appreciated!