LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Labview Executable

Context,

I have a labview program which runs great if I am running it out of the labview programming software. I have a loop timer as part of my program to keep an eye on the loop rate. If I create an executable and run the program on the same pc the loop rate is reduced to approximately 25% compared to when it runs from the programming environment. 

 

Question,

What would the possible reasons be for the discrepancy? Am I doing something wrong when creating the executable?

 

 

0 Kudos
Message 1 of 10
(643 Views)
  • What determines the loop rate?
  • Is this a greedy loop?
  • What does the program do?
  • What kind of loop times do you get (nanosconds? hours?)
  • Can you show us some simplified code?
0 Kudos
Message 2 of 10
(628 Views)

I have attached the project. Keep in mind I am learning and have not been doing this long. I am sure there are some fundamental problems, for instance I am not using the producer consumer format. If you would like to simulate the hardware it is as follows.

9174 CDaq with 4 cards

9375, 9215, 9215 and 9211.

We are trying to collect the analog voltage at 1K Hz (we know the 9211 will not meet that). 

 

I am happy I made it this far, but could use advise.

0 Kudos
Message 3 of 10
(609 Views)

Hi Jim,

 


@JimFischer wrote:

We are trying to collect the analog voltage at 1K Hz (we know the 9211 will not meet that). 


Why do you use the DAQmxRead with "1 Sample" mode when you want to reach a samplerate >100Hz?

Simple solution: use DAQmxRead in "n channel n samples" mode!

 

Btw. why do you set the buffer size at DAQmxTiming? Did you read the LabVIEW help for that function carefully? (In "continuous sample" mode that input is not needed…)

 

Other items with you rproject:

  • learn about using arrays and autoindexing loop to handle your several channels instead of copying code several times!
  • learn about the meaning of "Rube-Goldberg"! There are some very classic ones in your VI… 😄
  • "100L Manage Channel": that BuildArray/ANDArray/NOT combination is the same as an ordinary NAND operation! (Rube-Goldberg!). There are also InRangeAndCoerce functions instead of all those comparison functions…
  • learn to avoid ExpressVIs and their DDT datatype: they offer no good…
  • learn to use less local variables…
  • learn to structure your code by using a programming scheme (e.g. statemachines…)
  • place a border on VI icons, otherwise they are hard to handle (like your RunningAverage)…
  • learn to use more efficient array handling: using InsertIntoArray most often is wrong…
  • renaming the main VI outside of the project is no good…
  • the "100L time out" will not work as a subVI…
  • much more…
Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 4 of 10
(598 Views)
The "100L Main VI V280.vi" file is missing.
0 Kudos
Message 5 of 10
(592 Views)

Thanks,

 

All of the feedback is good. I can look into the suggestions and hopefully move forward. 

 

So, do you think that most of my problem with inconsistency regarding the executable on different PC's stems from my programming lack of knowledge or something else? Should the executable run as well as the program does directly from the labview software?

0 Kudos
Message 6 of 10
(563 Views)

@JimFischer wrote:

Should the executable run as well as the program does directly from the labview software?


Everything else being equal, an executable is typically more efficient (removal of debug code and other ballast, etc.).

0 Kudos
Message 7 of 10
(559 Views)

Hi Jim,

 


@JimFischer wrote:

So, do you think that most of my problem with inconsistency regarding the executable on different PC's stems from my programming lack of knowledge…?


I think so… 😄

 


@JimFischer wrote:

Should the executable run as well as the program does directly from the labview software?


The main difference between running the VI in the IDE and in the EXE is the presence of debugging options in the IDE (by default). Apart from that the EXE should behave the same as the VI in the IDE (theoretically)!

 

In your case some of the items in my previous post are just "bad", like overuse of local variables and banging the DAQmx device with "1 sample" requests: this may produce different behaviour in the EXE…

Best regards,
GerdW


using LV2016/2019/2020 on Win8.1/10+cRIO
0 Kudos
Message 8 of 10
(557 Views)

I appreciate the help.

 

I will change the read suggestion first and start looking at some of the other improvements. I may have more questions in a bit. I don't mind making mistakes as long as I can learn and move forward. I was starting to get lost in the problem. Having a direction helps.

 

0 Kudos
Message 9 of 10
(550 Views)

As has been said, your VIs need some extensive review, because many things are just plain silly.

 

Many things have already been mentioned, here are a few more:

 

  • Note that you are inserting into an array of rates to be averaged over 100 iterations. For some unknown reason, you are starting out with an array containing already one element with a value of 1000, which will be included in the average and will cause bias and meaningless results. You need to start with an empty array and build it up (or much more efficiently with an array initialized to the final size where you replace element until all 100 are replaced!). I would probably average the loop taime and calculate the rate from that.
  • To get the actual loop rate average over 100 readings, all you need is the following little piece of code (Your incorrect use of expanded shift registers will give you the rate of an older iteration). You can feed that to a mean ptypt with a history length of 100, eliminating all your other code below it. And of you want the longest recent time, use a min&max ptbypt instead.

altenbach_1-1638823634318.png

 

 

This is just the tip of the iceberg! (since the first reading will be zero, you might want to reset the ptbypt VI if i=1, for example. Check the help)

0 Kudos
Message 10 of 10
(547 Views)