03-05-2014 08:23 AM
Hello!
I am building a user interface to monitor and control Altivar31 invertor by RTU Modbus using Labview 2013 and Labview Modbus API https://decibel.ni.com/content/docs/DOC-30140.
At this moment I have successfully read about 11 variables which are going one by another (W3201-W3211)
I should read more variables (about 30). (3231, 3250, 3252, 5240, 5241, 5242, 5243, 5244, 5261, 6056, 7121, 7201, 7202, 7203, 7204, 7211, 7212, 7213, 7214, 8521, 8522, 8531, 8532, 8541, 8542, 8631, 8632, 9630, 12002, 12003)
To do this at the moment I am putting new Read Holding Registers VIs. It takes a lot of time and the program structure becomes overloaded.
Is it possible to use only one Read Holding Registers VI giving it an array of addresses which I should read?
How I can achieve it?
Thank you!
PS: My project is in attachment.
03-07-2014 01:17 AM
I have modified my application.
Now I build matrix of address values sending it to Modbus Read Holding Registers VI and sending result to indicators trough case structure. Data reading part of the program works in a double while loop.
Program structure became simplier to understand, but it works wery slow - data update of all indicators (variables) takes up to 1200 ms.
Previous version of the program was working much faster and delay was not noticeable.
Are there some options to increase performanse of the program?
The previous version of the program:
The new version of the program:
03-11-2014 06:48 PM
Hi ifku,
NI Labs as a whole is not monitored. Instead, each tool posted (like the Modbus library) has a discussion page associated with it. I happened to look at the recent content section, but no users are notified by your posts here. As such, I would appreciate it if you could direct any future posts to either the modbus library discussion page (for use of the libraries, or issues with the library) or to the standard NI forums (for other questions).
In your case, I have a few points of feedback:
I've attached an example of this. I think your performance difficulties come from the sequential single-element requests. The example I attached is more complex, but should help you achieve higher performance.
Thanks,
Daniel