Problem with com port when streaming data.

[cordm]

Sorry, I don’t have LabVIEW accessible right now, but I also used the latest vipm package. The code on GitHub definitely shows it to be there: https://github.com/rfporter/Modbus-Master/tree/master/MB_Master

Look in the MB_Master class under Properties>Slave ID.
Since it’s in a property definition folder, you could also use a property node instead of the VI.

The VI from the NI Modbus Library won’t do you any good since it belongs to a different class.
The password for the NI library is bestbus. It is only applied in the vip build and is listed in the VI package build spec on GitHub: https://github.com/NISystemsEngineering/LabVIEW-Modbus-API/blob/master/.vipb

[EdHarris]

Still having trouble getting labview modbus to run  fast enough. I tried most of the suggestions above including opening and closing the modbus session outside the loop but that in fact ran slower. using the propery node to change unit ID was slow. I tried the NI modbus library and eventually found the change unit ID vi for Plasmionique (it is in the library but the slave library doesnt show on my pallet) and this is my best result but it is still variably 3 or 4 readings per second when I want 10. I have tried it on labview 2014, 2020 and the latest community edition. I have changed laptop with a clean install of windows 10 pro, but no good. I have a similar program running on a windows 7 machine with Labview 2014 -works perfectly. Any more sugestions please before I go off and program it in python (another 12 months probably).

[Xonmyth]

Hello EdHarris,

Since you mentioned COM Ports. About a month or two ago, Windows 10 and 11 changed some settings with their update. This affected my application with the COM ports. For me, that the solution was to look into the latency settings: (Changed it to 1ms from 16ms) (Update forced a 16ms value).

Maaybe your settings needs to be looked at as well. Worth a try before 12 month new project. Here is where is discussed my issue.

[EdHarris]

Hello Xonmyth, thanks for that suggestion the atency was at 16 on my pc also. I am now up to 6 or 7 readings per second. I have tried reducing the number of slaves polled, taken out the arduino slave from the bus but it makes little difference. Still looks like its going to have to be pyhon though.

[Xonmyth]

ouch! 

If you still want to entertain using-LabVIEW idea.

Couple more things. First, I think you will be achieve the desired result in LabVIEW. Second, I looked at your block diagram just now, it is a mile long and uses flat sequences, not optimal.

I have not worked with modbus but have worked with other communication methods and I can confirm that LabVIEW works reliably up to 5,000,000 baud, parallel reads from two devices, I have well tested it. But that require producer consumer architecture. I would strongly recommend considering implementing that now or in future.

What you have right now is an invitation to problems. Move your code from different flat frame sequence structures to different states (Use a state machine). Producer loop will handle time sensitive part (i.e., Read and Write). Consumer will handle processing of the data you read (Buffered). Channels can be use to transfer data between producer to consumer loop (for less complexity).

Ensure wait times between each iteration safely allows you maintain desired read rate or functionality and does not cause any buffer overruns while not being too greedy for resources. 

Edit: it will look something like this:

I can add more details but writing all this made me think, you might be more comfortable with python.