Dataflow issue

[LarsUlrich]

I've been working on removing a rather large flat sequence structure from a program I'm writing (because everyone seems to hate them on these forums) and it has left me with a dataflow problem.

2 of my formula nodes excecute before any of the arrays are populated with data so they just spit out a zero, the next section excecutes just fine, and the third section has some math hardwired, and this excecutes before the arrays are populated, so it spits out zeros as well.

I used lines in microsoft paint to section off the problem areas.

[Broken_Arrow]

You should make SubVIs out of the sections you have partioned. Add Error in / Error out clusters to the SubVIs, and by wiring one to the next, you force dataflow. Your diagram will also be smaller, neater, and easier to maintain.

p.s. Your local variables demonstate "lazy" wiring.  Never you a Local when a wire can be used.

[CoastalMaineBird]

(because everyone seems to hate them on these forums)

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...

That's a lousy reason to do something.  They work, they do a job, they save space.  I don't hate them, and I've yet to hear a compelling reason to avoid them.

Don't let the dogma ruin your karma.

That said, your problem is, as you have recognized, data flow.

You have to force things to execute in the order you want.  That's what a sequence is for.  Hence the name.

If you are unwilling to go against the mood of the month, then try putting things into subVIs, and pass a data structure from one to the next.  The wires enforce an execution order.

With all that said, I don't see why your block #2 says "These two execute before the arrays are filled".  That cannot be.  The arrays are wired from INIT ARRAY, thru all the REPLACE ELEMENT nodes and into the FORMULA NODE.

IOW, I see nothing changed (other than appearance) by your use of a sequence, or subVIs or anything else.

[johnsold]

The way that is drawn, dataflow forces the arrays to be present and filled before the formula nodes will execute.  What is not shown is where the NFactor locals are written. Is it possible that the NFactors are zero or some other value which forces the formula nodes to prodice zeros?

Broken Arrow mentioned laziness as an excuse for local variables.  A more important reason to avoid them is the possibility of race conditions.  My guess is that you have a race condition with the locals which leads to your zeros.

Lynn

[LarsUlrich]

Haha thanks for giving the flat sequence a pep talk Steve, it's needed one for a while.

"With all that said, I don't see why your block #2 says "These two execute before the arrays are filled".  That cannot be.  The arrays are wired from INIT ARRAY, thru all the REPLACE ELEMENT nodes and into the FORMULA NODE."

The only thing I can come up with is that when the arrays are created in the first place, they are initialized to have all their entries = 0.  Then each entry is successively replaced.  Since the arrays are full already (even though they are full of zeros) it is still able to excecute the formula nodes.  That's my guess at least.

[aeastet]

Post your code or part of your code and we will try and help more. Yo uneed to post the actual VI's and not pictures.

[LarsUlrich]

I didn;t post the sub.vi that determines the N Factors, but I am pretty positive that they are not the culprit.  The whole image I posted is actually inside a for loop, and that for loop is inside a much larger flat sequence (which I will probably get rid of next).  The sub.vis that determine the N factor are in an earlier section of the large flat sequence, so they should not be zero (and when it writes the N factors to the data file they are not zeros).

[CoastalMaineBird]

The only thing I can come up with is that when the arrays are created in the first place, they are initialized to have all their entries = 0.  Then each entry is successively replaced.  Since the arrays are full already (even though they are full of zeros) it is still able to excecute the formula nodes. 

OK, you're making wild guesses.

The INIT ARRAY creates an array of zeroes, because YOU TOLD IT TO.

Assuming the wires actually proceed from one REPLACE ELEMENT to another (and not just behind them), then the replace element nodes will execute in the order you've wired them, left to right.

Since that's wired to an INDEX ARRAY node, that executes LATER.

Since THAT output is wired to the FORMULA node, that executes LATER.

Triple-click on the upper array wire  Soes it go behind the REPLACE ELEMENT nodes?  It shouldn't.

Use probes.

Use single stepping.

Guessing is not going to help.  You need facts.

[CoastalMaineBird]

  Since the arrays are full already (even though they are full of zeros) it is still able to excecute the formula nodes.

That shows a fundamental lack of understanding of how dataflow works.

The formula node can make no distinction between a "full" array and an "empty" one.  It executes when ALL of its inputs are satisfied.

Think of it as a bucket brigade.  I cannot pass the next bucket to my successor until YOU pass me YOUR bucket.  Whether the bucket is empty or full is immaterial. When YOU pass me the bucket, THEN and ONLY THEN can I pass it on.

[Mark_Yedinak]

---

@CoastalMaineBird wrote:

(because everyone seems to hate them on these forums)

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...

That's a lousy reason to do something.  They work, they do a job, they save space.  I don't hate them, and I've yet to hear a compelling reason to avoid them.

---

The reason I never recommend that people, especially new LabVIEW programmers, use flat sequence structures is because it tends to keep people thinking sequentially. New programmers will continue to use the same thought processes for writing code as they did when writing C, C++, Perl or whatever text based, sequential language. There is power in structuring programs using data flow. Yes, some things do need to be executed in specific order but if I have more than a few steps that are not in subVIs I will opt for a state machine. It is far more flexible and easy to maintain. Error handling in sequence structures can be a nightmare. Every frame essentially gets a case structure written around it to keep it from executing. In a state machine test for error when choosing the next state. If one is present go to the error state otherwise go to the next state. In addition, you cannot take advantage of parallelism as easily in the code.