LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why data processing with the serial commnication is slow in the state machines?

- serial communication speed : 100Hz (save every 10ms) with STM32 virsual COM port

- it is processed as a graph and saved as a csv file when the buffer data is received from the Virtual COM port.

 

Q1. There is no slowdown in data processing on high-end PCs(example CPU i7), but the problem occurs on low-end PCs(example CPU i5).

Q2. There is no problem if turn off the CSV save function(sub VIs) and only display the graph.

0 Kudos
Message 1 of 7
(477 Views)

Hi schkorea,

 


@schkorea_haechitech wrote:

Q1. There is no slowdown in data processing on high-end PCs(example CPU i7), but the problem occurs on low-end PCs(example CPU i5).

Q2. There is no problem if turn off the CSV save function(sub VIs) and only display the graph.


Is there a question?

 

You already discovered one important fact: file handling can be slow!

So to improve file handling you can follow several ways:

  • open the file once before the loop and close it once after the loop
  • don't save to file in each iteration, but collect data of several iterations and save it block-wise
  • use a producer-consumer scheme to decouple DAQ from file handling

Btw. plotting data in graphs tends to be slow, too. Especially when there are large plots!

(And usually it doesn't make sense to update a graph at 100Hz…)

Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 2 of 7
(468 Views)

It depends on how you using "CSV Save" function. In case of large data blocks may slow down, then probably better to use producer/consumer design pattern, where acquisition and storage splitted into two loops and the data transferred via queues.

Show your code for more details.

 

0 Kudos
Message 3 of 7
(465 Views)

I have shared the simpe vi code about my questioni.

 

schkorea_haechitech_2-1709709944296.png

 

0 Kudos
Message 4 of 7
(443 Views)

Hi schkorea,

 


@schkorea_haechitech wrote:

I have shared the simpe vi code about my questioni.


Some problems:

  • You open and close the file with each iteration as you use the WriteDelimitedFile function! This is going to be slow! Open the file once before the loop, write inside the loop using WriteTextFile/FormatIntoFile function, close after the loop!
  • You use BytesAtPort: this is very problematic! You should rely on the message format of your STM device instead of hoping to read complete messages! See this excellent video...
  • Once you rely on the message format you should delete the 10ms wait in the loop as the sender will determine the loop rate...
Best regards,
GerdW


using LV2016/2019/2021 on Win10/11+cRIO, TestStand2016/2019
0 Kudos
Message 5 of 7
(436 Views)

thank you about your fast feedback.

I will try the BytesAtPort code skill from the your shared video.

0 Kudos
Message 6 of 7
(429 Views)

If you are actually receiving a constant data stream at 115200 baud you may want to consider a Producer/Consumer architecture. 

 

Also the Write To Delimited Spreadsheet vi is slow because it opens the file, writes the data, and closes the file on every write operation.

 

Try this instead

  1. Open the file using the Open/Create/Replace File vi before you enter your acquisition loop
  2. Pass the file reference to the loop and use a shift register the pass it around the loop
  3. Write your data using the Write Text File vi
  4. Remember to close the file using the Close File vi after you exit your acquisition loop

oseCapture.PNG

 

 

========================
=== Engineer Ambiguously ===
========================
0 Kudos
Message 7 of 7
(360 Views)