writing properties to text ring is indeterminate

[dgholstein]

My application writes user-selectable information to the "Strings[]" property of text rings. I find that even with 200 ms delays in the loop, the "Strings[]" property read from that same control may be different than what I wrote.

I've also found that setting the advanced option of "synchronous display" does not affect the results. Inserting a breakpoint will make the VI operate properly, sometimes copying to an indicator helps (though is not consistent).

[chrisger]

hi there

i checked that with LV 7.0 WinXP SP2. it works fine without any delays, except when i write an empty string array to the property. in this case the property returned is a string array with an empty string as its single element. please post your vi here so we can have a look.

best regards
chris

[chilly_charly]

This may be due to a race between the reading and writting operations : in this case, the fact that the read string corresponds to the previous entered string should be symptomatic. Remember that LV executes an operation as soon as input data are available. You can define the order in which they are executed by linking in some way both operations (add some dependance, for instance in connecting the "Strings[]" properties through the error out/inputs) or by using a sequence structure.
CC

[dgholstein]

I already tried wiring as you describe, I've even put it into a sequence and that didn't work. The odd part is that it all worked well until I started using a DLL to access an Oracle ODBC driver, before that, my DLL was accessing either the MySQL API or MySQL ODBC.

I forgot to mention, probes fix the problem as well--it's like Heisenberg's uncertainty principle, anything done to observe the effect, in turn, modifies the results.

I'd attach the VI but it is really a system, with several layers of sub-VIs, DLLs, Oracle DB and multiple Oracle schemas.

I also know that UI properties are not treated the same as local variables (learned that the hard way with RT). The statement that "LV executes an operation as soon as input data are available" is
NOT TRUE for UI properties (per NI documentation). The property nodes give the programmer a great tool but it's implementation is weak and not stable (for complex VIs).

[chilly_charly]

Well, seems that the end of the road for me. If, as an advanced user, you can't locate the problem, the best thing you can do is to post the question again, giving more details, just to catch the attention of "top level " users. You should also ask directly NI support...

[Ben]

I beleive CC was correct in calling this a race condition.

Almost every time I saw a problem go away in execution highlighting, it ends up being a race condition (hardware is the exception).

In execution highlighting, the code executes as if it is single threaded.

Try turning off multi-threading (tools >>> Options >>> Performance and Disks >>> Run with multiple threads, unchecked and restart LV)and see if your problem goes away.

Ben

[dgholstein]

Thank you so much for the input, I found the problem though.

It turns out the calls to the Oracle ODBC driver randomly returns an empty table list (NULL string array). Placing a breakpoint or probe there slowed it down enough to more-consistently return the proper result set. Since I was placing this (sometimes blank) result set into the properties of a text ring, it looked like a LV properties problem.

Note, the problem never showed up while running the sub-VI only once, it did show up while running continuously.