Can you write an independantly cycling subroutine?

[spaceman_spif]

Well, yeah....but it was funny when I did it!! 🙂

[Donald]

" ... the toilet overflowed again."

You might be able to get some sort of help from NI for this if it is an offshoot of your using the Full Development Version of the SA Toolkit from a few years back.
(http://ni.com/news/releases/april9901.htm)

Unfortunately I don't know if the toolkit is still supported (can't find a board for it on the forum).

[spaceman_spif]

Thanks for your help guys. I'll look into each suggestion when I get a chance.

I unclogged the toilet last night. And now my wife called to say it's clogged again! I told her "Whatever you're feeding our kids...stop feeding them that."



A quick piece of info on my program...while it cycles through the main program, it runs a sub-VI I created called "Indicators". This sub-VI polls 17 fault registers, 6 heater status registers, and 4 board temperature registers and displays the status of each register to a block of indicators on the front panel. Like I said before, every serial read/write command has to have a minimum of a 0.25 second delay programmed in it or it chokes...so 0.25 seconds * 27 read/writes = 6.75 seconds of wait time before it finishes that sub-VI and continues through the rest of the program. Will a separate block of programming for my timer display always be affected by that logic? In other words, will that 6.75 second long sub-VI always slow everything else down?

[tbob]

If you have a parallel loop to display time, the processor will divide time slices to attend to the serial stuff, and some time slices to attend to the time loop. During the delay time in the serial loop, the time display should get ample time for updates. If the serial stuff is in a subvi, and your time loop is in a main, normally the subvi has to finish before anything in the main can continue. You may have to call the subvi by reference, and wire a False to the Wait for Completion (or something like that) terminal. Then your subvi will execute in a separate thread from the main, and you time loop should execute while the subvi is executing.

[John Rich]

As long as your timer is in parallel with the subvi it should work fine. LabVIEW will continue to execute code in the main vi which is not dependent upon the subvi. Since you've got these big delays in your subvi there should be lots of time for your timer loop to utilize to perform its updates.

[spaceman_spif]

Okay, I'm not 100% sure so let me ask...when LabView is executing my sub-VI, does it stay inside that sub-VI until it is done, or does it bounce back and forth from the sub-VI to any parallel loops while the sub-VI is running?

[John Rich]

If you have parallel loops then LabVIEW will execute code in the parallel loops in parallel with the code inside the subvi. The subvi is really just another piece of code and will execute in parallel just as if all of the components of the subvi were included in the main vi. For most purposes you can think of the code inside the subvi as just being concealed behind the subvi panel.

[spaceman_spif]

To update an old thread, I did put my timer loop in another while loop that was separate from my main program and it runs nicely. Looks good!



And in case anyone even cared....it was a plastic Disney toy that was wedged way down in the potty. Darn that Eisner.