Losing data along wire when not in Highlight Execution

[GammageATX]

I'm currently writing code to control some hardware. I have an FGV that I set up to pass the DAQ/VISA information throughout the main program. When I run the code in Highlight Execution mode, it works as intended. When I run it normally, data is somehow lost along a wire, as shown below with probes. How can I fix this?

[RavensFan]

Your innermost case structure has unwired cases for the purple tunnel.  I can tell because the tunnel is "semi-hollow".  If all were wired, it would be solid.

Right click all your tunnels and uncheck, "Use Default if Unwired".  Your VI will break until you go in and wire up that purple wire across all cases.

[GammageATX]

I'm aware of that. It's because I have an "Exit" case which doesn't return any task. However, I just went through and hooked up an empty constant to those tunnels and am still having the same problem. I also sometimes don't have any data on the purple wire at all, though it seems this can be helped by adding a wait to the innermost case structure.

[Mark_Yedinak]

If it is working with execution highlighting turned on and not when it is off it sounds like you have a race condition in your code somewhere. Without seeing more of your code it would not be easy to tell where that race condition is occurring.

[RavensFan]

Attach your VI.

Just adding empty constants to multiple cases doesn't help if you are executing a case and it should be holding onto the value.

Is there any chance a case is executing somewhere that you aren't expecting it to?

What is the "Default" case in that case structure.

Perhaps you are using it and the Action connector is unwired by mistake, it executes the default case, and that case is not passing through the value on the wire.

Seeing the actual VI let's us see what other cases look like and tell if anything is obviously wrong.

Adding a wait to the innermost case structure "helps".  Does it fix it?  Or does it still happen, but not as often?  Wait functions that miraculously fix code usually means you have race condition somewhere.  They don't usually fix code, they just hide the symptoms for awhile.

[Mancho00]

Probe points 4 and 6 were last updated nearly thirty minutes apart, so obviously that case didn't get executed.

[RavensFan]

---

@Mancho00 wrote:

Probe points 4 and 6 were last updated nearly thirty minutes apart, so obviously that case didn't get executed.

---

That doesn't help explain anything.  What is "that case" you refer to in your message?

Probe 4 executed when Initialized run 30 minutes ago.  I would expect that to happen once soon after the program starts.  Other cases  are going to execute numerous times at various times based on when and where you call those other cases.  We know probe 5 and 6 just occurred.  They will execute every time the VI is called.  But we don't know what what executed right before.  I'm guessing it went through a case where it was unwired and the default value of an empty reference came out.

Your best debugging tool might be to add a subVI inside of this that every time this action engine is called, it outputs to a data file, the time, the value of the enum, and any other useful information like the value of the reference (won't mean much, but you'll be able to see when it changes or disappears), or other pieces of data.

[Mancho00]

---

@RavensFan wrote:

---

@Mancho00 wrote:

Probe points 4 and 6 were last updated nearly thirty minutes apart, so obviously that case didn't get executed.

---

That doesn't help explain anything.  What is "that case" you refer to in your message?

---

Of course it does. "That case" refers to the only case we've been shown or have any knowledge of.  It was the OP's contention that the wire "lost" the data, and probe points were shown to support that.  I'm merely pointing out that the probe points were updated at different times. This shows that "that case" (showing probe point 4) was not the case that set the value at probe point 6.

[RavensFan]

Nobody is arguing that the wire lost data.  But knowing that it had the data one time 1/2 hour earlier when the Initialize case did get executed, and that now (1/2 hour later)  the wire after the case structure doesn't have doesn't tell us anything about why it lost data.  We can't tell from that picture what case was executing when the later timestamp was capture in the probe.  We can't tell what case was executing before this time, before that time, or whenever that caused the wire to lose data.

Doing a more targeted debugging of this can help figure that out.  Logging as it goes can help.  Putting in a conditional breakpoint that stops the code as soon as that wire as an empty reference can help.

Heck! Attaching an actual VI that allows us to see what are in the other cases can help others figure out where the problem might be occurring.

My theory is that one of those cases that does not have a wire going the case structure is executing.  Knowing which case that is and whether it is executing when it is supposed to is the key to solving the problem.

[GammageATX]

Sorry for the delay. I'm attaching a simplified version of the VI, as well as an image that more clearly demonstrates the problem.