Dataflow issue

[LarsUlrich]

Yes, I am making guesses because I am kind of stumped.  I ran it again with more data points this time, and attached the results.  (And you are correct, the wires actually connect, and not just pass behind, the replace array subset)

By more data points I mean that the image I posted runs in a for loop, once for each test frequency, so this time I used 2 frequencies instead of 1.

The DC reversals and AC/DC average/standard deviation all equal zero for the first frequency (1 MHz) (except for REF DC reversal, which is a 2, but thats because there was a 2 in the display on the front panel before I ran it, so that was the default value at the start)

For the second frequency(5 MHz), the DC reversals, AC/DC average and standard deviation are all calculated with the 1 MHz data

(189.1 is the average of 189, 188, 192, and 186, the data points from the previous loop).

[altenbach · Accepted solution]

Purely judging from the visible part of the diagram image you posted the only dataflow issues visible is the way the "AC/DC diff avg."  and "STDdev." are hadled.

While the indicator will only be updated once the formula has executed, the local variables of the indicators all the way to the right will be read right at the start of the program and thus contain stale data, which is then written to the file instead of the updated value.

Simple solution: Delete this local variable branch the wire leading to the indicator terminals  directly to the "build array" node.

Of course not the entire code is visible in your image, and there is no telling how all the other local variables get updated. This entire thing smells like Pandora's can of worms 😄

Here's an illustration for a quick fix of the mentioned issues. It will fix the AC/DC... and STDev, issues, but there are probably serious other problems.

 

[RavensFan]

You need to read

Why some people say Local Variables are bad...

[CoastalMaineBird]

I agree with others that the likely candidate is the local variables.

Remember that READING a local variable and WRITING a local variable, are TWO, COMPLETELY INDEPENDENT OPERATIONS.

If you don't enforce it by sequence or something else, they will execute however LabVIEW best sees fit.

If you can run a wire from here to there, do it instead.

[Yamaeda]

---

@CoastalMaineBird wrote:

Folks hate flat sequences too, now?  Sheesh.

Folks have hated stacked sequences for some time, but I didn't know the flat ones were out of favor too... 

---

Stacked sequences are a lesser evil, they are simply put rarly needed. E.g. when there's no error in/out to force execution order, typical example being Wait. In that regard they are similar to Local Variables, except Locals cause race conditions where sequences prevent them, which leads to the next point.

They tend to lure people to use Local variable (since a block is considered a separate entity, or something), which is a common reason for race conditions. This, however is saved by the use of the same frame, with alot more clutter as a result to do the same job. I assume it has a hidden performance hit due to preventing possible optimizations "between frames".

/Y

[thomas491]

Structures based on dataflows have been around since the days of Jackson Structured Programming.

[CoastalMaineBird]

Stacked sequences are a lesser evil

I refuse to accept the idea that a tool in my toolbox, which works as described and is described as it works, is "evil".

 they are simply put rarely needed

Maybe, maybe not. That doesn't make them evil.

Locals cause race conditions where sequences prevent them

Local variables do not "cause" race conditions, although the misuse of them can lead to race conditions.

They tend to lure people to use Local variable 

I've no idea where that conclusion comes from.

This, however is saved by the use of the same frame, with alot more clutter as a result to do the same job.

If someone will put "a lot more clutter" into a single frame of a sequence, then they will put "a lot more clutter" into a single VI, or an Event structure, or a CASE structure, or ....

I assume it has a hidden performance hit due to preventing possible optimizations "between frames".

This is no doubt true. My policy is to let the LabVIEW compiler have as much freedom as possible to execute things in whatever order it thinks best, except when A) They MUST be executed 1-2-3, or B) I don't care about performance.  I have plenty of cases where I have a zillion things to do when a window comes up.  A lot of those things are independent and I put them in a stacked sequence simply to save space.  I am not about to put them all on a single diagram because somebody thinks sequences are "evil".  I'm not about to connect a whole lot of property nodes and FP terminals to a whole lot of subVIs, because somebody thinks sequences are "evil".

Sequences, like local variables, are a tool.  Nothing more, nothing less.

[LarsUlrich]

One thing I think it's worth noting is that my local variables worked for my program BECAUSE I used a flat sequence structure, and it was only once I took it away that it led to race conditions.

[CoastalMaineBird]

my local variables worked for my program BECAUSE I used a flat sequence structure

Indeed.  You used a tool, and you used it correctly.

It is still my opinion that you took a working piece of code and created problems in it, simply because of some dogma from some zealots.

Your code was not flawed simply because taking away part of it made it not work anymore.

[Mark_Yedinak]

---

@CoastalMaineBird wrote:
 

I assume it has a hidden performance hit due to preventing possible optimizations "between frames".

This is no doubt true. My policy is to let the LabVIEW compiler have as much freedom as possible to execute things in whatever order it thinks best, except when A) They MUST be executed 1-2-3, or B) I don't care about performance.  I have plenty of cases where I have a zillion things to do when a window comes up.  A lot of those things are independent and I put them in a stacked sequence simply to save space.  I am not about to put them all on a single diagram because somebody thinks sequences are "evil".  I'm not about to connect a whole lot of property nodes and FP terminals to a whole lot of subVIs, because somebody thinks sequences are "evil".

Sequences, like local variables, are a tool.  Nothing more, nothing less.

---

I would still argue that a state machine, even if it is effectively sequential, is a better approach simply because it is very easy to modify the flow. A stacked sequence is not. In addition, it is much easier to wire data through a state machine as opposed to a stack sequence with sequence locals. Applications regularly require change. Why not use the more flexible architecture which facilitates change better?