I have a specific programming task that I have been trying to tackle for a little while which I’m sure has been solved before.
I have an absolute position sensor which outputs a value of 0to5v and a motor which turns the shaft attached to the sensor. The desired affect is that when I push a button, the axle will rotate 1/6 of a rotation (it is geared down so the physics shouldn’t be a problem). Then, when I push the button again, it will rotate another 1/6 rotation.
Another question, it seems that in out labview code, we have not used much in the way of “variables” like the local variables. Is my team just finding the “hard way around” problems that would be easily solved using variable nodes or would that just be inefficient?
Finally, In years past we have had problems with while loops in our teleop code (the robot would try to execute an automatic sequence and then it would timeout or drive into a wall). The workaround that we have used is a case structure with a bunch of feedback nodes.
Debugging local /global variables can a big headache. Feedback nodes are better for debugging. Nested loops should always be avoided unless there is a very specific reason for them. Most frameworks will not work correctly when bested loops are employed without intimate knowledge of the framework.
Maybe you can post your robot code with the updates you think is what you want.
In general, local variables are not desirable in your code. They were added to LV in LV3.0 or 3.1 in order to make UI programming easier, and they are useful for other initialization and communication situations, but in a parallel environment, they don’t provide any form of sequencing or notification, and are therefore a bit dangerous compared to a wire.
Loops that run in teleop are not a problem provided they terminate quickly. The teleop callback is supposed to complete in ~20ms so that the framework can call the appropriate callback again – often the teleop with the latest joystick info. When you have a sequencing operation that will take longer than 20ms, you have two choices – build a state machine inside of teleop, or make a parallel Timed task that controls the sequencing operation.
State machine:
This involves remembering state data in a feedback node or local/global variable so that the sequencing operation can be monitored and advanced when appropriate. The operation is essentially sliced up so that it can advance in small 20ms slices. This approach is fine if everyone understands the concepts. It is a common approach in a single-threaded system.
Parallel task:
This involves making a parallel loop (thread if not using LV) that monitors and advanced the sequencing operation. It does this outside of teleop, so that teleop can return quickly and keep other mechanisms going. Teleop can communicate set points and monitor the state of the operation through global variables, notifiers, queues, or RT FIFOs. This approach keeps the code decoupled, making it easier to modify and develop independent of the rest of the robot. Be sure that something throttles the loop so that it runs only when needed and not one million times per second.
Either approach will work, though I’d encourage you to try the second, as it keeps the code separated and can be developed in an independent project with a simple panel as a test harness.
Please ask more detailed questions if any of this didn’t make sense.
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.
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?
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.