It delays the code by the specified amount of time, but I’m not sure what the benefits of that are.
1 Like
The Timer.delay(); function allows the robot to activate a value and reset.
For example:
driveTrain.tankDrive(motor1, motor2);
Timer.delay(0.005);
This allows the drivetrain to refresh the motors at 5 ms(aka stop on a dime!)
OR
if(joy1.getRawButton(1))
{
move_motor = true;
}
Timer.delay(0.5);
if(move_motor == true)
{
motor.set(1.0);
}
Timer.delay(0.005);
This allows button 1 to change position only after every half second if the code changes. So the button held will not change if the button is hit again for 0.5 seconds.
Hope this helped.
P.S. The placement of the Timer.delay() is very important because having a drive train after a time greater than, for example, .15 seconds, will start to see a very small twitch in activating the motors and cause it to slow down and start up at intervals. It can get weird!
Happy Competition!
Just double checking, won’t timer.delay also pretty much freeze the thread that the robot is running under, so if you are running a single threaded robot the robot will completely freeze for that amount of time?
Almost. It will pause the thread it is called from, allowing your other threads to take that time to do stuff. Think of it as a way of saying “I’m good for the next N milliseconds, its someone else’s turn.”
Yes, if by “freeze the thread” you mean “nothing else in that thread will execute until the delay expires”.
so if you are running a single threaded robot the robot will completely freeze for that amount of time?
Nothing else in that single thread will execute until the delay expires. So if that’s what you mean by “the robot will completely freeze for that amount of time”, then yes.
Yeah, with the delay the entire program stops until the delay is over.
For the benefit of students reading this thread, as a blanket statement without qualifiers, that is untrue.
If the delay is implemented as blocked waiting (rather than busy waiting) it halts only the thread in which it is located. Other threads continue to execute. Even if the delay is implemented as busy waiting, other threads will execute IF they are of greater priority, or if they are of equal priority AND time-slicing is enabled.
That is really close. VxWorks has the following task states: executing, ready, blocked, delayed or any of these things in combination with suspended or stopped. I suspect the delay method simply puts the task into a delayed state. The “busy waiting” thing is not done by the OS. I think ether is referring to something commonly called a spinlock - that could be the case with this delay method but it is nothing to do with the OS.
I guess I could have been clearer. None of my comments were referring to the OS. Here’s an expanded clumsy-reading version of my post, with nothing left to the reader’s imagination:
If the delay is implemented as blocked waiting (used generically here to include blocked waiting for a timer) (rather than busy waiting aka “spinning”, either by the programmer or by a call to an intrinsic function of the language that the programmer is using or by a library routine that the programmer calls either directly or indirectly) it halts only the thread in which it is located. Other threads continue to execute. Even if the delay is implemented (see previous exansion of “implemented”) as busy waiting (aka “spinning”), other threads will execute IF they are of greater priority, or if they are of equal priority AND time-slicing is enabled.
I believe that in Squawk (the Java VM on the cRIO), all threads are artificial constructs in the VM.
I mean that in the sense that the Squawk system will not use the cRIO’s built in threading capabilities, it just kind of pretends to use them.
Also, Timer.delay() is implemented with Thread.sleep() and so it will NOT prevent other threads from running while it is asleep. However, the thread that calls Timer.delay(…) will wait until that time has passed.
Just a point of clarification: the cRIO doesn’t have a “built-in” threading capability. It uses a third-party RTOS, vxWorks.
I know that if you put in a Timer.delay() it will delay EVERYTHING. I put in a 4 second delay on a command to stop it from being called too often, but during that 4 seconds I couldn’t do anything, the DriveTrain,our BallFeed belt. everything was frozen.
Did you read posts 4, 5, 7, 8, 9, and 10 about threads ?
We are multithreaded. Which is why this is confusing me.
Are you saying that if you add a Timer.delay() to one thread (let’s call it “Thread A”) it will stop execution of all other threads?
Is Thread A higher priority than the other threads?
or
Is Thread A the same priority as the other threads, and you have time-slicing disabled?
What exactly is a thread and there can be multiple to change what delays or not.
This is confusing due to a lack of certain terminology.
Threads are amazing!
The command system is actually not multithreaded. There is one thread that goes around and constantly calls the initialize/execute/… on each running command. So using Timer.delay in a command is a terrible idea.
However, you can use the WaitCommand in a command group, or you can use the timeSinceInitialized() method built into each command to do some timing based code.