[Greg McKaskle]

You don't mention whether this is for autonomous, teleop, or more general. I'll give some options and try to explain the tradeoffs.

In autonomous, no other code is running, and there is no need to return to the scheduling code. This means that your code can be written the simplest. You can use a sequence and in frame 1, Set Motor to speed S1 and delay with D1 in parallel. Frame 2, Set to speed S2 and Delay with D2, etc. You can generalize this to use a loop and an array of S1, S2, S3, and D1, D2, D3 if you want to.

In teleop, your code needs to return to the scheduler every 20ms or so. The delay block prevents this until the delay is over, meaning that your joysticks will be frozen for a few seconds. The way to code this in teleop code is not obvious, but a trick well worth putting in your tool chest. It is called a state machine. You code it by Setting the motor and noting when you started it. You update the state to Running A and let the function finish and return to the scheduler. Each time teleop is called, you check to see what state you are in. If in state A, you compare the current time to start time to see if 0.25 seconds have passed. If not, leave it alone. Once 0.25 seconds have passed, you change the motor speed and set the state to B and let it return. B does the same time compare and eventually goes to state C where it stops the motor.

The third option is to put the code into Periodic Tasks and let auto and teleop communicate to it. When in Periodic Tasks, you can write it simply, like autonomous, but you put it in a mechanism loop so that it is started/stopped/canceled by a global or other communication mechanism. This is actually the approach I'd generally recommend, and I attached an image of the general code that would be pretty easy to duplicate and set to other mechanisms. The other case handles stop and delays for 20ms. Look through the code and see if you see any issues or have any questions.

Greg McKaskle