AnsweredAssumed Answered

Re2: vrf Instrument driver question...

Question asked by VRFuser on Apr 5, 2006

Like • Show 0 Likes0
Comment • 7

> In later
> versions of VEE, minimizing a panel would also cause it to revert to
> component driver actions.

Ah how memory fades after a dozen years. I have been having a discussion with one of the original VEE team members on this subject. The consensus is that although we discussed this as an enhancement, it was never implemented.
In case anybody actually cares, the panel actions are executed even when the panel is minimized. The only performance improvement is that windows would not take the time to do a full repaint on a minimized panel.

Sorry for any confusion.

Jay Nemeth-Johannes
Smart Sensor Systems
720 SW 14th Street
Loveland, Colorado 80537
(970) 663-0006
www.SmartSensorSystems.com

---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
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/".

No one else has this question

Outcomes

7 Replies

VRFuser Apr 3, 2006 8:45 PM
Mark Correct
Correct Answer
> I Can't help thinking there is an opportunity for making
> things simpler using panel drivers. (A picture is worth a
> thousand words) Especially for anything like a spectrum
> analyzer or scope. If you are on the receiving end of an
> instrument you don't know a lot about. A well written panel
> driver can put you days ahead of where you would be otherwise.

I won't disagree. However, they did have their problems. The drivers were
interpreted code and thus ran slowly compared to a true compiled driver such
as plug&play. The driver team did not have control of the driver engine
code. The proposal to provide a true panel driver compiler never got past
the cut on the new features list. The component driver path did provide
performance improvements because it bypassed all the panel repaint and
update code. In later versions of VEE, minimizing a panel would also cause
it to revert to component driver actions.

It is all moot though. The last panel driver was written in 1994. The last
panel driver maintenance was performed in 1997. The only people who
understand these drivers now work with me over at SSS. There will never be
another supported or distributed panel driver.

Jay Nemeth-Johannes
Smart Sensor Systems
720 SW 14th Street
Loveland, Colorado 80537
(970) 663-0006
www.SmartSensorSystems.com

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
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/".
Like • Show 0 Likes0
Actions
charles.stewart Apr 4, 2006 2:35 AM
Mark Correct
Correct Answer
I Can't help thinking there is an opportunity for making things simpler
using panel drivers. (A picture is worth a thousand words) Especially
for anything like a spectrum analyser or scope. If you are on the
receiving end of an instrument you don't know a lot about. A well
written panel driver can put you days ahead of where you would be
otherwise.

Chuck

>-----Original Message-----
>From: ext Stan Bischof (Richard S) [mailto:rsb@soco.agilent.com]
>Sent: 04 April 2006 17:24
>To: VRF
>Cc: vrf@agilent.com
>Subject: Re[2]: [vrf] Instrument driver question...
>
>"Brian H. Powell" <brian@ni.com> wrote:
>>       I think the instrument driver vs. Direct I/O question
>transcends
>> development environments, so I hope you'll allow me to offer a
>> perspective from the LabVIEW side...
>
>
>>       I think this applies to VEE as well. For one-time use, Direct
>> I/O is nice and easy. For reusability, wrap it in higher-level user
>> functions. Build up your code from there.
>>
>
>Now this is getting downright interesting!
>
>Using IO commands directly has the big advantage that it will
>work with any programming language since the actual instrument
>commands sent will be the same regardless of from where they
>are sent. That's a real plus. The downside of course is that
>the end user has a lot of work to do in assimilating the
>programming languages of every instrument that will be used.
>And of course all such languages are extremely sensitive to syntax.
>
>As Brian suggests, this is ameliorated to a large extent by
>wrapping sets of IO commands into higher-level functions that
>can be used within a given environment. All sophisticated code
>is written this way anyhow for many reasons. The big downside
>is that any work done becomes application specific since each
>programming environment is proprietary. This gets really ugly
>when environments get rev'd in a manner that breaks older code.
>
>Existing "Drivers" on the other hand are really just a
>different form of function wrapper around the same sets of IO commands.
>The intent of "drivers" is that they are cross-environment so
>can be used anywhere. However reality has shown that the
>industry has never agreed to the extent necessary to actually
>make this happen. No existing drivers handle more than a
>handful of special cases, so for all practical purposes they
>are proprietary in nature- severely hastening their eventual demise.
>
>Coupled with the difficulties in just attaching and
>communicating with instruments in the first place, this very
>often makes basic instrument control issues the bottleneck in
>automation. Which is crazy of course since the end user will
>almost never have instrument control as the end goal, but
>rather as a necessary evil that has to be overcome.
>
>My own feeling is that the only way this will fundamentally
>change is when instruments start being produced used portable
>objects of one form or another- such that command languages,
>drivers, and so on all vanish. Instead instrument control
>becomes as simple as web browsing- browse to the instrument,
>grab displays or other objects, drop them into your program
>and continue onwards. Just as the basic interfacing will need
>to move to computer standards ( ethernet, USB, etc.) this
>portable object technology will also have to be computer standards.
>
>I fully realize that this will take a long time to happen- but
>just imagine being able to use your instrument from any
>environment as easily as from the front panel, and then being
>able to spend most of your time doing useful programming
>rather than playing with instrument control. Pipe dream? Sure-
>but quite technically feasible at the same time.
>
>back to the fray---
>
>Stan
>
>
>---------------------------------------------------------------
>-----------
>Stan Bischof Agilent Technologies 707-577-3994
>stan_bischof@agilent.com
>---------------------------------------------------------------
>-----------
>
>---
>You are currently subscribed to vrf as:
>Charles.Stewart@vertu.com To subscribe please send an email
>to: "vrf-request@lists.it.agilent.com" with the word subscribe
>in the message body.
>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 please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
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/".
Like • Show 0 Likes0
Actions
rsb Apr 4, 2006 9:24 AM
Mark Correct
Correct Answer
"Brian H. Powell" <brian@ni.com> wrote:
>       I think the instrument driver vs. Direct I/O question
> transcends development environments, so I hope you'll allow me to
> offer a perspective from the LabVIEW side...

>       I think this applies to VEE as well. For one-time use, Direct
> I/O is nice and easy. For reusability, wrap it in higher-level user
> functions. Build up your code from there.
>

Now this is getting downright interesting!

Using IO commands directly has the big advantage that it will
work with any programming language since the actual instrument
commands sent will be the same regardless of from where they
are sent. That's a real plus. The downside of course is that
the end user has a lot of work to do in assimilating the programming
languages of every instrument that will be used. And of course
all such languages are extremely sensitive to syntax.

As Brian suggests, this is ameliorated to a large extent by
wrapping sets of IO commands into higher-level functions
that can be used within a given environment. All sophisticated
code is written this way anyhow for many reasons. The big downside
is that any work done becomes application specific since each
programming environment is proprietary. This gets really ugly when
environments get rev'd in a manner that breaks older code.

Existing "Drivers" on the other hand are really just a different
form of function wrapper around the same sets of IO commands.
The intent of "drivers" is that they are cross-environment
so can be used anywhere. However reality has shown that the
industry has never agreed to the extent necessary to actually make
this happen. No existing drivers handle more than a handful of
special cases, so for all practical purposes they are proprietary
in nature- severely hastening their eventual demise.

Coupled with the difficulties in just attaching and communicating
with instruments in the first place, this very often makes basic
instrument control issues the bottleneck in automation. Which
is crazy of course since the end user will almost never have
instrument control as the end goal, but rather as a necessary
evil that has to be overcome.

My own feeling is that the only way this will fundamentally
change is when instruments start being produced used portable
objects of one form or another- such that command languages,
drivers, and so on all vanish. Instead instrument control becomes
as simple as web browsing- browse to the instrument, grab displays
or other objects, drop them into your program and continue
onwards. Just as the basic interfacing will need to move
to computer standards ( ethernet, USB, etc.) this portable object
technology will also have to be computer standards.

I fully realize that this will take a long time to happen- but just
imagine being able to use your instrument from any environment as
easily as from the front panel, and then being able to spend
most of your time doing useful programming rather than playing
with instrument control. Pipe dream? Sure- but quite technically
feasible at the same time.

back to the fray---

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 please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
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/".
Like • Show 0 Likes0
Actions
VRFuser Apr 4, 2006 9:25 AM
Mark Correct
Correct Answer
"Brian H. Powell" <brian@ni.com> wrote:
>       I think the instrument driver vs. Direct I/O question transcends
> development environments, so I hope you'll allow me to offer a
> perspective from the LabVIEW side...

>       I think this applies to VEE as well. For one-time use, Direct
> I/O is nice and easy. For reusability, wrap it in higher-level user
> functions. Build up your code from there.
>

Now this is getting downright interesting!

Using IO commands directly has the big advantage that it will work with any programming language since the actual instrument commands sent will be the same regardless of from where they are sent. That's a real plus. The downside of course is that the end user has a lot of work to do in assimilating the programming languages of every instrument that will be used. And of course all such languages are extremely sensitive to syntax.

As Brian suggests, this is ameliorated to a large extent by wrapping sets of IO commands into higher-level functions that can be used within a given environment. All sophisticated code is written this way anyhow for many reasons. The big downside is that any work done becomes application specific since each programming environment is proprietary. This gets really ugly when environments get rev'd in a manner that breaks older code.

Existing "Drivers" on the other hand are really just a different form of function wrapper around the same sets of IO commands.
The intent of "drivers" is that they are cross-environment so can be used anywhere. However reality has shown that the industry has never agreed to the extent necessary to actually make this happen. No existing drivers handle more than a handful of special cases, so for all practical purposes they are proprietary in nature- severely hastening their eventual demise.

Coupled with the difficulties in just attaching and communicating with instruments in the first place, this very often makes basic instrument control issues the bottleneck in automation. Which is crazy of course since the end user will almost never have instrument control as the end goal, but rather as a necessary evil that has to be overcome.

My own feeling is that the only way this will fundamentally change is when instruments start being produced used portable objects of one form or another- such that command languages, drivers, and so on all vanish. Instead instrument control becomes as simple as web browsing- browse to the instrument, grab displays or other objects, drop them into your program and continue onwards. Just as the basic interfacing will need to move to computer standards ( ethernet, USB, etc.) this portable object technology will also have to be computer standards.

I fully realize that this will take a long time to happen- but just imagine being able to use your instrument from any environment as easily as from the front panel, and then being able to spend most of your time doing useful programming rather than playing with instrument control. Pipe dream? Sure- but quite technically feasible at the same time.

back to the fray---

Stan

--------------------------------------------------------------------------
Stan Bischof Agilent Technologies 707-577-3994 stan_bischof@agilent.com
--------------------------------------------------------------------------

---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
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/".
Like • Show 0 Likes0
Actions
charles.stewart Apr 4, 2006 9:49 AM
Mark Correct
Correct Answer
I Can't help thinking there is an opportunity for making things simpler using panel drivers. (A picture is worth a thousand words) Especially for anything like a spectrum analyser or scope. If you are on the receiving end of an instrument you don't know a lot about. A well written panel driver can put you days ahead of where you would be otherwise.

Chuck

>-----Original Message-----
>From: ext Stan Bischof (Richard S) [mailto:rsb@soco.agilent.com]
>Sent: 04 April 2006 17:24
>To: VRF
>Cc: vrf@agilent.com
>Subject: Re[2]: [vrf] Instrument driver question...
>
>"Brian H. Powell" <brian@ni.com> wrote:
>>       I think the instrument driver vs. Direct I/O question
>transcends
>> development environments, so I hope you'll allow me to offer a
>> perspective from the LabVIEW side...
>
>
>>       I think this applies to VEE as well. For one-time use, Direct
>> I/O is nice and easy. For reusability, wrap it in higher-level user
>> functions. Build up your code from there.
>>
>
>Now this is getting downright interesting!
>
>Using IO commands directly has the big advantage that it will work with
>any programming language since the actual instrument commands sent will
>be the same regardless of from where they are sent. That's a real plus.
>The downside of course is that the end user has a lot of work to do in
>assimilating the programming languages of every instrument that will be
>used.
>And of course all such languages are extremely sensitive to syntax.
>
>As Brian suggests, this is ameliorated to a large extent by wrapping
>sets of IO commands into higher-level functions that can be used within
>a given environment. All sophisticated code is written this way anyhow
>for many reasons. The big downside is that any work done becomes
>application specific since each programming environment is proprietary.
>This gets really ugly when environments get rev'd in a manner that
>breaks older code.
>
>Existing "Drivers" on the other hand are really just a different form
>of function wrapper around the same sets of IO commands.
>The intent of "drivers" is that they are cross-environment so can be
>used anywhere. However reality has shown that the industry has never
>agreed to the extent necessary to actually make this happen. No
>existing drivers handle more than a handful of special cases, so for
>all practical purposes they are proprietary in nature- severely
>hastening their eventual demise.
>
>Coupled with the difficulties in just attaching and communicating with
>instruments in the first place, this very often makes basic instrument
>control issues the bottleneck in automation. Which is crazy of course
>since the end user will almost never have instrument control as the end
>goal, but rather as a necessary evil that has to be overcome.
>
>My own feeling is that the only way this will fundamentally change is
>when instruments start being produced used portable objects of one form
>or another- such that command languages, drivers, and so on all vanish.
>Instead instrument control becomes as simple as web browsing- browse to
>the instrument, grab displays or other objects, drop them into your
>program and continue onwards. Just as the basic interfacing will need
>to move to computer standards ( ethernet, USB, etc.) this portable
>object technology will also have to be computer standards.
>
>I fully realize that this will take a long time to happen- but just
>imagine being able to use your instrument from any environment as
>easily as from the front panel, and then being able to spend most of
>your time doing useful programming rather than playing with instrument
>control. Pipe dream? Sure- but quite technically feasible at the same
>time.
>
>back to the fray---
>
>Stan
>
>
>---------------------------------------------------------------
>-----------
>Stan Bischof Agilent Technologies 707-577-3994
>stan_bischof@agilent.com
>---------------------------------------------------------------
>-----------
>
>---
>You are currently subscribed to vrf as:
>Charles.Stewart@vertu.com To subscribe please send an email
>to: "vrf-request@lists.it.agilent.com" with the word subscribe in the
>message body.
>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 please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
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/".
Like • Show 0 Likes0
Actions
VRFuser Apr 4, 2006 10:46 AM
Mark Correct
Correct Answer
> I Can't help thinking there is an opportunity for making things
> simpler using panel drivers. (A picture is worth a thousand words)
> Especially for anything like a spectrum analyzer or scope. If you are
> on the receiving end of an instrument you don't know a lot about. A
> well written panel driver can put you days ahead of where you would be
> otherwise.

I won't disagree. However, they did have their problems. The drivers were interpreted code and thus ran slowly compared to a true compiled driver such as plug&play. The driver team did not have control of the driver engine code. The proposal to provide a true panel driver compiler never got past the cut on the new features list. The component driver path did provide performance improvements because it bypassed all the panel repaint and update code. In later versions of VEE, minimizing a panel would also cause it to revert to component driver actions.

It is all moot though. The last panel driver was written in 1994. The last panel driver maintenance was performed in 1997. The only people who understand these drivers now work with me over at SSS. There will never be another supported or distributed panel driver.

Jay Nemeth-Johannes
Smart Sensor Systems
720 SW 14th Street
Loveland, Colorado 80537
(970) 663-0006
www.SmartSensorSystems.com

---
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
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/".
Like • Show 0 Likes0
Actions
VRFuser Apr 4, 2006 3:39 PM
Mark Correct
Correct Answer
> In later
> versions of VEE, minimizing a panel would also cause it to
> revert to component driver actions.

Ah how memory fades after a dozen years. I have been having a discussion
with one of the original VEE team members on this subject. The consensus is
that although we discussed this as an enhancement, it was never implemented.
In case anybody actually cares, the panel actions are executed even when the
panel is minimized. The only performance improvement is that windows would
not take the time to do a full repaint on a minimized panel.

Sorry for any confusion.

Jay Nemeth-Johannes
Smart Sensor Systems
720 SW 14th Street
Loveland, Colorado 80537
(970) 663-0006
www.SmartSensorSystems.com

---
You are currently subscribed to vrf as: rsb@soco.agilent.com
To subscribe please send an email to: "vrf-request@lists.it.agilent.com" with the word subscribe in the message body.
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/".
Like • Show 0 Likes0
Actions

Re2: vrf Instrument driver question...

Outcomes

Related Content

Recommended Content