LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Front Panel Controls reset at every VI run.

Solved!
Go to solution

Hello Alten, Dennis.

 

I don't think i am doing anything advanced and i think the toplevel vi should give a basic overview on the data flow. 

Please find attached the top level vi.

 

The report generation is a part of the top level vi and that is where the issue is. 

 

Please share your thoughts on this.

 

 

Thank You,
RP. 

 

 

0 Kudos
Message 11 of 22
(1,703 Views)

Reread Jeff's message #4.

 

Then look at your code all the way to the upper left.

 

What do you know?  There is a ThisVI Default Vals.Reinit All Invoke Node sitting right there!!!!!  Smiley Frustrated

Message 12 of 22
(1,698 Views)

@RavensFan wrote:

Reread Jeff's message #4.

 

Then look at your code all the way to the upper left.

 

What do you know?  There is a ThisVI Default Vals.Reinit All Invoke Node sitting right there!!!!!  Smiley Frustrated


Nice to know my magic 8-Ball is still in allignmentSmiley Very Happy


"Should be" isn't "Is" -Jay
Message 13 of 22
(1,682 Views)

Hello, 

 

Found it and changed it to Make current values default. 

 

Now I encounter Error 1073: Property writable only when the vi is in edit mode. 

 

I think i can only make changes to the front panel control in edit mode. Which is fine by me, but now the vi does not run. 

 

I changed the node to Get all control and it works. 

 

I would also like to know if "get all control values" is the right way to go to solve the issue or is there another way the issue can be resolved. 

 

Thank You,

RP. 

 

 

0 Kudos
Message 14 of 22
(1,672 Views)
Solution
Accepted by topic author RandelPrandel

Just remove the node that initialzies all to defaults! Apparently you don't want it, right?

Message 15 of 22
(1,661 Views)

Hi Alten, 

 

Roger that. 

 

Thanks for the valuable input. 

 

 

 

Regards, 

RP. 

0 Kudos
Message 16 of 22
(1,658 Views)

Hello Alten, 

 

So, I did the needful and the code works like a charm. 

 

However, I do still encounter a specific error when i run the vi; 

 

Error: Input paramater invalid at Dequeue Element. Possibly an incorrect file path: contains . or @.

 

I went through your solution to this in another post and i checked the file path and refnum validation. Both look fine to me but i still encounter this error. 

 

Also, the redundancy of the error is a little weird. I initially thought closing the generated file before runnning the vi again was causing an error. But this attempt fell flat too. The redundancy of the error is sporadic. Sometime i run the vi multiple times and it works fine, other times the error pops up right at the first run. 

 

You can check the code in my previous attachment in this forum. 

 

Please share your thoughts on this. 

 

Regards, 

RP. 

 

0 Kudos
Message 17 of 22
(1,607 Views)

RandelPrandel wrote:

However, I do still encounter a specific error when i run the vi; 

 

Error: Input paramater invalid at Dequeue Element. Possibly an incorrect file path: contains . or @.


You have a race condition.  When you get the error, your top loop finishes and closes the queue before the bottom loop comes back around for it's final iteration.  Since the queue was closed, you get an error when you try to dequeue.  Your major problem here is that you could be losing data.  What I like to do with situations like this is to send an empty array in the queue.  The bottom loop then knows to stop when it dequeues an empty array instead of using the stop button.  You then close the queue only after both loops have completed (use the Merge Errors with the error cluster from both loops followed by the Destroy Queue).


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 18 of 22
(1,603 Views)

Hello Cross, 

 

I used the merge error and destroy queue and the error is gone. 

 

However, I haven't fed an empty array into the queue at the start. Just the merge error option did the job. 

 

I was wondering if you could explain or point out to some reading material which explains the advantages of feeding an empty array to the queue. The reason i ask this is because i don't see any apparent data loss. Is it explicitly used to eradicate data loss? 

 

Please advice. 

 

Thank You, 

RP. 

0 Kudos
Message 19 of 22
(1,594 Views)

RandelPrandel wrote:

I was wondering if you could explain or point out to some reading material which explains the advantages of feeding an empty array to the queue. The reason i ask this is because i don't see any apparent data loss. Is it explicitly used to eradicate data loss?


I don't know about any reading material.  I just learned that lesson by experience.

 

Let's just say the the producer loop iterates twice as fast as the consumer.  So for every iteration of the consumer loop, there's an additional element in the queue.  Just to keep it simple, let's say you press the stop button in time for the 10th iteration of the consumer loop to read the button press.  So when the consumer loop quits, you still have 10 elements left in the queue that will never get processed.  Data loss.

 

So you really should not stop the consumer loop on the button press.  You need a command in the queue to let the consumer loop it has processed all of the data.  My way of doing that is to send an empty array when the producer loop is complete.  So when the consumer loop dequeues an empty array, I stop the consumer loop.  Only then can I destroy the queue.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 20 of 22
(1,579 Views)