C++ usercontrol priority

How do i set the task priority of user control and other tasks? The competition template in VCS has usercontrol defined as a function so


doesn’t seem to work because usercontrol is not a task. Will


have the same effect? It results in an error when I try it. My problem is my background task that displays LCD values is cutting down response time of user input.

Short answer, don’t change thread priority. Here’s why: if you have a priority thread, schedulers can tend to only run that thread if it’s allowed to run and not sleeping. [James has alluded to VCS’ scheduler having measures to avoid this scenario. Watch for his elaboration.] Also, it might not even solve your problem, depending on the nature of your problem.

And yes,




are functions, [not the actual threads themselves,] so they will not have the methods of the


class. You won’t have access to the thread objects that run those functions. To do anything just based on “currently running thread” look at the


namespace. And then don’t use


. It will only cause headaches. A better practice would be to make sure that the threads you don’t care about spend a lot of time sleeping so the threads you care about run more often. There are some additional nuances when you involve the nature of the thread scheduler, but for VCS I can’t speak as an authority on how they do scheduling beyond that they used a cooperative scheduler the last time I checked.

If your LCD display value is causing issues with response time in driver, add a vex::task::sleep(30); or a similar wait time to your display code, and that should fix that issue. Can you post your code for driver and the display updating so we can see exactly what is going on?

In VCS they are threads.

again, not as true with VCS, I’ll explain more later than I have time

Ya this is the most correct answer. The display code should not be allowed to eat all your resources.

Here is my display task, it does have a sleep command embedded.

int Display(){  //display task
    int Actual = 0; //actual current speed
        //clears lines without being as interruptive 
        Controller1.Screen.print("Actual:     ");
        Controller2.Screen.print("Actual:     ");
        Brain.Screen.print("Current Shooter Speed:      ");
        Actual = Shooter.velocity(velocityUnits::rpm);
        Controller1.Screen.print("Actual: %d", Actual);
        Controller2.Screen.print("Actual: %d", Actual);
        Brain.Screen.print("Current Shooter Speed: %d", Actual);
        for (int i =0; i < 4; i++){
        //fast loop - updates other data faster than the actual shooter speed    
        Controller1.Screen.print("Speed: %d", ShooterSpeed);
        Controller2.Screen.print("Speed: %d", ShooterSpeed);
        Controller1.Screen.print("Temp: %1.2f%", Shooter.temperature(percentUnits::pct));
        Controller2.Screen.print("Temp: %1.2f%", Shooter.temperature(percentUnits::pct));

Could the low response time be caused by

LeftMotor.spin(vex::directionType::fwd, Controller1.Axis3.value()/2.0, vex::velocityUnits::pct); 

in user control? Where

Nothing wrong with that display task, runs here ok, no impact on reading controller. Send me the whole program (the .vex file) and I will have a look.

Here is the program, after testing with it some more I found the likely cause

            if(ShooterSpeed >= 180){
              ShooterSpeed += 10;  
            while(Controller1.ButtonUp.pressing()||Controller2.ButtonX.pressing()){}//this here is the problem
        }else if(Controller1.ButtonDown.pressing()||Controller2.ButtonB.pressing()){
            if(ShooterSpeed <=100){
              ShooterSpeed -= 10;   

I added the while loops to stop the code from registering multiple button presses but this just stops all code from executing. If I use


and create a function called addFunction that executes the code I need this should solve the problem?
12-10-18_JD.vex (20 KB)

yea, this


would block all code in the same thread from running, other threads should continue.

And yes,


That will get you a nice, edge-triggered callback for the event of the individual button press. Much easier to deal with than a periodic checking in a dedicated task.