6
$\begingroup$

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.

$\endgroup$

2 Answers 2

3
$\begingroup$

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
}

task main()
{
    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;
}

task main()
{
    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

$\endgroup$
2
  • $\begingroup$ Exactly, but I actually need to know the compatibility between word types, since tMotor is not a type, just a specification. $\endgroup$
    – Genevieve
    Commented Jan 5, 2013 at 18:47
  • $\begingroup$ Nevermind, tMotor can be used as a variable specification. Thanks! :D $\endgroup$
    – Genevieve
    Commented Jan 7, 2013 at 1:45
0
$\begingroup$

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
}

task main()
{
    testThing(light_blue);
}
$\endgroup$
3
  • $\begingroup$ Nice guess :) Actually motor[] is more like an array of output ports. It is a built-in variable, and not generated because of the #pragma. light_blue is just an index. RobotC has some weird compiling in that motor[idx] is the same as motor(idx) - and it can and does get confusing because samples are written both ways. It is a 'C' like language, but not a pure 'C' by any means. $\endgroup$
    – Spiked3
    Commented Jan 5, 2013 at 18:31
  • $\begingroup$ 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. $\endgroup$
    – Ian
    Commented Jan 6, 2013 at 18:13
  • $\begingroup$ yes, that is correct. specifically intrinsic word property(motor, propertyMotorPower, kNumbOfTotalMotors, tMotor); equates the RobotC variable to a firmware variable. I just wanted to make the point that there is not really any additionally generated code from the preprocessor in this case. $\endgroup$
    – Spiked3
    Commented Jan 6, 2013 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.