dequeue error reading INI file

[nyc_(is_out_of_here)]

I am getting an error reading from INI file.

Is it a timing issue?

Two successive reads and the first read always has the error.

[RavensFan]

NYC,

You've been around long enough to know you need to post some code so we can have a chance to point you in the right direction.

My guess is that you have an invalid queue reference the first time you run it.  Perhaps a race condition where the queue reference wasn't obtained or sent to the dequeue element .

[Ben]

---

@nyc_(is_out_of_here) wrote:

I am getting an error reading from INI file.

Is it a timing issue?

Two successive reads and the first read always has the error.

---

I would have to guess that it a race condition where the config file had not been opened yet. I am a little confused about the mention of "Dequeue Element". At one time the ini files were written around a queue that was supposed to act like a Singleton.

Are you working in an old version of LV?

Ben

[nyc_(is_out_of_here)]

---

@Ben wrote:

---

@nyc_(is_out_of_here) wrote:

I am getting an error reading from INI file.

Is it a timing issue?

Two successive reads and the first read always has the error.

---

I would have to guess that it a race condition where the config file had not been opened yet. I am a little confused about the mention of "Dequeue Element". At one time the ini files were written around a queue that was supposed to act like a Singleton.

Are you working in an old version of LV?

Ben

---

I am working in LabVIEW 2015, and it has all the latest updates.

The entire main VI has five loops running concurrently.

The VI reading from the INI is used by the various loops especially when the main VI first starts up.

The VI opens,reads,closes the INI file.

So, I am thinking a race condition in which two loops try to read from the same INI file.

Any way that I can test this theory?

I was thinking of reading the INI file once instead of piecemeal.

.

[mcduff]

I had something similar happen to me, I had multiple loops starting up and communicating with each other via user events. Every now and then in the beginning a loop would miss a message because it had not spun up yet. I ended up using a subVI, based on subVI by Brian Hoover on LAVA, based on the Event Checker to see if all the loops have spun up before sending any messages.

Since you are using queues, maybe at the beginning check the status of the queue to see if it has a valid reference as part of your initialization process, before sending any messages.

mcduff

[nyc_(is_out_of_here)]

---

@mcduff wrote:

I had something similar happen to me, I had multiple loops starting up and communicating with each other via user events. Every now and then in the beginning a loop would miss a message because it had not spun up yet. I ended up using a subVI, based on subVI by Brian Hoover on LAVA, based on the Event Checker to see if all the loops have spun up before sending any messages.

Since you are using queues, maybe at the beginning check the status of the queue to see if it has a valid reference as part of your initialization process, before sending any messages.

mcduff

---

The queue in question is LabVIEW's own which is implemented in the  built-in NI_LVConfig.lvlib   ReadKey (Double).vi    seen in the error message.

I didn't know that reading from an INI file involves a queue!

.

[Bob_Schor]

---

@nyc_(is_out_of_here) wrote:

---

@Ben wrote:

---

@nyc_(is_out_of_here) wrote:

I was thinking of reading the INI file once instead of piecemeal.

---

It has been a long time since I used the Configuration File routines (I'm partial to XML), but I thought I remembered that (like XML) all the Reading and Writing were done "all at once" (or, alternatively, "invisibly"), and you then "retrieved" the information you needed.  I do recall that when I did use them, I did do the "all-at-once" business.

Bob Schor

[Ben]

---

@nyc_(is_out_of_here) wrote:

---

@Ben wrote:

---

@nyc_(is_out_of_here) wrote:

I am getting an error reading from INI file.

Is it a timing issue?

Two successive reads and the first read always has the error.

---

I would have to guess that it a race condition where the config file had not been opened yet. I am a little confused about the mention of "Dequeue Element". At one time the ini files were written around a queue that was supposed to act like a Singleton.

Are you working in an old version of LV?

Ben

---

I am working in LabVIEW 2015, and it has all the latest updates.

The entire main VI has five loops running concurrently.

The VI reading from the INI is used by the various loops especially when the main VI first starts up.

The VI opens,reads,closes the INI file.

So, I am thinking a race condition in which two loops try to read from the same INI file.

Any way that I can test this theory?

I was thinking of reading the INI file once instead of piecemeal.

.

---

I think that is what I had guessed. I will et you chase it down in the code but I suspect one loop is closing the file before the second has completed the read. Call your tow loops A and B.

A opens the file and the queue gets created

B Opens the file and the queues already exists

A Reads from the file.

A closes the file

B attempts the read.... Error because the queue was destroyed.

Now it you wrap-up the Open- Read- Close in a single non-reentrant sub-VI, and use that VI in your three loops I think you will fix your problem.

We have a re-use library that keeps a count of how many times a file has been opened and only closes it when the count drops to zero.

But a single wrapper should clear up the problem you are seeing.

Ben

[crossrulz]

---

@Ben wrote:

I am a little confused about the mention of "Dequeue Element". At one time the ini files were written around a queue that was supposed to act like a Singleton.

---

And it is still a Single Element Queue inside of the Configuration File library.  One of my suggestions for NI is to rewrite this library using a DVR since those are more performant.

[crossrulz]

---

@Ben wrote:

---

I think that is what I had guessed. I will et you chase it down in the code but I suspect one loop is closing the file before the second has completed the read. Call your tow loops A and B.

A opens the file and the queue gets created

B Opens the file and the queues already exists

A Reads from the file.

A closes the file

B attempts the read.... Error because the queue was destroyed.

---

Nope.  The queues are unnamed inside of the configuration file library.  So two separate calls to the Open Config Data will not collide.

My main guess is there is a miswire so that the proper reference is not going to a Read Key VI, which will result in an invalid reference to the queue.  Again, we need to see code.