Losing data along wire when not in Highlight Execution

[billko]

---

@RavensFan wrote:

They are referring to the picture in message #10 where probes 2 and 4 "appear" to be on the same wire in the same structure, i.e. between the case structure and the while loop.

---

[billko]

I don't see any errors on your error control or indicator, but I do see that your error wires run through some important stuff and the code isn't isolated from an outside error, so an error going into the F/G may produce default values on the output.

For a F/G having to do with references, I have the error wire running along outside the F/G structure so everything will execute regardless of input error.

Edit:

I've since abandoned F/G for references in favor of initializing them and sticking them in a global.  (I don't ever re-initialize them, so I don't encounter race conditions.)

[GammageATX]

I'm running the FGV on it's own so input errors shouldn't come into effect here, but I went ahead and isolated it anyway. I added a probe so you can see that the initialize case should be the one firing, and yet probes 6 and 7 still have different data.

I'm relatively new to LabVIEW, but I don't see where a race condition could come into this, especially when it's not being using as part of a larger VI.

[Mark_Yedinak]

Where are you calling this FG from? Do you call it in more than one place in your code? Is it ever possible to be called in parallel from your higher level code? What is the code inside your initialize VI?

[altenbach]

---

@GammageATX wrote:

I'm relatively new to LabVIEW, but I don't see where a race condition could come into this, especially when it's not being using as part of a larger VI.

---

Sorry, I don't have DAQmx, so I cannot run your VI. All works correctly for me if replace the task with a DBL (and remove the missing subVIs and disconnect from the missing typedef), leaving all wiring as is. Hard to tell what's going on in your case, but something is not right. No matter how, and how often you call it and irrespective of the enum value. Probes 6 and 7 should match in value except for the nanosecond where only the first one has updated yet, i.e. something you'll never see.

[Mancho00]

If there really were two probe points on the same wire (as shown in message 10), then I think the LabVIEW installation itself may be suspect.

[GammageATX]

I call it 3 times in my code, once to initialize, once to retrieve the task wire, and once to exit. There shouldn't be any way for those to overlap due to managing flow with error wires, but I've attached both my main program and the initialization code here anyway.

However, the main program doesn't even come into the specific problem seen with the probes, as I'm running the FGV as its own VI to get that information, not calling it from outside.

[altenbach]

---

@GammageATX wrote:

However, the main program doesn't even come into the specific problem seen with the probes, as I'm running the FGV as its own VI to get that information, not calling it from outside.

---

Exactly. No need for all that extra code. As I already said, something is wrong here.

• Maybe something in your VI is corrupt (try to force a recompile)?
• Maybe the compiler makes a mistake (try to place an always copy somewhere near probe 6)
• Maybe your installation of LabVIEW is corrupt? (Repair or reinstall, incl. DAQmx, but try the above first)

[Kevin_Price]

Piggybacking on altenbach's suggestion #2 about a possible compiler mistake:

I *think* I have an old, vague memory of encountering a similar puzzling situation with a DAQmx task probe that showed content in some probe locations but not others.  Unfortunately, I have no recollection whatsoever of how that situation resolved itself.  It just makes me inclined to consider the possibility that a DAQmx task refnum can behave a little different than common data wires like numbers, strings, and booleans.

I can't open any of your code b/c I'm still at LV2016.  My working hypothesis in this post is that your simplified example *might* have a different root cause than your much more involved original code back in msg #1.

Your simplified code initializes a DAQmx task and then performs absolutely no apparent useful DAQmx functions with it.  Consequently I think that when you run stand-alone, there's a possibility that the compiler is "getting a head start" on its cleanup and garbage collection for your unused DAQmx task.  Perhaps the probe outside the loop is showing the task refnum value *after* the auto-cleanup has occurred.

So in addition to the recommendation to try an "always copy", also try putting some DAQmx operations (Start, Stop, Is Done query, etc.) after the loop and placing probes before and after each of them.

Now, even if this solves the problem of the simplified stand-alone code, it may have no bearing on your original more complicated code.  There should be no auto-cleanup going on when the FG is held in run state by your larger app.

   (However, if you were testing your original code in stand-alone mode, auto-cleanup could indeed be relevant.)

-Kevin P

[GammageATX]

Maybe something in your VI is corrupt (try to force a recompile)? Maybe the compiler makes a mistake (try to place an always copy somewhere near probe 6) Maybe your installation of LabVIEW is corrupt? (Repair or reinstall, incl. DAQmx, but try the above first)

I tried the first two suggestions and no dice. If I have to, I'll reinstall, but I'd rather not come to that.

---

@Kevin_Price wrote:

Piggybacking on altenbach's suggestion #2 about a possible compiler mistake:

Your simplified code initializes a DAQmx task and then performs absolutely no apparent useful DAQmx functions with it.  Consequently I think that when you run stand-alone, there's a possibility that the compiler is "getting a head start" on its cleanup and garbage collection for your unused DAQmx task.  Perhaps the probe outside the loop is showing the task refnum value *after* the auto-cleanup has occurred.

So in addition to the recommendation to try an "always copy", also try putting some DAQmx operations (Start, Stop, Is Done query, etc.) after the loop and placing probes before and after each of them.

-Kevin P

I tried adding some DAQmx functions and that didn't work either, unfortunately I did find one way to get the reference out, which is to attach a local variable to an indicator inside the while loop, as seen below, so that no wire crossed out of the loop. Unfortunately, I can't seem to make this strategy work to pass along the reference for the Get and Exit cases.