Having a high usage isn't necessarily bad. Well written code can consume 100% of the CPU but be squishy enough to not get in the way. For example, let vision consume whatever cycles happen to be left over, but prioritize it correctly so it doesn't consume cycles that aren't left over.
Also, it is really easy to rail the processor - any while loop without a delay will take care of your spare cycles immediately.
Do any of the power users have a favorite way to implement Dominick's code? If it doesn't need to run in parallel with itself, I typically do that with a single (Enum)Notifier with multiple loops.
Let me temper that with an admission: I haven't gone into serious depth with FRC LabVIEW since I started working at NI. Most of my FIRST LV experience is in FTC/FLL, and most of that was so far under the hood that I didn't know what road we were driving on...
Quote:
Originally Posted by DominickC
Now, I've placed this code within Periodic Tasks.vi. There are two more case structures similar to the two visible, and I've moved the axis value to Teleop.vi. Today, we were getting some infrequent watchdog errors which shut down our comms with the cRIO.
Just by looking at this image, is there a way to streamline the code? I had tried to do something similar to the second image with just the single case structure visible, wired to a joystick button. When the structure was false, it set motor outputs to 0. No matter what I did, it wouldn't work. (I followed it in debug mode, and it appeared that the command to set the motor output to -1 was being triggered, however nothing happened on our jags.)
Is there a conflict between the 500 millisecond timing and the 100 millisecond timing within the while loop?
|
I found a few spots in your code that you might want to look at. Once you fix the first error, I think the others might not be relevant. I mention them just in case.
Both loops are busy loops - they will consume all available CPU time to check to see if 500 milliseconds have elapsed and to write the output. If there isn't anything else contending, you could just write once, wait 500, write again.
Both loops are fully blocking - the owning VI has to wait 500 milliseconds to continue. Was this intended?
Both loops pull the motor reference every iteration. If you are using the same reference often, you don't have to pull it each time.