We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi,
I have this design for a controller but i dont know the program for it?
Where can I find the code for it? I tried google coding but cannot find it. I normally write Pascal(Delphi) but this needs to be in Keil C for a 8051.
I need to get it working quickly. Who will help?
this begs a question: can you control a motion if it is perpetual?
Erik
but the question remain: what the frack is the OP talking about?! by the way, Per and Vince - do you guys speak Russian ("Maskirovka" is Russian for deception, if I remember correctly!)
Sorry, but no, alas. Too much literature I would have been able to read in original.
But both Maskirovka and Iron Felix should be part of the general education most people have received. Knowing our history helps us predict the future. The cold war is not long past, and this economic crisis will not help the world stability. With unemployment comes unrest.
New facts to learn, every day. I thought the greatest challenge was to control t, P and D. But then again, excavating takes time.
Ever notice how, in the embedded world, you have to keep track of huge quantities of 'things' in order to make the end product fit the customer's needs? And if you are doing both the electronics & the embedded code, it is a lot more than just a 'huge quantity' of things.
Then, you get a customer who expects perfection, and anything less will jeopardize zillions of dollars. They demand 'huge quantities' times 10, or times 100 or times 1000 or a large multiple of whatever the 'standard' embedded widget's Worry Number is.
You don't want to be "that guy" who screwed it up. So making sure your tools are certified to good standards ("Keil" of course --- "You should never post to any internet forum before you have confirmed that you are "on-topic"" ), your practices are solid, your everything is done "the best it can be done" (always at the cost of doing it, so 'best' being scaled by a Cost Coefficient).
Yes, from the top Project Managers down to the [highly skilled] solderer, every single person on that cooperative Excalibur project--aka XM982--did NOT want to be "That Guy."
Then you go to McDonald's, and order: 1) a Big Mac, 2) small fries, and 3) a small Coke. And you get 1) a fish-like sandwich--with extra cheese, 2) an Apple Pie, and 3) a Coke... no napkins, no straw, and no condiments.
Then, these McD employees tire of it and become Keil forum contributors in their pursuit to program one of my house-hold items: just to rub in the fact that they also messed up my cable-box as I open my McD bag to find that they got 2 of 3 items wrong.
Ever notice that?
I've got the dollars, they want the change, and government is efficiently capable of converting dollars into mere change.
Those are the same people (aka 'contributors') who wanted 'change' and are going to get just that. It is simply because, they don't study ANYTHING other than what the 'teacher' told them to study: they get their "useful" information from MTV, et al. (...or blindly using code from the internet so they can 'pass').
Knowing our [and I mean human beings in general] history, it vital to prevent this government (a major world player in world economics, so you guys over the pond need it just as much as the US idiot does) from worsening... only to cause unrest in the petite bourgeoisie and the current proletariat (ref Russian history) vis-a'-vis McDonald's employee *** Code Monkey.
The world in-stability will breed the dogs of war, and thus will just breed a war of corpses ( www.getty.edu/.../war_corpses_zm.html -- Rated G... artwork by John Heartfield: who should be part of the general education most people [should] have received ).
So learn your trade. Learn it well. And learn your history.
The answer to the question: can you control a motion if it is perpetual? is this:
History is perpetually in motion. It is controllable. But it takes skills, and stunningly, a knowledge of it.
'Maskirovka' is everywhere ( www.airpower.maxwell.af.mil/.../smith.html ) and it is up to us to 1) recognize it, 2) control it the best we can, and 3) prevent it from going unstable.
"Change" is a bunch of 'Maskirovka' that I will pay for.
--Cpt. Vince Foster 2nd Cannon Place Fort Marcy Park, VA
P.S. FPGAs are better than processors at 'computing stuff' and 'controlling things' in the various terminal maneuvers.
"You don't want to be "that guy" who screwed it up."
When the first swedish JAS 39 Griffin decided to dig earth after problems with the software in the fly-by-wire controlling a basically unstable airframe, I did spend quite a lot of time thinking about the people who was activelly working with the software. Luckilly, no one got hurt but accidents costs huge amounts of money and even if no fingers are pointed, I would assume a number of people did spend a couple of nights wondering if they where responsible, and what the result would be of the review.
" href= "http://www.youtube.com/watch?v=MdePhzIwOmw">www.youtube.com/watch
BUT at least the ejector seat worked!
The interesting thing is that the plane crashed among the spectators of a large festival. There might have been 20 000 people really close by the location where the plane crashed. But there was this tiny little area (Stockholm has a lot of water, which affects peoples abilities to select where to stand) where no spectator was standing, so I think the worst injury was someone getting light burns since a military jet engine even without afterburner requires huge safety zones.
The fascinating thing is that SAAB managed to get both prototype crashes on TV. The first crash, they had invited a national news team after having a large number of uneventful tests. This crash was shown in the intro for all BBC news casts (together with the Challenger disaster) for at least six months.
The big problem then was the journalists. It did not help to show them statistics of prototype crashes with earlier generations of Swedish planes, or statistics about crashing american, russian, french, israeli planes or displaying budgets taking into plane losses into account. All the journalists could see was two-out-of-two failures and that was enough for professors to publically explain that it was technically impossible for the plane to fly because of the instability of the airframe (a specially designed feature since it also translates into very quick reactions - you don't have to fight to make the plane turn).
The problem is that all projects - civilian or military - gets more and more in an economical sqeeze. If something goes wrong, you don't need to be the guy who did wrong. Somehow, the reporters likes to sell a story. And that story require a company or a person to have done something wrong. And a company (or its owners) do not like to be blamed for having done something wrong, in which case they have to distribute the blame to an individual or a group. And a group don't like to be collectively blamed so in the end, the shareholders or the journalists will come hunting individuals.
In an earlier life, I did work with care alarm systems for elderly, where someone who have fallen or had an heart attack should be able to press a button to get help. Several times every year, the newspapers had articles about the alarms failing or being disconnected, resulting in someone dying without having received help. Everytime, there was huge amounts of speculation about the cause and if it should turn out to be "our" products. Maybe I was lucky, or maybe our products was better than the competitors, but in the end, it was always a competitor product, or maybe the people who installed the equipment decided to save money by turning off daily test alarms in which case an unplugged phone cable didn't get caught by the alarm receiver software.
I'm currently workign with solutions for infrastructure. Product failures means pitch black road crossings, water tower leaks not being reported, public transportation signs not showing the time of the next train/bus, people getting stuck in elevators not getting any response when pressing the alarm button, delayed police responses to robbed money transports, ...
Somehow, it is hard to work in the embedded world without being involved in critical systems where people may come to harm or get very irritated in case of problems. A software joke says that all programs contains at least one code line too much and at least one bug. So in the end, you will be able to reduce your program to a single line, and that line will be buggy.
One thing I have been wondering a bit about, is the huge number of people who post to this forum about "how do I implement xxx", but how few there are who posts: "how can I make sure that my code actually works?"
Maybe a very large number of posters are students or hobbyists. But a lot of posters do give me the impression of being professionals (as in payed), working on a commercial product. Do they already have a very good knowledge of QA (can anyone ever know too much?) or do they ask QA-related questions somewhere else? Or do they just do what they think is "enough", and leave the rest to the customers?
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
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).
Per, Thanks for a long and catchy post. I have a few comments: The JAS 39 was not the first unstable airframe - the F-16 was the first operational fighter jet to have that property. Do you remember the F-20 peoject? see here: en.wikipedia.org/.../F-20_Tigershark
It also fell victim to multiple crashes and economic pressures that let to the cancellation of the entire program, 1.2 billion US dollars to late... By the way, I did not see an ejection in the first video or did it escape my eye?
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.
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.
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.