Labview Executable

[JimFischer]

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?

[altenbach]

• 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?

[JimFischer]

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.

[GerdW]

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…

[Gregory]

The "100L Main VI V280.vi" file is missing.

[JimFischer]

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?

[altenbach]

---

@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.).

[GerdW]

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…

[JimFischer]

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.

[altenbach]

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.

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)