Agilent BenchVue released

[HKJ]

I think it is a good idea with this kind of software, but it will only be really useful for a limited amount of people/companies. That is, of course, completely acceptable for a Agilent software package (Who would expect big measurement companies to support their competitors).
Personally I have many brands of equipment and do not see any reason to install this software. I have many brands of equipment and my computer is not only used for equipment control. To fix this I have made my own software that works without any VISA drivers (i.e. I do not always need new drivers when updating windows), this software is limited to support exactly what I need.

[Rigby]

I think it is a good idea with this kind of software, but it will only be really useful for a limited amount of people/companies. That is, of course, completely acceptable for a Agilent software package (Who would expect big measurement companies to support their competitors).
Personally I have many brands of equipment and do not see any reason to install this software. I have many brands of equipment and my computer is not only used for equipment control. To fix this I have made my own software that works without any VISA drivers (i.e. I do not always need new drivers when updating windows), this software is limited to support exactly what I need.

I'm not going to ask you to show me the source for this, but if you could give me a bit of detail about how you architected this software and what language(s) you used, I would greatly appreciate it.

[HKJ]

I'm not going to ask you to show me the source for this, but if you could give me a bit of detail about how you architected this software and what language(s) you used, I would greatly appreciate it.

I program in Java and due to lack of time I have only implemented equipment with serial ports (including virtual) and lan connections.
I have lots of DMM, both bench and handheld, electronic loads, power supplies, relays. Basically I add equipment when I need it.
The program uses a script and generates CSV files with the result.
Each piece of equipment can generate one or more columns of data. The electronic loads generate V, A, W, Ah, Wh and one or more time coulmns. And I can control the settings from the script, for power supplies I can ask them to slowly increase or decrease voltage while logging.

You can see the result on my website: http://lygte-info.dk/ many of the measurements are made with this software. The battery test is the most complex of them (All test is done with one setup and one script and takes a couple of days).

[free_electron]

Why are Agilent releasing software that is intentionally locked to only Agilent gear? 

you got proof of that ? if not ... eat your words ! This is just plain false !

why does lecroy's scope explorer only work with lecroy scopes ? why does tektronix wavestar only work with their Arbitrary generators ? Why does your diesel engine only run on diesel and not water ? why does the batteyr of a nokia phone not fit in an iphone ?
why why why ?

The fact of the matter is that Agilent created a focus group constructed from people working in labs having to collect and control instruments. I was one of those people.
We each had a one on one interview and then Agilent distilled a set of questions. The second round we were all interacting with each other answering the question set and bouncing idea's off one another. there were Labwindows user, Labview user Vee users, C coders , VB coders and plenty of other platform users

The outcome of this experiment was the following : It is too annoying to have to write a program to do simple things like record data over time or grab screenshots and data dumps. Every time you want to do something simple you have to start coding . Why don;t you make a base tool that can control instruments from the desktop. and do simple things like logging over time and upload download files/ screendumps.

6 months passed and we got the Alpha. The alpha could only control a 34401 and a e3631. The user interface was annoying , too many buttons to click too many menus , not logical. this was reworked , polished, streamlined. another six months later alpha 2 passed critiscism . so beta was released.
Bugfixes, instrument disconnects etc were al solved. another 6 months later V1.0 is released.

don't go looking for conspiracies. Agilent created a focus group because they were got questions from users. so they anted to find out what was 'missing' in the gap between full blown code riting ala Labwindows Labview C or Vb and instruments on a bench.

This is the outcome.

[Rigby]

I program in Java and due to lack of time I have only implemented equipment with serial ports (including virtual) and lan connections.
I have lots of DMM, both bench and handheld, electronic loads, power supplies, relays. Basically I add equipment when I need it.
The program uses a script and generates CSV files with the result.
Each piece of equipment can generate one or more columns of data. The electronic loads generate V, A, W, Ah, Wh and one or more time coulmns. And I can control the settings from the script, for power supplies I can ask them to slowly increase or decrease voltage while logging.

You can see the result on my website: http://lygte-info.dk/ many of the measurements are made with this software. The battery test is the most complex of them (All test is done with one setup and one script and takes a couple of days).

+1 for Java
+1 for minimum app required to get the needed results.

[HKJ]

+1 for Java

Jave is mostly ok to program in, but its support for hardware is not very good.

+1 for minimum app required to get the needed results.

The app it not exactly minimum, it took me about 5 minutes to move a test from a Fluke based setup to a Agilent based setup on another computer, I only had to change the instrument names and the ports, everything else stayed the same.
Forcing all instruments to fit the same template has advantages, but, of course, also disadvantage. I can extend the program to overcome the disadvantage, if I need it.

[Rigby]

Why are Agilent releasing software that is intentionally locked to only Agilent gear? 

you got proof of that ? if not ... eat your words ! This is just plain false !

How is it false?  This software doesn't support hardware from other vendors.  It is intentional because the ability to connect to non-Agilent hardware isn't present.  Didn't work last night when I tried, anyway.

why does lecroy's scope explorer only work with lecroy scopes ? why does tektronix wavestar only work with their Arbitrary generators ? Why does your diesel engine only run on diesel and not water ? why does the batteyr of a nokia phone not fit in an iphone ?
why why why ?

for the same reason Agilent's software does the same.  Everyone is afraid that if they standardize, people will choose competitors.  It's a coward move that is considered industry practice, unfortunately.  Proprietary connectors/software/protocols/form factors suck, and everyone knows it.

It used to be that when you bought a bit of test gear, you got the schematics, service manual, and calibration manual.  Now, you get a bit of paper with a URL on it, and if you're lucky, you get a CD with marketing documentation and a very basic user's guide.

The fact of the matter is that Agilent created a focus group constructed from people working in labs having to collect and control instruments. I was one of those people.
We each had a one on one interview and then Agilent distilled a set of questions. The second round we were all interacting with each other answering the question set and bouncing idea's off one another. there were Labwindows user, Labview user Vee users, C coders , VB coders and plenty of other platform users

The outcome of this experiment was the following : It is too annoying to have to write a program to do simple things like record data over time or grab screenshots and data dumps. Every time you want to do something simple you have to start coding . Why don;t you make a base tool that can control instruments from the desktop. and do simple things like logging over time and upload download files/ screendumps.

6 months passed and we got the Alpha. The alpha could only control a 34401 and a e3631. The user interface was annoying , too many buttons to click too many menus , not logical. this was reworked , polished, streamlined. another six months later alpha 2 passed critiscism . so beta was released.
Bugfixes, instrument disconnects etc were al solved. another 6 months later V1.0 is released.

don't go looking for conspiracies. Agilent created a focus group because they were got questions from users. so they anted to find out what was 'missing' in the gap between full blown code riting ala Labwindows Labview C or Vb and instruments on a bench.

This is the outcome.

I'm not looking for conspiracies, and I'm surprised and impressed that Agilent actually spoke to folks about their needs.  That isn't common in my industry.  What I'm not impressed by is that no one thought (or that collectively, you didn't think) that maybe since you're working on standardized physical interfaces (GP-IB, RS-232, Ethernet, USB), with a standardized data protocol (VISA) that it might be, oh, i don't know, wise, possible, or realistic to be able to talk to any gear that implements that protocol over those physical interfaces.  It just doesn't seem like a stretch to me, and as a software developer, I can tell you it was absolutely a design decision to do prevent that, because the natural way to do it on .NET is to use objects that represent the ideas your application works with.

.NET is an object oriented platform.  If you want to write software for an object oriented platform, you take advantage of the facilities that object orientation gives you.  In this case, polymorphism and inheritance at least.  This means that (even if you're supporting only one vendor) that you create something like a "multimeter" class and you create one subclass for each actual model you want to support.  If you do that, and it's really hard not to if you know object orientation at all, supporting any "multimeter" is as easy as writing a subclass for it.  Call it a plug-in if you like.  Same goes for oscilloscopes, power supplies, electronic loads, all of it.  Either Agilent has done that all wrong, or they've blocked the ability to load external modules.

Agilent doesn't have to support those modules.  Agilent doesn't have to say that their app supports those modules.  Just make it an option for folks like me who know how to do it.  Make the license for BenchVue prevent me from selling modules.  Just let me do it, augh.

And it's not Agilent I'm mad at.  It's just that this was an opportunity to talk about how stupid we're all getting in terms of proprietary lock-in.  We all think it's no problem, yet we all know that proprietary physical connectors suck hard.  This is the exact same thing.

[EEVblog]

In the real world it is almost always a homogenous mix of vendors, ages, and capabilities.  I won't say "always" because I've not set foot in every lab.

If you are buying gear for an automated test rack for example then it's not uncommon to buy all the same gear. And something like availability of this program to tie them together might make the choice easier.

[EEVblog]

I'm not looking for conspiracies, and I'm surprised and impressed that Agilent actually spoke to folks about their needs.  That isn't common in my industry.  What I'm not impressed by is that no one thought (or that collectively, you didn't think) that maybe since you're working on standardized physical interfaces (GP-IB, RS-232, Ethernet, USB), with a standardized data protocol (VISA) that it might be, oh, i don't know, wise, possible, or realistic to be able to talk to any gear that implements that protocol over those physical interfaces.  It just doesn't seem like a stretch to me, and as a software developer, I can tell you it was absolutely a design decision to do prevent that

Yes, because it would be quite a risk for a company to allow the program to support other vendors tools, because THEY would end up with the support calls when it doesn't work.

[Rigby]

Yes, because it would be quite a risk for a company to allow the program to support other vendors tools, because THEY would end up with the support calls when it doesn't work.

The software community worked that out long ago - don't offer technical support for other vendor's stuff.  Application support for plugins and technical support for plugins don't have to go hand in hand.

edit: one can also define their plugin interfaces so that support information is mandatory in the plugin, that use of the plugin requires that the support information be shown, and that the framework (BenchVue, in this scenario) disable any plugin that is not operating properly.  So you can mandate that a single plugin cannot consume too much RAM or CPU, for example, or that plugin faults automatically perform some action, such as pausing all communication, or whatever the user wishes, really.

Pretty much anything is possible in software, if you know what you are gonna need before you start architecting, or really work to create an extensible framework.

[EEVblog]

The software community worked that out long ago - don't offer technical support for other vendor's stuff.

Doesn't stop them calling.
It's simply a smart pre-emptive move to not support other brands. Ans as I said, they can't even support all their own products yet, let alone competitors.
Really, what is in it for Agilent to support other vendors products? Nothing, that's what, just headaches and extra work. This is free software, and is designed to support the sale of use of Agilent products, and there is nothing wrong with that, every other manufacturer will do the same.
If you don't like it, fine, move on, or go write your own custom job as needed, like it's always been done in the industry. Or if you sense an opportunity here to go write your own universal tool as I suggested, there must be a huge market for that requirement, you'll be rich.

[Rigby]

they don't have to "support" anything.  just allow end users to talk to non-Agilent stuff.  make it hard so that dumbshits who don't know how tech support works can't load non-Agilent stuff.

step one for Agilent support would be to instruct the caller to disable all non-Agilent plugins, anyway.  If that fixes the issue, then politely explain that non-Agilent plugins are not supported and wish them well.

If one knows enough to set it up and use it, then that person would be someone that knows what is supported by Agilent and what is not.

[Rigby]

the more I talk about this the more I am resolved to create the mythical open test framework myself.  if done properly it will be awesome.

[quantumvolt]

Imo many good arguments for openness and generality in several posts.

Whatever Agilent's goal was/is, it lacks imo a broader perspective. If Agilent does not grab the chance to become the standard in this kinf of software, somebody else will (sooner or later). History shows imo that programs that are meant to patch together stuff, are best made with an application (task)-oriented structure. Boxes change - supplying and 'counting' electrons does not.

Anyway - Agilent (the company) prescribes emulation in order to have old customer test programs believe that the 34461A actually is a 34401A (video on YT). So the question is: If this software is any good - who will be the first to write/make emulators that mimics one common Agilent instrument of each supported class?

[EEVblog]

the more I talk about this the more I am resolved to create the mythical open test framework myself.  if done properly it will be awesome.

Then don't waste your development time complaining here about how some company is a pack of unfair bastards for not giving you exactly what you wanted for free. Go create it yourself.

[Dr. Frank]

I only have HP DMMs, so I can't check that on my own:

This BenchVue, and its predecessor only support SCPI instruments, obviously.

SCPI on the other hand is a universal instrument command language, and competitors of HP claim, that their DMMs may emulate HP instruments.

Could anybody, who owns a Keithley or Fluke or else of that kind, if it's possible to make BenchVue think that an HP instrument is connected?

Frank

[Rigby]

Then don't waste your development time complaining here about how some company is a pack of unfair bastards for not giving you exactly what you wanted for free. Go create it yourself.

my kid is using my computer. 

it's not free, though, is it, Dave?  You have to own Agilent equipment to make use of it.  that is a cost, and not an insignificant one.  "Buy any supported Agilent  test gear, and get communication software FREE!"  That's not free.

edit: and it isn't Agilent that is a pack of unfair bastards (I love Aussie slang), it is us as a community that fails to recognize lock-in like this as a software-only proprietary connector.  This is a proprietary connector, in software.  I can't touch the connector, but that doesn't make the connector any less real.

[EEVblog]

my kid is using my computer. 

A pad and pencil works a treat for sketching out ideas and planning. Hurry.

[Rigby]

I'm getting nowhere convincing anyone, so I'll end my participation in this thread, here. 

We, as a community, are getting (or have always been) pretty poor at recognizing proprietary stuff.  When it is physical, it is easy to spot. Dave just did a rant video on proprietary connectors.  When they are in software, no one seems to care.  That's what I don't get.

Anyway, if anyone feels that I attacked them personally, I apologize, as that was not my intention at any point.  I'm just frustrated.  What is the point of open, standardized connectors and protocols, one of which HP invented, if you're not going to honor them, choosing instead to artificially restrict and create a virtual proprietary connector?  I can't even begin to fathom how this is justifiable.

free_electron, I hope I didn't ruin your thread.  You didn't deserve (no one deserves) to have their thread overrun with my stink.  Agilent clearly spent a good amount of time and effort on this, and that is to be commended.

Hurry.

Just tell me to go away, if that's what you mean. I'm not asking for a ban, but if you tell me to chill out, I will.  Just say that, if that's what you mean.

[ShiftRegister]

Windows only.... Sucks!

Damn! That sucks indeed!

[free_electron]

How is it false?  This software doesn't support hardware from other vendors.  It is intentional because the ability to connect to non-Agilent hardware isn't present.  Didn't work last night when I tried, anyway.

Just because it is not in there doesn't mean it is intentional.  It is only intentional if there is somewhere a written clause in the design spec that says 'thou shalt not support non-agilent machines'. it works fine with a rigol dmm configured to emulate a 34401. if they deliberately wanted to cripple it they could have probed to find the real name ( yes there is an instruction to do that ) and shut down. They don't.

Proprietary connectors/software/protocols/form factors suck, and everyone knows it.

fine. let's all agree toonly make instruments using 10 watt 10k resistors , 2x4's and nails. anything beyond that is 'proprietary'. definately no SMd or BGA as joe schmoe can't solder that at home with his flamethrower. Let's stop making asics and construct everything with 2n2222 transistors. IC's are the work of the devil.

you get a CD with marketing documentation and a very basic user's guide.

have you taken the time to read the users and programming manuals from agilent for their new instruments? They are hundreds of pages. very detailed. Schematics don't make sense anymore. Half the machine run's on ASIC's you can't get your hands on and trying to fix the 10 layer boards full of BGA's is BER : Beyond Economical repair. Agilent , Keithley and Tektronix have ZERO income from hobbyists anyway. Hobbyists and small companies buy used stuff from ebay. Hobbyists fix broken stuff found in the bin. Not their target audience.

I agree that, as a hobbyist, this is a bit of a problem and we will have to restrict ourselves to older machines.

I'm surprised and impressed that Agilent actually spoke to folks about their needs.  That isn't common in my industry.

Really ? i'm am flabbergasted ... speechless.

In the 9 years i have been in SV not a single year has passed where i was not in at least 3 such panels. I'm doing one next week on spectrum Analyzers. Last november i sat in one for MDO (not Mixed Signal Oscilloscopes. MDO is Mixed Domain Scopes). I've been in panels for different products and companies. These are organised by Market research companies , on demand from their customer. You interact either directly with the customer , or in 'guided discussion' using a moderator. Typical sessions are 1 to 3 hours. Everything is recorded and filmed through one-way glass. You sign papers upfront not to discuss what you saw or commented on BEFORE it is released to market. They pay you for your time. Typically a preloaded VISA card a rato of 100$ an hour.

  Either Agilent has done that all wrong, or they've blocked the ability to load external modules.

Oh, it is object oriented. But they don't provide an API so you could attach your own code. This thing is closed source. sorry.
and who knows, they may eventually release an API so it can be extended. Like i said this is Version 1.0... and the ARE listening to feedback ! Get on the Agilent forums. voice your gripes there. you may get lucky !

[Rigby]

Get on the Agilent forums. voice your gripes there. you may get lucky !

Based on the general response I'm getting here, I'm not even going to try.  I'll make my own framework!  With hookers!  And Blackjack!

[free_electron]

Windows only.... Sucks!

Damn! That sucks indeed!

dear shiftregister, please keep clocking yourself until you contain all zero's. thank you.

[free_electron]

Get on the Agilent forums. voice your gripes there. you may get lucky !

Based on the general response I'm getting here, I'm not even going to try.  I'll make my own framework!  With hookers!  And Blackjack!

you forgot booze. Actually forget the blackjack and the h...

I re-read the thread and i think i know why you have been applying the flamethrower to the thread.

you expect something from this tool that it is not. It was NEVER designed for an audience that wants to control complex test setups, extend them with their own drivers , and write code.
As i explained what the focus group was about : this is a tool for people that want to do a few , simple things, repetitively , without writing code.

an example : some physiscist is tasked with testing a new compound for a rechargeable battery. he has a power supply and a few multimeters,
 set the power supply to a fixed voltage with current limit. when we start charging the output voltage is limited becasue the supply operates in CC. once we hit CV mode there is still ongoing charging until current becomes zero.
We want to plot actual Vout, Iout and temperature ( multimeter with thermocouple attached)

this is an ideal candidate for this Program. start program , configure power supply. set a recorder with time interval 5 seconds and read back actual output voltage and current from the supply (an E3641 has a built in 5 1/2 digit meter ). also , record every 5 seconds the battery temperature. spit it into matlab

Physiscist walks away. checks from his office using his tablet or local computer from time to time progress without having to drag his theoretical ass to the bad lab where manual labour is done. when he ees the thing is stable he stops the recorders opens matlab and he can have a ball racking his brains on statistics.

THAT is the target audience.

Now, if you want a universal tool. that has been tried over and over and invariably ended in a massive disaster.
National instruments tried this back in the DOS days. Labwindows Basic and C under DOs. it could talk GPIB ( there was only gpib or serial back then as LXI and USb hadn't been invented.
they gave some example 'drivers' for some machines. pretty soon they discovered there were so many different machines from different vendors, each with their own instruction set they really would need to buy one of each to write the drivers... So they tapped into the 'open' community. Using bulletin boards users could post their own drivers to share freely.
Most of these drivers were written by nitwits that had no clue , were far from complete or simply plain wrong.

HP had the VEE framework under HPUX. same story there... They supported the stuff they had but were not going to buy a rohde and schwarz spectrum analyser to provide you with a driver...

rohde actually made the effort to make drivers for both NI and VEE but gave up because of support required and ever changing revisions and incompatibilites between revisions.

this went on for a few years until a taskforce was created : SCPI   STANDARD COMMANDs PROGRAMMABLE INSTRUMENTS.
everybode (tek, hp, rs, fluke,keithley,ni , cec and many others were in on it.)
Let's once and for all define a command set , sort of XML style in the sense it is extendable , and structure how to parse it. this will make building drivers easier.

if i send :MEAS VOLT DC to any multimeter it will switch to volts dc mode ( if it can do that of course)
so SCPI was drafted and ratified. all was well. making drivers was easier... until we started needing new command not originally in the spec. and then certain instrument makers descended the wrong branch... commands that clearly belonged under the trigger branch where thrown in a different branch (SCPI defines root branches) because the designers of those machines felt they belonged better there according to their intuition.
So there you go. compatibility is now lost.

the same crap is still ongoing today. Nationla labwindows and labview 'drivers' are only made for national stuff. all others are skeletons or crap thrown together by nitwits. the ones that do work right are not interoperable becasue the instruments are not interoperable as they violate the SCPI standard.  poof. there goes the nice balloon.

So , you are welcome to make your own super duper environment that supports all. I'll be the first one looking at it.

But you better include a driver for my half million dollar scope that is complete and bug free or i will be the first one lighting the flamethrower the moment you start a topic that your version 1.0 is released. 'Wo is you' when i find out it doesn't support all the machines i have. (and i got some really archaic ones you can't even get your hands on). and it better run on windows is i can't be arsed touch those weird environments like Loonix or that overpriced CrapOS.

so it is lost upfront. you are looking to a massive investment developing this and a massive financial investment buying every single piece of testequipment ever made to complete your program.
Trusting your 'users' to supply working and complete drivers ... has been tried many times. doesn't work. Users are nitwits and complainers.

[AlfBaz]

the same crap is still ongoing today. Nationla labwindows and labview 'drivers' are only made for national stuff.

It's no where near that bad. There are drivers submitted by third parties (nitwits?) that may or may not be certified by national. There is a huge collection of non-NI drivers on their driver website

all others are skeletons or crap thrown together by nitwits

That's a bit harsh. Non-certified drivers are a good starting point to create or modify your own

the ones that do work right are not interoperable becasue the instruments are not interoperable as they violate the SCPI standard.  poof. there goes the nice balloon.

I must have SCPI's purpose all wrong then. It's just as difficult for the standard to cater for every instrument as it is for benchvue or any other "framework". In Labview if a device requires some "non-standard" scpi commands you simply double click the icon carrying out the function and in the "schematic" for that you just change the ASCII command to what ever the instrument requires. If instead of MEAS DCV it needs DCV just go in there and change it. It's that simple

So , you are welcome to make your own super duper environment that supports all. I'll be the first one looking at it.

But you better include a driver for my half million dollar scope that is complete and bug free or i will be the first one lighting the flamethrower the moment you start a topic that your version 1.0 is released. 'Wo is you' when i find out it doesn't support all the machines i have. (and i got some really archaic ones you can't even get your hands on). and it better run on windows is i can't be arsed touch those weird environments like Loonix or that overpriced CrapOS.

so it is lost upfront. you are looking to a massive investment developing this and a massive financial investment buying every single piece of testequipment ever made to complete your program.
Trusting your 'users' to supply working and complete drivers ... has been tried many times. doesn't work. Users are nitwits and complainers.

Like it or not, your words carry a fair bit of weight and I won't for a second presume to tell you how to think but you should consider that discouraging experimentation or simply just trying things for oneself isn't conducive to advancement in anything.

If the frame work is open and it doesn't support you million dollar voltage viewer, then a decently designed tool will just require you to look into your manual and write some simple text commands to do what you want