10-28-2021 12:11 PM
Here the "FP.Close" runs before the case structure! The darned compiler knows that the reference will be unchanged, so it doesn't wait for the case.
Solved! Go to Solution.
10-28-2021 12:22 PM - edited 10-28-2021 12:27 PM
@paul_cardinale wrote:
Here the "FP.Close" runs before the case structure! The darned compiler knows that the reference will be unchanged, so it doesn't wait for the case.
So you're trying to be cute (but also correct) by wiring the reference through the case structure to create an "artificial" dataflow dependency, and the compiler outsmarts you by compiling as if you had the reference wire outside the case structure. So how did you fix it? Error cluster inside the case structure going to error in on front panel close?
This is alarming to me.
10-28-2021 12:32 PM
Well, I believe NI says not to wire through a structure unless something somewhere in the structure needs the data, so I guess there's that...
10-28-2021 12:50 PM
@billko wrote:So you're trying to be cute (but also correct) by wiring the reference through the case structure to create an "artificial" dataflow dependency, and the compiler outsmarts you by compiling as if you had the reference wire outside the case structure. So how did you fix it? Error cluster inside the case structure going to error in on front panel close?
Synchronize Data Flow.vim could be used (one input being the panel reference, another being the error).
10-28-2021 01:06 PM
@crossrulz wrote:
@billko wrote:So you're trying to be cute (but also correct) by wiring the reference through the case structure to create an "artificial" dataflow dependency, and the compiler outsmarts you by compiling as if you had the reference wire outside the case structure. So how did you fix it? Error cluster inside the case structure going to error in on front panel close?
Synchronize Data Flow.vim could be used (one input being the panel reference, another being the error).
Nice. I suffer from being too lazy to learn all the new stuff from version to version. In fact, it's posts like yours that cause me to add another tool to my tool bag.
10-28-2021 01:09 PM
@billko wrote:
@paul_cardinale wrote:
Here the "FP.Close" runs before the case structure! The darned compiler knows that the reference will be unchanged, so it doesn't wait for the case.
So you're trying to be cute (but also correct) by wiring the reference through the case structure to create an "artificial" dataflow dependency, and the compiler outsmarts you by compiling as if you had the reference wire outside the case structure. So how did you fix it? Error cluster inside the case structure going to error in on front panel close?
This is alarming to me.
Here's how I fixed it:
10-28-2021 01:46 PM
@paul_cardinale wrote:
@billko wrote:
@paul_cardinale wrote:
Here the "FP.Close" runs before the case structure! The darned compiler knows that the reference will be unchanged, so it doesn't wait for the case.
So you're trying to be cute (but also correct) by wiring the reference through the case structure to create an "artificial" dataflow dependency, and the compiler outsmarts you by compiling as if you had the reference wire outside the case structure. So how did you fix it? Error cluster inside the case structure going to error in on front panel close?
This is alarming to me.
Here's how I fixed it:
Looks like "Rube-ish" (pun intended) at first glance, but when you know the reasoning behind it...
10-28-2021 02:31 PM
I, for one, am very interested to see how you figured this one out!
10-28-2021 02:46 PM
I guess this is Stupid Question Time (for me at least)...why aren't you wiring that error wire to the FP.Close Invoke Node?
10-28-2021 03:07 PM
@BertMcMahan wrote:
I, for one, am very interested to see how you figured this one out!
Fortunately Highlight Execution worked in finding it.