仪器驱动问题

>我不禁想到有机会使用面板驱动程序使事情更简单。
（一张图片胜过千言万语）特别适合频谱>分析仪或示波器。
如果您在>仪器的接收端，您不太了解。
一个写得很好的小组>司机可以把你提前几天放在你的位置。我不会不同意。
但是，他们确实遇到了问题。
驱动程序是解释代码，因此与真正的编译驱动程序（如插件和播放）相比运行缓慢。
驱动程序团队无法控制驱动程序引擎代码。
提供真正的面板驱动程序编译器的提议从未超过新功能列表的削减。
组件驱动程序路径确实提供了性能改进，因为它绕过了所有面板重绘和更新代码。
在VEE的更高版本中，最小化面板也会导致恢复到组件驱动程序操作。但这一切都没有实际意义。
最后一个面板驱动程序是在1994年编写的。最后一个面板驱动程序维护是在1997年完成的。唯一知道这些驱动程序的人现在和我一起在SSS工作。
永远不会有beanother支持或分布式面板driver.Jay内梅特 - JohannesSmart传感器Systems720 SW 14 StreetLoveland，科罗拉多州80537（970）663-0006www.SmartSensorSystems.com ---您当前订阅的VRF为：r***@soco.agilent.comTo
订阅请发送电子邮件至：“vrf-request@lists.it.agilent.com”，邮件正文中包含subscribe一词。要取消订阅，请发送空白电子邮件至“leave-vrf@it.lists.it.agilent.com
“。要发送邮件到这个邮件列表，请发送电子邮件至”vrf@agilent.com“。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。



     以下为原文

  > 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: [email=r***@soco.agilent.com]r***@soco.agilent.com[/email]
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/".

我不禁想到有机会让面板驱动程序更简单。
（一张图片胜过千言万语）尤其适用于频谱分析仪或示波器。
如果你正在接受一个仪器的结尾，你不知道很多。
一个写得很好的面板驱动程序可以让你提前几天.Chuck> -----原始消息----->来自：ext Stan Bischof（Richard S）[mailto：r***@soco.agilent.com]
>发送时间：2006年4月4日17:24>收件人：VRF>抄送：vrf@agilent.com>主题：Re [2]：[vrf]仪器驱动程序问题...... >>“Brian H. Powell”写道：>>
我认为仪器驱动程序与直接I / O问题>超越>>开发环境，所以我希望你能允许我从LabVIEW方面提供一个>>视角...... >>>>我认为这适用于VEE
同样。
对于一次性使用，Direct >> I / O非常简单。
为了可重用，请将其包装在更高级别的用户>>函数中。
从那里建立你的代码。>> >>现在这很有趣！
>>直接使用IO命令具有很大的优势，它将>可以使用任何编程语言，因为发送的实际仪器>命令将是相同的，无论它们从何处被发送。
这是一个真正的优点。
当然，缺点是最终用户在吸收将要使用的每种仪器的编程语言方面还有很多工作要做。
>当然，所有这些语言都对语法非常敏感。>>正如Brian所说，这在很大程度上得到了改善，>将IO命令集包装成可以在给定环境中使用的更高级函数。
无论如何，所有复杂的代码都是以这种方式编写的，原因很多。
最大的缺点是，由于每个>编程环境都是专有的，因此完成的任何工作都会变为应用程序。
当环境以破坏旧代码的方式进行转换时，这变得非常难看。>>另一方面，现有的“驱动程序”实际上只是围绕相同IO命令集的一种不同形式的函数包装。>意图
“驱动程序”是指它们是跨环境的，所以>可以在任何地方使用。
然而，现实表明，>行业从未达成过必要的程度才能实现这一目标。
没有现有的司机处理超过>少数特殊情况，因此对于所有实际目的而言，他们都是专有的 - 严重加速他们最终的死亡。>>再加上刚刚附加和>与仪器沟通的困难，
这非常>通常使基本的仪器控制问题成为>自动化的瓶颈。
当然，这是疯狂的，因为最终用户将>几乎从未将仪器控制作为最终目标，而是>而不是必须克服的必要的邪恶。>>我自己的感觉是，这将从根本上改变的唯一方式是
当乐器开始制作时，使用便携式>一种或另一种形式的对象 - 这样命令语言，>驱动程序等都消失了。
相反，仪器控制>变得像网页浏览一样简单 - 浏览仪器，>抓取显示或其他对象，将它们放入您的程序>然后继续。
正如基本接口需要>转向计算机标准（以太网，USB等），这>便携式对象技术也必须是计算机标准。>>我完全意识到这将需要很长时间才能实现 - 但
>想象一下，能够像从前面板那样轻松地从任何>环境中使用仪器，然后能够花费大部分时间进行有用的编程>而不是使用仪器控制。
白日梦？
当然 - >但在技术上同时也是可行的。>>回到战斗--- >> Stan >>> -----------------------
----------------------------------------> ---------
- > Stan Bischof安捷伦科技公司707-577-3994> stan_bischof@agilent.com> -------------------------------
--------------------------------> ----------- >> --->
您目前订阅了vrf：> Charles.Stewart@vertu.com要订阅，请发送电子邮件至：“vrf-request@lists.it.agilent.com”，并在邮件正文中添加“subscribe”一词。>至
取消订阅发送空白电子邮件至>“leave-vrf@it.lists.it.agilent.com”。>要将邮件发送到此邮件列表，请发送电子邮件至“vrf@agilent.com”。
>如果您需要有关邮件列表的帮助，请发送邮件至>“owner-vrf@it.lists.it.agilent.com”。>在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。
> ---您目前订阅了vrf：r***@soco.agilent.com要订阅，请发送电子邮件至：“vrf-request@lists.it.agilent.com”，邮件正文中包含subscribe一词。取消订阅
发送一封空白电子邮件至“leave-vrf@it.lists.it.agilent.com”。要发送邮件到此邮件列表，请发送电子邮件至“vrf@agilent.com”。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。



     以下为原文

  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:r***@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" 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: [email=r***@soco.agilent.com]r***@soco.agilent.com[/email]
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/".

“Brian H. Powell”写道：>我认为仪器驱动程序与直接I / O问题>超越了开发环境，所以我希望你能允许我从LabVIEW方面提供一个视角......>我认为这个
也适用于VEE。
对于一次性使用，Direct> I / O非常简单。
为了可重用，请将其包装在更高级别的用户>函数中。
从那里构建你的代码。>现在这变得非常有趣！
直接使用IO命令具有很大的优势，它可以使用任何编程语言，因为发送的实际仪器命令将是相同的，无论它们从何处发送。
这是一个真正的优点。
当然，缺点是最终用户在吸收将要使用的每种仪器的编程语言方面还有很多工作要做。
当然，所有这些语言都对语法非常敏感。正如Brian所说，通过将IO命令集合包含在可以在给定环境中使用的更高级别的函数，可以在很大程度上改善这种语言。
出于多种原因，所有复杂的代码都是以这种方式编写的。
最大的缺点是，由于每个编程环境都是专有的，因此所做的任何工作都会成为应用程序特定的。
这变得非常丑陋的环境以破坏旧代码的方式获得转换。另一方面，现有的“驱动程序”实际上只是围绕相同IO命令集的函数包装器的不同形式。“驱动程序”的意图是它们
是跨环境的，可以在任何地方使用。
然而，现实表明，该行业从未同意实际发生这种情况所必需的程度。
没有现有的司机处理超过少数几个特殊情况，因此对于所有实际目的而言，它们本质上是专有的 - 严重加速了它们最终的消亡。加上首先附加和与仪器通信的困​​难，这经常使得基本仪器控制问题成为可能。
自动化的瓶颈。
当然，自从最终用户以来几乎从未将仪器控制作为最终目标，而不是作为必须克服的必要品，这当然是疯狂的。我自己的感觉是，这将从根本上改变的唯一方式是当仪器开始生产时使用的便携式物品
形式或其他形式 - 命令语言，驱动程序等都消失了。
相反，仪器控制变得简单，因为网页浏览 - 浏览仪器，抓取显示器或其他对象，将它们放入程序并继续。
正如基本接口需要转移到计算机标准（以太网，USB等）一样，这种便携式对象技术也必须是计算机标准。我完全意识到这将需要很长时间才能发生 - 但是可以肯定能够使用你的
仪器可以从任何环境中从前面板开始，然后能够花费大部分时间进行有用的编程而不是使用仪器控制。
白日梦？
当然 - 但在技术上同时也是可行的。回到战斗中--- Stan -------------------------------
------------------------------------------- Stan Bischof Agilent Technologies 707-577
-3994 stan_bischof@agilent.com-------------------------------------------
----------------------------------您目前订阅vrf为：r***@soco.agilent.com要订阅
请发送电子邮件至：“vrf-request@lists.it.agilent.com”，邮件正文中包含subscribe一词。要取消订阅，请发送空白电子邮件至“leave-vrf@it.lists.it.agilent.com”
。要发送邮件到此邮件列表，请发送电子邮件至“vrf@agilent.com”。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。



     以下为原文

  "Brian H. Powell" 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: [email=r***@soco.agilent.com]r***@soco.agilent.com[/email]
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/".

“Brian H. Powell”写道：>我认为仪器驱动程序与直接I / O问题超越了>开发环境，所以我希望你能允许我从LabVIEW方面提供一个>视角...>我认为这个
也适用于VEE。
对于一次性使用，Direct> I / O非常简单。
为了可重用，请将其包装在更高级别的用户>函数中。
从那里构建你的代码。>现在这变得非常有趣！
直接使用IO命令具有很大的优势，它可以与任何编程语言一起使用，因为发送的实际仪器命令将是相同的，无论它们从何处发送。
这是一个真正的优点。
当然，缺点是最终用户在吸收将要使用的每种仪器的编程语言方面还有很多工作要做。
当然，所有这些语言都对语法非常敏感。正如Brian所说，通过将IO命令集包装到可在给定环境中使用的更高级函数，可以在很大程度上改善这种语言。
出于多种原因，所有复杂的代码都是以这种方式编写的。
最大的缺点是，由于每个编程环境都是专有的，因此完成的任何工作都会变得特定于应
当环境以破坏旧代码的方式进行转换时，这变得非常难看。另一方面，现有的“驱动程序”实际上只是围绕同一组IO命令的不同形式的函数包装。“驱动程序”的意图是
它们是跨环境的，因此可以在任何地方使用。
然而，现实表明，该行业从未同意实际实现这一目标所必需的程度。
没有现有的司机处理超过少数特殊情况，因此对于所有实际目的而言，它们本质上是专有的 - 严重加速了它们最终的消亡。与首先连接和与仪器通信的困​​难相结合，这通常是基本的
仪器控制问题是自动化的瓶颈。
当然，这是疯狂的，因为最终用户几乎从不将仪器控制作为最终目标，而是必须克服必要的邪恶。我自己的感觉是，这将从根本上改变的唯一方式是仪器何时开始生产
使用了一种或另一种形式的便携式对象 - 这样命令语言，驱动程序等都消失了。
相反，仪器控制变得像网页浏览一样简单 - 浏览仪器，抓取显示器或其他对象，将它们放入程序并继续进行。
正如基本接口需要转向计算机标准（以太网，USB等）一样，这种便携式对象技术也必须是计算机标准。我完全意识到这需要很长时间才能实现 - 但只是想象能够
从前面板轻松地从任何环境使用仪器，然后能够花费大部分时间进行有用的编程，而不是使用仪器控制。
白日梦？
当然 - 但在技术上同时也是可行的。回到战斗中--- Stan -------------------------------
------------------------------------------- Stan Bischof Agilent Technologies 707-577
-3994 stan_bischof@agilent.com-------------------------------------------
----------------------------------如需订阅，请发送电子邮件至：“vrf-request@lists.it
.agilent.com“在邮件正文中单词subscribe。要取消订阅，请发送一封空白电子邮件至”leave-vrf@it.lists.it.agilent.com“。要向此邮件列表发送邮件，请发送电子邮件至”vrf @ agilent
.COM”。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。



     以下为原文

  "Brian H. Powell" 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/".

我不禁想到有机会使用面板驱动程序使事情更简单。
（图片胜过千言万语）尤其适用于频谱分析仪或示波器等。
如果您在仪器的接收端，您不太了解。
一个写得很好的面板驱动程序可以让你领先几天.Chuck> -----原始消息----->来自：ext Stan Bischof（Richard S）[mailto：r***@soco.agilent。
发送时间：2006年4月4日17:24>收件人：VRF>抄送：vrf@agilent.com>主题：Re [2]：[vrf]仪器驱动程序问题...... >>“Brian H. Powell”写道：
>>我认为仪器驱动程序与直接I / O问题>超越了>>开发环境，所以我希望你允许我从LabVIEW方面提供>>视角...... >>>>我认为这适用
到VEE也是如此。
对于一次性使用，Direct >> I / O非常简单。
为了可重用，请将其包装在更高级别的用户>>函数中。
从那里建立你的代码。>> >>现在这很有趣！
>>直接使用IO命令具有很大的优势，它可以使用>任何编程语言，因为发送的实际仪器命令将是相同的，无论它们从何处发送。
这是一个真正的优点。
>当然，缺点是最终用户需要做很多工作>吸收将要使用的每种乐器的编程语言。>当然，所有这些语言对语法都非常敏感。>>正如Brian建议的那样。
通过将> IO命令集包装到可在给定环境中使用的更高级函数，可以在很大程度上改善这种情况。
无论如何，所有复杂的代码都以这种方式编写>出于多种原因。
最大的缺点是，由于每个编程环境都是专有的，因此完成的任何工作都将变为特定应用。
>当环境以>破坏旧代码的方式进行转换时，这变得非常难看。>>另一方面，现有的“驱动程序”实际上只是围绕相同IO命令集的函数包装器的形式。>
“驱动程序”的意图是它们是跨环境的，因此可以在任何地方使用。
然而，现实表明，该行业从来没有达到实际实现这一目标所必需的程度。
没有>现有的司机处理的不仅仅是少数几个特殊情况，因此对于所有实际目的而言，它们都是专有的 - 严重地>加速它们最终的消亡。>>加上首先只是附加和通信>仪器的困难
，这经常使基本的仪器>控制问题成为自动化的瓶颈。
这当然是疯狂的>因为最终用户几乎永远不会将仪器控制作为结束目标，而是必须克服必要的邪恶。>>我自己的感觉是，这将从根本上改变的唯一方式是>
当乐器开始制作时，使用一种形式的便携式物体>或另一种 - 这样命令语言，驱动程序等都会消失。
>相反，仪器控制变得像网页浏览一样简单 - 浏览到仪器，抓取显示器或其他对象，将它们放入>程序并继续向前。
正如基本的接口需要>转向计算机标准（以太网，USB等），这种便携式>对象技术也必须是计算机标准。>>我完全意识到这将需要很长时间才能实现 - 但
只是>想象能够从任何环境中轻松地使用您的乐器，从前面板开始，然后能够花费大部分时间进行有用的编程而不是使用乐器>控制。
白日梦？
当然 - 但在同一时间技术上是可行的。>>回到战争--- >> Stan >>> -----------------------
----------------------------------------> ---------
- > Stan Bischof安捷伦科技公司707-577-3994> stan_bischof@agilent.com> -------------------------------
--------------------------------> ----------- >> --->
您目前订阅了vrf：> Charles.Stewart@vertu.com要订阅，请发送电子邮件至：“vrf-request@lists.it.agilent.com”，并在>消息正文中使用subscribe一词。> To
取消订阅发送空白电子邮件至>“leave-vrf@it.lists.it.agilent.com”。>要将邮件发送到此邮件列表，请发送电子邮件至“vrf@agilent.com”。
>如果您需要有关邮件列表的帮助，请发送邮件至>“owner-vrf@it.lists.it.agilent.com”。>在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。
> ---要订阅，请发送电子邮件至：“vrf-request@lists.it.agilent.com”，邮件正文中包含subscribe一词。要取消订阅，请发送一封空白电子邮件至“leave-vrf@it.lists。
it.agilent.com“。要发送邮件到这个邮件列表，请发送电子邮件至”vrf@agilent.com“。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。



     以下为原文

  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:r***@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" 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/".

>我不禁想到有机会使用面板驱动程序更简单。
（一张图片胜过千言万语）>特别适用于频谱分析仪或示波器。
如果您>在仪器的接收端，您不太了解。
A>写得很好的面板驱动程序可以让你比你想象的还要早几天。否则。我不会反对。
但是，他们确实遇到了问题。
驱动程序被解释为代码，因此与真正的编译驱动程序（如即插即用）相比运行缓慢。
驱动程序团队无法控制驱动程序引擎代码。
提供真正的面板驱动程序编译器的提议从未超过新功能列表的削减。
组件驱动程序路径确实提供了性能改进，因为它绕过了所有面板重绘和更新代码。
在VEE的更高版本中，最小化面板也会导致它恢复为组件驱动程序操作。但这一切都没有实际意义。
最后一个面板驱动程序是在1994年编写的。最后一个面板驱动程序维护是在1997年完成的。唯一了解这些驱动程序的人现在在SSS与我合作。
再也不会有另一个支持或分布式面板driver.Jay内梅特 - JohannesSmart传感器Systems720 SW 14 StreetLoveland，科罗拉多州80537（970）663-0006www.SmartSensorSystems.com ---如需订阅，请发送电子邮件至：“VRF请求@名单
.it.agilent.com“在邮件正文中单词subscribe。要取消订阅，请发送一封空白电子邮件至”leave-vrf@it.lists.it.agilent.com“。要向此邮件列表发送邮件，请发送电子邮件至”vrf“
@ agilent.com”。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。



     以下为原文

  > 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/".

>在后来的VEE版本中，最小化面板也会导致>恢复到组件驱动程序操作。十几年后内存如何消失。
我一直在讨论这个主题的原始VEE团队成员之一。
大家一致认为，尽管我们将此作为增强功能进行了讨论，但它从未实现过。如果有人真正关心，即使面板最小化，也会执行面板操作。
唯一的性能改进是Windows不会花时间在最小化的面板上进行完全重新绘制。对于任何混乱.Jay Nemeth-JohannesSmart传感器系统720 SW SWthth StreetLoveland，Colorado 80537（970）663-0006www.SmartSensorSystems.com--
- 您目前订阅vrf为：r***@soco.agilent.com要订阅，请发送电子邮件至：“vrf-request@lists.it.agilent.com”，并在邮件正文中添加“subscribe”字样。要取消订阅，请发送空白
发送电子邮件至“leave-vrf@it.lists.it.agilent.com”。要发送邮件到此邮件列表，请发送电子邮件至“vrf@agilent.com”。
如果您需要有关邮件列表的帮助，请发送邮件至“owner-vrf@it.lists.it.agilent.com”。在“www.oswegosw.com/vrf_archive/”上搜索“非官方vrf档案”。



     以下为原文

  > 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: [email=r***@soco.agilent.com]r***@soco.agilent.com[/email]
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/".