LabVIEW
Slow Front Panel
You have a number of weird bits of code so after you resolve this problem there are a number of other things you may want to look at improving as well, by the way... (bad local variable use, the very strange choice to convert your array to a cluster, your use of "Dynamic data"...)
To address your actual complaint, in a "While" loop everything has to finish before it loops again, so you're mostly just looking for the slowest thing in the program. Of all the things in your loops, the only things that really could be slowing you down are:
- The DAQmx read in the small loop
- The dequeue in the large loop
- The file saving in the large loop
I'll address these in reverse order.
The file saving is unlikely to be the problem unless you're saving to something really slow, like an old USB thumb drive or something on a slow network drive.
The dequeue is set with a timeout of 100 ms. That means that it should be going at least 10 Hz, unless you are timing out. Have you put an indicator on the "Timeout" output of it to see if that is happening? If that were the case you would likely get a lot of zeros in your data and notice that. Have you looked for that?
Both of those are in your large loop. Have you tried adding a loop counter to see how fast it updates? Just something simple like this:
Your small loop is more likely to be the problem. What you have done might work, but when you write code that way, DAQmx is starting and stopping the task for you constantly. Each stop and start can take quite a while (relatively speaking), maybe around 200 ms each. So what's probably happening is that each time it runs, it has to do a lot of startup prep for 200 ms, then measures for 10 ms, then runs a shutdown for 200 ms, for a total of around 410 ms per loop, about 2.5 Hz.
If that's the case, what you need to do is start it outside the loop, execute it inside the loop, and then stop it outside the loop when done. Something like this:
That image is not mine, it is from here:
Before you make changes to your code, you likely want to time it to be sure that this is the cause. Use this method to check execution time of pieces of your code:
https://forums.ni.com/t5/Example-Code/Measuring-Execution-Time-of-a-Code-using-LabVIEW/ta-p/3511278
Your main loop shouldn't have any Wait at all, since it's limited by the Dequeue, although that's not why it'd be 2.5Hz. Your Local variables (which is a bad name, it's a local data copy) will cause some race conditions, try to avoid those. The Wire is the variable. 🙂
There are plenty of express VIs that have more overhead than explicit code. Also, most of the calculations could probably be done on the array with three elements, avoiding all these formula nodes. Yes, your local variables have obvious race conditions because for each iterations, they get read before their terminal receives new values.
The most silly construct is the "array (with 3 elements!) to cluster (with 9 elements!) to unbundle, to 3 scalars" to get the first three elements, a job that can be done with a single index array!
@adamtry wrote:
Hi, thank you very much for your answer! I would be extremely thankful for any tips to improve my program. Anyway, back to the speed problem. I have implemented the improvements to the daq data acquisition as well as some other improvements suggested by other users. I also wanted to add that I am using continuous samples. I added the loop counter indicators, ran the program for 10 seconds and the loop cycle was exactly 100/s on both whole loops. I have attached the improved vi. I have created the TEST 1 vi to test the cycle time of smaller while loop, and presuming I have done something correctly, the time was 9,8ms. (see attached test1 VI and picture). Then I did the same for the bigger loop, see TEST2 vi and picture, and the time of the first loop was 859ms, every next is about 9,1ms. I am starting to think that the problem is with Labview itself, either some strong setting, or that's just how Labview is...I have attached a short video to show how exactly the front panel looks when running.
It's always a LabVIEW problem. Until you find it's actually you.
No, its not LabVIEW.
What's the purpose of that "reserve network device" that runs in parallel to the rest of the code?
What's the purpose of these three hidden indicators that only seem to serve as scaffold for local variables?
Can you translate some of the control labels so we get an idea how they should be used? (e.g."VYNULOVAT" seems to mean RESET is Czech) and why is that set to the rather unusual "switch until released" mechanical action? That seems incorrect and can easily be missed by the code).
Your express VI is set to use the next available file name if the file already exists. Finding that next available name could be slow on the first iteration if there are many files.
Since you stop the big loop after a given number of cycles, it is just a glorified FOR loop (with conditional terminal), so why is it a while loop?
What are reasonable control values for "Úhel Nábìhu a ", "Délka ramena mm", and "NO CYCLES"?
Zero does not seem reasonable, so why are they zero by default?
