Indicator output value resets every other time sub VI is called

[amcmahon]

Hi All,

I have a sub VI which loads some values from a file and populates a table indicator which is passed to the calling VI.  Every other time the sub VI executes, the table (and output) resets to it's default values immediately upon the sub VI finishing execution (and the output of that call is affected).  I tried wiring an empty constant to the table to ensure it is cleared at the beginning of execution which seemed to have solved the problem when the sub VI's front panel is open, but when it is closed (usually the case being called from the main VI), the behavior persists.  With breakpoints in place, the table retains it's values until the last step of execution (when paused the whole sub VI window has a dashed line blinking around it), but still resets on resume and returns the wrong (default) values.

Attached is a snippet of the call from the main VI, the sub VI and a sample "sequence" file that it would open.  Also, I'm running LV 2013.  Any thoughts would be appreciated (hopefully I'm not missing something too obvious).

Thanks,

Andrew

[P@Anand]

The issue is because you have kept the indicator in the 1st sequence and it executes before the value gets updated to it. Add a frame after the execution and keep the Table indicator there and check how it works. You always have to keep the Control and indicator out of the structures as a good coding practice (There is a Nugget which tells about this, I am missing the link)

[ghighuphu]

I did not find the nugget, yet, but here is an answer on a thread with a similar issue:

http://forums.ni.com/t5/LabVIEW/case-structure-parameter-efficiency/m-p/382563/highlight/true#M19164...

[P@Anand]

---

@ghighuphu wrote:

I did not find the nugget, yet, but here is an answer on a thread with a similar issue:

http://forums.ni.com/t5/LabVIEW/case-structure-parameter-efficiency/m-p/382563/highlight/true#M19164...

---

Thanks. That is the link I was looking for to provide a reference.

[amcmahon]

Thanks for that thread, I hadn't thought about the idea of sub VI acting in place vs allocating new memory, etc., that's very interesting and good to know.  However, with my indicator on either the top level or in an additional frame at the end of the sequence, the behavior still exists.  Does the use of property nodes (access via reference) inside the structures play into this?

To clarify the "every other execution" behavior, it resets to default value if the data in the table matches the data that is read in from a file.  If I change one cell prior to execution (or one value in the file being read), it reloads the data correctly.  So if you run it multiple times without any changes, the first time it loads the data, then on the next execution that data matches what is being read in and it is reset at the end of execution.  On a third execution, it is starting with it's default values (not what is in the file) and reads in the data correctly again.  This test can be done calling from my main VI or executing the sub VI alone.  Why would having the new data match the starting values cause it to reset, even if I clear it at the beginning of every execution (the original reason for putting the indicator in the sequence structure)?

[P@Anand]

I am  not very clear about the behaviour. For a try can you replace the Table in the Sub VI with a 2D string array and feed the key values as an input from the main VI and see what happens? I am sure the solution would be much easier  than we expect, but something is missing.

[crossrulz · Accepted solution]

I would avoid using the property node, especially inside of the loop.  Each time you call that property node, you are forcing the front panel to redraw.  Instead, build up the 2D array using autoindexing on your FOR loops and write directly to your indicator.

[amcmahon]

---

P@Anand wrote:

I am  not very clear about the behaviour. For a try can you replace the Table in the Sub VI with a 2D string array and feed the key values as an input from the main VI and see what happens? I am sure the solution would be much easier  than we expect, but something is missing.

---

Before I saw your post I found a "solution" that works.  I added a table as a control, linked the two property nodes to that and then update the indicator from the control at the end of the sequence.  This consistently loads and outputs the correct values (though it does violate the practice of avoiding outputs in structures).  My "fixed" sub VI is attached for reference.

That being said, when I have a few minutes (maybe this afternoon or Monday), I am going to try what you suggest to try to better understand the behavior, because I would still really like to find the underlying cause.  Since the control doesn't demonstrate the behavior, it would seem that maybe it is something inherently related to indicators.  I will keep you posted on any findings.

Thanks again for the insight.

[amcmahon]

---

@crossrulz wrote:

I would avoid using the property node, especially inside of the loop.  Each time you call that property node, you are forcing the front panel to redraw.  Instead, build up the 2D array using autoindexing on your FOR loops and write directly to your indicator.

---

Thanks!  This sovles the problem in a simpler and more efficient way.

Though I am still curious about the resetting to defaults on sub VI exit when not directly writing to the table.