LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multiple EXE of the same program running at different speeds

Hello,

 

This is a weird issue problem. I have a Labview program that logs a large amount of data. I created an executable and it was a laggy one. I made some changes to the program, deactivated a couple of bad codes (i.e. DAQ assistants in while loops) and then created a new executable. That seemed to have boosted the speed and data logging was faster. Let's call the first executable Program1 and the second one Program2. I made a few minor changes to the program (nothing that could significantly increase the complexity of the program) and created a new program called Program3. I tried opening Program3 and it was taking forever to initialize, so I closed it. I tried opening the other 2 executables but they were also taking forever to initialize. I restarted the computer and ran the executables again one by one. This time, Program2 ran smoothly without any lags, but Program3 is still as laggy as the first one. Any ideas on what's happening there?

0 Kudos
Message 1 of 4
(2,336 Views)

There is absolutely no useful information in your post. There a billions of ways to make "some changes", for example.

 

What determines your loop rate? Any reasonable program should runs at a well defined rate. What is the target rate? What is involved in "initialization"? Do all try to access a common resource? Does the task manager show anything interesting (at least one CPU core maxed out, memory increasing forever, disk thrashing, etc.)

0 Kudos
Message 2 of 4
(2,333 Views)

So, I figured out that the laggy executable is being caused by one of the changes that I made to the program. Please refer to the first image where I have highlighted the changes made to the program. I am taking the output waveform array (1D) from the signal conditioner.vi and deleting some elements from it and then adding back other elements to replace the deleted indexes. The replacement elements are indexed in a for loop and the VI called inside the for loop (see the second image attached) sets attributes to the input waveforms according to their types (i.e force or moment). The faster executable does not include these changes (i.e. no adjustments made to the output waveform array from the signal conditioner.vi). What could be the reason for this?

 

p.s. I am a newbie in Labview so I'm still not familiar with time complexity issues on Labview.

 

Download All
0 Kudos
Message 3 of 4
(2,258 Views)

@arceus77 wrote:

p.s. I am a newbie in Labview so I'm still not familiar with time complexity issues on Labview.

 


You should be aware that truncated code pictures are completely useless to show anything programming related. If you would attach your VIs instead, we might be able to offer suggestions and explanations.

 

Your code looks quite flawed. For example, you are constantly resizing arrays, which could be a burden on the memory manager. You have a local variable where we have no idea where the terminals is. You have a sequence structure that does absolutely nothing useful. Why are there so many channels and where do they go? What's the purpose of the code fragment below?

 

altenbach_0-1636387716769.png

 

0 Kudos
Message 4 of 4
(2,227 Views)