Local timing

[ErnieH]

I ran across this while I was editing a program. Basically, I want to update a table with a filename. The control is on the outside of the case statement.  I basically set it up and then the information for my program. I take the control data into the loop, edit it, then write it to a local. It was not updating the control on the next loop when it is read. I added a 5ms delay when I write the local, but it still did not work. I added 20 ms delay, and then it would work as expected. If I use a value property node, it would work also. I guess my question is, if you read a control after it was updated through a local, apparently before the local has update the value in memory, does the value then never get updated? It just loses it?

[tbob]

What actually doesn't work?  I'm confused.  Your code seems OK.  Are not seeing the updated data after this code is run?

If using a loop anywhere, be sure to add a small delay inside the loop to prevent using up 100% CPU time.  It could be that the CPU is so busy trying to run the loop as fast as possible, that other things, like updating the control from the local's value, takes longer than expected.  I've seen this before.  A small wait (10ms) inside the loop fixed the problem.  Maybe that is why the 20ms delay fixed the problem.  But the delay belongs in the loop, not buried inside a case structure which is inside the loop.

If using a Timeout case with the event structure, this is equivalent to adding a delay, as long as the timeout value is greater than the default of -1.  I can see a number wired to the hourglass, but I'm not sure if this code is inside a loop or not.

[GerdW]

Hi Ernie,

"if you read a control after it was updated through a local, apparently before the local has update the value in memory, does the value then never get updated?"

When you read the old value form the terminal, then the value doesn't get updated. Not nice, but so it is...

Why don't you use a shift register to hold the table? It seems, you write to the table in each iteration, so it is a indicator and should be used that way!

[tbob]

---

@GerdW wrote:

When you read the old value form the terminal, then the value doesn't get updated. Not nice, but so it is...

---

GerdW:  What you said is absolutely true.  But why does it work with a 20ms delay?  That is what the OP said.  Confusing!!!  I think the rest of the code holds a clue.  There is no indication that a loop is being used, hence there would be no place to put a shift register.  We need to know where he is attempting to read the control after it is being updated.

[ErnieH]

It is in a loop. It reads the terminal every iteration. So, if I read the terminal, update it through a local, and then read it the next iteration quickly,  it never gets updated. If I add 5ms and it still does not get update, how slow is it? Just trying to understand the timing or rules for locals. I already fixed the vi, just trying to understand why the local takes so long to update. I guess I am surprised that reading a terminal will cause it not to be updated and that update is lost, and 5ms after writing the local, it still does not update the front panel before I read it.  I inherit and maintain a lot of code, some of which use a lot of locals and globals.

[tbob]

From your picture, it looks like there is a case structure around the event structure.  Is your loop around the outer case structure?   You still should try to put a 10ms delay in the loop itself, outside of any structures inside the loop.  This may solve your problem.  Doesn't hurt to try.  It should not take that long for a local to update the control.

[tbob]

Here is some code sort of similar to yours.  It has a loop, and inside is a case structure with an event structure in it.  When the OK event fires, I add a character to the string, write it to the local, and get the string length.  After the event, I immediately read another local and get the length.  Run it and press the OK button.  Everytime it is pressed the string length increases by one.  The two length indicators always agree.  Also the string control on the front panel shows an update immediately.  This shows that the local updates the control very quickly.  The timer shows 0 sometimes and 1 sometimes.  This means that the local is updating within 1 ms.

There is something else in your code causing the local update delay.  Could it be the size of the FPGA FIles array?

[GerdW]

Hi tbob,

"What you said is absolutely true.  But why does it work with a 20ms delay?  That is what the OP said.  Confusing!!!"

From time to time such threads like this pop up. Sometimes it's about using locals, sometimes it handles "value" property nodes. But each time they are complaining "no update of the terminal". Most often it's a mixture of compiler optimization and resulting race condition, solved by delaying the next read access.

And most of the times the solution is to use a proper coding scheme - like a shift register...

[ErnieH]

The question I have, for future reference, is If I update a front panel variable through a local, how long before it is valid? If I read the front panel terminal before that happens, does the front panel control then never get updated and it loses that value. Does reading the front panel control cause it not to be updated? Basically, this is being used like a right once, read many variable.

[tbob]

Did you run the vi I attached a couple of posts earlier?  I was able to write to a local variable and then read from it less than one millisecond later, and it read the correct value all of the time.  So updating from a local to the control took less than 1 mS in my example.  However, my code was small.  If the code is large and there are a lot of thing going on in parallel, it may take longer.  There is no set time for updating.  That is why I said it may be something else in your code.  Perhaps code optimzation would be the thing to do.

One thing for sure, elimination of the local variable would be the best solution.  Now that I know you have a loop, you should use a shift register (as suggested by GerdW).  You can get the value anytime right off the wire.  No updating involved because the wire holds the data.  Depending upon how complex your code is, this may be the best course of action.  I noticed you had two nested cases, an event structure, and another case around the whole thing.  There may be more that I can't see.  Using a shift register would involve wiring in values for each case in every case structure.  If you use "Use default if unwired", you would lose the value whenever a non wired case executes.  So this solution may be complex to implement.

You should attach your entire code for us to take a look.  We could probably recommend some things to optimize the code.  I have a feeling that this is what will solve your problem.  Updating from a local variable, baring all other activity, is very fast.  Less than 1mS.