Should everything **really** fit on one screen?

[Evan R.]

Hi Everyone,

I wanted to pose the leanest and meanest LabVIEW programmers a question about code size and style for parallel multithreaded architectures.

I understand the reason behind having all code within a single screen. Indeed I have been able to achieve this on many occasions when I set my sights on it. The results are often quite nice!

My question is really focused on parallel architectures. What (if any) is the recommended style for creating highly parallel architectures. I recently built an application with the following threads in parallel:

T1. Command processor (sends and receives commands using queues to and from each FSM)

T2. Connection consumer (spawns a new FSM for each incoming connection to manage the protocol using VIT)

T3. Connection manager / producer (awaits for incoming TCP/IP connections and enqueues the connection for the connection consumer)

T4. UI Processing (loop for handling user interface actions)

The resulting application was rather large in terms of real-estate. I'm wondering if there's a better way? I acknowledge that I'm using a flat sequence structure for some initialization and finalization, and I realize this is a no-no. I know how to get rid of that piece, but it only solves part of the real-estate question.

Should I simply accept that parallel architectures will always take up a lot of screen area, or should I take each thread (except the UI thread) and make a SubVI out of it? What about error handling?

What do you recommend?

-Evan

[gosenbach]

What we have done on occasion when we have more than just the one producer-consumer loop set is place all the aux loops into sub VI's.  Three are several advantages here.  When you create all your queues, put them in a cluster and have that cluster as an input for each subvi.  This way you still maintail your interloop communication (queue variant cluster).  Leave the event loop and the "main" loop on the top level.  If any errors are generated in the subvi loops, just send it to the error queue and it can be handled by the error handling loop (also in a subvi).

This taks up a lot less realestate.  Another benifit appears when you have execition highlighting on.  You can only highlight the loop you are interested in which saves you a lot of waiting around.  This method also allows you to work on and test each loop seperatly.  Which is handy if you have more than one devloper on a project.

[Ben]

All of those loops except the GUI stuff can be made into sub-VI's.

You can stop them by using queues and send commands to stop etc.

I use an Event Logger (that Ideveloped years ago) that logs errors to a Evnt Log file for trouble shooting. Each sub-VI handles it own errors as required but the errors always go to the log folder.

Ben

[tstahl]

Placing multiple loops like that always seem to take more real estate than the monitor has.  I agree with other posters that subVIs are the way to go.

Tim

[Evan R.]

Do you recommend having each SubVI (thread) just sitting off on it's own space of the main VI? Like this:

[tstahl]

Something like that would be good.  I'd recommend making the queues, events, etc., before you execute the UI loop and threads and then pass those into the subVIs and while loop.  You'd need a destroy/cleanup after all the threads are complete and the while loop terminates.

Tim

[Ben]

Yes that's the idea.

here is an app I am working on now so it will eventually be squished down a little more but this illustrates how I handle it.

Since this app goes through a sequence of states that can be very complicated I did not use static event cases but dynamicall register as required.

The VI labled "Run Test" does all of the GUI work while in the state "Test".

But meanwhile..

A) The DAQ loop is collecting daa and sharing it with the GUI and the logging loop.

B) Handle all file operations and get commands from the GUI and get via queues from the DAQ loop.

C) Inside all the code I use the Event logger but when those two extra loops shutdwown I merge the error so i don't loose any trouble shooting info.

D) I shutdown my Event logger as the last act before closing.

So...

I'm not just feeding you "THe Official Answer" but what I actually do in my code.

Just trying to help,

Ben

[AristosQueue (NI)]

My style preferences:

A) I don't insist on "one screen" but I do insist on "only one scrollbar." So if you're going to have the vertical scrollbar for parallelism, you shouldn't also have to scroll horizontally.

B) Any single structure node should fit on one screen. In combination with (A), that means you can create a string of structures or a stack of structures, but you can't have one giant structure wrapping around everything.

That's my taste for these things.

[shew82]

I tend to be of the similar mind - only scroll in one direction and try not to have to scroll more than one screen over (ie 2x hight or 2x width).

When it comes to running parallel VIs, a technique I find very convienient is to run each thread/module loop in the background (launching dynamically) and then use a subVI for each message type. Those subVIs will theb basically simply get the thread's Q reference and build the right message (ie state + data). Using subVIs instead of bundling a variant makes it much easier to ensure that the right parameters get packaged up with the message type (see screenshot).

A silver lining of this approach is that it keeps the implementation of the thread/module hidden (ie the thread may actually be a bunch of descrete VIs and no loop - the programmer does not have to care).

[TroyK]

I always like to try and fit everything on one screen, but then I guess that depends on how big your screen is!

1024 x 768... not so easy, 1600 x 1200 a fair bit easier.

Here's a block diagram of one I'm working on right now.

Very similar to Ben's suggestion I guess. (I isn't finished yet so it may not look as neat in the final version.)

There are (or will be) 8 queues in the queue cluster for inter-module communication and 1 User Event Ref (to push data back to UI thread).

Some awsome suggestions in this thread so far. They don't even teach you this stuff in the LabVIEW Advanced training course.

It's just a pity it isn't in the LabVIEW forum so I could give you all kudos. Valuable stuff here.

Thanks,