How big is a big LabVIEW project?

[cebailey]

Andrey, thank you for the Guidelines - looks very useful.

 About the flat sequence nugget:

>Wrong!  One little-known fact about Flat Sequence Structures is that individual frames will execute if they don't have any outside data flow dependencies.  So in the first example, the entire Flat Sequence Structure must wait until the While Loop ends until it can execute.  But in the second example, the first frame of the Flat Sequence Structure will actually run independent of the While Loop, while the second frame must wait until the loop is done.

OK, I am missing the point of this. It seems obvious that frames in a flat sequence will not execute until all the frames to their left have finished. That's the point. It's also obvious that a frame will not execute if it is still awaiting dataflow from anyplace else, because this is a basic tenet of dataflow. So, the necessary condition for a frame to execute is that both all the frames to its left and any of the terminals  feeding it are finished. That is the conclusion that I understand Darren reaches, but he reaches it by a more complicated chain of reasoning, involving the history of the developer's choice of how to handle a very specific situation with a wire leaving the sequence at one frame and reentering at a later frame. Why would such a specific use of sequences have been part of the development process? Flat sequences would HAVE to work as they do, if frame order is left to right and dataflow still applies. Could they? Or am I missing something here?

[Ben]

---

cebailey wrote:

Andrey, thank you for the Guidelines - looks very useful.

 About the flat sequence nugget:

...

OK, I am missing the point of this. ...

---

I Believe the take away message is that a flat seq structure executes as if it is multiple single frame structures with an invisable wire connecting them in the order they appear.

So if a wire enters in frame #3 then frames 1&2 execute in that order (1 first...) and can excute prior to the data in the wire feeding frame 3 being available. Of course frame 3 has to wait for the two previous frames AND the wires data. Frame #3 acts as if it has a rendevous set-up such that both the previous frams and the data have been completed.

I bet I did not clear anything up with this post.

Ben

[RavensFan]

I think the point is that in this instance, frame 1 will not execute until the while loop is stopped.

In this instance, Frame 1 is allowed to run concurrently with the while loop.  But frame 2 won't run until the while loop is stopped AND frame 1 is done.

I think his statement "that individual frames will execute if they don't have any outside data flow dependencies" is a little bit misleading in that it neglects to mention that prior frames of a sequence structure are also critical to the data flow, even if there is no data explicitly being passed from frame 1 to frame 2.  The statement makes it sound like frame 2 can execute before frame 1, but that would defeat the purpose of having a sequence structure.

[cebailey]

Then I get the same message and the same point. Dataflow already requires upstream items must finish before downstream items may start. The definition of a sequence adds the requirement that frames to the left must finish before frames to the right may start. These two simple rules require all Darren's examples to work the way they do. Never mind about his example where the wire exits frame 1 and enters frame 3 - it must work as he says, or else it would violate these rules. The developers didn't have any choice left about how it would behave. Why would discretion in how this example behaves be a part of defining what sequences do?

>They look like they do the same thing, right?

I guess this is the thing I miss. Why would we expect these two examples to do the same thing, when Frame 1 has a dataflow dependency on the loop in one of them, and doesn't in the other?

And, Raven, I agree the statement is misleading. In fact the statement is flat out wrong until all the frames to the left have executed, isn't it?.

[RavensFan]

I believe you are understanding this all correctly.

[RavensFan]

Accidentally hit submit, and the forum timed out while I was editing to put in the rest of my statement.  Of course I have to type from memory because what I typed in the previous edit window disappeared...

Basically, I think Darren was using those 2 examples to show how the behaviors would be different in terms of when the first frame executes, but some people at first glance would think they are equivalent.  The original statement just wasn't that clear and gives the impression that the execution in frame 2 is different between the two examples.  I think further discussion in that nugget and Ben's comment about the "invisible wire" that underlies a sequence frame helps to clarify the original confusion.

I'm not sure what that 3rd example added to the original discussion.  It is definitely an unusual way to use the flat sequence structure, but it is perfectly legitimate.  I guess you might use if you wanted to act on some data coming out for the first frame, but let it execute in parallel to the frames between the first and the last.

[cebailey]

>It is definitely an unusual way to use the flat sequence structure, but it is perfectly legitimate.

I agree. I find this is a good way to execute something big and not time critical while also executing the other frames in a time critical fashion, or at least critical order. You can even have several flat sequences operating in parallel and enforce various timing relationships between them while leaving arbitrary timing relationships to sort themselves out and execute as soon as they can.

BTW I find the forum is timing out faster lately, but I can go Back to the window I did my typing, select and copy it, go further Back to the post I'm responding to, Reply again and paste in the window. I usually don't think to copy my text before Submit and this usually saves me.

[RavensFan]

---

cebailey wrote:

BTW I find the forum is timing out faster lately, but I can go Back to the window I did my typing, select and copy it, go further Back to the post I'm responding to, Reply again and paste in the window. I usually don't think to copy my text before Submit and this usually saves me.

---

The timeout seems to be 10 minutes, which is what it has been for awhile.  When I tried submitting my edited message, I was at the 11 minute point.  I tried going Back, but all I got was "That page is expired message."  I don't usually copy my message before posting unless I happened to have just gotten burned on a posting.

Message Edited by Ravens Fan on 11-13-2008 05:53 PM

[F._Schubert]

 About the flat sequence nugget; just a guess as I never use more than a single frame flat sequence:

This kind of behaviour is not the same for a stacked sequence. That's the point of example 3 which can't be coded in a stacked sequence. This is a point to care about when refactoring code by first replacing a stacked sequence by the flat sequence.

Again to the large application point:

It seems to me, that any project to break through the 'sonic barrier' of somewhere 700-1000+ VIs is using a kind of plugin-architecture, where the static code still is below the 'sonic barrier', and I guess that most dynamically called code modules will be in an easy to manage size of some hundreds VIs.

This makes a lot of sense, like using dll's in the old time. Breaking the code in the module is not affecting the complete code; only working and tested code is used for the main app while changing the 'plugin'/'dll'; cleare interfaces are defined, propably a testing routine exists (so one can verify the plugin-code without the main app).

And of course, a plugin-app is likely to grow as it doesn't need to much knowledge about the overall code to program it (means adding a bunch of 200 VIs).

Felix 

[awood04]

I thought I would jump in and say that the project I'm working on contains 3,224 VIs and 1 GB in size. We're using it to automate tests on prototype electronics (that's all I can say). It's been in development for years (I'm not really sure how long) and we're constantly adding new tests and improving our process so it just keeps growing.