Local timing

[ErnieH]

Gentlemen, I am not looking for a solution for this problem, I already solved it. I just want information about the timing and rules are for locals. It appears my example should work and I created other examples that do the same thing and they do work. It is a small 3x3 table. I even allow 5 ms to the case and it still did not update when the loop re-iterated. I have used locals on occasion to update program variables, like in this case. I was under the assumption that if you wrote a local that it would eventually get updated. It did not in this case, and I only write it once from one area of code. So reading a terminal that you updated with a local will cause it never to update? Is there a maximum time you can wait to guarantee the terminal has updated? It seems like a very basic function here and one of the very few uses of a local. If this does not work reliably like in the in the above example, how can you ever use locals or globals? Again, I maintain and support a lot of software written by a lot of different engineers. I am not necessarily going to update every program because they use (and abuse) locals. This was such a simple example, I guess I am surprised it did not work.

[ErnieH]

Gentlemen, I am not looking for a solution for this problem, I already solved it. I just want information about the timing and rules are for locals. It appears my example should work and I created other examples that do the same thing and they do work. It is a small 3x3 table. I even allow 5 ms to the case and it still did not update when the loop re-iterated. I have used locals on occasion to update program variables, like in this case. I was under the assumption that if you wrote a local that it would eventually get updated. It did not in this case, and I only write it once from one area of code. So reading a terminal that you updated with a local will cause it never to update? Is there a maximum time you can wait to guarantee the terminal has updated? It seems like a very basic function here and one of the very few uses of a local. If this does not work reliably like in the in the above example, how can you ever use locals or globals? Again, I maintain and support a lot of software written by a lot of different engineers. I am not necessarily going to update every program because they use (and abuse) locals. This was such a simple example, I guess I am surprised it did not work.

[tbob]

---

@ErnieH wrote:

.... I was under the assumption that if you wrote a local that it would eventually get updated. It did not in this case, and I only write it once from one area of code. So reading a terminal that you updated with a local will cause it never to update?

---

Didn't you say that it worked if you delayed for 20mS.  So it did eventually update, didn't it.

I'm trying to tell you that the time it takes for locals to update the control is not the same for all cases.  It is not defined.  There are no rules.  There is no set timing.  It is not deterministic.

I showed in my example that it updates in less than 1mS.  I would expect it to update that quickly every time.  But it takes between 5 and 20mS in your vi.  Why the difference?  Something else is taking priority over the background Labview functions that updates the control.   Something in your code.

It is not a matter of locals not working reliably.  It is reliable.  I've shown this in my example.  But external factors can affect the time it takes to update.  One of those external factors is any code running in parallel.  Another external factor is any windows OS functions that need to be running due to your code execution (such as UI updates).  It should not take 20mS to update a control.  Something in your code is causing the delay.  If you don't think your code needs fixing, you will just have to live with the delay.

[ErnieH]

If I don't have a delay in that case, it never updates. I can read it forever and it never changes. So reading the terminal terminal, apparently before the local updates the memory, will cause this update to be lost. I can write examples that are faster and work. This one does not. So the code will start another iteration of a while loop before the local updates the memory for the control. Basically, if you use a local to update a control on you front panel, there is no guarantee that it will be updated.

[altenbach]

Instead of starting new threads about the same thing, please post some code, or at least tell us your LabVIEW version.

It is impossible to debug a picture, especially since most of the code is hidden, either outside the image boundaries or in other cases of the various case and event structures. If what you show is the bulk of the code and there is nothing funny elsewhere, the delay should not be needed. Please strip out all unnecessary code, make sure the observation is still there, then attach the VI. We can only help if we can reproduce the problem.

---

@tbob wrote:

Here is some code sort of similar to yours.

---

tbob, are you sure this is guaranteed to work? Since the wire branches to the local variable write and to the sequence frame, the local update at (A) can occur in parallel to the local read (B) and you potentially have a race condition. I probably wouldn't trust this. (This is LabVIEW 2010, so the locals look a little nicer ;))

[Yamaeda]

Oh yes, that's a race! I've had that happen to me in my project in an error handling case!

Either you have to:

1. add a frame before to make certain things are read and written in order (ugly solution)

2. connect the Concatenate string to Array/string length (the correct version).

/Y

[ErnieH]

The other thread contains specific questions about locals in general. The problem I encountered here, which raised some questions about local timing. This problem appears to be caused by clicking on the control and having the mouse click trigger an event. The event writes to the local, but the mouse click remaining in the cell will override it (sometimes) on the next loop. I was disabling the right mouse click (to get rid of the pop up menu) not the left, as the user must enter data in some cells and others I want them to select a file.

[altenbach]

---

@ErnieH wrote:

This problem appears to be caused by clicking on the control and having the mouse click trigger an event. The event writes to the local, but the mouse click remaining in the cell will override it (sometimes) on the next loop.

---

Looking at your code picture once more (which, as we already said, lack full information to reproduce the problem!), you are not using a plain "mouse down" event, but a filtering "mouse down?" event (notice the question mark). This can potentially complicate things.

Local variables are not your problem here.

[ErnieH]

Yes, that is true. Thought I put mouse down? but I didn't. The mouse down filter seems to cause the front panel control not to be updated when using a local with no delay. Does not happen when I use a value property node or allow 20 ms or so. My question was can a update to a local be lost, I would say no. This is seems to be a  one of a kind self inflicted problem of trying to do too much with the somewhat dated controls we have to work with (hint, we need better ways to present data if anyone is listening). As far as posting code, it takes a lot to rip all the code out, since it is confidential and cannot be posted.  I don't view this as a big problem. Anyway, here is a vi that shows what I was seeing. Note the timeout copy ( that simply displays the main control) has the updated value until I click away from the control. If I add a delay, it works as (I) expected.

[altenbach]

It seems that the simultaneous writing to the local while you are still manually editing the control causes interference:

Two possible solutions (pick one!):

1. right-click the main control...advanced...enable state...disabled.
2. WIre a TRUE diagram constant to the discard terminal of the event structure, so the mouse click does not get forwarded to the editing handling code. (The code in the event still executes, of course.)

Try it! 🙂