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

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

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

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

thanks for the responses. the cluster is not written to all at once. most times each state will only read or write two pieces of data from the cluster at a time. i had used a shift register to carry the cluster through the states but thought i would try this aproach this time. it seems cleaner. i just wasn't sure if this was a common aproach used (lv2 global) or i was off on my own. also, i didn't know about the memory usage of the lv2 global versus the shift register aproach i used before.

im thinking about using lv2globals to share information between states in a queued message architecture program. which approach would be better to use? reading and writing the entire cluster each time as in example#1 or writing just whats needed each time as in example#2. or if there is a better option i am open to that as well. obviously the cluster items will grow in number as the program matures, so this is a concern as well. i don't want to pass around too much data unnecessarily.

Download File:post-981-1112375596.vi

Download File:post-981-1112375599.vi

Hi Robert,

You can indeed simplify it a bit by combining all 'mouse enter' and 'mouse leave' events for the same cluster into one event case. Then you can check the 'Type' of event returned (enter or leave) and react accordingly.

This way you can get it down to six event cases.

Cheers,

                  Heiko

3528[/snapback]

heiko,

yes, good idea :thumbup: . i like it. thanks for your response.

robert

i wanted to make some hover buttons (button property changes with mouse over). some on their own and others in clusters. its not hard to do with the events structure, but it seems like there is a better way to do it then what i did. anybody got a better suggestion? LVversion7.0

thanks,

robert

Download File:post-981-1105725797.llb

The reason the dialogue box only happens once is because it is not in a loop. If you add a loop it should solve this problem.

another problem that I ran across was the send notifier case is true for 10 ticks or 100 ms.

this will send a notification twice with a 50 ms timeout and caused me to have to click the ok button more than once.

3422[/snapback]

thank you for the explanation. i was not aware the notifier need to loop. i had mistakenly thought that if the send notification was looped that would be sufficient. this is the modified version.

robert

what im trying to accomplish:

. start count down timer.

. every ten seconds, trigger an event via notifier

. do not interrupt counter while triggering event.

. abort at any time via "abort" button

. finish after 60 seconds

what its doing:

. starts count down timer

. after first ten seconds trigger event

. does not interrupt counter

. will abort at any time

. finishes after 60 seconds

. will not trigger event after first ten seconds

obviously im not using the notifier properly and

am hoping someone here can fix my mistake

with a small amount of explanation on what

i did wrong.

the attached "code/vi" shows what i did.

i also added a .jpg screen capture incase of version issues.

thanks,

robert

Download File:post-981-1105123825.vi

michael,

hello and thanks for the response. i agree, a status bar isn't much more then a collection of string/numeric indicators or even controls. with the proper attributes and spacing, it can look just like a "windows" status bar. i like the activeX status bar for its built in features like the time, date, caps lock and num lock. as it is i have a progress bar and multicolored status indicator in string indicators "next" to the status bar so that they look like they belong to the status bar. i thought it would be nice to incorporate those features into the status bar i am using. again, if anybody has insight on how to do this, i would be interested in how it was done.

thanks,

robert

hello,

i am using the MSComctlLib.IStatusBar, to create a status bar for an application. i would like to place an image (dynamically, i know you can place an image using the statusBar properties via the front panel) and progress bar in panels of the status bar. has anyone done this? if so, could you please show an example. all i can figure (vb code examples) is i have to use the loadPicture function to place an image in the status bar, but am unsure how to go about that. is their a good resource for activeX programming in labVIEW.

thanks,

robert