LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

What could change after a baud rate increase to slow down serial communication?

Hi

I have been using Plasmionique Modbus Master library for several years, on two separate systems, just reading a standard modbus server at baudrate 9600 through an Easysync RS485 serial converter. All works fine rock solid.

Now I am trying to stream data at 100ms intervals and have upped the baud rate to 38400. Since I updated the baud rate (twice) it has briefly worked fine on both systems but then  starts running much slower about 7-800ms reading interval. By looking at Max/ Devices and Interfaces; Visa Interactive Control  and Windows Device Manager I can see that the baud rate is saved correctly and the aliases are correct. There is only one thing that I can find that might be a problem on one of the machines and that is Visa Interactive Control cannot access the relevant com port - as shown in "visa2" png below. But I think that might be just because Labview is using it.

I have tried uninstalling all the com ports and changing the com ports being used by Labview. It seems that NI Visa and MAX weren't installed when I made the changes but since the problem occurred I have installed them. I have LV 2022 Q3.

 

I have been at this weeks now and would really appreciate any suggestions.

 

Download All
0 Kudos
Message 1 of 9
(163 Views)

Hi,

I am having problems with streaming data with the attached VI. It concerns the inner FOR loop in frame 7 of the flat sequence. The times between readings were more than the specified 100ms timer so I upped the buad rate from 9600 to 19200 this improved the timing down to about 125ms. But after a few runs the time increased again to about 800ms. I updated to 38400 and the performance was perfect but then after starting the VI a couple of times it went back to roughly 800ms again. I suspect this is something to do with Visa because I have found generally that if you stop a VI when it is running you get unusual com port addresses in the comport list which when cleared gets rid of communications problems. But clearing those in this case doesnt help.

I have the same issue on another similar set up and changing the modbus client pc, also with a new installation of Labview community, doesnt help either. 

I hope you can help.

0 Kudos
Message 2 of 9
(175 Views)

Please share your VI, it may also be with how you implemented the code inside the loop causing it to slow down over time, a common mistake is accumulating data over time in array and writing to file in the same loop as the reading part.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
Message 3 of 9
(173 Views)

Sorry I attached my VIs before but didnt upload

Download All
0 Kudos
Message 4 of 9
(163 Views)

The code could really use a make over. It is not employing any data flow techniques and the use of sequence frames is generally not recommended.

 

Anyway, to answer your specific question, the delay is most likely caused by delays writing your results to the file. Disc access such as writing data files should be handled in a separate task in parallel with your data collection. Look at examples of a producer/consumer framework for how this is done.



Mark Yedinak
Certified LabVIEW Architect
LabVIEW Champion

"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot
Message 5 of 9
(132 Views)

@Mark_Yedinak wrote:

Anyway, to answer your specific question, the delay is most likely caused by delays writing your results to the file. Disc access such as writing data files should be handled in a separate task in parallel with your data collection. Look at examples of a producer/consumer framework for how this is done.


Thanks for that, I am sure my code could be improved, the thing is that I know it works because I have files that it produced with the correct write time interval. I worry that employing a producer consumer framework would just increase processing overhead. It eems to me the problem is outside of the code.

0 Kudos
Message 6 of 9
(94 Views)

Don't open and close the communication each iteration, open outside the loop and close it after.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Message 7 of 9
(80 Views)

Yamaeda,

Can I award you a spooky action at a distance badge? I made the change that you suggested on one of my machines, saved it, ran it. Both machines output perfectly at 100ms intervals. The other machine is not connected to the internet, the only connection between them is via the power supply. I reversed the code change and all continued solved.

I dont know if thanks are due or not but offer them anyway.

0 Kudos
Message 8 of 9
(47 Views)

The  solution is here. Not eally a solution more like an outcome.

What-could-change-after-a-baud-rate-increase-to-slow-down-serial 

0 Kudos
Message 9 of 9
(44 Views)