Various Labview Questions

[Ether]

Originally Posted by Greg McKaskle

...

I have bookmarked the above post so I can refer others to it when necessary. It is one of the most clear, complete, and concise explanations I have yet seen of this common problem which plagues newcomers.

Thanks Greg.

[baronep]

I am very interested in the parallel task and I understand it in theory but I have no idea how to implement it. Where would you put such a thread? Would it be out of robot main? Would you control the motors directly from there or just do computation? And what is the difference between doing this and just having the computation in a subvi?

[Greg McKaskle]

Good questions.

but I have no idea how to implement it.

A parallel task in LabVIEW is implemented using a parallel loop. To keep things more organized, the LV framework has a Team Code VI called Periodic Tasks, though the icon says Timed Tasks. By default there are a few mostly empty loops that run at different rates. They contain a sleep function to control how often they run. In reality, the vision loop is a special purpose parallel loop/task, and so is the compressor control. You can have as many as you like. The LV dataflow scheduler allocates a pool of OS threads, and the threads take turns executing the loop contents. In reality, this is no different than spawning threads in C/C++, it is just simpler syntax and since LV manages the threads, there are no leaks or runaway threads.

While you could put your parallel loop in Robot Main, I would encourage you to put it into Periodic tasks or its own subVI containing your loop. Robot Main is full of other machinery, and the idea is that Team code is where you will place your team's robot-specifid code.

Would you control the motors directly from there or just do computation?

You will typically do the motor control in the control loop, but in cases where you layer or cascade these, you may find situations where you are simply communicating set points to other loops.

And what is the difference between doing this and just having the computation in a subvi?

SubVIs are just synchronous function calls. Any code that depends on the results waits for the subVI to return, and the calling diagram waits as well. SubVIs are a great way to share code or abstract code, but they don't affect parallelism except that the contents are within a subDiagram. The Vision Processing subVI contains an infinite loop, so will never return. Periodic tasks contains many parallel infinite loops, so never returns. Other subVIs such as TeleOp will process inputs and return a result as quickly as practical and internal loops are simply to visit data in an array, average results, etc.

Greg McKaskle

[baronep]

Wow. Thanks, that makes everything much clearer and no I have an idea of how to go about this. A+