Limit to number of While loops

[LockheedJoe]

I know that each while loop is an independant thread, is threre a limit to the number of while loops? Or is there a time penalty for having to many loops? (as long as they all have appropriate waits in them)

Thanks

Joe V

FIRST team 704

[sciencewhiz]

I was wondering the same thing. For example, in the past, we've had a 100hz loop in periodic tasks that had a lot of code in it (Several different PID controllers, etc). That loop could probably be broken up into 5 different loops. Would the 5 loops be easier on the task scheduler then the one giant loop or would the extra overhead from more loops be the dominant factor?

I tried to play with this with LabVIEW running on my computer, but it was much to fast for me to be able to simulate it very well.

[nathand]

LockheedJoe wrote:

I know that each while loop is an independant thread, is threre a limit to the number of while loops? Or is there a time penalty for having to many loops? (as long as they all have appropriate waits in them)

This is incorrect.  There is no connection between the number of threads and the number of loops.  LabVIEW allocates some number of threads regardless of how many loops your code contains, then executes your code in those threads.  Different threads may potentially execute different portions of the same loop.

sciencewhiz wrote:

I was wondering the same thing. For example, in the past, we've had a 100hz loop in periodic tasks that had a lot of code in it (Several different PID controllers, etc). That loop could probably be broken up into 5 different loops. Would the 5 loops be easier on the task scheduler then the one giant loop or would the extra overhead from more loops be the dominant factor?

I tried to play with this with LabVIEW running on my computer, but it was much to fast for me to be able to simulate it very well.

It should make little difference whether you use multiple loops or a single loop.  LabVIEW turns your code into "clumps" and executes those as they're ready to run (all their inputs are satisfied).  You can give the LabVIEW scheduler some hints about which loops are higher priority by setting the VIs execution properties (which is one reason to use separate loops - you can put them in separate VIs and set them at different priorities).  However, if inside your loop there are 5 independent processes, then you're likely to get similar clumps regardless of whether that code is in one large loop or broken into 5 smaller loops.

Does anything on the robot really need to execute at 100hz?  I doubt it, but I'd be curious to know if you've seen a need for it.  Have you checked that you're actually achieving that timing, or you set it and hope that it executes that fast?

It's probably beyond the scope of what any student on an FRC team needs to know, but here are two links with technical details about how the LabVIEW scheduler works.

http://zone.ni.com/devzone/cda/tut/p/id/3558

http://forums.ni.com/t5/LabVIEW/Multitasking-VIs/m-p/2825#M2171

[LockheedJoe]

Thanks, there's some good information. However you should probably pass this on to the LabVEIW training department. I've been told in 2 different classes that the while loops are separate threads.

[nathand]

I don't have any connection to anyone at NI, training or otherwise.  If you feel there's an inconsistency between the NI training materials and the technical documents on the NI website, I'd recommend posting to NI's LabVIEW forum at http://forums.ni.com/t5/LabVIEW/bd-p/170.

By the way, here's one more link that might help answer your question about the time penalty in adding additional loops - basically, it's not much.  Also note that the linked message was written a decade ago, and both LabVIEW and processors have of course gotten faster since then.  http://forums.ni.com/t5/LabVIEW/Loop-overhead/m-p/4197#M3187