Being too dependent on one "guru"

I think you're missing the point, and if your bosses only have the "guru" angle, then they're missing it, too.

Especially in your kind of shop, Labview or something of its kind is by far the best kind of software system to use -- it's very powerful at a high level, easy to program (after a more or less substantial learning curve), quite reliable, and easy for a scientist with little software training to understand, so he can verify that your program does what he intends before it breaks stuff (if he's interested).

Building small research systems in C and assembly is a big loser. I speak from the point of view of one who has done both -- I spent most of my career doing just that, because the Labview-type programs weren't available or advanced enough to do the job.

In your case, where you appear to have performance needs that Labview can't meet, but a lab environment that needs flexibility, the multiple-level approach is ideal. You need the high-level flexibility, which the research scientists themselves could implement if they had the interest, but which a tech or entry-level software person could handle (under expert supervision, of course). This can make possible experiments that the researchers would not otherwise consider, because the lower level design and programming is so costly and time-consuming.

Where you need performance, the microcontroller/DSP approach is much easier to build at the lowest possible level, which will usually be stable enough to be usable with little or no change between experiments. Set up a low-level command protocol, and let Labview do the high-level stuff, then send the low-level commands via the protocol to the low-level controllers. The simpler the low-level stuff, the better and more reliable the system will be.

I do understand custom micontrollers and such (I've built several myself), and I agree with them that you're dead wrong, even foolish, to want to build research systems at such a low level. In fact, you can build even farther-reaching systems using the mixed high/low approach, simply because it's so much cheaper and less time-consuming. You can't get higher low-level performance with the low-level only approach than with the mixed approach, but you can fail to build a system at all with the low-level approach, simply because it's too complex to do.

The squeamishness about "guru" culture is altogether justified, but is far less important than the vastly improved ability to do research.

I think you would be wrong, and I hope you would lose your case.

Even

This makes me wonder whether there's even a need for the truly low-level stuff. I've never done DOS, but my impression is that it works like a PLC, which would be much easier to program, and can give submillisecond performance for the stuff Labview can't handle. If you truly need microsecond performance, then maybe...

Dead wrong. What they need is a system they can change on short notice. The less low-level stuff they have, the lower their risk is. They could use two software people, yes. You would do better by them (and by yourself) to bite the bullet and learn to use Labview. That way, in the rather unlikely event that you really need the truly low-level stuff, you can do it. They don't have to pay you to do something that's probably mostly unnecessary, and if you should get hit by a bus, less of the system depends upon mysterious stuff that they'll need an expensive consultant to sort out.

Sorry, all my sympathies go to your bosses. They hired you for one job, and you're apparently trying to change it into something they probably don't need and is inappropriate. If they truly need low-level stuff, they should have (or develop) an embedded expert. But this will be so costly to keep in-house that they must have a real compelling need.

Low-level embedded systems have their place, but it's not in the small research lab.

It is unwise in the extreme to build a simple, low-complexity custom one-off board if a commercial alternative exists. It is simply foolish to try to build a complex board if a commercial alternative exists, especially if you're not already expert at building such boards. Your bosses are dead right.

And, for a research lab, gross overkill in a commercial $5k DSP/microcontroller/fpga board is still dirt cheap compared to building even a simple custom microcontroller board. Just as $15K for a reusable, flexible Labview system is dirt cheap compared to building even one C/assembly language system.

John Perry

Without a fulltime EE ? Unfortunate. The lab borders to the useless, IMO.

Labview suggests programming is complicated and comes up with an incredibly complicated graphical interface. As experienced programmer I once spent a month trying to these put wires through walls, a job I could have solved in an hour or so on a PC with a decent language. But it was Labview on a MAC. Dump it in favour for Labwindows.

Any scientist, and also those of the world's best should be able to program in a decent language, otherwise they are useless at least when they leave research.

We once had an Innovative Integration DSP. The lacking source of the libraries made us more work than having had built the board ourselves in the longer run.

Rene

My background was similar to yours, just separated by a couple of decades. I designed analytical instrumentation for a Research University back when it was all done with logic and not processors.. It was incredibly challenging and incredibly fun. Back then, we were just on the threshold of the build vs buy argument. Now there is a very rich set of tools and solutions from which to chose. In the time since then and now, I went off and founded a small product development company that employs people similar to myself. I can probably provide comments on both sides of the question.

Even though the technology ande times have changed, the fundamental theme remains the same. Buy as high up the commercial ladder as you can. Only build what you can not get otherwise. And when you build, create it using a highly disciplined approach that will allow someone else to re-create the results of your work. It is counter-productive for any organization for a single individual to be too deeply invested in any one product/process/program.. The bus/meteor/terrorist arguement is a valid one.

And, I would add, it is counter-productive for the individual as well. While your time is lockup up twiddling bits for something your could have purchased, a project that actually requires your unique skills may appear and go by the wayside. There is an out of print book with a great title that says it well: "The Existential Pleasures of Engineering". This stuff is fun. No doubt about it. But we rarely get to do it for purely our own satisfaction. And we should not let the fun we get out of it interfere with the objectives of the people who are funding us (our customers). The voyage of self discovery is a wonderful thing, but it is expensive.

My career goal has always been to be as prolific as possible: To create as many things as my time, interests and abilities allowed. To do that, you can't waste time in re-invention. To do that, you have to learn when and how to delegate. (The more projects you are "guru'd" into, the fewer you will ultimately get to do). To do that, you have to get it right the first time. Tracy Kidder in "Soul of a New Machine" summed this up best by equating project development to "Pinball". If you are successfull, the only thing you win is an invitation to play the next game; to do the next project. And if you lose, the game is over. You don't get to do the next one. You are only successful in rising to new challenges as long as everything you have done in the past works. Otherwise you will spend a good chuck your time fixing your mistakes. And again, the stuff you maybe were really born to do will pass on by without you.

Hundreds of thousands of man hours have gone into the creation of lots of really neat stuff. (Real time O/S's, TCP/IP stacks, etc). While it might be fun to build your own, I would offer that unless you are paying for this on your own dime, it is unethical to expect a customer to pay for such a development when cost effective alternatives exist. This is not an easy determination to make. There are always factors that obscure the choice. But if you base your decision on what is in the best interests of the customer, you will choose correctly most of the time. While all of this might make what you do very rewarding personally, it will not make you wealthy. I have yet to find proof to the contrary.

Blakely

Hello Chris,

No EEs? Maybe you guys don't do much in electronics in which case that would be ok, to some extent. Or you have a really good tech who understands electronics well enough to get by ;-)

Your boss has a very valid concern here. He or she has to think that way.

With all due respect I would side with your boss here. In a research lab and also in a production environment you want to see the least amount of custom or proprietary gear possible. Ideally everything should be COTS, just like LabView is. Try to understand you bosses. They would have a lot of egg in the face if something happened down the line with proprietary stuff that could have been done COTS. They would be asked "How could you let that happen?".

And then one day you'd find out that the chosen DSP has been obsoleted.

I was in your boss' position for many years and I would never have thought that way. If you don't have to do something from scratch, then don't. We tried to keep everything COTS and only resorted to custom builds when there either was no other way or cost was very outrageous.

If you want to get into uC and DSP designs you'd have to leave a lab career and move towards product design. Just be aware that this is nowadays a cut-throat cost cutting environment. The most elegant solution is of no interest to anybody. The cheapest solution is what wins you points there. A very, very different environment from where you are now. It's the daily bread here: You turn a couple of BAT54 or a BSS123 around and around to see if they couldn't be replaced by something that costs one or two cents less. Your opamp du jour will become the LM324 because everything else is too expensive. If the offset is too high you'll have to clamp it. Actually, most of the designs will likely be transistor level anyway for cost reasons.

I don't want to discourage you but be prepared before you take that plunge. It's cold out there.

Regards, Joerg

Me too, except even more decades. That was a time when there was no buy option, and even after say 1975 there was no reliable buy option at a reasonable price. We don't need to mess with NAND gates etc. today, when we can buy a few PAL/GAL chips and synthesize any specialized logic needed. I went from hardware to software by the late '70s, and for some time could depend almost entirely on the hardware I had designed in the early '70s. However by adhering to standards I could ensure that my software designs could last much longer, even up to the present.

Just as by 1975 I wouldn't think of designing a hardware CPU any more, today I would not consider designing a CPU board in most circumstances. I would consider designing a simple preprocessing i/o peripheral.

I have been pushing them to allow me to build a custom DSP/FPGA board

You are both right, to a degree.

The test should always be to justify the next level of complexity.

viz If Labview and a relay will work, then use them.

If you can prove some 'coal face' HW is needed to augment labview, then that should be used.

Only if you can prove that Std board, [and that _includes_ vendors Silicon EVAL pcbs ] will not be suitable, should you embark on green fields development. In that case, often a conditioning PCB is all that will be needed.

I'd look very closely at the better FPGA development PCBs: ones with USB,Ethernet and VGA support - you'll need USB/ethernet to get decent speed into Labview, and VGA allows some local-display, for setup, trace, and fault finding. Then, explore the Soft-Cpu support around, and you'll have something more flexible than your custom F2812+FPGA pcb, without the PCB development cycle.

There are also just emerging ARM chips, with FLASH, ADC/Ethernet/USB/CAN, so an Eval PCB for one of those would also be usefull. Ask ST about a EvalPCB for their STW22000 - tho that might be a tad new to deploy in a lab...

-jg