Given the multitasking sticky, I'd like to confirm that this is an acceptable use of multitasking in RobotC.

In essence, I would like to have two tasks running at the same time: The main one would respond to sensors and decide on actions, most importantly the set points for each motor. Then, another task would be a PID control loop (due to complicated reasons we can't use the built-in PID control) which constantly adjusts the motor power. There are multiple motors to be controlled, and each iteration of the main task might only change the set points of some motors.

This is an appropriate use of multitasking, because the tasks are simultaneous, and not sequential--right?

So you have one task settings encoder positions, and another controlling the motors to get to those positions, yes? That sounds alright to me. It'd be what I'd do.

Ok. Thanks!

One way that I think is helpful to decide whether or not I would use multiple sequence beams in NXT-G. Provided that there are some exceptions to the rule that I have to ask about.

Ugh. NXT-G... Sequence beams are my worst enemy.

Like I said in my previous posts, I have not found a single scenario that I really need to use RobotC tasks. Unless you are very experienced in multi-tasking programming, there are a lot of gotchas you need to deal with. Everything could be accomplished with using just the main task if your code can cooperate. For details on how this could be done, you may want to read my previous posts.

search.php?keywords=cooperative&terms=all&author=mhts&sc=1&sf=all&sk=t&sd=d&sr=posts&st=0&ch=300&t=0&submit=Search

I know, But The Analogy Works.