NI LabVIEW Modbus API Discussion

[matteci]

Mister Wizard,

Thanks very much for the detailed information and study material. I'll be sorting through it!

I did find the passthrough .zip, but was just curious if there's a page of links I somehow missed before.

The HMI is not a SCADA per se, but it is interesting to learn that's how those things go about collecting data.

I'm sure I'll be back.

Matt

[c.w.]

Hello,

I am trying to use the Modbus API to communicate with 8 AC servo motors via TCP Modbus. I am using a consumer/producer architecture.

I am storing the motor IP's and modbus references (among other data) in an array of clusters in a functional global, and pulling them out as needed. I initially tried using a for loop when communicating with the motors to simplify the code, as shown below.

I am keeping track of each motor error separately so I am able to reconnect individually as needed and keep the other motors online. I ran into a problem where each iteration of the for loop took upwards of 500ms, so going through all 8 motors took 4 seconds which takes too much time. I parallelized the structure to look more like the screenshot below:

This brought the execution time down to around 500ms.

Now to the problem: I was trying to write code that automatically reconnects any motor that has been disconnected, but every time I get a TCP error for the motor that I unplugged from the switch, I would get a TCP error for all of the other motors during the next iteration even though I only unplugged one of them. I have scoured my code and was not able to find any place where I accidentally fed in the wrong motor's error cluster. I am beginning to suspect that I should be using these VI's in preallocated clone reentrant execution mode instead of the default shared mode, but when I tried to switch it I got the dynamic input terminal error. I am also not very familiar with reentrant execution modes. We used the LV8.6 Modbus VI's for another project in a preallocated clone reentrant mode without issues, but those VI's were different of course.

Any help would be greatly appreciated. I am new to posting in the NI forums so not really sure which VI's would be helpful for you all to see. Let me know if you need more info and I will post it.

[smithd]

The reentrancy settings shouldn't be an issue -- no state should be retained between runs and everything thing be on the wire. Shared reentrancy just means if you have 8 VIs running in parallel, labview will generate that many intances, but if you were to drop those VIs down in series (meaning you still have 8 instances, but only 1 will be executing at a time), LabVIEW will only allocate 2 instances of the VI (2 is the minimum).

When you say TCP error, what is the error? 56?

Some thoughts:

It looks like you have a loop in the 2nd picture but no shift register. Is there a reason for that?

It might be a good idea to use the parallel for loop feature in the future, which does something similar to what you did there manually:

http://zone.ni.com/reference/en-XX/help/371361K-01/lvhowto/enabling_parallel_for_loop_iterations/

You might also take a look at some of the async call by reference examples here:

<LabVIEW>\examples\Application Control\VI Server\Asynchronous Call By Reference

Troubleshooting:

I'm not sure why this would be happening unless you are not intializing multiple masters. If you were not, however, the reads would still operate in series as I added a semaphore around the critical section of the read function and so you would not see a performance boost. I'd recommend trying a simple state machine with two separate loops and see what happens. I've attached a simple example. The error should be latched in each loop, so you can see what happens. If this code works, you know that something strange is happening in your code, and we can go from there.

[c.w.]

Smithd,

Thanks for getting back to me. The error I'm seeing is 66 when the one I unplugged first times out, and all of the other ones throw an error 63 even though they are still plugged in. I am initiating multiple masters (one per motor) and am tracking the modbus refs in the FG.

There is no shift register because I'm only running one iteration of the while loop and it gets fresh input data from a FG get call before that subvi is called. I can get rid of the while loop. I am very interested in the parallel loop feature; I had no idea that for loops had that option! I'll try that next week and let you know how it goes.

I will also try to generate a simple state machine tester next week to do some more troubleshooting. Unfortunately I am using LabVIEW 2012 and can't open the VI you've attached, can you save it so it's compatible with 2012 and re-post it?

Thanks for your time!

[smithd]

No problem, heres the 2012 version of the file.

[Versatilesamudia]

Hi Smithd,

I am currently using Modbus Library 1.1.3.32 and I am trying to write some coils located at address 26 - 29. These coils are LED on the front panel of my Modbus slave device. I am using the write to multiple coil believing that the output of these coils can be set as desired. But I noticed that the first boolean in the write to multiple coil array is what determine the value to which all other coils will be set. I thought I could specify the values  I want to write on each of the coils and have them all written with just one click.

[smithd]

You should be able to do so. Take a look at the example for a demonstration:

This example can be found in ...\vi.lib\NI\Modbus Library\Examples

If this doesn't work for you, please try posting a screenshot of the code in question, that may give us some hints about what is happening.

Finally, there is a newer version of the library available on the main page now. This shouldn't matter for you (big upgrades were on the serial side) but its still worth noting.

Thanks,

Daniel

[smithd]

Announcement:

An R&D supported version of the modbus library has been added to LabVIEW DSC 2014:

What's New in the LabVIEW DSC Module

It is also available in the LabVIEW 2014 Real-Time Module.

What does this mean for users of the library? If you have 2014 available to you, we recommend upgrading as soon as possible. While the VIs have changed slightly, most of the functionality has remained the same between versions. The big change is with the "init" function, which has been split into two pieces -- one for Master and one for Slave.

Support for this R&D API should be directed to either the forums or to the normal phone support line. Support for this API should remain here. However, as before, support for this NI.com/Labs version of the API is limited to my availability.

Thanks,

Daniel

[Versatilesamudia]

Dear Smithd,

Thank you very much. I shall take a look at the example and see how it goeswith my Modbus device.

Regards,

PETER.

[Mrmas]

Hi Smithd,

I am unsure what this message means.

"What does this mean for users of the library? If you have 2014 available to you, we recommend upgrading as soon as possible." 

Is the library available with labview 2014 or does one need to buy DSC module seperatly to use this modbus API?

I was under the impression that this library was to be a replacement for the old free one available.

As it says on the project page **This NILabs release is currently intended as a replacement and expansion of the free Modbus library functionality**. Will the labs version remain available and resonably mantained?

regards

Olja