Both LabVIEW and VEE are good tools - and function side-by-side in many places, especially where lots of H-P/Agilent gear is used. I worked at such a place, myself!
DPC
-----Original Message----- From: Les Hammer [mailto:Les.Hammer@CompleteTest.com] Sent: Monday, January 30, 2006 9:04 AM To: VRF Subject: RE: [vrf] Vanishing VEE support??
> What can we as users do to encourage these makers of fine hardware to continue to support VEE?
Call them up and say "You are a maker of fine hardware. I would be more encouraged to use your product if you had a VEE driver."
> All users of VEE are not heavy duty programmers, like many LabView > users, we are scientists and engineers ...
I'm trying to parse that sentence. Are you saying that many LabVIEW users are heavy duty programmers, while VEE users are not? Or: both VEE and LabVIEW users are scientists and engineers?
While I sympathize with you, in some ways the managers of VEE brought this upon themselves. Look back at the early days of VEE. There was an academic version that didn't even have the instrument support. Universities were suppose to use this for general purpose programming. That version was soon dropped. Some members of HP/Agilent management didn't see the need for instrument drivers because Direct IO was available as a work-around. Meanwhile, NI made sure that there was an instrument driver available for just about everything. Sometimes the driver wasn't very good. (I looked at the Plug&Play C-code for a simple DAC. The Init code from Agilent just about had more instructions than the entire code from NI. And those were important instructions.) But NI had drivers. Also, NI made sure that they set up deals with many universities - introducing LabVIEW to most of the engineering students. Those students soon became engineers making purchasing decisions. They purchased what they knew - LabVIEW.
Face it. HP/Agilent marketing fell flat on its face on this. They assumed that since HP/Agilent was the market leader in High Performance instruments that they would be the market leader in graphical language. They were wrong. Now they are paying the price.
Les Hammer
--- You are currently subscribed to vrf as: dean.coombs@lmco.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
> What can we as users do to encourage these makers of fine hardware to continue to support VEE?
Call them up and say "You are a maker of fine hardware. I would be more encouraged to use your product if you had a VEE driver."
> All users of VEE are not heavy duty programmers, like many LabView users, we are scientists and engineers ...
I'm trying to parse that sentence. Are you saying that many LabVIEW users are heavy duty programmers, while VEE users are not? Or: both VEE and LabVIEW users are scientists and engineers?
While I sympathize with you, in some ways the managers of VEE brought this upon themselves. Look back at the early days of VEE. There was an academic version that didn't even have the instrument support. Universities were suppose to use this for general purpose programming. That version was soon dropped. Some members of HP/Agilent management didn't see the need for instrument drivers because Direct IO was available as a work-around. Meanwhile, NI made sure that there was an instrument driver available for just about everything. Sometimes the driver wasn't very good. (I looked at the Plug&Play C-code for a simple DAC. The Init code from Agilent just about had more instructions than the entire code from NI. And those were important instructions.) But NI had drivers. Also, NI made sure that they set up deals with many universities - introducing LabVIEW to most of the engineering students. Those students soon became engineers making purchasing decisions. They purchased what they knew - LabVIEW.
Face it. HP/Agilent marketing fell flat on its face on this. They assumed that since HP/Agilent was the market leader in High Performance instruments that they would be the market leader in graphical language. They were wrong. Now they are paying the price.
Les Hammer
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
I noticed that Measurement Computing is scaling back its VEE support (See below). Some VEE'ers say that lack of VEE drivers is no big deal as you can use VEE to call functions from their Universal Library but I don't see how to do that (advice welcome!, perhaps a future episode of retro VEE-TV?)
The bigger issue to me is that VEE (the best darn Graphical programming language) is being squeezed out, while everyone offers LabView drivers. First Data Translation stopped offering their DT-VPI to add direct control of their hardware to VEE, now Measurement Computing (and I am sure many others have fallen in between). Data Translation now offers their own (Measurement Foundary) but still offers LabView Drivers but no VEE support.
What can we as users do to encourage these makers of fine hardware to continue to support VEE?
All users of VEE are not heavy duty programmers, like many LabView users, we are scientists and engineers just trying to get a job done. The last thing in the world I want to do is have to figure out how to write drivers (but I will if someone produces some readable instructions if you have never used .h files or DLL'S it is pretty confusing!).
"The reason for this process is due to the decreasing support requests received for Agilent VEE. Since MCC has not received many support calls for VEE, we have elected not to invest any R&D dollars in maintaining the product through out software engineering group. However, we would like to offer you the best support we can, so the updating of this product has moved over to our Application Engineering team."
-- Jim McClymer, PhD Graduate Coordinator Department of Physics and Astronomy University of Maine
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Keep in mind that NI owns Measurement Computing, too.
Martin Rowe Senior Technical Editor Test & Measurement World 781-734-8419 m.rowe@tmworld.com http://www.tmworld.com
> -----Original Message----- > From: Jim McClymer [mailto:McClymer@maine.edu] > Sent: Monday, January 30, 2006 10:18 AM > To: VRF > Subject: [vrf] Vanishing VEE support?? > > > I noticed that Measurement Computing is scaling back its VEE support > (See below). Some VEE'ers say that lack of VEE drivers is > no big deal > as you can use VEE to call functions from their Universal > Library but I don't see how to do that (advice welcome!, > perhaps a future episode of retro VEE-TV?) > > > The bigger issue to me is that VEE (the best darn Graphical > programming > language) is being squeezed out, while everyone offers > LabView drivers. First Data Translation stopped offering > their DT-VPI to add direct control of their hardware to VEE, > now Measurement Computing (and I am sure many others have > fallen in between). Data Translation now offers their own > (Measurement Foundary) but still offers LabView Drivers but > no VEE support. > > What can we as users do to encourage these makers of fine > hardware to continue to support VEE? > > All users of VEE are not heavy duty programmers, like many > LabView users, we are scientists and engineers just trying to > get a job done. > The last thing in the world I want to do is have to figure > out how to write drivers (but I will if someone produces > some readable instructions if you have never used .h files or > DLL'S it is pretty confusing!). > > > From Measurement Computing > ftp://ftp.measurementcomputing.com/UL%2 ... stallation %20instructions%20for%20VEE%207%20and%20higher%20and%20patch/
"The reason for this process is due to the decreasing support requests received for Agilent VEE. Since MCC has not received many support calls for VEE, we have elected not to invest any R&D dollars in maintaining the product through out software engineering group. However, we would like to offer you the best support we can, so the updating of this product has moved over to our Application Engineering team."
-- Jim McClymer, PhD Graduate Coordinator Department of Physics and Astronomy University of Maine
--- You are currently subscribed to vrf as: mrowe@reedbusiness.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
>>All users of VEE are not heavy duty programmers, like many LabView users, >> >> >we are scientists and engineers ... > >I'm trying to parse that sentence. >Are you saying that many LabVIEW users are heavy duty programmers, while VEE >users are not? >Or: both VEE and LabVIEW users are scientists and engineers? > >
I was struggling to make myself understood in few words- then ran off to class. I was saying that many Labview and VEE programmers are users who know just enough to get the job done, they don't program every day and the thought of creating drivers, etc can be formidable.
When I first learned about graphical programming, at a free NI LabView event, I was hooked. They had a very cheap student edition which I bought. I was about to buy a site license when I heard about VEE and met some HP guys who would come to the University. They had such a great deal it blew NI away, I think I got a 40 copy site license and a GPIB board for about $500! I have since updated the license a few times (Vee one lab and now VEE 7.0 (and I am behind again!).
While I was teaching students VEE, one of our big research institutes hired some labView guys so LabView became the standard programming environment at the lab, rendering some of what I do less relevant..
I still think VEE offers good deals to universities but not many know about it as Agilent doesn't seem to go to the conferences academic scientists and engineers go to nor does it advertise in our journals. Agilent should take a lesson from LEGO (latest WIRED) and create an Academic Users Group to learn how to infiltrate universities better so as to create future VEE demand.
Jim
>While I sympathize with you, in some ways the managers of VEE brought this >upon themselves. >Look back at the early days of VEE. There was an academic version that >didn't even have the instrument support. Universities were suppose to use >this for general purpose programming. That version was soon dropped. >Some members of HP/Agilent management didn't see the need for instrument >drivers because Direct IO was available as a work-around. >Meanwhile, NI made sure that there was an instrument driver available for >just about everything. Sometimes the driver wasn't very good. (I looked at >the Plug&Play C-code for a simple DAC. The Init code from Agilent just >about had more instructions than the entire code from NI. And those were >important instructions.) But NI had drivers. >Also, NI made sure that they set up deals with many universities - >introducing LabVIEW to most of the engineering students. Those students >soon became engineers making purchasing decisions. They purchased what they >knew - LabVIEW. > >Face it. HP/Agilent marketing fell flat on its face on this. They assumed >that since HP/Agilent was the market leader in High Performance instruments >that they would be the market leader in graphical language. They were >wrong. Now they are paying the price. > >Les Hammer > > > > >
-- Jim McClymer, PhD Graduate Coordinator Department of Physics and Astronomy University of Maine
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
I love Vee and I would class myself as a heavy duty programmer as I have periods in my life when I do nothing but code. Also most of my code goes "out of house" to customers. In this respect, vee is my main language.
To be honest, the lack of instrument drivers for vee doesn't really bother me much. DAQ manufacturers now often have activeX libraries to allow communication, programming via direct I/O for GPIB, etc is no real problem. In my experience most vee drivers produced by 3rd party companies in support of their hardware was pretty rubbish anyway (some notable exceptions).
As a graphical user language, vee has one ironic but major drawback. Its features for producing Graphical User Interfaces are poor. The basic vee graphical user interface objects have not changed since I hopped on board at version 5 (probably before that). This is unacceptable in my opinion.
Before anyone steps in, I've just finished evaluating vee 7.5! I was really hoping that the "new" ability to embed window's controls onto vee interface panels would finally provide the functionality required but alas it appears not to be the case. Unfortunately, the vee "panels" do not function as true windows forms. Individual controls can be added to a user panel but there is no way to set up things like tabbing between individual controls meaning that user interfaces designed in this way are limited to mouse or touch screen operation. This is not intuitive. It also gives you nothing over adding activex controls to the user interface which you have been able to do since version 5 or 6.
Sure, you can program multiple controls within a forms panel object, etc but you need to write code for this line by line, you can't place or arrange the controls visually. This is just ridiculous for a visual programming language.
Meanwhile, NI proceed at pace and now have cool stuff like all sorts of toolboxes and the ability to target handheld PCs with applications. This is the kind of stuff we need as engineers.
In my opinion, Vee really needs at least the following urgently if it is to compete:
1. proper "native" user interface objects including a datagrid object that allow contemporary user interfaces to be designed. These objects need the ability to raise events, programmable properties and the ability to be referenced to as variables. Alternatively (or as well), the vee user interface panels need to function as true windows forms to allow .net forms controls to be used properly and in all their glory. 2. better thread control (or some thread control). 3. ability to target different versions of windows (such as windows mobile). 4. free "lite" copies sent out to every university offering engineering degrees worldwide!
Cheers
Nick
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
I noticed that Measurement Computing is scaling back its VEE support (See below). Some VEE'ers say that lack of VEE drivers is no big deal as you can use VEE to call functions from their Universal Library but I don't see how to do that (advice welcome!, perhaps a future episode of retro VEE-TV?)
The bigger issue to me is that VEE (the best darn Graphical programming language) is being squeezed out, while everyone offers LabView drivers. First Data Translation stopped offering their DT-VPI to add direct control of their hardware to VEE, now Measurement Computing (and I am sure many others have fallen in between). Data Translation now offers their own (Measurement Foundary) but still offers LabView Drivers but no VEE support.
What can we as users do to encourage these makers of fine hardware to continue to support VEE?
All users of VEE are not heavy duty programmers, like many LabView users, we are scientists and engineers just trying to get a job done. The last thing in the world I want to do is have to figure out how to write drivers (but I will if someone produces some readable instructions if you have never used .h files or DLL'S it is pretty confusing!).
From Measurement Computing ftp://ftp.measurementcomputing.com/UL%20for%20VEE/Installation%20instructions%20for%20VEE%207%20and%20higher%20and%20patch/
"The reason for this process is due to the decreasing support requests received for Agilent VEE. Since MCC has not received many support calls for VEE, we have elected not to invest any R&D dollars in maintaining the product through out software engineering group. However, we would like to offer you the best support we can, so the updating of this product has moved over to our Application Engineering team."
-- Jim McClymer, PhD Graduate Coordinator Department of Physics and Astronomy University of Maine
---
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Jim McClymer <McClymer@maine.edu> wrote: > I noticed that Measurement Computing is scaling back its VEE support > (See below). Some VEE'ers say that lack of VEE drivers is no big deal > as you can use VEE to call functions from their Universal Library but I > don't see how to do that (advice welcome!, perhaps a future episode of > retro VEE-TV?)
The Universal Library is a well behaved and fully documented DLL- so calling from VEE as compiled library and follow the examples from MCC. The only hard part is the def file: after that the examples will work line for line as they are just function calls.
to get you started:
int __stdcall cbDConfigPort( int Boardnum, int Portnum, int Direction); int __stdcall cbDOut(int Boardnum, int portnum, int DataValue); int __stdcall cbDBitOut( int boardnum, int Porttype, int bitnum, short bitValue ); int __stdcall cbFlashLED( short Boardnum);
It really is pretty easy in this case.
> > > The bigger issue to me is that VEE (the best darn Graphical programming > language) is being squeezed out, while everyone offers LabView drivers. > First Data Translation stopped offering their DT-VPI to add direct > control of their hardware to VEE, now Measurement Computing (and I am > sure many others have fallen in between).
Well- to be fair- consider who owns MCC.
Stan
-------------------------------------------------------------------------- Stan Bischof Agilent Technologies 707-577-3994 stan_bischof@agilent.com --------------------------------------------------------------------------
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Jim McClymer <McClymer@maine.edu> wrote: > I noticed that Measurement Computing is scaling back its VEE support > (See below). Some VEE'ers say that lack of VEE drivers is no big deal > as you can use VEE to call functions from their Universal Library but > I don't see how to do that (advice welcome!, perhaps a future episode > of retro VEE-TV?)
The Universal Library is a well behaved and fully documented DLL- so calling from VEE as compiled library and follow the examples from MCC. The only hard part is the def file: after that the examples will work line for line as they are just function calls.
to get you started:
int __stdcall cbDConfigPort( int Boardnum, int Portnum, int Direction); int __stdcall cbDOut(int Boardnum, int portnum, int DataValue); int __stdcall cbDBitOut( int boardnum, int Porttype, int bitnum, short bitValue ); int __stdcall cbFlashLED( short Boardnum);
It really is pretty easy in this case.
> > > The bigger issue to me is that VEE (the best darn Graphical > programming > language) is being squeezed out, while everyone offers LabView drivers. > First Data Translation stopped offering their DT-VPI to add direct > control of their hardware to VEE, now Measurement Computing (and I am > sure many others have fallen in between).
Well- to be fair- consider who owns MCC.
Stan
-------------------------------------------------------------------------- Stan Bischof Agilent Technologies 707-577-3994 stan_bischof@agilent.com --------------------------------------------------------------------------
--- To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Keep in mind that NI owns Measurement Computing, too.
Martin Rowe Senior Technical Editor Test & Measurement World 781-734-8419 m.rowe@tmworld.com http://www.tmworld.com
> -----Original Message----- > From: Jim McClymer [mailto:McClymer@maine.edu] > Sent: Monday, January 30, 2006 10:18 AM > To: VRF > Subject: [vrf] Vanishing VEE support?? > > > I noticed that Measurement Computing is scaling back its VEE support > (See below). Some VEE'ers say that lack of VEE drivers is > no big deal > as you can use VEE to call functions from their Universal Library but > I don't see how to do that (advice welcome!, perhaps a future episode > of retro VEE-TV?) > > > The bigger issue to me is that VEE (the best darn Graphical > programming > language) is being squeezed out, while everyone offers LabView > drivers. First Data Translation stopped offering their DT-VPI to add > direct control of their hardware to VEE, now Measurement Computing > (and I am sure many others have fallen in between). Data Translation > now offers their own (Measurement Foundary) but still offers LabView > Drivers but no VEE support. > > What can we as users do to encourage these makers of fine hardware to > continue to support VEE? > > All users of VEE are not heavy duty programmers, like many LabView > users, we are scientists and engineers just trying to get a job done. > The last thing in the world I want to do is have to figure out how to > write drivers (but I will if someone produces some readable > instructions if you have never used .h files or DLL'S it is pretty > confusing!). > > > From Measurement Computing > ftp://ftp.measurementcomputing.com/UL%2 ... stallation %20instructions%20for%20VEE%207%20and%20higher%20and%20patch/
"The reason for this process is due to the decreasing support requests received for Agilent VEE. Since MCC has not received many support calls for VEE, we have elected not to invest any R&D dollars in maintaining the product through out software engineering group. However, we would like to offer you the best support we can, so the updating of this product has moved over to our Application Engineering team."
-- Jim McClymer, PhD Graduate Coordinator Department of Physics and Astronomy University of Maine
--- You are currently subscribed to vrf as: mrowe@reedbusiness.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
---
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
> What can we as users do to encourage these makers of fine hardware to continue to support VEE?
Call them up and say "You are a maker of fine hardware. I would be more encouraged to use your product if you had a VEE driver."
> All users of VEE are not heavy duty programmers, like many LabView > users, we are scientists and engineers ...
I'm trying to parse that sentence. Are you saying that many LabVIEW users are heavy duty programmers, while VEE users are not? Or: both VEE and LabVIEW users are scientists and engineers?
While I sympathize with you, in some ways the managers of VEE brought this upon themselves. Look back at the early days of VEE. There was an academic version that didn't even have the instrument support. Universities were suppose to use this for general purpose programming. That version was soon dropped. Some members of HP/Agilent management didn't see the need for instrument drivers because Direct IO was available as a work-around. Meanwhile, NI made sure that there was an instrument driver available for just about everything. Sometimes the driver wasn't very good. (I looked at the Plug&Play C-code for a simple DAC. The Init code from Agilent just about had more instructions than the entire code from NI. And those were important instructions.) But NI had drivers. Also, NI made sure that they set up deals with many universities - introducing LabVIEW to most of the engineering students. Those students soon became engineers making purchasing decisions. They purchased what they knew - LabVIEW.
Face it. HP/Agilent marketing fell flat on its face on this. They assumed that since HP/Agilent was the market leader in High Performance instruments that they would be the market leader in graphical language. They were wrong. Now they are paying the price.
Les Hammer
--- To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
Both LabVIEW and VEE are good tools - and function side-by-side in many places, especially where lots of H-P/Agilent gear is used. I worked at such a place, myself!
DPC
-----Original Message----- From: Les Hammer [mailto:Les.Hammer@CompleteTest.com] Sent: Monday, January 30, 2006 9:04 AM To: VRF Subject: RE: [vrf] Vanishing VEE support??
> What can we as users do to encourage these makers of fine hardware to continue to support VEE?
Call them up and say "You are a maker of fine hardware. I would be more encouraged to use your product if you had a VEE driver."
> All users of VEE are not heavy duty programmers, like many LabView > users, we are scientists and engineers ...
I'm trying to parse that sentence. Are you saying that many LabVIEW users are heavy duty programmers, while VEE users are not? Or: both VEE and LabVIEW users are scientists and engineers?
While I sympathize with you, in some ways the managers of VEE brought this upon themselves. Look back at the early days of VEE. There was an academic version that didn't even have the instrument support. Universities were suppose to use this for general purpose programming. That version was soon dropped. Some members of HP/Agilent management didn't see the need for instrument drivers because Direct IO was available as a work-around. Meanwhile, NI made sure that there was an instrument driver available for just about everything. Sometimes the driver wasn't very good. (I looked at the Plug&Play C-code for a simple DAC. The Init code from Agilent just about had more instructions than the entire code from NI. And those were important instructions.) But NI had drivers. Also, NI made sure that they set up deals with many universities - introducing LabVIEW to most of the engineering students. Those students soon became engineers making purchasing decisions. They purchased what they knew - LabVIEW.
Face it. HP/Agilent marketing fell flat on its face on this. They assumed that since HP/Agilent was the market leader in High Performance instruments that they would be the market leader in graphical language. They were wrong. Now they are paying the price.
Les Hammer
--- You are currently subscribed to vrf as: dean.coombs@lmco.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
---
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
I love Vee and I would class myself as a heavy duty programmer as I have periods in my life when I do nothing but code. Also most of my code goes "out of house" to customers. In this respect, vee is my main language.
To be honest, the lack of instrument drivers for vee doesn't really bother me much. DAQ manufacturers now often have activeX libraries to allow communication, programming via direct I/O for GPIB, etc is no real problem. In my experience most vee drivers produced by 3rd party companies in support of their hardware was pretty rubbish anyway (some notable exceptions).
As a graphical user language, vee has one ironic but major drawback. Its features for producing Graphical User Interfaces are poor. The basic vee graphical user interface objects have not changed since I hopped on board at version 5 (probably before that). This is unacceptable in my opinion.
Before anyone steps in, I've just finished evaluating vee 7.5! I was really hoping that the "new" ability to embed window's controls onto vee interface panels would finally provide the functionality required but alas it appears not to be the case. Unfortunately, the vee "panels" do not function as true windows forms. Individual controls can be added to a user panel but there is no way to set up things like tabbing between individual controls meaning that user interfaces designed in this way are limited to mouse or touch screen operation. This is not intuitive. It also gives you nothing over adding activex controls to the user interface which you have been able to do since version 5 or 6.
Sure, you can program multiple controls within a forms panel object, etc but you need to write code for this line by line, you can't place or arrange the controls visually. This is just ridiculous for a visual programming language.
Meanwhile, NI proceed at pace and now have cool stuff like all sorts of toolboxes and the ability to target handheld PCs with applications. This is the kind of stuff we need as engineers.
In my opinion, Vee really needs at least the following urgently if it is to compete:
1. proper "native" user interface objects including a datagrid object that allow contemporary user interfaces to be designed. These objects need the ability to raise events, programmable properties and the ability to be referenced to as variables. Alternatively (or as well), the vee user interface panels need to function as true windows forms to allow .net forms controls to be used properly and in all their glory. 2. better thread control (or some thread control). 3. ability to target different versions of windows (such as windows mobile). 4. free "lite" copies sent out to every university offering engineering degrees worldwide!
Cheers
Nick
--- To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
>>All users of VEE are not heavy duty programmers, like many LabView >>users, >> >> >we are scientists and engineers ... > >I'm trying to parse that sentence. >Are you saying that many LabVIEW users are heavy duty programmers, >while VEE users are not? >Or: both VEE and LabVIEW users are scientists and engineers? > >
I was struggling to make myself understood in few words- then ran off to class. I was saying that many Labview and VEE programmers are users who know just enough to get the job done, they don't program every day and the thought of creating drivers, etc can be formidable.
When I first learned about graphical programming, at a free NI LabView event, I was hooked. They had a very cheap student edition which I bought. I was about to buy a site license when I heard about VEE and met some HP guys who would come to the University. They had such a great deal it blew NI away, I think I got a 40 copy site license and a GPIB board for about $500! I have since updated the license a few times (Vee one lab and now VEE 7.0 (and I am behind again!).
While I was teaching students VEE, one of our big research institutes hired some labView guys so LabView became the standard programming environment at the lab, rendering some of what I do less relevant..
I still think VEE offers good deals to universities but not many know about it as Agilent doesn't seem to go to the conferences academic scientists and engineers go to nor does it advertise in our journals. Agilent should take a lesson from LEGO (latest WIRED) and create an Academic Users Group to learn how to infiltrate universities better so as to create future VEE demand.
Jim
>While I sympathize with you, in some ways the managers of VEE brought >this upon themselves. >Look back at the early days of VEE. There was an academic version that >didn't even have the instrument support. Universities were suppose to >use this for general purpose programming. That version was soon dropped. >Some members of HP/Agilent management didn't see the need for >instrument drivers because Direct IO was available as a work-around. >Meanwhile, NI made sure that there was an instrument driver available >for just about everything. Sometimes the driver wasn't very good. (I >looked at the Plug&Play C-code for a simple DAC. The Init code from >Agilent just about had more instructions than the entire code from NI. >And those were important instructions.) But NI had drivers. >Also, NI made sure that they set up deals with many universities - >introducing LabVIEW to most of the engineering students. Those >students soon became engineers making purchasing decisions. They >purchased what they knew - LabVIEW. > >Face it. HP/Agilent marketing fell flat on its face on this. They >assumed that since HP/Agilent was the market leader in High Performance >instruments that they would be the market leader in graphical language. >They were wrong. Now they are paying the price. > >Les Hammer > > > > >
-- Jim McClymer, PhD Graduate Coordinator Department of Physics and Astronomy University of Maine
---
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
I still have my "I want my ITG" T-shirt. What a cool tool that one was. We had a script that would take the .id file and generate all possible states (using low, mid and high values if it was a numeric). Then it would save each state and recall each state from all the other states, comparing the recalled state to what it was the first time through. I found a few firmware bugs that way.
But, as the VEE designers told me, the only thing that ITG and VEE have in common is that they both parse the same .id files. (Well, almost the same. VEE couldn't parse .id files that called RMB code user functions that could be used in ITG.) Other than that ITG and VEE are very different.
~~Les Hammer
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
> Face it. HP/Agilent marketing fell flat on its face on this. They >assumed >that since HP/Agilent was the market leader in High Performance instruments >that they would be the market leader in graphical language. They were >wrong. Now they are paying the price.
I have to agree with you on that one - I have been using VEE since before it was VEE (anyone remember ITG?), even developed a mixed signal tester base on a HP82000 and some HP rack and stack instruments all tied together using Vee. But the only way I could 'sell' VEE to my bosses was the old "Well we have a lot of HP kit so they will have drivers in Vee..." even though I knew for the most part it wasn't true.
The only weak link in VEE was the abysmal marketing support it received from HP.
--- You are currently subscribed to vrf as: rsb@soco.agilent.com To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com". To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com". To send messages to this mailing list, email "vrf@agilent.com". If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com". Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
places, especially where lots of H-P/Agilent gear is used. I worked at
such a place, myself!
DPC
-----Original Message-----
From: Les Hammer [mailto:Les.Hammer@CompleteTest.com]
Sent: Monday, January 30, 2006 9:04 AM
To: VRF
Subject: RE: [vrf] Vanishing VEE support??
> What can we as users do to encourage these makers of fine hardware to
continue to support VEE?
Call them up and say "You are a maker of fine hardware. I would be more
encouraged to use your product if you had a VEE driver."
> All users of VEE are not heavy duty programmers, like many LabView
> users,
we are scientists and engineers ...
I'm trying to parse that sentence.
Are you saying that many LabVIEW users are heavy duty programmers, while
VEE users are not?
Or: both VEE and LabVIEW users are scientists and engineers?
While I sympathize with you, in some ways the managers of VEE brought
this upon themselves. Look back at the early days of VEE. There was an
academic version that didn't even have the instrument support.
Universities were suppose to use this for general purpose programming.
That version was soon dropped. Some members of HP/Agilent management
didn't see the need for instrument drivers because Direct IO was
available as a work-around. Meanwhile, NI made sure that there was an
instrument driver available for just about everything. Sometimes the
driver wasn't very good. (I looked at the Plug&Play C-code for a simple
DAC. The Init code from Agilent just about had more instructions than
the entire code from NI. And those were important instructions.) But
NI had drivers. Also, NI made sure that they set up deals with many
universities - introducing LabVIEW to most of the engineering students.
Those students soon became engineers making purchasing decisions. They
purchased what they knew - LabVIEW.
Face it. HP/Agilent marketing fell flat on its face on this. They
assumed that since HP/Agilent was the market leader in High Performance
instruments that they would be the market leader in graphical language.
They were wrong. Now they are paying the price.
Les Hammer
---
You are currently subscribed to vrf as: dean.coombs@lmco.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to
"leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to
"owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".
---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe send a blank email to "join-vrf@it.lists.it.agilent.com".
To unsubscribe send a blank email to "leave-vrf@it.lists.it.agilent.com".
To send messages to this mailing list, email "vrf@agilent.com".
If you need help with the mailing list send a message to "owner-vrf@it.lists.it.agilent.com".
Search the "unofficial vrf archive" at "www.oswegosw.com/vrf_archive/".