I was testing the public RC1 yesterday and really like some of the new features. Before I was running 1.10 with the appropriate firmware. Because some new test functions (i.e. for acceleration sensor) where included, I wanted to make use of them. Unfortunately the NXT keeps telling me "Bad version!". I tested with acceleration and sonar sensor in particular, but also tried to use the other test buttons without attaching the appropriate sensor with the same result. Also I tested the view function on NXT and found the sonar sensor stuck at a value of 253. The light sensor is working in view-mode (it didn't test more sensors). Is this a bug of the firmware?

By the way, the program I was running in 1.10 without compiler errors, now produced a bunch of it. In particular he was complaining something with the line (I didn't pass to the other errors so far):

Was there any change with the type "tMotor"?

hi, concerning tmotor, this is what I found:

does this help?

BTW:
I prefer to use the direct port addresses, or variables, not constants, e.g.


To me, this is more "C-like", more strict and straight, and actually more "simple and stupid".
Additionally, if you use numbers instead of const names, you may increment and calculate with those by for- and while-loops (sorry for my poor English):

(just my 2ct)

Thanks for the answer. Interesting to know. Where did you find the definition?

The error messages I get are as follows:



These are just generated when including the line:



The warning can be simply overridden by adding type "short" in front of "tMotor". All the other errors seem to originate from some declaration syntax he doesn't like.
But the same code was working perfectly with RobotC 1.10!? Any ideas?

what happens if you erase "const" and write:


but, again, why do you use tMotor at all? It's just an Integer, why don't you use an integer?



To my opinion, this seems to be a bug, maybe you wish to report this to the bug tracker.
Let's see, what the developers will respond to this...

Removing "const" results in one error message less than before (the first error message is suppressed).

Why using this at all? First, its a way of keeping the code more readable. Second, I don't mind using it or not. I just copied from one sample program and had the opinion that it should keep working also in the new version of RobotC, which apparently is not the case. So I just wanted to clarify, because I want to understand what is happening (the only way to learn the language).

Before reporting this as a bug, I wanted to make sure its not just a mistake by me. Although I have experience with programming, I'm still a beginner in terms of RobotC.

Thanks so far. Any further comments are welcome.

Using
there is not such an error message with neither the 1.38 nor the 1.22.
There wasn't any change with the type "tMotor" till 1.38.
But there are meanwhile more compiler "errors" by newer releases, where there haven't been any with earlier ones.

Plz send us the complete original source code to check it out.

BTW: did you completely remove the 1.10 before you installed the 1.40, and did you download the associated firmware (because of the "bad version")?

Of course I did. In fact it has nothing to do with the firmware on the NXT. This is a pure compiler issue. I discovered so far that "tMotor" is no longer accepted as variable type. Therefore you could simply declare anything with "tMotor" and get these error messages, e.g.:



If you simply exchange "tMotor" by for example "short" everything is fine. As you already explained this will make no difference in the program anyway. So this is a simple workaround. I just wonder if it was intended to remove "tMoter" as type declaration?

BTW: Anybody discovering theses "bad version"-messages when using the sensor-test-functions under 1.40 public rc1?

Hi Zeron,

The correct declaration should be this:

const tMotor NewNameHere = (tMotor) motorA;
const tMotor NewNameHere = (tMotor) motorB;
const tMotor NewNameHere = (tMotor) motorC;

Tmotor is a fixed variable in RobotC, it should not be changed. The reason is the motors and sensor setup wizard uses this variable. Try experimenting with this wizard by going to Robot in the upper menu and selecting the Motors and sensors wizard. This wizard lets you give motors or sensors simple names to use in your program, so you don't have to always use motorA or S1 S2. You can name the port LeftMotor or RightLightSensor.

It looks like an older wizard or compiler may have generated some bad syntax that has been fixed in the newer release.

Hope this helps, let me know if this works.
Scott B-)

Thanks for the suggestion.
For testing, I setup a motor on port B, which then generated the code:


Interesting feature! This way the declaration I used before is not needed anymore! Anyway, the code causing the error I retrieved from one of the examples which are delivered with RobotC. The typecasting "(tMotor)" doesn't help at this point. Really seems to me as if this type is no longer valid. Maybe it is intended.

I got feedback from the developers via the bug tracking page. Here is what they told.
Regarding the "tMotor"-problem:



As I've already assumed, this kind of declaration is no more valid. Regarding the sensor-test function I got the following info:



BTW: Can any moderator or admin delete this spam-bot "micky0604", please?

hi,
I don't think it's a good idea always to setup motors and sensors by the automatically generated code.

1st, because I hate automatically generated codes. They could put header files and libraries to the examples, so that everybody can read the code and include it if he wants (or not), but please no hidden functions, no automatics, and no "code optimization" beyond the programmer!
2nd, because manual assignment of I/Os is the usual way of programming (and this is even better for "educational" intentions).
3rd, because code portation to other C platforms (such as NXC and even a ATMEGA32 or renesas C) is much easier if you have your own private ways of assignments, and those common C compilers NEVER have automatic generated code.

so, what should this be for ?

As you can see in one of my former posts, there is still some manual declaration possible (without using the dialog):



This should do the job. Of course, more documentation about #pragma definitions would be appreciated.

how will you tell a NXC or a renesas or a Atmega 32/128 C compiler to compile this ?
(back to the C roots!)

PS:
this is the C code which a "real C compiler" (renesas C) uses to switch on outputs (motors) and to get sensor inputs:.


To make this readable, you surely will have to write macros and functions like

(or use such functions enclosed in some libraries) which encode these "close-to-hardware" commands.
By routines like these, motor and sensor control can simply be adapted to the current hardware.


THIS is "REAL C" - this is the way RobotC is expected to work!
What Robot"Fantasy"C does is not "real C": it's sometimes easier, sure, but mostly it's unfathomable and unpredictable !

But this is the way RobotC works. And to my opinion it is fine anyway. I'm used to adapting code when running on other machines or compilers. But I understand your complains. Nevertheless the more I work with RobotC the less I feel, the compiler does things, which I can't control. I think it just needs some more polishing and bug-fixing. Why not just switching to another language, if you find one that fits your needs better than RobotC? Is "rensas C" something which can be used for the NXT?