Thanks for testing the problem, Ford. Yeah, I hadn't noticed it at all with the 1.05 std and enhanced. At first I thought it was something with the motors or the batteries. I am glad it is neither but sad that it's the FW.

Moreover, this motor controlling parameter seems to belong to another hidden background task.

I think in RobotC, there are much too many system parameters and background tasks - to crown it all, mostly undocumented.
And over and above that the compiler produces "code optimization" which sometimes is faulty and was not strictly necessary. (Let the programmers optimize their codes by themselves! It's their responsibilty!))

If a background task is needed, it's also the responsibility of the programmer, not of the compiler!

I agree to a degree. However, you must not forget the target audience of this product. It is used a lot in education and you can't expect a 12-15 year old to be able to do all those things (yet). I agree with the documentation part, though. I would love to know some of the more nitty gritty details of how the FW does certain things, like the PID control of the motors, for example.

In the end it's a trade-off, both for the manufacturer and the developer. Power and control vs ease of use I think RobotC does it quite well and I am quite happy with it so far. In fact the only "problem" I have now is that my robot reacts too quickly to certain events. It is something I didn't have to deal with when using NXC. I think it something I can live with, though

I doubt if a 12-15 year old child needs those built-in system features like nPidUpdateInterval or nMotorPIDSpeedCtrl.

And I hope that you won't misunderstand me:

I wish RobotC to be easy to use, but in a straight and direct way, just like C with it's macros and libraries.
For example, in every C language there is the basic command and key word set,
and besides this, there are "basic expansions" like
- a stdio.h with a console for input and output,
- a math.h or math.lib with exp and sin and atan and tanh,
- as well as some "advanced, more complex libraries" like a sort library with a quicksort

all these are made to make programming easier. I really appreciate those expansions also at RobotC, above all, where C has got no definitions or interfaces (e.g., for motor or sensor control). But don't let a compiler use hidden function parameters or start hidden background tasks which cause sort of "own existences".

Above all, RobotC should be C - and not a language of "fantasy and imagination".

Just remember KISS: Keep It Simple and Stupid - as far as possible:
- and not in spite of, but just because of didactic reasons

I like compilers to make my programming life easier, but as an experienced programmer I NEED to know what's hapenning in the background.

The example of C libraries is great.

When a student that I'm mentoring asks "How does the robot do that?" it's important for me to answer inteligently and accurately. If I don't know the answer I need to be able to say "Let's go look at the library and find out".

If I just have to guess at what's hapenning, then I'm doing two things....

1) I'm potentially providing the student incorrect information.
2) I'm missing the opportunity to pass on the knowledge accumulated by the person who wrote the "hidden" library in the first place.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum