need help on modbus RTU: don't know the meaning of other output registers

[ivelson]

greetings to all,

I am using LV 8.5, a novice LV programmer & 1st time to post msg in discussion forum so please let me know if  I missed something important.

Anyway, I am acquiring data from 2 power meters (1st is CPM-50 model, 2nd is MWH-10 model, both ADTEK brand). the protocol of these devices are modbus RTU. I have two targets to do:

1. acquire data using RS-485 (laptop <--> power meters)

2. acquire data using ethernet (laptop <--> serial/ethernet converter <--> power meters)

now I am in the 1st part, I am using USB-RS485 converter local brand & I think there is no problem in the port itself (passed loopback test). I create a program using MB library of LV using w/ these port parameters: 9600, 8, N, 1 as baud, databit, parity, stop bit respectively (the same data format of device: see pg. 17/42 of manual). I am using the MB serial query.vi that I customized to eliminate the timeout error 6101 (see picture attachment).

Problem: I can read the right data in the output register but is located in the 5th element of 1D array. In the example attached pic, I'm trying to read the baudrate of device (see pg 26/42 manual: address 0102h = 258d). so I read the 9600 w/c is correct. I also got correct readings to other parameter addresses which is also located in the 5th element of 1D array. note: i still never tried to read power data because the power meters are not been installed yet in the power cabinets (maybe installed nextweek onwards)

Question:

1. what is the meaning of the first four output registers in my output 1D array?

2. why I got 5 output registers eventhough I request only 1 quantity?

3. Is reading the correct data in the 5th element normal?

I just want to be cleared in what data I am reading before jumping into the 2nd part (connection thru ethernet). If I forgot some valuable information, just let me know. thanks in advance!

Regards,

Ivel

[RavensFan]

Can you post your VI and subVI's?

You have a subVI called Serial Master Query which doesn't look like the one that the Modbus library provides.  I'm wondering if it is a homemade modification to the real subVI and it isn't doing something correctly.

Message Edited by Ravens Fan on 03-13-2010 02:14 AM

[ivelson]

Thanks for quick response,

here is the attached vi and subvi.

the only change is in the MB serial transmit.vi. I add a waiting timer after VISA write (not sure if is really the solution but it works in my CMP-50 device). In MWH-10 power meter, i dont need to revise it. but in order to work the program in two power meters, i used this customized vi i created.

[ivelson]

Hi ravenfan,

another thing is, eventhough i use the original vi of the MB library (MB serial master query.vi), i still got the same result (reading correct output value in 5th element of 1D-array). the picture below is working in my MWH-10 power meter (the custom vi before is working in both MWH-10 meter & CPM-50 meters).

so back to the previous three questions above... I do not know what is the 1st four elements in the 1D-array. I am thinking to just disregard that output values but maybe, there is someone whom already encountered this result, so i may know.

thanks very much.

[RavensFan]

What if you read different register addresses?  Or read multiple addresses?  Which elements of the array do the correct responses show up in?  Do the previous 4 register values in any way correlate with correct data in previous registers?

It's possible that the device is not using the modbus spec. correctly.  Maybe it is sending back 5 registers of data even though you only asked for 1. 

I'd recommend putting some indicators and probes in your code to get a closer look at the data stream.  Put a string indicator on the data getting written out and the response string.  Put an indicator on the Modbus data unit In and Out.  These will show the data in more of a byte by byte format.  See if there is anything odd about the data streams and compare them to the device's manual and also to the modbus spec found at www.modbus.org

Message Edited by Ravens Fan on 03-13-2010 11:43 AM

[ivelson]

Hi ravens fan,

I've tried reading other register addresses (i.e. 0101h, 0102h, 0103h, 0104h) independently and still got the correct answer needed in 5th element of 1D-array. there are some changes in 1st - 4th registers of this 1D-array but not sure if correlated in the correct value since the changes is quite strange. however, i've never tried reading multiple addresses because the power meters have not yet been installed in power cabinets. After installation (maybe nextweek), I will surely NEED to read multple registers for power & energy (Hi & Lo word) because this was my project is all about: "centralized power consumption monitoring system".

By the way, i also tried putting string indicators before when trying to find my timeout error but cannot figure out the change in string characters because its unreadable (so i come up using "bytes on port" as alternate debugging).

Any advice on how to convert this string values to make the result more noticeable for changes???

why need to put string indicator in Modbus data unit In and Out (not so clear about this vi function & its significance to monitor its string data in and out in my situation)?

lastly, i see this link already before and read some articles from it, but still no idea on how to compare and check if my device is following the basic rule of modbus data streaming. how???

I see your point is right, reading the data flow of my entire program will be key to know where the unwanted register generated. but it seem quite hard for me to do it right now(still beginner in LV). I will do it little-by-little & tell the result afterwards.

regards,

Ivel

[RavensFan]

I mean instead of just reading register 258 (102h) trying read 4 or 5 registers starting at 258.  Or 4 or 5 starting at 256 (100h).  I wasn't talking about multiple slaves.

Right click on your string indicator and set it for Hex display instead of normal display.  Now you'll see the bytes displayed in hex value rather than as crazy or non-printable characters.

The Modbus Data Unit in and out is just another way of writing and reading the data.  It consists of the function code (3 for read holding registers) and an array of bytes.  The modbus decode subVI ultimately takes this and converts it to registers as either 16 bit integers or boolean values depending on what function code is used.  The bytes array should probably look just like what the string indicators would show in hex display mode.  Perhaps give or take a few bytes due to CRC and the slave address needing to be appended to the strings being sent to and recieved from the device.

The two more important specs are

http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf

http://www.modbus.org/docs/Modbus_over_serial_line_V1_02.pdf

and they basically define the function codes and the order of bytes to be sent and received for each command.  I always refer back to them when I start questioning the protocol being used.  I compared the .pdf file you posted to these files, and I didn't see any discrepancies.

I think looking at the strings being sent back and forth through the serial port will show whether there are any extra bytes being sent that aren't called for in either the device manual or in the modbus specs.

You may also want to run NI-SPY during the communication to be able to capture the data flow.  If you capture a short session of NI-SPY for one query and response, please post it here and I'll see if I can detect anything odd in it.

[ivelson]

Ravens fan,

I tried reading multiple registers and result timeout error, so new problem. now i am trying to detect where it came from and hoping to come up a solution ASAP becoz im running out of time in this project.

btw, here is the attached file of NI-spy. i capture one execution only (1 query 1 response) of reading single register since reading multiple registers returns timeout error. i really didn't know how to interpret NI-spy data. I just knew it monitors the data of our communication port. i hope you can share what you know on how to read NI-spy data.

thanks in advance!

[ivelson]

Is it possible that becoz im reading 5 output registers in single quantity, that i come out timeout error in multiple registers?? in this part (pls refer to picture below) of the MB serial receive.vi, i believe the CRC.vi inside the case structure will return some numeric values in 1st while loop execution (based on command data generated in CRC.vi), and 0 numeric value in 2nd while loop execution (becoz we combine the original command data to CRC data that result to 0). this is  based on my observation on manual checking of command data in CRC.vi. so if this CRC.vi will not output a 0 value in 2nd while loop, the while loop will continuously execute until our set timeout reach and result timeout error. This is what happens when i read multiple registers, "timeout error" occurs.

I just think, since i acquire 5 output registers in single quantity, acquiring multiple quantities (2 or 3) will generated more output registers and produced wrong CRC data. If that happens, it result to continuous while loop execution in this part and result timeout error. just my guess, im not sure.

[RavensFan]

That wasn't as helpful as I thought.  I thought NI-Spy had the means to display the bytes read or written as a hex display.  Searching help didn't show how to do that.  Most of the bytes are showing up as dots as representation of a non-printable character.  Since in Modbus many of the important bytes would be non-printable characters since they would be less then 32 (decimal).

It might be better to try again using Portmon.  Also, showing the strings that are read and written from within LabVIEW with the string indicators set for hex display would help.

It actually looks like you had two write/read queries in that screen shot about 1/2 second apart.  I'm not sure why you'd get a timeout for the mulitple registers, unless it is just taking too long for the device to respond.

One interesting thing I see is that you get the 1 byte back which is correct according to the VI's as they first read one byte to check the slave address.  But then it proceeds to read 14 bytes.  (Or as 7 and 7 in the second query).  In a response after you get 1 byte for the slave address, you'd get 2 more bytes for function code and byte count.  Then 2 bytes for each register you are reading.  Then 2 bytes for the checksum.  So for 1 register, you should get 6 bytes.  A 14 byte response would correlate to reading 5 registers  2 + (5 x 2) + 2.  But the device should not be sending back 5 registers if you are only requesting 1.