Connecting vi's to build a dynamic system

[KOutland]

The user should press a button on A, which opens B. I think I may have gotten it to work. I put the sub VI of B inside a case structure on A and wired a TF button to it. Is this a really bad way to do it? If it's alright, I think I'll just try and put one of these case structures with the next VI in it on each of the separate files.

[Dennis_Knutson]

For something a little fancy, you at my example that I posted. For something really simple, you would do something like the attached picture. A main VI would have you four subVIs connected by data in/out and error in/error out cluster. Each subVI would have it's code inside a while loop with an OK (or next, or whatever you want to call it) button that stops the while loop and finishes the subVI. To make a subVI display it's front panel when called, select VI properties>Window Appearance>Customize and click Show Front Panel When Called and Close Afterwards if Originally Closed.

[mikeporter]

That's not a real good way of doing it because it's not readily expandable. I'll post you something over the weekend.

Mike...

[paul_s]

First of all, don't use sequence structures--ever. They really aren't necessary and have some very bad side-effects

I wonder if you might be able to comment a little further on this if you get a chance Mike. I haven't used them much but sometimes use single frames to pass a dummy constant around so I can be sure I'm getting the dataflow I'm expecting. Just wondering what the side-effects of (presumably) multi-frame sequences are.

[KOutland]

The example posted before yours only has the error in/out wired, and not the data in/out. Is the data in/out necessary (the only data I'm transfering between vi's is a string which I put into a global variable - if that's what it's supposed to be.)

[mikeporter]

Yes, I was intending multi-frame sequences. There are several issues.

First, like any multi-frame structure, they hide your code. (At least with a case structure you can still see at once all the code that will execute this time.)

Second, once you get into one you can't bail out early. You're committed to going through everything.

Third, the way sequence locals are done means that there tends to be a lot of wires running back and forth across the screen.

Fourth, there's no logical reason for having a multiframe sequence in a dataflow programming environment so having them supports people in maintaining some very bad habits like not checking for errors, or thinking one-dimensionally.

Mike...

[paul_s]

Thanks for those pointers. I'm starting to wonder how you find time to do your own work... 🙂 ***** 5stars

[Dennis_Knutson]

If you don't want to pass data then don't. If you do, pass it directly instead of using a global variable. Only use globals as a last result. You probably won't have any real problems with just a single string but you might as well develop good habits at the beginning (just like avoiding sequence structures).

[KOutland]

This seems to make sense. I tried putting the case structures around all my programs and wiring the error in/out to all of them just like the diagram (by the way, where do I find these in the functions palette?). When I put the subvi's on the main diagram, nothing would wire into them. It also seems sort of bad to be putting a huge while loop around my entire diagram, and another case structure all the way around that. It seems a bit inefficient isn't it?

[unDees]

Do you mean where are the error in/out clusters? These are for the front panel, so they are on the Controls palette (which is visible when you have the front panel showing) in the Array and Cluster subpalette.

The While loop doesn't go around your whole diagram; it just goes around the read of the OK button (and the accompanying timer). Your code can execute in parallel to that and therefore goes inside the non-error case, but outside the while loop. That way, if an error is generated in (for example) B.vi, then the program will skip right over C.vi and D.vi. It's actually quite efficient.