Parallel loops vs. One loop?

[GuyM142]

Hey guys,
We have several loops in our robot code (in periodic tasks vi) each controls a different sub system and all of them have a 20ms delay in them.
I was wondering if this is the right way to do it.
Will it make the code (Especially teleop.vi) run faster if I will merge all of the loops into one main loop with a 20ms delay?

[Mark McLeod]

It is more efficient to combine them into one loop, but not significantly. If they are affecting Teleop at all then you need to rethink your code design.

Before doing anything I'd suggest measuring the rates of all your loops to see how they are affecting overall timing.
One or more of your loops may not be running as fast as 20ms and that would impact Teleop worst of all.

Look under Support Code" in your project and you will see Elapsed Times.vi
Drop a copy of this vi into each of your loops, and into teleop, and give them unique names so they can be told apart.
Open the front panel of Elapsed Times and run your code in debug from Robot Main. Elapsed Times will tell you how long each loop is actually taking.
Each of your loops should be taking just a few ms longer than 20ms. If you see any that are taking significantly longer than that, then you will need to slow down the loop to a more reasonable time or you will need to streamline your code more.

[Greg McKaskle]

Are you asking because you have CPU issues? LabVIEW is quite efficient at doing parallel loops, so ideally you make the decision based on what makes sense.

Let's compare having one 20ms loop where we place all subsystems that run at that rate into the single loop, to having multiple loops all running at 20ms. The biggest difference is that the parallel loops are not synchronized. You don't know which starts first, which finishes first, etc. Additionally, if something happens in one loop that would delay it, it will not have much impact on the other loops.

If the code is in one loop, the data connections can directly synchronize things. You may need this, you may not. Additionally, if one operation starts to take longer, it directly affects all things in that loop.

If you have CPU issues or want to gain understanding of how often a loop is running, please follow what is in Mike's post. If you have other questions, please post them in more detail, perhaps even including your code.

Greg McKaskle

[GuyM142]

Originally Posted by Mark McLeod

It is more efficient to combine them into one loop, but not significantly. If they are affecting Teleop at all then you need to rethink your code design.

Before doing anything I'd suggest measuring the rates of all your loops to see how they are affecting overall timing.
One or more of your loops may not be running as fast as 20ms and that would impact Teleop worst of all.

Look under Support Code" in your project and you will see Elapsed Times.vi
Drop a copy of this vi into each of your loops, and into teleop, and give them unique names so they can be told apart.
Open the front panel of Elapsed Times and run your code in debug from Robot Main. Elapsed Times will tell you how long each loop is actually taking.
Each of your loops should be taking just a few ms longer than 20ms. If you see any that are taking significantly longer than that, then you will need to slow down the loop to a more reasonable time or you will need to streamline your code more.

Thanks, I'll check that.

And about the code design, our code design is based on state machines where every sub system has a different state machine in periodic tasks (a loop) which get commands from other vi's about state changes (or it changes states by itself, depends on the sub system)

for example,
we have the state machine for out hammer sub system (which kicks the ball)
the states it has:
1. Hammer Ready
2. Shooting
3. Hammer Down
4. Reloading

the loop runs in the periodic waiting for a command from any other vi (in the form of a global variable).
the teleop contains all the operating code and sends the commands according to the driver's actions.
so pressing on a certaing button will send a "Kick" command and the Hammer state machine will move to shooting state, in the shooting state we have all the code that control the hammer and actually make it kick and when it finishes kicking it automatically moves to 'Hammer Down' state.

What do you think about our code design?
we found it very easy to program and debug using this method.

[Mark McLeod]

Your code design sounds fine.
That's how we also implement most complex robot functions.

With that style you can save some processing overhead by reducing how fast you check the global variable. For instance, a human button press can be checked more slowly, such as every 100ms, and the human probably won't notice any lag.

But measure how long everything is taking first. You may find a coding error elsewhere.

[Joe Ross]

I'm curious whether there's any noticeable difference on the roboRIO with dual cores, or whether there are enough other processes running that it doesn't matter.

[tcjinaz]

Originally Posted by Joe Ross

I'm curious whether there's any noticeable difference on the roboRIO with dual cores, or whether there are enough other processes running that it doesn't matter.

Isn't the cRio a dual core PowerPC, ~400mHz?
Given that, it's not the number of cores that will matter, the roboRio will provide more MIPS just on clock speed (yeah, I know, how deep are the pipelines), plus some architectural enhancements. I kinda suspect the RTOS switch may be a wash, but I have not dug deep enough to comment. Just on OS bigotry I like the switch to Linux.

[Greg McKaskle]

The cRIO is single core.

Greg McKaskle