# Confused about the variables in RobotC?

I'm trying to program advanced functions in RobotC but I'm not too sure I'm doing it right. I want to specify the motor port I'm using, but I assigned names to all the motors. Funny thing though, they don't exactly work the same as regular variables.

For instance, motor[port7]'s alternate name is light_blue.

#pragma config(Motor,  port7,           light_blue,    tmotorVex393, openLoop)


I'm not really sure if these are new variables, or just specifications. Anyway, here is the variable's signature:

int motor[tMotor motor]


My code plans on doing something similar to this:

void testThing (Motor motorName)
{
motorName = someValue;
}

testThing(light_blue);


But with the int/motor hybrid variable/unidentified I'm not sure how well that would work out. Or at all.

-

The #pragma is more like a #define in terms of names, as opposed to a variable declaration.

Your code is very close; something like this would work fine;

#pragma config(Motor,  motorA,          light_blue,    tmotorNXT, PIDControl, encoder)

void testThing (tMotor  motor_name)
{
motor[motor_name] = 20;   // set power to 20
}

{
testThing(light_blue);
}


The actual type of a tmotor is an enum (and used like an int) and the definition can be found in RobotCintrinsics.c included with the product.

for exmaple;

#if (1)

// the actual 'enum' values for 'tMotor' are automatically defined by the ROBOTC compiler. Each platform
// and circuit board type has its own set of "enum names" and it was becoming too hard to manage them in
// this file. So they are automatically configured by the compiler which has better utilities for managing
// differences between platform types.

typedef enum tMotor;

#else

// The old definitions are temporarily maintained here as well until the new implementation is confirmed
// to be working well!

#if defined(NXT) || defined(TETRIX)

typedef enum
{
motorA = 0,
motorB = 1,
motorC = 2,
mtr_S1_C1_1 =  3,

... etc


If i was to look at your code, and accept its functionality as literal then the following would work;

#pragma config(Motor,  motorA,          light_blue,    tmotorNXT, PIDControl, encoder)
#pragma config(Motor,  motorB,          light_green,   tmotorNXT, PIDControl, encoder)

void testThing (tMotor&  motor_name)
{
tmotor_name = light_green;
}

{
tmotor motor_to_use = light_blue;
testThing(motor_to_use);
motor[motor_to_use] = 20; // will actually move light_green since testThing function changed its value
}


It's hard to guess what it is you are trying to actually do

-
Exactly, but I actually need to know the compatibility between word types, since tMotor is not a type, just a specification. – Mia Garbaccio Jan 5 '13 at 18:47
Nevermind, tMotor can be used as a variable specification. Thanks! :D – Mia Garbaccio Jan 7 '13 at 1:45

I think I see where you're confused, and you're correct in noticing that the motor variables are a little different than regular variables.

The #pragma config( ) is actually doing a lot of heavy lifting for you because it is a "preprocessor directive". In other words, there is a hidden step — preprocessing — between the code you wrote and the code that the compiler sees. The preprocessor is why you have access to the motor[ ] array (which you didn't need to declare before using), and why assigning a value to a motor causes your real-world motors to move (which does not happen when assigning to a "normal" variable). The code generated by the preprocessor is saving you from writing a lot of setup code yourself, but it is also making some normal-looking variables do some unexpected things.

In your case, this is the motor config line that you wrote:

#pragma config(Motor,  port7,           light_blue,    tmotorVex393, openLoop)


This tells the preprocessor to generate some code that does the following:

1. Declare a variable of type tMotor and store it in motor[light_blue]
2. Set the port of motor[light_blue] to port7
3. Add a function that gets called when you assign a value to motor[light_blue], which converts that value directly to a power-level signal understood by Vex 393 (and outputs this signal on port7). In other words, use open loop control instead of PID control.
4. (Other things not relevant to this question)

So, light_blue is not an "alternate name" for motor[port7], and in fact neither of those names are correct. The correct way to refer to this motor in code is motor[light_blue]. In other words, light_blue is an index into the motor[ ] array.

The code that Spiked3 posted would be the proper way to set up your function:

#pragma config(Motor,  motorA,          light_blue,    tmotorNXT, PIDControl, encoder)

void testThing (tMotor  motor_name)
{
motor[motor_name] = 20;   // set power to 20
}


I agree that motor is a built-in variable, but I'm saying that it originates from the preprocessor -- not specifically as a result of the #pragma config( ). Most likely it's part of some header file that's pulled into every project as part of an automatic #include. – Ian Jan 6 '13 at 18:13