How many of your jobs are like this?


I was tasked to create a modern upgrade to the central experiment controller for each of 8 multi-million $$$ research laboratories. They are still using a DOS based system, except for the first proto that we've deployed.

I get to make the real-time hardware and software, and the programmer who worked with the department since the PDP-11 days and developed the old system gets to make the PC GUI, which has to be backward compatible with old-style text input files.

The new system has to account for all the lab variations, including one with a dual experiment necessitating various multiplexers and complications. And add oodles of new capabilities.

There are no written specs. I poll the scientists to pin down all the requirements. In the process I suggest to them what we could do, which they want all of and more. I write down most of the requirements and set to work. Every once in a while they request new capabilities or decide to use higher resolution sensors that the programmer promised we would never need, so my design had better incorporate enough headroom to be able to adapt without re-spin.

So over the course of several years, while also being the department's Laser Technologist, completing numerous other electronics projects, and getting sidetracked by upper management to become an electrical safety guy and UL inspect 2000 pieces of equipment--which I finally threatened to leave over and they backed down after I got done with about 20:

I created what I think is an innovative approach to eliminate the old practice of custom tweaking the real-time code to implement each variant of the experiment and enable the deployment of a flexible yet standard solution for all the labs. I chose to implement a dynamically reconfigurable state machine which outputs sequenced digital waveforms and pulse generator parameters. All glitch-free, and able to be reconfigured on the fly while running. Oh, and the state machine execution engine meets the real-time deadline of the 4.17us period between 240kHz shaft encoder ticks.

Now that it's done, they don't want to deal with any complexity, don't want to read any documentation or learn any new concepts (such as a concept that is central to elementary control theory--the state machine--and these are all Ph.D. engineers), and the programmer is having fits because he doesn't like the state machine control model and is 2nd guessing all of my design decisions because the metaphor doesn't fit a canonical "programming loop" construct.

Other than that, it's a great job and they provide me with lots of cool equipment and for the most part let me explore many neat new ideas, so I'm not complaining. It's just funny (so funny I was up at 3:30am last night worrying about it all).

Let me guess, this is par for the course?

 Click to see the full signature
Reply to
Loading thread data ...

That is the first big mistake.

Second mistake is not getting the scientists to agree the written requirements specification. They should understand that, once written, agreed and signed off by them, any changes are going to add cost.

Part of your written specification should be complete interface descriptions, including resolution ranges and accuracy of translation.

Not on my watch. It was in my very early days then I learnt the better way to organise a project. These days I get to sleep easy at night.

I can recommend reading "Better Embedded System Software" by Philip Koopman. See

formatting link
for details about the book.

Paul E. Bennett...............
 Click to see the full signature
Reply to
Paul E. Bennett

Let me guess ... you've never dealt with users before. Users almost never like it when existing processes change and NEVER want to read documentation.

Moreover, if I understood correctly, you've removed some of the ability of the users to hack custom applications. That doesn't sit well with NIH (not invented here) control freaks. It doesn't matter how clever or easy to use your extension method is, they want the control that comes from do-it-yourself.


I used to write industrial QA/QC software that had to have quite complex control available to supervisory users while presenting only doorknob level controls to ordinary users and requiring in-application security to prevent ordinary users from, either inadvertently or deliberately, screwing up or breaking anything. [Some of the industries served literally used piece-work day laborers who would foul up things deliberately to take a break or to bypass QC so as to get paid more.] At the same time the functions were getting more sophisticated and supervisory control was getting more complex, the ordinary user controls had to be secured and idiot proofed, then imbecile proofed, and finally moron proofed ... and meanwhile the applications had to get smarter and smarter about realizing and sounding alarms when the software or hardware was being messed with.


Reply to
George Neuner

I'm not sure that in the research environment, there is any other choice. I mean, I can write some specs for them, such as electrical specs. But for behavior, there was no way 5 years ago for us to foresee what experiments would need to be done today. They would simply complain to the manager that I wasn't serving their needs if I asked them to specify anything so precisely. They want me to figure out the precise details of what they want, for them.

They don't care about added cost, since the cost of paying me is already committed. They only care that when they want it to do something different from what they said they wanted it to do last time, that it happens as soon as possible.

Well the way it actually works is that I ask them what their current system does, what they think needs improvement, etc. Then I have to become familiar with their work. I have to get in their experiment and understand it, get familiar with the direction of their work, then begin to make best guesses at what they probably will want to do in the future.

My experience in this research environment so far is that every time I am told to just implement the immediate need, that it is a big mistake and it would have been better to spend a little more time to think through a more forward reaching solution.

Every time I think ahead, they wind up actually doing what I thought they would do.

There is no organizing here. Most of the time, I am it, the only electronics person in a department of mechanical engineers. This time I have to work closely with the programmer, who originally wanted the simplest thing possible, which would have turned out useless the moment it was committed to HW.

Thanks for the reference and the input.

 Click to see the full signature
Reply to

Heh heh. And then they will also complain if there isn't detailed enough documentation when they get messed up to the point where they finally decide to read it.

I'm more used to giving my users hardware. Software or a system with complex user-configurable behavior is a new thing.

Perhaps you misunderstand a little. The department is quite rightfully concerned that when their programmer, who has specialized knowledge of engine research and the ability to integrate that into his programming, knowledge that is going to be very hard to replace, that they will be in a quandry.

You see it is the programmer, not the scientists, who customizes each lab control system to the details of the lab. This is done at the code level, not just configuration parameters.

I have been reading a lot of the technical notes and papers here:

formatting link

and some other literature about reconfigurable state machines, and have become convinced that it is better to implement flexible system behavior by changing configuration information, which instructs an execution engine to exhibit the behavior, rather than hard coding the behavior.

The scientists are not going to be able to customize embedded real time code to do what they want once the programmer retires.

The system that I have designed is capable of exhibiting all of the behavior of all the separately customized control systems, and then much much more that the current systems cannot do, without any hard coding of the behavior. So I have achieved the goal of vastly more capability with standardized code for all labs.

Interesting experience. Thanks for your response.

 Click to see the full signature
Reply to

My favorite is when you're trying to nail down a spec and grilling the client on what he wants to happen in .

Typically, they'll respond with "I don't care..." (i.e.,

*you* figure it out).

While taking notes on these exchanges, I have learned how to mumble these words (or equivalent) sotto voce:

"When , short out the power supply, spin down the drives without retracting the heads, erase all of memory..."

(doing so with a straight face -- "professionally" -- takes *lots* of practice! :> )

The sign of sheer terror on the client's face makes it well worth the effort! *And*, they are usually *very* careful not to utter the 'I don't care' phrase, again!

(there *are* some rewards for being in this business!)

Reply to
Don Y

That's very funny! I'll keep that in mind.

 Click to see the full signature
Reply to

Then I write them out and send it to them.

Me, in a board room, nice dark suit and tie (wife picked that out). Giving a presentation with lots of big ticket cost factors in there, machine amortizations and all that fun stuff. At the end all the other suits seemed content with what was presented, the mood became a bit more loose, everyone had their thoughts on lunch, the smells of which were already wafting in. Then one guy asked "What's your confidence level in those numbers?" ... "Ahm, plus minus 3db" ... silence, you could almost here a pin drop ... then thundering laughter.

During lunch the CEO asked me never to pull one like that again, almost gave him a cardiac event he said.

Regards, Joerg
 Click to see the full signature
Reply to

**Don't** do it unless you have a really good feel for your customer/client!

With *good* (i.e., "rational") clients, this can lead into a sober discussion along the lines of:

"Well, Bob, how would you like me to go about figuring out what *should* be done in these situations? I can take the easy way out (for me) -- like 'reset the device and start over from scratch'. That will keep your development costs down -- anything you can't foresee *here*, *now* won't affect the final product's design or its cost. OTOH, your users might not like the way the device behaves in those cases. Especially if this means they lose 'something' (time, data, test results, product, etc.).

If, OTOOH, you just want me to 'do whatever it takes' to get the *right* solution, then your costs (and timetable) become unbounded -- but, we can be reasonably assured that the end user will be happy with the result.

Sure, I can *call* you each time I encounter one of these, 'what-do-you-want-to-do-if' scenarios. But, will you be able to give me a quick, well thought-out reply? Who'll bear the cost of documenting that? Do I have to update my time/cost estimates each time this happens? Who will bear the cost of *that*?? Or, do I have to put whatever I was working on *aside* and try to *find* something to keep me busy (progressing towards a final product) while you think about the 'what-if'?

Lastly, do you think either of us are really going to be

*happy* working like that?

So, why don't you guys give this a bit more thought and flesh out those areas that you know *I* haven't yet discovered (since you guys *should* know more about this than me!) and we can look at the project again, later, if it still makes sense (you may discover that there is some huge GOTCHA that just makes this totally impractical).

*Or*, you can hire me on an open-ended, time & materials basis to research your project, the needs of the targeted users, etc. and *write* a specification for you. You can then take this and either ask *me* to bid on it. Or, pass it around as an RFQ and get someone *else* to bid on it..."

I.e., this puts the comment into a rational perspective. "I'm not trying to be 'cute'... or 'a smart-ass'. This is what the consequences of unknowns in your specification will be. How would you like to resolve them so we can CONTRACTUALLY agree how to proceed?"

Reply to
Don Y

What the OP is doing does not fit any formal definitions of "project".

Of course, any fixed price contracts are out of the question in this kind of environment, but when compensated by the hour, why not.

In the OP's case, the most important thing is to resist the temptation of doing "quick hacks" in order to satisfy some current needs.

You really have to think ahead and for example provide some primitive hooks that could be usable at future request and tell the original requestor how to use these hooks e.g. in a configuration file (text) to achieve the original requirement.

Reply to

> _____________________
> Mr.CRC
 Click to see the full signature
Reply to
Bruce Varley

I no longer am willing to take on T&M projects. They tend to "drag on". Client figures he's paying you so why should

*you* care how long it takes... (?)

("Um, maybe because I think there are other, more interesting, things to spend my time on??")

To be clear: I did *not* intend for that to happen! It was just an unfortunate case of me making a wise crack -- that ended up reflecting reality! (bad coincidence)

Ha! At least you were able to spot the problem (in the load) instead of trying to sort out where the design/fab problem lies!

I envy you the fact that you don't have to *make* it in order to *enjoy* it! :<

OTOH, I probably have a wider range of flavoring choices at my disposal ;-) I wonder if I can come up with a butter pecan gelato that's as flavorful as my butter pecan ice cream? (I suspect not as I think much of the "flavor" comes from the insane amount of *fat* -- a *stick* of butter in a quart of ice cream X-, )

Today will be a good day for it, too -- uncomfortably hot!

Reply to
Don Y

Huh? It's usually the only way I work. Most of my work is on the cutting edge so it is next to impossible to do any fixed bid projects. Before I'd take on any fixed bid the spec would need to be water-tight and complete. Which is not possible in most of my cases.

Well, they are paying you, right?

There's always more interesting projects or new ones but to me it's a matter of loyalty to see the client through to the final goal, even if they had a serious schedule slip.

The problem was the power supply. They needed a better one. I never understood why some switchers have min load requirements. I've designed a lot of switchers and none ever had that. You can run them completely open.

Our swamp cooler did a wonderful job the last couple of weeks. The only thing I don't understand is that while it keeps the temps down it has a hard time cooling a house back down if you were gone and it got to 85F. I mean, there's 65F coming out at over 3000cfm, meaning it'll (theoretically) swap out all the air in the house in 10 minutes. So one would think the 85F air will be replaced in a jiffy. But that doesn't really happen.

Regards, Joerg
 Click to see the full signature
Reply to

[recall you are working primarily on (analog?) hardware. More and more I am moving into pure software designs -- the hardware is becoming trivialized (exceptions being power conversion -- which I don't mess with :> ) so that part of the design is easy to tackle]

Exactly! People don't want to think about what they want -- they want to *see* something... and then decide that that is NOT what they want! (OK, let's try something different)

"User stuff" tends to just drag on and on because people seem to lack "imagination". Not "creativity" but, rather, the ability to look at a description of how something *might* work, close their eyes (figuratively) and *imagine* what it would be like to use that hypothetical device... what sorts of problems they would likely encounter, how they would work themselves into a corner -- and, how they would get back *out* of it, again -- etc.

[I was discussing one such design with a friend and told her exactly what frame of mind she needed to put herself in to adequately reflect the needs of the typical user of said device. A few days later, she contacted me "all excited". She would never have been able to make the connection with the product, otherwise!]

It's easy to get the technology under control. Where things tend to get hung up is "humanizing" (userizing?) that technology.

Now, I try to spend most of my time working on "proof of concept" and/or "prototype" designs. Identifying the key issues that will ultimately drive the product and seeing how (if?) they work. A lot of that happens "between the ears" instead of on paper or in foil ("What would likely be the consequence of this type of implementation? Where would it fall down? What unexpected surprises might come along? Would they be benevolent or malevolent? etc.")

[e.g., this is the force behind the questions like "wire", etc.]

Or, *if* said device existed and had these particular capabilities, what *other* potential applications/markets could it address that aren't being addressed (adequately) today?

So, when I actually have to *make* something, it's only "a handful". I don't have to "qualify" components for manufacturing (though I have to be able to identify important issues that will ultimately affect their selection), I don't have to worry about packaging (though I have to have some idea as to the final volume/weight/etc. that an implementation is likely to require), regulatory agency approvals (except to identify issues that would *necessitate* them), etc.

It's infinitely more "fun" as most of the dreariness has been taken out of the process. It's sort of like the OSS guys who want to add some zany new feature to a product: do "enough" of it to prove it *can* work, then leave the details to others to work out. Except, *I* have to take care of those details that

*make* it work (unlike the OSS guys :< ).

That doesn't mean I want it to last forever! I like moving to *different* application domains. You can spend *years* tweaking a single product... and its revisions... and its successors. You end up being an expert on *that* product and little else.

(could you imagine digging ditches for a living? "for as long as your boss wanted ditches dug"? even at your current pay scale?? :< )

As an *employee*, this was no big deal. If the M.E.'s couldn't get the mechanism working properly, you were still getting paid. Or, if the I.E. didn't have the casing design complete. It was your boss' job to figure out how to get suitable work out of you given the bottleneck.

But, on my own, I can't afford to be idled for a month, six weeks, etc. if someone has to turn the crank again on some custom silicon. And, what if *that* turn goes bad? Or, something else creeps in? There's no billable hours there. And, I can't take on another contract, in good faith, knowing that 6 weeks hence I will have to put *that* on hold.

It's also very hard to put down a piece of software and come back to it months later and know where you were headed. It's not like a schematic where you can see *everything* on (dozens?) of pages. People forget that you haven't done anything on "their project" in "all these weeks" and wonder why you're "so late"...

I think it depends on the design of the switcher logic. I.e., some turn the switching transistor on at each clock edge -- and then decide when to turn it *off* based on "current conditions". So, the minimum on time of the switching transistor determines how much energy you've put into the output stage hoping for a load...

Swamp coolers are BFM. Every time I think I understand how to "use" one (control it), I get screwed. One thing that I *have* learned is that once the indoor temperature starts creeping up, there's nothing you can do to stop it.

I suspect there must be a science behind "optimal control", there. E.g., how much to vent to the outside for a given current operating rate, outdoor wind speed/direction, etc. It would be fun to motorize the window and let a machine "learn" how to do this...

I think I am going to explore the possibility of replacing the fan (squirrel cage) in the cooler with something that works effectively in both directions -- turn the cooler into an exhaust fan for use at night/early morning.

Reply to
Don Y

The minute you deal with hi-rel, aerospace, medical, EMC and all that, hardware is immediately "untrivialized" :-)


Yep. I'd get myself the coolest Caterpillar there is, with sound-proof cabin, six-speaker stereo, the whole nine yards :-)

But it ain't going to happen. Hardware design is a very diverse job. Megawatt power designs one day, microvolt receiver design the next.

I always have several assignments concurrently. Some urgent, some not so much. It's like with doctors, usually you only need them when sick and the workload you present is unpredictable to them unless you have some sort of chronic illness.

Working for just one client is risky. What if they go belly-up?

That's why I keep harping on documentation. Some SW guys think that a few comments in the code is sufficient documentation. It ain't. For anything I ever designed there is a module spec, whether the client wanted it or not. I can't work any other way, or won't. This allows me to hop back into the same saddle 10 years late.

I consider that an unsafe design :-)

That's the weird thing. You can stop it from creeping up or at least slow its rise, but you can baerly make it get down again. In the evenings we can, but even then very slowly.

I've tried experimenting with that. No luck. There comes a point where the moisture in the house starts to rise when you close the windows too much. But beyond that the cooling efficiency seems to be about the same.

Exhaust would turn it into a whole house fan. I wouldn't want that around here because it'll suck in all the pollen and dust. My wife would have a fit.

Regards, Joerg
 Click to see the full signature
Reply to

Yeah, but I've been steadily headed *away* from that sort of market. And, most of my designs are approaching 100% digital (with the exception of power). Even the analog subsystems are getting to be "prepackaged".

I'd enjoy playing with the cat' for a few days. Then would quickly grow bored with the job. Too repetitive. What do you

*learn* each day (besides "if it looks like a buried pipeline, it probably *is* a buried pipeline!!)

I'm not talking about hitching your cart to a single client. But, the costs of moving between projects aren't small. And,

*you* bear those costs (how are you going to conscientiously bill your clients for your inefficiencies at juggling two or more concurrently?)

A (typical) doctor can move between patients in 15 minute intervals. There isn't much *immediate* follow through -- "Go try this and let me know what happens". Imagine a surgeon leaving a surgery partially completed because some bit of kit wasn't available at the time... wandering into the *next* surgery, starting on that one, then wandering back to the first one when the necessary items became available. :-/

You're preaching to the choir, here!

But there is a big difference between the effort required to prepare a good software specification -- let alone the formal

*documentation* -- and a similar one for a piece of hardware. E.g., I have 100 page documents just describing the *accounting* (money) subsystem in gaming devices -- without even mentioning how the "game" works!

By contrast, when documenting hardware, I get a big headstart just by preserving copies of all the datasheets used in the design (you typically don't have similar documents for the software "components" used in a software design -- unless you want to consider the language manual and processor instruction set as "components"... pretty crude).

The software industry is lacking a *good* tool to make software documentation easier, more complete and more *accurate*. There's no "pictorial shorthand" like schematics, timing diagrams, 'scope traces, etc. Too much relies on words. Words take a long time (relatively speaking) to parse. And, require a lot of effort to verify.

And, since software is so (relatively) easy to change, it becomes a cat-and-mouse game where the documentation is always struggling to keep up with the latest (ahem) "enhancements".

Dunno. I'm just recalling the few SMPS controllers I've used in the past...

Yes. Logically, you should be able to cool a house *quicker* with a cooler (assuming suitable RH) than with an ACbrrr. The ACbrrr is "indirect acting" -- it tries to suck up heat in the evaporator and pump it heat out of the house through the condenser. This should be more inefficient than "replacing the air in the house"! :>

Closing too much leads to rapid increases in interior RH. OTOH, if the windows are *open* to much and don't present enough "back pressure" to keep wind from pushing HOT AIR back into the house...

I think the real solution requires monitoring wind speed and direction, plus outdoor temperature and RH. *Then*, being able to control individual "window exhausts" to vent enough air while admitting the least amount from the outdoors. I have been adding instrumentation to do exactly this. What remains to be done is an unobtrusive mechanism for the venting...

We're debating a large skylight in the kitchen. I look at that as an opportunity to vent (warm, ceiling) air from a large area, quickly. (but, we haven't yet decided for or against)


The cooler already does that. Except it *blows* the air into the house instead of sucking it in through the windows. (this is one of the big complaints we have re: the cooler -- allergies)

A better solution might be a ground-sourced heat pump. Or, even just the air intake!

Reply to
Don Y


So can I. Seriously, it is very normal for me to be talking about a chip design at 8:15, then an EMC problem on an aircraft at 8:30, and some power electronics for a third client at 9:00. Interruptions because of an urgent issue are also not a problem. But you must be diligent in starting and stopping several time registers.

Time recording is done on the fly and computerized. Each client has a separate file and the strtict rules is "file closed and put away when moving to another client's project". That takes, oh, about 5sec. I gladly eat those 5secs each time :-)

If I need to work on something that requires high focus I switch the phone to answering machine and ignore email arrival alerts during that time frame.

My dentist does exactly this and he ain't no spring chicken, >70 now.

The only tools you really need are a word processor plus MS-Paint (seriously, MS-Paint). Write it while coding and never let the coding get ahead of the document. Just like I'd easily get carried away in SPICE and could end up with half the circuit done but white sheet in the document. So I brace myself. It was hard in the first 2-3 years of my career but not anymore.

Ok, I often use my CAD to create flow charts, firmware documentation and such. But only because it's paid for, it's there, and I am so much used to it.

It ain't any easier in HW. Write first, then code or design. Not the other way around. Sometimes that is a time-saver all by itself. While writing I sometimes lean back, squint, and darn, it won't work that way.

There used to be a lot of junk out there in the 80's and 90's. From folks who likely didn't quite understand what they were doing. Seriously, when I asked one engineer what would happen if we ever dipped below min load he said "Well, it'll usually just squeal but if you get much under 10% load it might blow its guts out". I refused to use that thing :-)

That is what I really don't understand (yet). For example, today the cooler has run for 5h or so at half power, outlet temp 68F. Yet the house sits solidly at 75F even though the cooler must have exchanged the air about 15 times over. Now 75F is much more comfy than the 82F it would be without but still it's a puzzler.

I can imagine that a large opening in the ceiling could be the ticket. But we don't have a skylight. If we were in your shoes the debate would have taken 10sec, max :-)

Big difference: The aspen pads catch lots of dirt, the water flushes that into the basin and there it sinks to the bottom. After dust or pollen storms it's good to clean that out. Easy to do, just open a panel, shut off valve, pull a piece of pipe, gurrrrrgle ... shhhhlurrrp .... wipe bottom with Kleenex, put panel back in, open valve again ... done. That's why I made a discharge pipe for it. The whole process takes maybe five minutes. I actually find the air quality to be better than without the cooler running but that may just be my personal preference.

Air intake? That how we often run it, blow in fresh air but without the water cooling.

Regards, Joerg
 Click to see the full signature
Reply to

Very sensible response.

I have to be a little careful what I say here. My boss might read this ;).

I've worked in high-volume environments, where everything was planned out, and all the ISO procedures were followed to the letter. Any changes to specs were followed by mountains of paperwork... and I was happy. I knew where I was, and what the score was.

I've also worked in low-volume, high-value, experimental environments, where V1 turns into V6 at high cost, all procedures fall by the wayside, and mistakes get made... and it's all wanted yesterday, and tempers get frayed. (This describes my current job.)

But, as Bruce says, it's a culture thing. Not too long ago, I quit after a *spactecular* barney with my boss, who I'd often previously defended (and still do) as being entitled to being a bit stressed (and hence loopy) from time to time. I withdrew my resignation the following day, on the basis that my injured pride was not a good reason to a) lose my living and b) kill the current (high-investment) project, for which I'm key.

Since then, we've got on fine ;).

It might help that I'm mid-fifties, and fairly thick-skinned nowadays (didn't use to be - ho no...).

I'm hanging in there on the basis that the project is worth it, the folks who report to me are worth it, my boss is fallible but human, and I might be able to make a difference to how it all turns out longterm.

Also, I enjoy it ;).

Steve (currently working all hours to complete hardware and firmware on a high-value system which *must* ship next week... we *might* make it...)

Reply to
Steve at fivetrees

Bingo. It is a scientific research lab, and I'm a regular employee, not a contractor. Both aspects make for a mushy continually morphing situation. I actually prefer it to the strict legally binding world that I get impressions about here from folks who do contract work.

Holy bingo! Thanks for that. It's funny, because the programmer I interact with usually has exactly the opposite philosophy. Just quickly cobble something together that works. And he expects me to work that way. It drives me nuts. I think it's a bias problem. In his world, you change change some lines of code. In my world, you have to re-spin a board. A much greater time and cost penalty for not designing carefully in the first place. Consequently I design my software like I design hardware. I spend vastly more time thinking, analyzing, and planning than coding.

The historical situation is interesting. When I started in 1999, we had an electronics technologist with a 2 yr. degree and no analysis skills. He built mostly cookbook circuitry, and much of it to the specification of the programmer. Funny huh? You can imagine the results. And they were still in the 7400 series TTL mindset at that time as well.

The result was that many of the electronics were designed like the "bad circuits" sections of "The Art of Electronics." Glitches and signal integrity problems were the norm. The consequence of not thinking ahead, nor having a solid engineering level analytical background.

More importantly, they were limited in what they could do by the crude technology being employed. PLDs and microcontrollers were respectively not even within their awareness, or considered too difficult to work with.

I discarded all the drawers of TTL chips and built the labs a general purpose CPLD "Magic Box" that has a matrix of BNC connectors buffered to the IOs of the CPLD. That replaced the discrete ANDs and ORs they were using to glue the lab experiment together, and solved the signal integrity problems of the old device.

Very quickly there appeared need for more sophisticated circuits than were possible before using the CPLD. In a particularly interesting case, a gear was machined wrong on one engine vs. another in two test stands. In order to make the two different encoders interface to the same engine controller, the choice was to re-work the gear at the expense of possibly two weeks (a very complicated customized optically accessible engine, not easy to gain access to the gear--plus fixturing it in the machine shop and doing the cutting), or design a moderately complicated logic circuit to "fix" the encoder signal from the faulty gear.

The logic took about 2 days.

This pattern has repeated for many years now.

Yes, you even use my exact terminology. It seems you have some understanding of the research world. I design two aspects into my systems: 1. resource headroom with factors of 4-10x being common if possible; 2. hooks at the HW and SW levels to expand IO, etc., far beyond what was originally requested, or to add capabilities that are only at the very horizon of potential need. More often than not, those hooks are eventually used, and avoid the need for a complete HW re-design.

 Click to see the full signature
Reply to

Hi Steve,

[Why are you read> I've worked in high-volume environments, where everything was planned

There's a happy middle ground. Without the insane, overly structured development approach where i's are dotted (in triplicate, etc.) and the "fly by the seat of the pants" where no one knows what they *want* -- until they see what they *don't* want!

What I object to is the latter being so commonplace, needlessly. Granted, if you're working on the bleeding edge, you often don't *know* if something is really *possible* -- let alone how, exactly, to approach it.

But, too often, it's *not* bleeding edge and the lack of direction, specification, procedure, etc. is just a result of laziness or lack of discipline in the parties involved. People fearful to

*say* what they want for fear it might not fly well in the market. Or, people not willing to say what they can deliver for fear it might not come to fruition, etc.

So, things wander, aimlessly, so no one -- and EVERYONE -- can ever be held accountable.

This, IMO, is the difference between folks who are "working" at engineering and folks who *are* engineering. If you woke up tomorrow and someone told you you could no longer do these things (e.g., you had a stroke), would you miss them? How much?

[think about it]
Reply to
Don Y

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.