Possible bug: Local variable writeback ignored if it's too fast

[Underflow]

Just ran into something odd when writing a console style interface.

The console takes a command (on the left hand string control), followed by an enter.  It gets a response from the top loop, and sends it via queue to the bottom loop.

In the bottom loop, the response is concatenated with the current value of the string control, and written back to the string control itself via a local... or at least, it should be.  Often, the write back to the string control local doesn't actually write to the control.

Enabling the disabled 10 ms delay in the lower loop allows the correct writeback to occur.  Alternatively, using a value property node rather than a local also works... though that may just be inducing enough delay for it to work.

Anyone able to confirm this one?

Thanks, Joe Z.

[GerdW]

Hi,

using LV8.6.1 looks fine:

Message Edited by GerdW on 07-23-2009 10:20 PM

[Underflow]

Crossposted to LAVA: http://lavag.org/topic/10568-string-control-writeback-via-local-not-writing-back/

[Underflow]

Look again.  The local variable for the control on the left and the string indicator on the right are being written in the same frame.  They should be identical after an entry.

Good idea on the minmax.

Joe Z.

[RavensFan]

I think I see the differences you are talking about once I enable the 10msec wait.

I don't understand what you are doing though.  You enter data into the queue (which comes from a series of characters you just typed into the console window.).  Then you put the new data into a queue.  You dequeue that and take the control (which should have the new data already put into it, and append the new data to it).  Although it doesn't quite seem to be doing that.

What is your goal here?  Your methods seem a bit convoluted to me.

I would suspect a race condition.  Any time something behaves differently by putting in a wait statement, a race condition is the likely cause.  Using a property node is a bit slower than using a local variable, so perhaps that is why is works as well as putting in the wait statement.  You should try doing it with highlight execution turned on as well (though that is painfully slow).

Message Edited by Ravens Fan on 07-23-2009 04:40 PM

[Spectre_Dave]

It works on my PC without the delay

 Windows xp SP2

LabVIEW 8.6.1.f1

HP 8400 Workstation

[GerdW]

Hi Joe,

now I got it...

I attached a possible workaround. As you already check for keypresses you can do that entirely on your own...

I also think of a (kind of) race condition because of your event structure used for filtering keypresses...

[RandyR]

Put a Console Window.Key Focus = False in the frame before the write to local...

[Underflow]

Ravens Fan,

Good to hear from you again 🙂

The goal is to emulate the interface on programs like hyperterminal.  In the real program, there is a serial comm VI in the upper loop, rather than just feeding back a formatted string.

I'm open to reasonable suggestions for alternative implementations.

Joe Z.

[Underflow]

VADave,

Thanks!

RandyR,

Thanks, I noticed that as well.  Again, not sure if that is just allowing more time for the operation, or if it's something else.

Joe Z.