I was looking at the VEXcode Pro V5 vex::thread documentation ( VEX Help (vexcode.cloud)), but I don’t really understand how to make a thread and make it run code.
VEXcode has examples showing how to use threads, have a look at those and then ask questions if you still don’t understand.
7 Likes
I couldn’t find the examples, but I found a forum thread that answered it: One Thing Runs But Everything Else Stops - Programming Support / VEXcode Pro V5 Text Tech Support - VEX Forum
ok, you really don’t need to worry about the whole detach() function.
example is here for VEXcode.
or here for pro
6 Likes
I have a mildly off topic question for you jpearman: why does no one really use multi threading that much? Is there a downside to it in some way, or is it jsut not really useful for nromal vex stuff? When I check out other peoples code on the forums i don’t really see it.
Why don’t you need to worry about the detach function?
A good question, and I’m not sure I know the answer.
It may just be that the best coders don’t ask questions or post their code here.
It may be that there’s too much reliance on using blocks and some of the methods that blocks forces to you to use don’t translate that well to using text.
IMHO, there is no downside to using multi threading if used appropriately.
I find it useful for normal VEX programming, for example, separating the display of status on the V5 screen from code controlling motors. But then I wrote the scheduler that VEXcode uses so I’m biased 
There used to be much more discussion about using threads (or tasks as we called them in the RobotC days) on the forum, I wrote some long explanations about that in this topic.
and I used to post far more example code than I do these days, part of that is not having the time, but it’s also due to the student centered policy, too many students just cut and paste code without understanding how it works, so I backed off on doing that as much. But that means that on the forum students are not being exposed to as many advanced examples as we used to have in years past.
11 Likes
I know this was to jpearman, but the likely reason is inexperience. It is extremely difficult to write a good autonomous with PID without multithreading (i.e. drive forward while raising the lift). It is nearly essential to multithread to use PID. If a team doesn’t multithread, then likely they have not yet understood its importance of it, which opens the doors to more advanced levels of programming. That being said, most teams are simply less experienced when it comes to these things, and if any team asks for help, it exists. But if the majority doesn’t ask for help then the community cannot know who truly needs help with learning stuff.
5 Likes
It may just be that the best coders don’t ask questions or post their code here.
I’m also assuming something similar to the negativity bias is going on (an example is where only people who have bad things to say about a product post a review). In the same way, only people who need help understanding threads will post about them on vexforum. From anecdotal experience, usage of threads is somewhat common, especially among better teams.
I used tasks in RobotC all the time since it was very easy and the overarching RobotC made it pretty idiot proof.
I do most things in blocks now days since I need a quick 30 second example on how to do things. When the V2 IQ brains start showing up as a shipping item then I’ll want to use C to be able to do I2C sensors with the brain.
1 Like
I think it’s partially @jpearman and his team’s fault. 
Robot teams are standing on his shoulders.
In RobotC tasks were used to handle blocking. A programmer would put the arm code into a different task as the chassis code. We would have to write the hold function to keep the arm in a position. If the hold function was in the same task as the chassis you would lose control of the chassis while the hold was running because the code was stuck in an inner loop.
V5 kids these days get to use MotorArm.setBrake(brakeType::hold); and you are done. The same goes for the Drivetrain. It is very easy to use and does the heavy lifting.
Now I’m not complaining. Programming is a global community effort and we all help to make it better and easier for more people to learn and gain access. Here’s to the hard working programmers at Vex and its affiliates.
//RobotC Sample Lift Control
task liftControl(){
int PIDTargetValue;
//PID constants. Do research if you don't know what these are
float kp = 0.5;
float ki = 0.01;
float kd = 0.00001;
int error;
int integral = 0;
int derivative;
int lastError;
int PIDDrive;
while(true){
if(vexRT[Btn[6U]) == 1{ //Pressing Up
//lift up
motor[liftRight] = 127;
motor[liftLeft] = 127;
PIDTargetValue = SensorValue[liftPot];
}
else if{vexRT[Btn[6D]) == 1){ //Pressing Down
//lift down
motor[liftRight] = -127;
motor[liftLeft] = -127;
PIDTargetValue = SensorValue[liftPot];
}
else{
//PID to hold
error = PIDTargetValue - SensorValue[liftPot];
integral += error;
derivative = error - lastError;
PIDDrive = kp*error + ki*integral + kd*derivative;
motor[liftRight] = PIDDrive;
motor[liftLeft] = PIDDrive;
lastError = error;
}
wait1msec(15);//don't hog cpu
}
}
3 Likes
Actually, this was exactly what I was thinking this would be useful for. I’m going to start coding a better graphics API since in vexcode it is very annoying to do pretty much anything with graphics besides circles and rectangles. I haven’t looked yet, but I believe we’re able to see the source code of what the graphics functions do, which is really nice if I can use those basics in the main code (I.e. I can make more complex things like buttons, I made a whole thread about this).
I do like what the other guy said about autonomous. I did not have PID in my code last year and it showed. We should definitely do that this year. I’m thinking I will have one thread for drivetrain, one thread for lift systems, one thread for graphics, and one thread for service buttons (I have around 7 buttons that check different stats about the robot): does this sound like too many for the Brain?
1 Like
I think it partly depends on how long of waits you have. If half of your loops have a 2 second wait with every loop, it takes less brain power than all of them having only 3 msec waits. With that said, I don’t really know how powerful the V5 brain is, so maybe it would still run fine.
1 Like
Having different wait loops is smart, since I don’t need graphics to be super fast and well updated. A 200 ms wait could be fine. Thanks
What does PID stand for?
There’s probably 70 posts on the forum man. Look it ip
I would suggest searching the forum to figure out what PID stands for and how to code it. I made a tutorial a while ago on how to code PID if you’d like to look at it. It also includes multithreading as well
2 Likes
Does anyone know the answer to this? That is like the only thread command I use
detach is a dummy function, it does nothing.
/**
* @brief Permits the thread to execute from the thread handle.
*/
void detach() {};
It’s only there for users who may be used to using std::thread.
9 Likes
I actually found your post while searching for what PID stands for!