UKnowWhat

That's what I thought when I look at the graphical representation of LabView. I was asking myself how do I implement RF formulas into this mess. With LabWindows, I know automatically the process would be much "simpler" and much intuitive for us than LabViews, considering your comments of 10 years of LV comparing to us NONE. LabView in my case will be transformed to a stuffed pig and it's not due to Labiew, but due to my inability to making the right choice at the first place. I've already pictured myself breaking my computer if using LabView. Thank you, you guys for answering my questions, especially inputs from MA - I would definitely take a look at test stand. Lanny

The right kind of man asks the right kind of questions :thumbup: 1) DAQ & GPIB mainly NI. Vector network analyzer, power meter and sweep synthesizers are mainly HP. Source meters & switch box mainly Keithly. 2) Post processing imported from network analyzer or DAQ to further processed in PC, typical parameters in data sheet such as IP3, noise figure etc 3) The most common task we encounter is device characterization and it covers broad spectrum of ICs. The test operators have minimum knowledge of everything, except push the button, or click the mouse to be exact. 4) We have few software engineers in house and are strongly C & C++ oriented. I have 20 plus years in C programming and assembly language, in embedded system, test and measurement lately. Since I am also the hardware guy, if the load is too much to for me to handle, subcontract is also another option. My concern is this: ease in programming with relative low learning curve and the ability to adapt to 3rd party developer, especially in DSP areas and RF which have intensive mathlab applications. Consider our background, it's a natural tendency to lean toward LabWindows but Josep Travis's ATE implementation in Labview just piques my curiosity.

1) In general, if all things are equal, your first statement is true. I just ignore that part because anyone has ever seriously code something in their life for a living would come to that conclusion, one way or another. I just don't bother to argue about something outside of my issues when I ask for people's opinion on something else. 2) You read too much and assume too much in one single line. My statement , quoted by you, applies equally to all products but your assumption (your preconception and bias?) carries it into your own world. Labview could elegantly works and LabWindows could be a stuff pig or vice versa. It all depends on how it fits into our needs and the cost associates with the product ie. learning curve, ability to incorporate with other 3rd party codes etc. With ZERO understanding in our organization, our strength, weakness and our needs, you have already bloat some strong opinions based on your assumption. Of course, with a strong background in C & C++ programming language and environment, we are definitely bias toward applying our strength in such environment, especially those with math intensive codes. However, we also have a short term turn around cycle for quite a few products, which I wonder whether Labview could fit nicely or not. With my understanding of our organization, I have to make a compromise somewhere to have a single platform, so yes, we do use hammer for everything, provided 80+% of our job is involved with nail. The rest of those things can be flat a bit but that's the penalty we have to accept.

Thank you for so succinctly explaining the differences. You just put into words what I have felt about the 2 products. I have intuitively thought that LabWindows is the way to go because of the flexibility in adding third party codes. And yes, you also right about throwing enough time and money into a problem will make either solution would work. The only difference is one elegantly works and the other is like a stuffed pig. Thanks again.

beside the obvious that one is a graphical language and other is text based. We need to build a test scheme to test RF components for military and space industry, in addition to mixed-signals ICs. What would be the ideal platform to do the job described above? Why would NI build 2 products when one can do the job so it must be something in it to differentiate the 2 products, right? TIA.