Front Panel Controls reset at every VI run.

[RandelPrandel]

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. 

[RavensFan]

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!!!!! 

[JÞB]

---

@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!!!!! 

---

Nice to know my magic 8-Ball is still in allignment

[RandelPrandel]

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. 

[altenbach · Accepted solution]

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

[RandelPrandel]

Hi Alten, 

Roger that. 

Thanks for the valuable input. 

Regards, 

RP. 

[RandelPrandel]

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. 

[crossrulz]

---

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

[RandelPrandel]

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. 

[crossrulz]

---

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.