From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Start button xcontrol

Solved!
Go to solution
Solution
Accepted by topic author LarsM

First of all, thanks for contributing to the community. You start to dig into more advanced techniques of LV, so this is in general a good thing.

 

On the hand, i am with Altenbach: Your XControl to start the "edit mode" VI with a UI button element works, but it blurrs the reality. This is only a tool which works within development environment, but will fail for a "real application" because that is expected to be an EXE. See remarks of Altenbach (MS Word).

 

Your remark about "scripting" somehow fails since there are already two feasable ways to start the VI execution: Press the run button by mouse or press Ctrl+r. So you simply provide a third way for execution VIs in the development environment!

 

Regarding the discussion about data flow representation of code:

Greg is correct that a branch doesn't create a new thread. This would, in my opinion, also collide with "data flow" because such a feature would better be labeled as "execution control flow".

 

Data flow ensures two things:

  1. Order of execution. This is done by the very basic principal of LV: A node can only execute once it's inputs have valid values. If a node finishes execution, it passes valid values to each output as last action (with the exception of the flat sequence structure). You can display the flow of valid values using "Highlight Mode". But please note that this feature serializes execution making it effectively using only a single thread (no concurrency).
  2. Data management. During compilation of the block diagram, the LV compiler makes several transforms/optimizations on the code. Those decide about how many threads will be invoked during runtime as well as how many data copies of a single data will be created. The rule of thumb is that a branch creates a copy of the data, but this is not true for certain cases....

 

One additional hint:

Overuse of XControl will have a negative impact on edit AND runtime performance (required overhead to execute each XControl).

 

hope this helps,

Norbert

 

EDIT: Increased readability.

Norbert
----------------------------------------------------------------------------------------------------
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Message 11 of 14
(518 Views)

@Norbert_B wrote:

First of all, thanks for contributing to the community. You start to dig into more advanced techniques of LV, so this is in general a good thing.

 

On the hand, i am with Altenbach: Your XControl to start the "edit mode" VI with a UI button element works, but it blurrs the reality. This is only a tool which works within development environment, but will fail for a "real application" because that is expected to be an EXE. See remarks of Altenbach (MS Word).

 

Your remark about "scripting" somehow fails since there are already two feasable ways to start the VI execution: Press the run button by mouse or press Ctrl+r. So you simply provide a third way for execution VIs in the development environment!

 

Regarding the discussion about data flow representation of code:

Greg is correct that a branch doesn't create a new thread. This would, in my opinion, also collide with "data flow" because such a feature would better be labeled as "execution control flow".

 

Data flow ensures two things:

  1. Order of execution. This is done by the very basic principal of LV: A node can only execute once it's inputs have valid values. If a node finishes execution, it passes valid values to each output as last action (with the exception of the flat sequence structure). You can display the flow of valid values using "Highlight Mode". But please note that this feature serializes execution making it effectively using only a single thread (no concurrency).
  2. Data management. During compilation of the block diagram, the LV compiler makes several transforms/optimizations on the code. Those decide about how many threads will be invoked during runtime as well as how many data copies of a single data will be created. The rule of thumb is that a branch creates a copy of the data, but this is not true for certain cases....

 

One additional hint:

Overuse of XControl will have a negative impact on edit AND runtime performance (required overhead to execute each XControl).

 

hope this helps,

Norbert

 

EDIT: Increased readability.


 

Whoops! You're right about the exe! My control is useless! Well, that rendered this thread a tad superfluous.

 

You're right about the data flow stuff. I wasn't very precise in my text.

 

With that I guess this thread can be deleted.

 

 

Regards and thanks to you all for the answers.

 

Lars Melander
Uppsala Database Laboratory, Uppsala University
0 Kudos
Message 12 of 14
(508 Views)

@O.P. wrote:
With that I guess this thread can be deleted. 

It is important that the thread is not deleted, otherwise we will have the same discussion again in 6 months and we would need to start over from scratch. 😄

Message 13 of 14
(488 Views)

Hello again,

 

I discovered that if I remove run mode check the exe starts just fine. Problem solved for me. So why did I need a big start button? Here's why:

 

  • I'm designing the VI for people who want a big start button, but
  • they must be able to stop and restart the VI, plus
  • because of previously mentioned design criteria I can't use top level while loops.

So there, I've solved my problem, and I've explained that under certain conditions, a start button is needed.

 

 

Thank you

 

Lars Melander
Uppsala Database Laboratory, Uppsala University
0 Kudos
Message 14 of 14
(446 Views)