Limiting Code

VEX V5 General Discussion
1

I’m trying to write a piece of code that makes it so I cant move my Chain bar pasta certain amount, which simulates a lock bar. So something that if my chain bar reaches a point where the sensor is at 2200, I cant move it any further but I cant move it back forward. Ive made a piece of code that just move it forward when it passes the breaking point. but it doesn’t look smooth and makes it difficult to manipulate. any pseudocode?

2

@97934V What you are describing is a limiting if statement, like this: (you might need to switch the greater than to less than depending on how the sensor counts… also the positive and negative power value). However, to simulate a lock bar I would recommend adding a brake or using PID to counteract momentum.


//limiting if statement
if(vexRT[Btn6U] == true)
{
     if(SensorValue[chainPot] > 2200)
     {
     motor[chainBar] = 0;
     }
     else 
     {
     motor[chainBar] = 127;
     }
}
else if(vexRT[Btn6D] == true)
{
     motor[chainBar] = -127;
}
else
{
     motor[chainBar] = 0;
}
3

The bar already uses PID, how do you do immediate counter acting for it?

Right now the code is like this

[/code/]
While(1){
if (vexRT[Btn6U] == 1)
{
chainRequestedValue =+ 0.3;

}
else if (vexRT[Btn6D] == 1)
{
chainRequestedValue =- 0.3;

}

else {
chainRequestedValue =SensorValue[LiftChain];
}
}

4

@97934V I don’t quite understand… if you are using PID it should always stop at the correct value.

5

If chainRequestedValue is 1:1 mapping with your sensor reading (it looks like it is, from the no-button else branch), you just need to limit the target. Such as:


...]
if (vexRT[Btn6U] == 1 && chainRequestedValue < 2200) {
    chainRequestedValue =+ 0.3;
}

(SIde note: I see you have a very small per-loop update (0.3), which matches my observation that you have no per-loop wait, i.e. your control task runs as fast as it can. That’s not good, that leaves your control at the mercy of the OS scheduler, whether something else is taking more of CPU at any given point, changing how often your “+0.3” gets applied. Much better approach would be a per-loop delay, allowing you to use more reasonable and consistent control. E.g. 20ms delay and an increment of 40 would allow you (as long as your PID and motors keep up) swing by 50*40=2000 potentiometer units, or about 125 degrees of the arm movement.)