nimodbus.llb help

[iastateEEstudent]

hello I have LabView 8.2 and I have downloaded the nimodbus.llb. I want to use a computer running Labview as a master device on a modbus network. The slave device is a delta temperature  controller. It communicates using the modbus protocol via RS-485. I have an RS-485 to RS-232 converter so I want to use the serial port on the computer to communicate to the temp. controller. However I am new to both Modbus and Labview. I wold like to know more about the example VI's in the modbus library. I want to be able to read and write a single register value. How do I use the example VI's to read a register value, and do I need to connect multiple VI's to do so. For example do I need to use the MB serial init.vi before I can do any thing else? If there is a help file somewhere that explains each block in the examples and how they work that would be great. I have already read though the using touch screens with LabVIEW through Modbus Serial Devices tutorial. It doesn't explain how the different blocks work. I'm also quite confused about how to use the serial master query. What is the difference between a holding register and an input register? What does it mean by starting address. If I choose 1 would it just try to read the first register it found on the device? If it does read a register where would it display the result? would it be in decimal or Hex? Sorry to list soo many qeustions If anyone can help I would be greatful.

[RavensFan]

Begin with the MB Serial Master Query VI.  Save as a new name and work with that.

I am attaching a screen shot with some notes.  Full details on Modbus can be found at www.modbus.org.  particularly

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

An input register (Read is command code 4) read from registers that are in the 30,000 series.  Address 0 in NI will be register 30001.  Address 1 will be 30002.  (Usually you have to play with this to confirm you are reading from the correct register.)  These are read only registers.  You can only read data from them, not write to them.

A holding register (Read is command code 3, write a single is 6, write multiple is 16) are the registers that are in the 40,000 series.  Again there is a offset of 1, and its best to verify this with your device.  Holding registers you can read to and write from.

Coils relate to boolean storage locations you can read or write to.  They are either on or off, true or false.

Discrete inputs are boolean storage you can only read from. 

Between these they are the 0000 series and 10000 series.  I can't remember which is which.

I usually use the multiple register functions because I often have 32 bit words I'm dealing with which takes up 2 registers.  In those cases you have to deal with little endian and big endian to determine which 16 bit register is the significant word and which is the least significant.  That may require swapping registers and joining U16 values to make a U32 value.

The results show up in the Registers Output Cluster in either an array of U16's (one for each register) or an array of booleans (also 1 for each register) all depending on whether you are reading registers or booleans.  Whether you want it to show up as decimal or hex is all in how you set the display for the array indicator.  You will need to index the arrays as necessary to send the data to wherever you need it to go in your program.

I hope this information helps.  It is accurate as far as I know, but there is always a chance I said something wrong.  You can use this query as your basic subVI in your main program.  You shouldn't need to string along any other VI's.  In some of my programs, I have wrapped this in other VI's where I created type def'd enums so that I could create something that says Get  and Motor Status to be my commands and buried the knowledge of what exact register I'm referring to in a case select structure in the wrapper VI.

Message Edited by Ravens Fan on 02-16-2008 09:13 PM

[iastateEEstudent]

Thank you very much for the quick response. I think I have a lot of reading to do before I fully understand the Modbus protocol. Your explaination of the labview vi was very helpful.
I do have a qeustion thought. I don't know if this is something I should ask the manufacturer or not, but anyhow. The value that I'm interested in is listed in the manual of having an address of 1001H. I'm cofused about what this means. If I wanted to read this coil what would be the starting address (1or 0 maybe) and what does the H mean.Thank you very much it turns out that I need to learn alot more about the modbus protocol.

[RavensFan]

---

iastateEEstudent wrote:
Thank you very much for the quick response. I think I have a lot of reading to do before I fully understand the Modbus protocol. Your explaination of the labview vi was very helpful.
I do have a qeustion thought. I don't know if this is something I should ask the manufacturer or not, but anyhow. The value that I'm interested in is listed in the manual of having an address of 1001H. I'm cofused about what this means. If I wanted to read this coil what would be the starting address (1or 0 maybe) and what does the H mean.Thank you very much it turns out that I need to learn alot more about the modbus protocol.

---

Try it as address 0, if that doesn't work, try address 1 or 2 as well.  My first guess would be that the H means hex, but that doesn't make much sense to me in this context.

Play around with the VI and the various settings.  If you are just trying to read a register or coil, there's not much that can go wrong and you'll just get an error message back.  If the manufacturer provides any software for communication, or a front panel interface on the hardware for reading and setting parameters, use that to verify that the address you are reading is truly the one you want to read.  Once you get comfortable that reading is working the way it should, then try to write to the registers or coils.

[iastateEEstudent]

Ok so I have tested my device with another program and it is functioning properly. I have a couple more qeustions about how some of the blocks work. Every time I try to use the MB serial master query.vi It just timesout. First is the address in the modbus command in decimal or Hex ( I think it's decimal I just wan't to make sure). Second how does the  MB serial transmit.vi work? To me it doesn't seem like it is actually transmitting anything. It just seems to change some data types and start to format what to send. I would expect some sort of visa block in there to send serial data. Thank you for your help thus far.

[RavensFan]

MB Serial Master Query takes the address in as Hex (there is an "x" for the radix next to the value.)  So if you have address 1 thru 9 it won't matter.  If you have address 10(decimal), it will look like A rather than 10.  If it timesout, then something must not be correct in the command or the modbus register being sent.

MB Serial Transmit takes the data and formats it to a string, then sends it to a VISA write all in sequence #1.

[iastateEEstudent]

Thanks for the help so far. So I have tested my hardware with software that came with it and I have verified that it sends the exact same string the the master query. So for example If I want to read a holding register I will send this :010310010001EA using ascii 01(slave address) 03(read reg) 1001 (reg address) 0001 (number of words) EA (LRC). So everything in my command string seems to be right, but I'm still getting a timeout error. So I started to look around in the MB Serial Recieve.vi and I think that the vi does is check the address of the slave to make sure to read the right string. I think my problem is there is a block that checks if there is a byte at the com port. When I tested the program it looks like my error is coming from there becuase it will just return a 0 so then the vi never actually reads anything. If you have any ideas on how to solve this problem they would be greatly appreciated. Thank you

[RavensFan]

I think you are on to something there.  All of my experience is with Modbus RTU, not ASCII, so I'm not sure.  But if address 01 comes back as a string of "0" and "1", then it needs to look at both bytes and compare the string "01" to numeric value 1.  As it is a string value "0" coming in first gets typecast to the ascii value of 48, which is not equal to the address of 1.  Thus it would fail.

I am going to post a screenshot of that portion of the VI.  Hopefully anyone following this thread with more experience with Modbus ASCII can comment.

Perhaps if you can make a copy of MB Serial Receive (its embedded in the modbus library), edit that portion, and try it out.  It could confirm whether that is a problem with that part of the code.

Message Edited by Ravens Fan on 02-25-2008 12:07 AM

[iastateEEstudent]

that's an interesting idea but I think my problem is with the property node (bytes at Port) right before the If else case structure. When I ran the program I got a 0 so there isn't a byte at the com port, so the program goes into the '0' case instead of the default case. Do you know how that property node works? Because I assume that there is a byte at the com port becuase the program is sending the proper command. Unless the VISA send block isn't working correctly and the computer isn't actually physically sending any data. Thank you for you quick responses they have all been very helpful.

[RavensFan]

I hear you.  If something is coming back from the device, there has to be at least 1 byte showing up at the bytes at port.

You may need to confirm that the data is going out of the port.  Try running NI-SPY.  Try connecting the RS-232 to another computer to see what is coming out.

Over the years, I have accumulated a collection of RS-232 indicator light adapters, splitters, null modem adapters, 9-25 pin adapters, gender benders, 232/485 adapters, custom build your own adapters to break down and troubleshoot RS-232 and RS-485 communications.

Double check all of your port, baud rate, parity, stop bit, and handshaking settings.  Double check the wiring between your PC and the RS-232/485 adapter.  Does it need a straight through cable, or a null modem?  Double check the wiring from the 232/485 adapter to the device.  Make sure Receive wires go to Transmit and vice versa.