Quote:
Originally Posted by pyr0b0y
... , how can I avoid this problem?
|
The easiest way is to limit the number of places in your code where you set the speed on a given motor. Use logic to determine the parameters that then flow into a single block to update the motor speed.
The typical, but incorrect approach, is to have conditional code scattered about the teleop loop that computes the value of speed and immediately updates the motor. It seems fine except for the fact that other logic which may not be exclusive is doing similar things elsewhere. When there is nothing to arbitrate the outcome, we call this a race condition .
If you were one of the twelve who attended my advanced LV presentation this will be review, otherwise, my analogy is to give two people in the same room identical remote controls to a common TV. Instruct one of them to turn the tele to channel 12, and the other to channel 34. What outcomes can you forsee? The correct answers include 12, 34, 1234, 3412, 2, 4, 1342, 3124, and there could be others depending on the protocol -- unpredictable. How do you fix it? Have only one remote control or develop an access control mechanism so that only one person can use their remote at a time.
Returning to the motor update issue, delete all but one of the motor updates for a particular motor channel, move this subVI to the right of the teleop loop, and wire the computed values from various logic to that subVI. If you had potentially parallel updates, you will have multiple inputs that will break the wire. Fix the logic so that a given set of inputs produces only one outcome -- you needed to do this anyway as the motor can only have one speed.
If you want more background on this topic, search for race conditions in programming, and especially on LV forums you will get more insight, thought, and religion on this than you probably care for. I suspect other parallel languages will have similar discussions. Or ask more detailed questions here.
Greg McKaskle