Event in 1st "While Loop" must stop 2nd "While Loop"

[Pavel_47]

Not-keeping default values issues resolved: I had been mistaken - being in harry, instead of save as default values I made "default types".

But neverteless even I restart VI, the old values for frequency and amplitude still remain.

Does exist something like TOTAL RESET of VI.

Thanks.

[altenbach]

---

@Pavel_47 wrote:

Not-keeping default values issues resolved: I had been mistaken - being in harry, instead of save as default values I made "default types".

But neverteless even I restart VI, the old values for frequency and amplitude still remain.

Does exist something like TOTAL RESET of VI.

---

Is its either:

"right-click...data operations...make current values default"

or

"select control...menu...edit...make selected values default"

What do you mean by "total reset of VI"?

You can do "menu...edit...reinitialize values to default", but that won't clear uninitialized shift registers or chart histories. You can also do it programmatically with an invoke node.  If you have done some editing, you can do "menu...file...revert". 

Why don't you attach your code?

[Pavel_47]

Unfortunately I can't test your suggestions because already at home and have no access to device ... will try it tomorrow.

But I kept the code (in attachment).

By "total reset" I mean some action the put VI in a state as if it was just created (just before 1st run) ... all buffers are empty, all variables are at theirs initial states, etc.

Because what I observed make me think that some history traces are active and influence the VI behavior.

Thanks in advance.

[Hatef.fouladi]

Hi Dennis_Knutson than you for your advice 

""No, using a property node instead of a local or global is not a good solution. Nor would it require an extra cycle even if it was used.""

but could you explain more ? because I was use it this method in one of my project and I need to know what is the problem ?
I just know that this method is not good for time cycle under 100ms also the second loop will be iteration  one more time that first one 

[RavensFan]

Because a property node runs about 100 times slower than a local variable.

If you don't need the features of having the error wire, or havint the ability to programmatically select the control reference that the property node applies to, then there are no advantages to the value property node and only disadvantages.

The second part of what you say "I just know that this method is not good for time cycle under 100ms also the second loop will be iteration  one more time that first one" is not accurate at all.  It has nothing to do with loop speed or number of times it runs, other than you are playing guessing games on the race condition as to when the stop value is read vs. when the rest of the code in the loop finishes.

Attached is a better way to code this.  Also, your stop button had the wrong mechanical action.  Switch Until Released is just not right, and is pretty rarely used.  Switch When Released is what functions properly.  Normally you' use a Latch Until Released for a stop button, but you can't use the latch action if you are using local variables or value property nodes.  So instead, use the switch action, and programmatically reset the switch back by writing a False constant to the local variable.

[Hatef.fouladi]

---

@RavensFan wrote:

Because a property node runs about 100 times slower than a local variable.

If you don't need the features of having the error wire, or havint the ability to programmatically select the control reference that the property node applies to, then there are no advantages to the value property node and only disadvantages.

The second part of what you say "I just know that this method is not good for time cycle under 100ms also the second loop will be iteration  one more time that first one" is not accurate at all.  It has nothing to do with loop speed or number of times it runs, other than you are playing guessing games on the race condition as to when the stop value is read vs. when the rest of the code in the loop finishes.

Attached is a better way to code this.  Also, your stop button had the wrong mechanical action.  Switch Until Released is just not right, and is pretty rarely used.  Switch When Released is what functions properly.  Normally you' use a Latch Until Released for a stop button, but you can't use the latch action if you are using local variables or value property nodes.  So instead, use the switch action, and programmatically reset the switch back by writing a False constant to the local variable.

---

Indeed I know about what you told but I don think that they make problem in such condition but your text was really complete and helpful about it 
thank you for that 

[=Jean]

Dynamic Events, Queues, Notifiers, FGVs are examples of design patterns to stop multiple loops in parallels and to be sure to avoid race conditions (well .. almost ..). LV Core 2 taught you some of these, have a look at it.

[dkfire]

Pavel_47: How are you stopping your vi?

You have a loop that can never be stopped, due to the False constant that you have wired to the Conditional stop terminal.

If you use the Abort button, then stop doing that now. Your DAQ clean up code will never run, that the DAQ tasks will never stop.
Check your error wires for any errors in the system.

[Pavel_47]

Hello Altenbach

I've tried your suggestion - unfortunately problem persists.

I sent this issue to NI support

Best Regards

[Pavel_47]

Hello Dkfire,

It looks like cycle of 2 steps:

I start VI and it stops itself

Then I restart it, nothing happens and I click on "Abort Execution"

Then this 2-step behavior repeat.

But what is surprising - this morning I run the VI after powering both - USB-6343 and PC with LabVIEW ... and it still started with amplitude/frequency that I saved as default YESTERDAY.

Concerning errors ... I have 2 error paths on generating and acquiring - nothing happens (at least no error message appear)