Running version 1.44.

See example below

Using your FTC controller simulator or the Labview FTC Controller simulator, the values of the StopPgm and UserMode seem to be the reverse of what is expected.

Disabled is reported when enabled is selected

Teleop is reported when autonomous is selected

#include "JoystickDriver.c"

task main()
{
while(true) //continously loop to check for "mode" switching
{
getJoystickSettings(joystick); //update joystick values from FMS
if( joystick.UserMode == false) //While in "autonomous" mode (UserMode = false)
{
//do autonomous
if( joystick.StopPgm == true )
{
// we are disabled
nxtDisplayClearTextLine( 4 );
nxtDisplayTextLine( 4, "Disabled Autonomous" );
}
else
{
// we are enabled
nxtDisplayClearTextLine( 4 );
nxtDisplayTextLine( 4, "Running Autonomous" );
}
}
else //While in "User Control" mode (UserMode = false)
{
//do usercontrol
if( joystick.StopPgm == true )
{
// we are disabled
nxtDisplayClearTextLine( 4 );
nxtDisplayTextLine( 4, "Disabled Teleop" );
}
else
{
// we are enabled
nxtDisplayClearTextLine( 4 );
nxtDisplayTextLine( 4, "Running Teleop" );
}
}

// wait for next packet
wait1Msec( 50 );
}
}

It does the right thing when I run my program...
I guess that you did not take into account that StopPgm would be True if the robot is disabled because the variable is named StopPgm and not StartPgm...
Just use common sense to write the program, not boolien logic. If you were trying to stop the program, then you would want StopPgm to be true.

In the example program, when StopPgm is true the message printed to the screen is "Disabled Autonomous" or "Disabled Teleop". ie StopPgm == true means disabled. However, when you use the field controller simulators (LabView or RobotC) and select "Disabled" the display on the NXT changes to enabled. This means that StopPgm is being set to false when disabled is selected on the field controllers. This is the opposite of how it should work.

That is strange, I just tried out my NXT a few days ago, and the same problem happened. Get RobotC version 1.45 out before it's too late!!!

I'm looking at the root cause now.

An immediate and temporary fix appears to be change "bool" to "short" in the following two lines in "yostickDriver.c" program.

Old Value


New Value:

If a new version of ROBOTC is required, then it should be release monday (tomorrow).

Another small point. In the C-lanague a boolean value of false has the value zero. Any value that is not zero is usually considered true.

Internally, ROBOTC, along with many other compilers/systems, uses a numeric value of 1 to store the true value.

It is not best programming practices to use the following language construct because of the potential ambiguity.

because it will be a comparison against the value '1' which is most likely not the intent. The intent is most likely is the value not false.

So the following are good programming practices

A small clarification on the intent of the "StopPgm" variable. It is used as a "Pause" command to stop your robot moving. I believe the only case where it will be used is before the start of either autonomous or tele-operation mode.

A new version of ROBOTC with this fix is available. See forum posting http://www.robotc.net/forums/viewtopic.php?f=33&t=797 for location.

Even better practice is to never compare anything to "true" or "false" but to use the boolean values directly like so:

Dick,
this is not correct !

in ANSI C
the "truth value FALSE" means equal to 0 (zero)
the "truth value TRUE" means unequal to 0, so any other value different from 0 is TRUE (e.g., 2 or 6Million or -784623 or "t").

So if you define a system constant / key word "true", this has to be taken into account; maybe the (pre-) compiler should substitute the key word "true" by "not 0" or "not false", so that there won't be any difference between the "truth value TRUE" and the system constant "true":

if (boolean_value == true)
means:
if (boolean_value !=0)
and must not mean
if (boolean_value ==1)

Sorry Ford but ANSI C does not include keywords for "true" and "false". Most C compilers include them either as #defines or as keywords but there is nothing in the ANSI spec about it. Furthermore, every C/C++ compiler that I have ever used (or heard of) that does defined "true" uses a single numeric value, typically either 1 or -1.

Example: Microsoft VS 2008's documentation for the C++ "false" keyword says:



Please point me to where in the ASCI C definition that it says otherwise.

no, Ididn't say that it should have!

I said: the truth values of TRUE or FALSE (statements) are defined like this in ANSI C, e.g. in
if (bool_var)
or
if (!bool_var)

And what I meant was, when there is a global system constant called "true" (which in fact does exist in RobotC, and what actually is NOT ANSI C), this constant "true" must behave just like the logical truth values, so

if (bool_var) must always be identical to if (bool_var==true) // which is NOT the same in the moment
and
if (!bool_var) must always be identical to if (bool_var==false) // which (mostly) is the same in the moment

There are 2 implications to be made for this

bool_var = true
has to be exchanged by the (pre-)compiler to --> bool_var = 1

and
if (bool_var == true)
has to be exchanged by the (pre-)compiler to --> if (bool_var != 0) or to if (bool_var)

If it's interpreted like this, it will work logically correctly.

sorry for my poor English - if you wish, I will be able to explain it better in German.
One point is (German:) der logische Wahrheitswert einer Aussage ,
the other point is (German:) der Variablenwert einer Booleschen Variablen oder Systemkonstanten,
und alle Wahrheitswerte und Variablenwerte müssen im logischen Sinne immer übereinstimmen.
Die Konstante "true" grundsätzlich immer mit "1" gleichzusetzen ist jedenfalls Bullshit.
(You understand "Bullshit"? It's supposed to be the same word as in English )

Your theory would make more sense if ANSI C specified intrinsic "true" and "false" constants. It doesn't. As you say, in C any non-zero value is logically true. So, the statement "if (5) ...." is functionally equivalent to "if (1) ...." or "if (-742) ....". However, no C complier makes "if (<expression> == true)" mean "if (<expression> != false)".

Find me a single example of any C compiler that would evaulate (5 == true) to be logically true. Every C compiler would evaluate (5 != false) to be logically true.

Jeff

I never said ANSI C specified intrinsic "true" and "false" constants, I spoke of truth values, an these are values of Boole's Algebra.


ok, I thought you didn't understand the mathmatical deduction. So I can make it quite easy:

C compilers identify a statement (expression) as false, if the numeric value is equal to 0 (zero),
and a statement (expression) is identified as true, if the the numeric value is unequal to 0 (zero), e.g. 2 or even -3.

Regarding this, you can't go and define a "faked constant" also called "true", which is only equal to 1.
That's a contradiction.

If you implement a Boole's variable called "true" (like in RobotC) you have to consider this.

I completly understand your argument. I did from your very first post. In pure boolean algebra your arugment is true. However, you are were talking about a C compiler. No C compiler treats boolean expressions and relational expressions the way you think they should. I believe that it is more important for RobotC to treat boolean expressions and relational operators consistantly with all other C compilers than to meet a theoretical standard of boolean algebra that no other compiler follows.

Jeff