too many loops?

[robert.berger]

how many separate loops can you get away with? i have the following separate loops, so far

1: main gui loop (event driven) - run all user interface functions

2: main function loop - update user panel, updates test selection etc.

3: time loop (displays time and date) - runs every 100ms to update time, date and polls a LV2 global for text

4: mouse scroll loop (scroll windows) - runs when user moves mouse into text box or multi listbox to allow scrolling with mouse wheel

5: test loop - used to run any test independently of any other loop.

these are all triggered from notifier or queues from main gui loop.

too much ...not enough (haha) :laugh:

thanks,

robert

[robert.berger]

no opinions? is what i am trying to do out of the norm and thats why no responses? i would be interested in what the group thinks.

thanks,

robert

[Louis Manfredi]

Hi Robert:

I'm always willing to use as many loops as I need to get the job done, but very reluctant to use more than I need-- They've all got to be started and stopped when the program ends, and an error in one has to be handled gracefully in all, so there's additional work in parallel loops which should be avoided unless there is a reason.

So, no arbitrary number is too many... often I get away with one, especially with state-machine architecture. But Right now, I'm working with a fairly straightforward program that uses three, although it could have been written with two. (The client added a file storage requirement to a previously written program-- easier to add a storage loop than to integrate storage with the other loops, though if I had been starting from scratch I would have probably kept the size to two loops.) Often, including the above program, I have optional display windows, and these will each add a loop of their own to the number of loops in the main vi.

In your case, however, I suspect many of the loops are unnecessary: It seems to me that the Time loop, and the mouse scroll loop could be integrated into the GUI loop. the "main" loop could be split between the GUI loop and the test loop as appropriate-- so I suspect you only need two loops. Certainly, for example, if the GUI loop updates every 20-50 ms, I wouldn't expect it to be worth separating the time update from the GUI simply to keep the time from being updated unnecessarily often-- simply too much programming effort to go to avoid the unnecessary update frequency.

But perhaps there are details in your program not shown in the outline that justify the added loops.

Just my H.O., Best regards, Louis

[robert.berger]

Hi Robert:

I'm always willing to use as many loops as I need to get the job done, but very reluctant to use more than I need--  They've all got to be started and stopped when the program ends, and an error in one has to be handled gracefully in all, so there's additional work in parallel loops which should be avoided unless there is a reason. 

So, no arbitrary number is too many... often I get away with one, especially with state-machine architecture.  But Right now, I'm working with a fairly straightforward program that uses three, although it could have been written with two.  (The client added a file storage requirement to a previously written program-- easier to add a storage loop than to integrate storage with the other loops, though if I had been starting from scratch I would have probably kept the size to two loops.)  Often, including the above program, I have optional display windows, and these will each add a loop of their own to the number of loops in the main vi.

In your case, however, I suspect many of the loops are unnecessary:  It seems to me that the Time loop, and the mouse scroll loop could be integrated into the GUI loop.  the "main" loop could be split between the GUI loop and the test loop as appropriate-- so I suspect you only need two loops.  Certainly, for example, if the GUI loop updates every 20-50 ms, I wouldn't expect it to be worth separating the time update from the GUI simply to keep the time from being updated unnecessarily often--  simply too much programming effort to go to avoid the unnecessary update frequency.

But perhaps there are details in your program not shown in the outline that justify the added loops. 

Just my H.O., Best regards, Louis

4532[/snapback]

thanks for the response. H.O.'s is what im looking for. im always interested in new ideas for what im doing.

thanks,

robert

[JackHamilton]

Robert,

I've had as many at 10 loops running at once. Most were performing discrete I/O. Analog wfm output, Analog input, DIO and counter/timer functions.

I try to make each loop totally queue driven and completely 'detangle' control and display updates so each loop is actually a Sub-VI. This way I can choose the execution priority for each loop.

I've attached a diagram snapshot of what this looks like. The flat sequences are to control the start-up sequenceing, some DAQ config functions can collide with each other.

Some of the VIs are programs I've written some years ago like Queue driven RS-232 or TCP/IP.

Regards

Jack Hamilton

[Michael Aivaliotis]

how many separate loops can you get away with?

thanks,

robert

4521[/snapback]

Use as many as you feel comfortable with. There is no limit or right or wrong. One thing I would comment on is how you implement and document them. If you are using 2 loops in parallel then it's ok to have both of them on the same diagram outside of a sub-vi. This is good especially if the communication is mostly done between the 2 loops. As things grow in complexity however you will find that displaying and debugging code with 4 or more loops (on the same diagram) gets complicated. I would suggest you download and review some of the code in a presentation I gave a while back.

http://lavausergroup.org/niweek2004/meetin...niweek_2004.zip

[Rolf Kalbermatter]

Basically LabVIEW can handle 100 of loops in parallel, and does this with an amazing grace. The only thing you have to watch out is making sure that they are not free running, meaning that in each of them there is at some point an asynchronous function to limit its speed to that necessary for the task. Asynchronous nodes can be a number of different ones, the obvious ones being "Wait ms", "Wait until next multiple ms", and "Wait on Occurrence" but also the event structure itself. Also VISA or TCP functions and other ones with timeout input can be seen as asynchronous too in most cases, sometimes it is an option you need to enable on them (VISA).

The only reason not to use to many loops is that you need to somehow manage them in your application. They need to be started at some point, maybe you need to have some synchronization at certain points, although they run completely asynchronous for the rest. At last but not least they all need to be told to stop gracefully somehow when the user decides to close the application.

This adds overhead to your programming and also makes the application usually more difficult to understand, and with that in most cases also somewhat (and sometimes a lot) more difficult to debug.

An architecture I have found to be very powerful for multi loop applications is to have each use its own queue as command input. This queue is polled inside the loop and decides the next step to execute in its case structure, really resembling a normal state machine. With some utility VIs you write, you can now send from anywhere in your application specific commands to a specific loop/state machine. You need to be careful however to design the loops and their functionality in advance and remember to adhere to this design at all times. Once you start to mix functionality in between loops in the heat of your development work, you really can end up with an application even you can't understand yourself anymore, not to talk about debugging and maintaining it later on, and even worse having someone else have to debug it!

Rolf Kalbermatter

[robert.berger]

Use as many as you feel comfortable with. There is no limit or right or wrong. One thing I would comment on is how you implement and document them. If you are using 2 loops in parallel then it's ok to have both of them on the same diagram outside of a sub-vi. This is good especially if the communication is mostly done between the 2 loops. As things grow in complexity however you will find that displaying and debugging code with 4 or more loops (on the same diagram) gets complicated. I would suggest you download and review some of the code in a presentation I gave a while back.

http://lavausergroup.org/niweek2004/meetin...niweek_2004.zip

4542[/snapback]

michael,

and everyone that has offered it, thanks for the advice. i looked at the presentation and was intrigued by the Queue diagram on page 41. i was not able to find that code in the download. is there any chance i can get that actual code? i have retrofitted some early projects with queues and notifiers, but this is the first project im trying to use queues from the start and i would like to get it "right", if there is such a thing.

thanks,

robert

[Michael Aivaliotis]

michael,

and everyone that has offered it, thanks for the advice.  i looked at the presentation and was intrigued by the Queue diagram on page 41.  i was not able to find that code in the download.  is there any chance i can get that actual code?  i have retrofitted some early projects with queues and notifiers, but this is the first project im trying to use queues from the start and i would like to get it "right", if there is such a thing.

thanks,

robert

4591[/snapback]

Actually, this is my favorite little piece of code. It was impossible to cover everything in a 1 hour presentation so I left this code out but I should add it in. Here it is:

Download File:post-2-1114377201.zip