From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

MODBUS RS 485 VISA Communication with sensor

Solved!
Go to solution

Hello All, 

This is my first time posting (even though I have taken advantage of  great posts many times). I have a Modbus RS 485 sensor that I am trying to communicate with. I can successfully do so using Matlab (I have included the vi with the script), but when I try to do so using VISA communication labview vis, the sensor is timing out. I have tried the MODBUS libraries available (not supported by NI), but no luck. Unfortunately, there is no way to tell exactly what fwrite and fread are doing in Matlab (I wanted to check so I could reproduce the syntax in the input string for the VISA in Labview).

 

Any suggestions? Thank you all for your help in the past, and hopefully with this one. 

jlp324

Download All
0 Kudos
Message 1 of 12
(3,814 Views)
Solution
Accepted by topic author jlp324

The various Modbus libraries DO work, even the ones that are "unsupported".  The problems with your VI:

1.  You configured it with the termination character enabled.  When you work with binary data such as modbus, that will cause you problems if your data string contains a byte equal to the termination character it its data packet.

2.  You are reading 200 bytes.  When your communication protocol doesn't have a termination character, and you try to read more bytes than are coming, you will get a timeout.

3.  Your command you are writing out isn't saved in your VI by default, so we don't know if you are sending the correct command.

 

Try the attached VI.  It uses one of the original Modbus libraries which I liked because you can dig into it and see the underlying code.

 

PS, the matlab script had an error where it was multiplying the high byte by 265 rather than 256 for the temperature register.

Message 2 of 12
(3,795 Views)

Fantastic input!  First rodeo with Modbus at my end... Thank you very much for your help.

jlp324

0 Kudos
Message 3 of 12
(3,776 Views)

Hello, 

You helped me quite a bit with one of your posts in the past (related to modbus rtu communication). 

I was able to get a soil sensor working thanks to your help. Now I have a co2/temp/humidity sensor that I am trying to communicate with. The manual (located at https://bravocontrols.com/shop/co2-sensor-2/ ) does not provide any syntax examples, and after reading a lot of MODBUS for dummies, i still cannot figure out what syntax is needed to communicate with the sensor. I was able to communicate with the provided T3000 software, but unfortunately, it does not show the hex strings used. My question: could you help me understand what is the syntax hex string that needs to be provided by labview to communicate with the sensor based on the manual information? I know this is not quite a labview question, but more a please "help me understand modbus rtu." Any guidance would be extremely appreciated. 

I have set the ID of the device to 3.

 

I have attached a simple modbus communication vi that works with the soil sensor... just in case it could help someone.

0 Kudos
Message 4 of 12
(3,612 Views)

I'm glad I could help.

 

A couple things I see.

1.  You say you set it for sensor 3, but your sensor # in you VI is set for 1 as the default.  Are you changing that value to 3 before you run the VI?

2.  The manual doesn't say whether those are input registers or holding registers.  You set your command to 04 hex which is used to read input registers (those numbered like 30001 if the manual listed the full number).  I think it is more likely those are holding registers (would be numbered like 40001).  Holding registers use command code 3.  So try changing that 04 hex to 03 hex.

3.  If you do use their software, see if you can use a port sniffer to capture some of the data stream such as Wireshark.  It could generate too much data to really understand depending on how talkative their software is.  But you might be able to pick out some patterns.  But on the other hand, the software me using a different protocol than modbus. 

0 Kudos
Message 5 of 12
(3,610 Views)

Hello,

thank you again for taking the time. I will try function 3 as you recommended. It seems like you agree with me that their manual does not provide sufficient information to come up with the communication syntax. I will let you know if i get it to work.

 

Thank you again.

0 Kudos
Message 6 of 12
(3,596 Views)

Hello!

You were correct! Function 3 is the way to go (holding registers). I was able to communicate using a modbus communication software with the following syntax: 03 03 00 CC 00 01 45 D7 (last two sets are CRC16 codes).

 

The issue is that the hex string in the attached labview vi places the values in sets of 2: 0303 00CC 0001 45D7.

 

Do you know how to separate the byte description in the string? 

Many thanks again.

jlp

0 Kudos
Message 7 of 12
(3,583 Views)

That's not a problem.  There is nothing you need to change.

Your manual just formats the bytes with a space between each pair of hexadecimal digits to make it easier to read.

LabVIEW formats it with a space between each pair of bytes (4 hex digits) to make it easier to read.  I'm not exactly sure why.  Possible reasons:

1.  It is a bit easier to scan groups of 4 characters rather than a longer train of 2 characters separated by spaces.

2.  The groups into 2 bytes makes it easier to pick out 16-bit words.

3.  Half the spaces means the string is shorter.

 

Just don't worry about it.
I'm glad it is working for you.

0 Kudos
Message 8 of 12
(3,580 Views)

Thanks! Then my vi does not work with this sensor, since it gives an error with 0303 00CC 0001 45D7. When i put the syntax 03 03 00 CC 00 01 45 D7 in the software T3000 Modbus Poll test center (i have attached an image of the testing window), data is sent and received. If i write in the test center 0303 00CC 0001 45D7 it does not work (first two lines of the image). Also as mentioned that syntax does not work in my labview vi.

 

I have used this vi with other sensors that have taken the syntax without issue. Should I try to use the Modbus functions available? I would rather simply use the serial communication functions since it is simple, but I cannot figure out what the issue could be.

 

Thank you again! Much appreciate it.  

0 Kudos
Message 9 of 12
(3,577 Views)

That doesn't make any sense.  But I don't know how that test program works so what it is doing may be hiding some details.

 

There is one possibility.  Do you know if this us using Modbus RTU or Modbus ASCII?

 

RTU uses raw bytes, so nothing about spaces would ever come into play.  Sending hex 03 means you are sending a single byte with the value of 3.

ASCII uses the human readable part of the ASCII character set.  So if you want to send the value 03hex, it gets send out as a literal 0 and a literal 3.  Two bytes get sent out of the port, 30hex  which is the byte code for a character of "0" and 33 hex which is the byte code for a character of "3".  In this case, the protocol may ask you to send spaces  (a literal space which is a byte code of 20hex in the ASCII table).  I've never used Modbus ASCII, only the RTU version, so I'm not familiar with the details of how the Modbus ASCII messages are formatted.   That test program you show doesn't really tell me what is being sent, but the fact that is so specifically mentions putting in spaces in the box for the data to send makes me very suspicious.

 

See what the manual says about which version of Modbus is being used.  The Modbus libraries allow you to choose the version.

Since you aren't using the libraries, but just sending the string data as raw bytes, put a string constant in that is set for normal display and has all those characters with the spaces in between.  So with normal display set, you would see "03 03 00 CC 00 01 45 D7"    See if that works.

 

Try using Wireshark while you are using the test program that is working for you and you'll be able to see what it is really sending.

 

 

 

Message 10 of 12
(3,573 Views)