NI serial modbus libray

[m_min]

Guys,

I have been using NI serial modbus library but the way I use is just read the a few integers periodically (from PLC). But now I have to read like 2000 integers after the experiment of 5 hours. Wanna shed some light? 

Thanks

[andre.buurman@carya]

The VI "MB Serial Master Query.vi" input "Modbus command" takes two important parameters. Starting address and quantity. You will have to look in the modbus specification (quick search will turn it up) and found the largesteamount of data fields that can be retrieved in one MB message or use trial and error to find it. Then use a for loop to iterate through the queries to be done. E.g. 0 to 100, 100 to 200, etc.

[Caleb_W]

Hello,

This Developer Zone article will help when forming the message.  In the article you will see the different functions that you will be able to do and how to set it.  If your byte count is represented by 2 Hex Digits, you will be limited to 255 bytes per message. 

http://zone.ni.com/devzone/cda/tut/p/id/7675

[unclebump · Accepted solution]

Modbus commands can read 100(maybe 125) registers at a time. How important is the info?? You might want to look at adding checksums to the plc data in blocks of 99 registers. This way you can guarantee data integrity by recalculating checksums inside labview. Just depends on what you are doing. How long will the test data be available and how quickly do you need to see the results?? RTU mode is the fastest way to retrieve the data. You could loop thru reading 100 registers in blocks and increment the starting address each time. If you need to store these results for historical purposes, the DSC module would be the best way to grab the data with an opc server program. Saving the results in the Citadel database.

[mbtoday]

Hi unclebump.  I'd like to echo that the Citadel historical data server is an extremely valuable part of the DSC module.

Also a question about your "checksum" idea - given that Modbus RTU is using a 16 bit CRC, I would not expect corrupt data to get through the protocol.  Have you experienced otherwise?   I think errors would be completely unlikely using TCP as the transport for Modbus.  Of course this requires that the Modbus function calls be watched for errors and retried upon failure.  A checksum over the block of 99 or so values would be useful for detecting program logic errors, I'd say, but unless I'm missing something I don't think it would add anything to the data transmission reliability.  Am I missing something?

Thanks, 

Mike

[unclebump]

Yes it does make a difference. My first labview project was using Modicon momentum plc's with analog inputs and Load Controls Inc 3 phase power sensors. I was doing tool monitoring while we were machining automotive cylinder heads and cylinder blocks. I would read the analog input into the plc and store the value into a continuous block of registers. I basically made the plc into a storage oscilloscope with a few extra wrinkles thrown in. I used kepware to read this continuous block of data. To test the response of the system. I made the plc count up by one for each plc scan into about 2000 registers. What I should have gotten into labview was a straight line, but that wasn't always what i saw as a result. Sometimes it would grab old opc data. I was using a 50ms refresh rate. How do you sync the DSC data with kepware and the plc?? Who would be updating when?? I tried making a circular buffer between the plc and labview with only a few hundred registers. I had to end up storing all of the data into large blocks. I needed to read a large block of data within .2 seconds before a new toolpass was started. I ended up making labview read data until the plc calculated checksum matched the labview calculated checksum for the data section. Then I knew I had good data. I had the plc's setup using the I/O scanner option and kepware was a mailbox. The plc's continually blasted data in one direction without kepware having to request it. This was all done over ethernet. I even multi-homed the computer lan card, so each plc had a specific ip address to send data into kepware. This was started in a DSC 6.02 world and ended in a DSC 7.0 world. I'm not sure how 8.6 would work with this setup.

I guess I was a bit anal about knowing that I really got the values that the plc had in the registers at the end of a toolpass. But when you stop machines for faults and have bad data that is causing it, production doesn't like that very much.