Property node error in parallel loops

[andyforpresident]

Hi all,

I am running two VIs under LabVIEW2014 SP1 simultaneously and each one contains a loop doing something. In this case one VI loops reading a string control via property node and the other VI loops showing an empty IMAQ-Image. After some loop iterations the property node reading the string value throws an error which I don't understand. The error occurs again and again.

Can anyone reproduce this behaviour and/or knows the issue about this?

[Oksavik]

I tried running "Update string forever.vi", and did not encounter any error messages.

Does the error only happen when you run both .vi at the same time?

What is the error message?

Regards,

Oksavik

[Norbert_B]

You are running into a race condition. The race is about the two VIs competing against each other for the UI thread.

The error situation only occurs in case both VIs do not wait.

That being said, the solution is to use proper waiting times like 100+ ms instead of 0.

Norbert

[andyforpresident]

Thanks for your answers...

In my case this is only a test scenario derived from a much bigger software where waiting times of multiple miliseconds are not tolerated and more than two loops run at the same time. I placed a waiting time of 0 miliseconds to release the cpu but that doesn't help at all.

[Norbert_B]

Handling UI and "waiting times of multiple milliseconds are not tolerated" are exclusive to each other. Your UI thread is the creator for the issue and you have to make sure that it is not so heavily loaded.

Make sure to use as little amount of property nodes as possible and run code (e.g. DLLs) in "any thread" instead of the UI thread if possible.

---

@andyforpresident wrote:

[...] I placed a waiting time of 0 miliseconds to release the cpu but that doesn't help at all.

---

This does not help the UI thread or the CPU. It is only a compiler statement that the scheduler might behave different during runtime regarding multiple threads to be scheduled on the CPU core(s). I would assume that removing the waitings (0) doesn't change a thing as the VIs should already run on different cores but having to sync for the UI thread.

Norbert

[andyforpresident]

Increasing wait times does not erase the error it just delays it...

[mikeporter]

You still haven't said what the error is.

Mike...

[Norbert_B]

---

@andyforpresident wrote:

Increasing wait times does not erase the error it just delays it...

---

How long did you wait for the error to popup and what was the delay you used?

Also notice that replacing the property node "Value" of the string with a local variable of string gets rid of the error. Please note that a variable has its disadvantages of its own....

Norbert

[natasftw]

If your end application cannot possibly wait multiple milliseconds, why are you developing this in Windows?  It's going to wait multiple milliseconds whenever it feels like and there's nothing you can do to prevent that.

[altenbach]

---

@andyforpresident wrote:

Can anyone reproduce this behaviour and/or knows the issue about this?

---

Sorry, I don't have IMAQ, so I cannot test, but you are apparently stating that the string property node throws an error. As Mike already said, you have not told us what that error is. I also must have downloaded a different set of VIs, because what I am looking at here reads a property node of a string indicator (not control!) and writes it back to itself. What can possibly be the pupose of all this? Maybe the error is irrelevant and you can just suppress it by wiring the error out to the loop boundary?

Is there something else that changes the string? (After all, It is an indicator and thus cannot be changed by the operator!) If the string is changed programmatically, there is no need to read a value property of it and again write it back to the string. This does not gain you anything over just having the plain string terminal sitting disconnected outside the loop.

Can you explain what you are trying to do here? There has to be more to it!