Periodic Tasks Help

[ChrisArmour]

I need some help with putting my teleop code into periodic tasks. I have never worked with doing that. The loop that I have in teleop is casing things to lockup when it is running. Any help would be great.

[Levansic]

OK. Your stuff triggered by button 5 and 6 need to move over to periodic tasks. Teleop has to finish in 20 ms or less, and you have waits in both.

Set a global variable when the button is pressed, and read the variable to trigger those actions in a timed loop in periodic.

Global variables are specified in Robot Global Data.vi.

[ChrisArmour]

ok i think I got it, never worked with global variables either

http://prntscr.com/32pged
http://prntscr.com/32pgg2

[Levansic]

Almost. Those parts that you moved to periodic tasks need to be in a while loop with a delay. There are two of those in your screenshot. All of the code you moved needs to be in one of those loops (I suggest the 100 ms one). You can keep the refnums outside the loop.

[ChrisArmour]

http://prntscr.com/32pini should I remove the while loop that is in the case structure for button 5 since it is in the 100ms one now?

[Kevin Phan]

Yes remove that while loop, but before that can you explain what does your digital input do? I see that it stops the while loop, but what is its intention?

[ChrisArmour]

it actually worked perfectly today at regional with out taking it out thank you so much. the DIO is to stop the turning of our shooters cam right before its release point. we are running a chain driven choo-choo style cam for our shooter.

[Kevin Phan]

Well the reason why I thought you needed to remove that while loop is to save on processing time. Since you have a condition wired to it, that probably allows it to work correctly. I'm just confused about a 10 ms task in a 100 ms task, since it will only execute every 100 ms in the outer loop.

[Greg McKaskle]

A delay is just a node that takes zero CPU to execute but doesn't finish executing until a deadline takes place. It does not prevent the loop from doing other things in parallel.

So, since the outer loop contains a wait of 100ms, it will not execute more than 10 times per second. If the other contents take longer than 100ms, then it will execute even slower.

The inner loop has a delay of 10ms. That means that it will check no more than 100 times per second to see if the digital switch has closed.

To document that portion code with an English sentence, I'd describe it as ...

About 10 times per second, check button 5 on the joystick. If pressed, set the motor to 75% and start checking the switch. Check 100 times per second. The motor will be turned off in other code unless button 6 is pressed at the time.

I'm glad to hear it worked. A couple things that would make it easier to understand and more robust ...
1. Loops that check for things like switches should probably have a limit on how long they will check and enter an error state after you have waited long enough for the mechanism. Not doing this, and having a HW or electrical issue may cause other code to stop working, may leave motors stalled, or may cause a mechanism to rip themselves apart. So, it is useful to identify all the conditions which should cause the motor to stop. I'd also suggest moving the motor stop so that it is more obvious.

2. The rate that you want to check the switch should be based on how fast the mechanism moves and how long it will press the switch before going beyond. I'm not saying 10ms is good or bad, but SW values like this can be converted to "check every 1/4 inch, which is 10ms", and those comments in the code really help later if anything is changed such as the motor gearing, the speed of the motor, friction, springs, weight reduction, etc.

There are others, but that is a good start, and congrats on figuring out that it didn't belong in teleop and successfully getting it to work in periodic.

Greg McKaskle