Perpetual motion controller

Know how to keep a perpetual motion engineer busy?

Please see the middle of this thread (look for my name) for some helpful examples.

http://www.keil.com/forum/docs/thread14479.asp

Know how to keep a perpetual motion engineer busy?

Please see the middle of this thread (look for my name) for some helpful examples.

http://www.keil.com/forum/docs/thread14479.asp

Know how to keep a perpetual motion engineer busy?

Please see the middle of this thread (look for my name) for some helpful examples.

http://www.keil.com/forum/docs/thread14510.asp

I forgot to send that link as well.

My close call was along time ago, when I came in on Monday morning, there was "The Phone Call" awaiting me/us in the conference room. The call was from the launch-pad (all fueled up and awaiting the 'big red' launch button), and it turned out that MY widget failed the pre-flight testing. Which in-turned scrubbed the entire launch. ($$$).

Yup, I was "That Guy" and shall never-ever be him again.

But, and this got my hind-quarters out of the fire, the root cause was technically mine, but equally theirs.

THEY requested that I make "a minor change" on Friday afternoon. Then ship it out Overnight so they could integrate it over the weekend, and be ready for the launch on Monday 'Mourning'. When they 'asked' for the change, I explained that it would take an additional eight-hours for the re-qualification process. They said "we'll write a 'waiver' for that" so I didn't have to test it after I made the change.

I told them that wasn't a good idea, and questioned the absolute need for the change... they messed up something on their end, and my widget needed to make up for it. Hmmmm.

It was a simple change, but I forgot a little teeny tiny thing (out of tens of hundreds), and I became "That Guy" ... even have a project related coffee mug that puts my name in quotes due to that issue.

I wonder if I made that tiny mistake on a subconscious purpose to 'prove them wrong' but I really don't think so: such a trivial triumph is so minor to the 'down-side' of being "That Guy."

Anyway, they didn't 'water-board' me, but I now know what a "Mancuerda" is. When I regained consciousness again, it turned out that I got off lightly because of the big warning I gave them before-hand... and that it was a last-minute patch-job due to somebody their end doing an 'oops.' (And there are hundreds of thousands of potential 'oops' in these things). Unlike the picture Per paints, not all companies kill "That Guy" because of the investment in such a lesson learned. Ever drop a $7,000,000 camera? I did. Won't do that again either.

The tiny mistake: copy-n-paste, then change the copied new values... I missed one. (I was doing it in assembly and not "C" so it was a tad more complex that this example which is completely made up example and but makes the point):

 locked_on_1 = Get_Evil_Bad_Guy_Image( IR_CAMERA_1, &sardine_image.frame.current  );

 locked_on_2 = Get_Evil_Bad_Guy_Image( IR_CAMERA_2, &sprat_image.frame.current    );

 locked_on_3 = Get_Evil_Bad_Guy_Image( IR_CAMERA_3, &smoked_image.frame.current   );

 locked_on_4 = Get_Evil_Bad_Guy_Image( IR_CAMERA_3, &jack_image.frame.current     );

 lock_complete = ( (    ( locked_on_1 != FALSE )
                     && ( locked_on_2 != FALSE )
                     && ( locked_on_3 != FALSE )
                     && ( locked_on_4 != FALSE )

                   ) != FALSE
                 )
                     ?     // ternary = ( cond==TRUE )? TRUE : FALSE ;

                    TRUE   // TRUE == !FALSE, so TRUE goes here

                     :

                    FALSE
                 ; // end ternary, end assignment

 // if true, then bad things happen to bad guys...
 if( lock_complete != FALSE )
 {
    Enable( BAD_THINGS );
    ...
 }
 else
 {
    Disable( BAD_THINGS ); // just in case
 }

See how all four cameras are used?

Andy, funny you should mention the ejector seat. I helped on a project for a vectored thrust ejection seat controller that could "intelligently control" the seat path. An inverted aircraft near the ground the seat would blast-out, and re-direct up and away from danger, like the ground or the tail. Was cool. I'm sure they're standard issue by now. (Forgot the name of the oh... its was called the "MAXPAC" ejection seat--it worked and it wasn't called "The Judas Seat" Project after all).

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

Don't talk about ejector seats. That was the most recent JAS 39 Griffin accident. The handle for the ejector seat (updated in the most recent edition of the plane) was found to be able to snag in the leg pads that gets inflated at high g loads.

One very surprised pilot suddenly found himself leaving a perfectly working plane in a hurry because he had been a bit hasty fitting the flight dress that morning.

In real life, just about everything can fail or go wrong. And do tend to fail. Twenty years of flying and then finding that the new and improved ejection seat intended to keep the pilot maximally safe could actually be his worst enemy.

Maybe our programming editors should contain the same type of pattern matching logic that Microsoft has in Excel. If you duplicate a formula to multiple cells, you will get a warning if one cell has absolute instead of relative addressing or references one step further or shorter than another cell. Your example should be quite easy to automagically analyze and flag as suspect.

Per,

I've worked on widgets that had direct "human safety factors" involved, and I don't like doing that stuff all. So, Mr. Westermark, I can sympathize with your work.

It is scary to be responsible for the safety of people, when so many things can go wrong. Even if the root cause isn't directly tied to you, you still feel like your part could have been done better to avoid that other part you don't have control over.

Even though a 'commercial product' is just an iPhone, it could have life-saving applicability. Although it wasn't designed for that, the people writing the apps or firmware for it, should be aware its potential use.

The code should be treated like it has that life-n-death potential, and just telling yourself "well, its not like its a pacemaker and was not intended for that kind of use" doesn't absolve you of a basic responsibility to do it the best you can.

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

Vince,
I have to say something related to your posts (I like them a lot). It shows that you have been working in this field for a long time; I look around me and I see budget cuts, mediocrity in programming language skills, and danger. danger everywhere. our society is in the hands of a handful of more or LESS skilled engineers who have the safety, future and welfare of our civilization in their (sometimes) capable hands. I see managers who are even more incompetent (not at my current employer, I must say). I am not very old yet, but I have seen my share. I have been working on safety critical system until a couple of months ago until I decided to leave because I felt that the level of incompetence was exceeding any tolerable measure, and that lives were literary at risk. It is good to know that some of us have the touch, still and despite of everything.

Thanks! (especially since I ramble on so much).

Don't you worry, I've had my share of *those* people you describe. The trick is to get yourself into a position, or place that doesn't have *those* people. I've had a few jobs in my life that horrified me, while I've had jobs that were the greatest thing since [ insert-your-favorite-thing here ].

I'm currently doing some work with people who have a clue, and boy-o-boy is that nice.

NOTE: All of the military related stuff have the cream of the crop R&D engineers on the teams. At some of these 'primes' an engineer would have to work there for 15-20 years on military/aerospace stuff before being allowed into an R&D team, so by the time they're On The Team, they're gooooood. Believe me, I've felt like the 'idiot' in the room, but somehow have managed to keep my head above water.

Even so, these engineers & scientists get it wrong sometimes. (for example, uh just look around everywhere). So when I see these Code-Monkeys doing their "isn't this the coolest code-fragment ever, cuz I do this thing in which you can't tell its doing it 'cuz I used the side-effect of that to do this and it is so tight nobody but 'smart-people' can figure it out" crap, I fear for my kid's lives.

Yet, while even these 'great places to work' are sweet, they can have their idiotic bosses, coworkers, *them*, etc (ALL of my current co-workers and bosses are super-cool), but you'll still get *them* from time to time. NEVER under-estimate their ability to screw you over though. You might think you're Sittin' Pretty and there is no way they can touch you---and then wow---suddenly 'stupidity strikes' and you get screwed.

NEVER EVER let *them* have the upper hand. Don't give them something to 'catch you on' or allow yourself to be the scape-goat.

Spot *them*, watch *them*, and avoid *them* as much as you can. And when you have to interact with *them*, make sure you are viewed as being a 'good guy' and doing the best you can FOR THEM. *Those* people will stab you in the back--and fast. Make sure your back isn't turned their way or provide them with a target.

I'm doing some live-saving bio-science stuff now. If I get it wrong, they just won't know they'll die... so since--in-effect--that outcome could be changed, I'm doing that whole Human Safety Factor cra--stuff again... Oh, we'll be doing the whole government compliance stuff too. Don't get much more fun than going through the Formal Qualification processes. Almost as much fun as writing the documentation.

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

P.S. When I fly on airplanes, I'm not worried. I just don't think about the zillion 'oops' that could be flying with me. I've seen these planes being manufactured, and it does make me feel 'more safe' knowing the amount of effort and quality they put into these airplanes. Uh, at least here in the USA. I'm not going to vouch for some "Biafra Airlines" plane though.

Vince: What are your definitions of TRUE and FALSE?

Are your explicit use of TRUE and FALSE in every test and assign a result of TRUE and FALSE having very specific values, possibly completely different from the "normal" true/false of the C compiler? Such that for example hardening the code from having a single bit error of a false/cleared variable giving a 100% conversion to true/set? Something like having

enum {
    FALSE = 0x5a,
    TRUE = 0xa5
};

If that is the case, then I would prefer the last if statement to be changed from:

if( lock_complete != FALSE )
 {
    Enable( BAD_THINGS );
    ...
 }
 else
   ...

to

if( lock_complete == TRUE )
 {
    Enable( BAD_THINGS );
    ...
 }
 else
 ...

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.

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

Don't worry. Your guys fathers or grandfathers probably built those planes too. Just that the DC3 passed its best-before date somewhere when the ancients on this forum were still not born.

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!