Weird Disappearing Commands

[Orborde]

That's the best description I could think of to describe this problem. I have the following code:

void Elbow_Targetize_PID(void) {
     unsigned int current;
     signed int error, output;

     current = Get_Analog_Value(elbow_pot);    // measure the elbow potentiometer

     elbow_motor = 127;   // just to be safe

     // (elbow_target_abs is a global variable describing the goal state of the
     // potentiometer. It is set up this way to make the elbow's usage roughly
     // in line with that of the PWMs and such

     error = ((signed int) elbow_target_abs) - ((signed int) current);
     //yes, I know I'm cast-crazy...

     output = (error >> 3);   // quickly divide by 8
     output = output * 2;    // and multiply by two (I have no idea why I did this)


     // kick the output out of the deadband
     if (output < 0) output -= 7;
     if (output > 0) output += 7;


     // finally, assign the end result to the motor (it's backwards)
     elbow_motor = (unsigned char) (127 - output);

     // the output gets limited later by a safety function, though it occurs
     // to me that I should do it in here to avoid problems
}

First, yes, I know it's just a P, not a PID, controller. Sue me.

At any rate, the problem is in the bolded lines. They don't seem to be getting executed at all. I've checked it several times and it still doesn't seem to do it. Now, the elbow control works fine despite this, but it still worries me. I can only guess that those few lines are being "optimized" away for some reason by mcc18. I even put the same function into another development environment and tested it, and it worked as expected. What gives?

I'm using Master Software 10 and mcc18 2.40 with MPLAB 7.00.

Maybe I'm crazy. Could someone else try this function to see if the problem shows its hairy face?

[Greg Ross]

Originally Posted by Orborde

At any rate, the problem is in the bolded lines. They don't seem to be getting executed at all. I've checked it several times and it still doesn't seem to do it. Now, the elbow control works fine despite this, but it still worries me. I can only guess that those few lines are being "optimized" away for some reason by mcc18. I even put the same function into another development environment and tested it, and it worked as expected. What gives?

May I ask HOW you know that these lines are NOT being executed? Could it be that they are executing, but simply not doing what you are expecting?

I can spot several chances for errors in this code. First: >>3 works great for positive numbers, but will only give you headaches if the number you're shifting is negative. (I'm almost positive. I'll leave it as an exercise for the student to demonstrate yea or nay.)

Second, if you're expecting the lines in questions to only do something when output is between -6 and +6 (as your comment seems to indicate that you might), you're wrong!

Third, if output starts out between -6 and -1, it will first have 7 subtracted from it, and then immediately have 7 added back in!

Do any of those sound like it might explain the behavior/symptom you're seeing?

[Orborde]

May I ask HOW you know that these lines are NOT being executed? Could it be that they are executing, but simply not doing what you are expecting?

I looked at some printf stuff from our robot in varying conditions and concluded it was so. However, my memory is fuzzy and the last time I saw the robot was at the Boilermaker Regional, and the last time I checked this was at St. Louis. So, having the robot not handy, I can't test it easily, and it may be a figment of my imagination. It just now occurred to me to hook up Robovation and see if I can duplicate it; I'll do that in a bit, maybe.

I can spot several chances for errors in this code. First: >>3 works great for positive numbers, but will only give you headaches if the number you're shifting is negative. (I'm almost positive. I'll leave it as an exercise for the student to demonstrate yea or nay.)

Yeah, I wondered about that, but it seems to function correctly. I tested it in Dev-C++, and it worked there, and our robot doesn't seem to be doing a crazy-loony dance, so that seems okay.

Second, if you're expecting the lines in questions to only do something when output is between -6 and +6 (as your comment seems to indicate that you might), you're wrong!

Fortunately, no, it is intended to be the way it is in that respect. The idea is that if there is nonzero output it will need a push to get out of deadband. I'll update the comment in my own code.

Third, if output starts out between -6 and -1, it will first have 7 subtracted from it, and then immediately have 7 added back in!

I thought you had nailed it, but then I realized that, no, the 7 only gets added if output > 0, and is only subtracted if output < 0.

I'm sure I missed something, though. When I posted this, I had momentarily forgotten my motto, "No matter how irrational the problem seems, it's always your own dumb fault." Thanks for the help. Feel free argue with and make fun of me if my logic is fatally flawed.

[Greg Ross]

Originally Posted by Orborde

I thought you had nailed it, but then I realized that, no, the 7 only gets added if output > 0, and is only subtracted if output < 0.

Never mind. I was thinking that if output was negative, then 7 would be ADDED (not subtracted.) Thus, after the addition, the value could be greater than zero, and the 7 would then be SUBTRACTED back out again.

[Ryan M.]

Just for giggles, why not try changing the divided by 8 and multiply by 2 into a divide by four? It will probably be about the same, and even if it's not I don't think the nanoseconds will be noticable.

P.S. Casts are good. I had at least 3 times where I'd test something for literal hours, only to find that my original code was fine. All I had to do was add casts for things which the compiler should have been able to easily handle on its own...

[billbo911]

Originally Posted by Orborde

// kick the output out of the deadband
if (output < 0) output -= 7;
if (output > 0) output += 7;

If I understand the "kick it out of deadband" and the rest of your code, the problem should be Victor related.
What I am getting at is that the speed controllers have a built in deadband of +/- 10, not 7, centered on 127. In other words, 7 doesn't quite kick you out of the deadband region. But expanding your numbers too far could lead to an unsafe/uncontrollable situation where it will never find a stationary position.
Try increasing the value +/- 1 at a time.

And, by the way, let us know how it turns out!!!