Perpetual motion controller

I'm not going to vouch for some "Biafra Airlines" plane though.

If I interpret the preliminary results of the board of investigation correctly, it was a software failure that killed 9 people in the Turkish Airlines crash in Amsterdam about 3 weeks ago. A faulty radar altimeter made the autopilot (that was landing the plane) think it was much closer to the ground (and to the runway) than it actually was. hence, the throttles were retracted reducing thrust to minimum. The plane stalled before the pilots could correct the situation, fell from an altitude of 500 meters. it was simply a miracle that the wreckage did not catch fire.

I'm not going to vouch for some "Biafra Airlines" plane though.

If I interpret the preliminary results of the board of investigation correctly, it was a software failure that killed 9 people in the Turkish Airlines crash in Amsterdam about 3 weeks ago. A faulty radar altimeter made the autopilot (that was landing the plane) think it was much closer to the ground (and to the runway) than it actually was. hence, the throttles were retracted reducing thrust to minimum. The plane stalled before the pilots could correct the situation, fell from an altitude of 500 meters. it was simply a miracle that the wreckage did not catch fire.

This thread has descended into total nonsense!

I wish civilian pilots would be a bit more distrusting.

It's one thing to rely on the autopilot at 30,000 feet, but during a landing it would be a lot better to keep the hands on the controls, while watching the ILS and ground, all the time prepared. There are so many other things the automatic landing systems can't detect - even if they have go-around quick-buttons for automatic automatically aborting a landing.

Having made a mental decision where the power should be reduced, the pilot would not need any extra response time if the automated landing system tries to reduce the power long before the pilots decided point.

But this problem exists everywhere. A lot of car companies have very advanced solutions to predict and automatically break before you run into stopped cars in front of you. But they are very scared of releasing the systems since they know that people will rely on them instead of using them as an extra guard. If professionals relaxes and puts all trust in automatic systems, how can a normal user be assumed to be better?

We already have a generation of people assuming that ABS breaks will guarantee the ability to break with maintained steering. The anti-skid systems of most newer (at least premium) cars will make people assume that they can't loose control of the car as long as they just hold the allowed speed limit.

"This thread has descended into total nonsense!"

Safety issues with embedded systems may actually be more on-topic for this forum than perpetual motion, even if safety issues may not win a Nobel price in physics.

What do you mean, "descended"?

A Perpetual Motion Machine is total nonsense!

en.wikipedia.org/.../Perpetual_motion_machine

Per,

Excellent catch:

to make sure that all bits of the lock_enable variable has the expected state - unless the product had been self-defense and multi-shot like a stun gun in which case it might be preferred to defend one time too much.

It was just an example, and the code review guys might have caught me on that one. The use of the '!=' versus the '==' operator is something I practice and/or is a habit. At least one in which I would like to impart to others.

My defines for TRUE and FALSE are not the simple 0 and 1, or 0 and !0. if it is #defined, it usually contains 'many bits' (like your example of 0x5A/0xA5... or like 0xAAC3/0x553A, but it will also depend upon the processor architecture, instruction-set, etc. It is in a separate 'logic.h' or 'logic.inc' file.

And sometimes it is also #define TRUE (!FALSE) where FALSE = 0. Which I find 'lame.' Most of the time FALSE should be zero though, while TRUE is not simply a simple 1 or all 1 value:

0x0000 - 1 = 0xFFFF
0xFFFF + 1 = 0x0000

So you're only one bit away from a state change. (I'm sure there are many articles about this somewhere in the www).

It is a better construct to use a typedef/enum for flags (Boolean states) like TRUE & FALSE (where it is also assigned a value in the enum, and then actually declare the data-store as that type for your code.

// you pick your favorite name and/or 0 versus !0 thing
typedef enum {FALSE = 0x00, TRUE = !FALSE } boolean_typedef_name;

// not 1 bit away from state change on a 16-bit system
typedef enum {FALSE = 0x0000, TRUE = 0xC3A5 } Flag_Type;

// an 8-bitter: 8051
typedef enum {FALSE = 0x00, TRUE = 0xCA } Flag_Type;

Flag_Type Add_New_Code_Monkey( u8 *name )
{
    Flag_Type hired;

    hired = Check_Name( name, "Per" )

    return( hired );
}

But my point is, that Per is keenly aware of the potential to 'prefer' one state versus the other. Unfortunately, most 'bosses' are unaware of the difference between catching that and the code-monkey who can't. Thus during your performance review, you'll get chided over how many Post-It notes are on your monitor while Curious George in the cube next to you gets the kudos for 'neatness.' [If you're working at a place where the boss is that clueless, leave as soon as you can].

As far as my Biafra Airlines (Biafra == a country that existed from May of 1967 to January of 1970) comment, and the whole thing about flying is that although 'we' know how things can go wrong on very complex systems, when I fly, I don't get freaked out over it.

My wife on the other hand is very nervous when flying. Yet I have more of a reason that her to be nervous as I know more about the plane than she does. (While in flight, various noises that 'freak' passengers out, but they don't bother me at all since I have a clue on what that 'noise' means... and my wife knows that I know: she hates it when I used to say "Oh my! What was that noise?" just to get a rise out of her---I stopped doing that a long time ago).

And yes, the thread name is so very apt for the topic of the pursuit of Safety Related Issues of the non-Nobel Prize winning type.

(Funny how 'Nobel Prize' came up, as a coworker here knows, personally, several people who have received them. But, I'm starting keep my eye on *that* person though; 'cuz I'm just not sure about this one's 'stability' yet: a "Change" type personality).

--Cpt. Vince Foster
2nd Cannon Place
Fort Marcy Park, VA

I used to think that I was a fairly competent programmer.

However ... after noticing some of the responses on this thread I'm starting to wonder if I've got sufficient experience to even attempt to read them. I won't even pretend to say I can understand what it's all about!