为什么HP / Agilent主要以某种形式的BASIC编程网络分析仪？

> {quote：title = SOLT_guy写道：} {quote}>我观察到了广泛使用IBIC语言的IEEE 488.1协议。
>> IBIC和C语言兼容。
>>当开发IIEEE 488.2时，为什么HP / Agilent主要以某种形式的BASIC编程网络分析仪？
>> BASIC相对于C和IBIC的优势是什么？
为什么这种语言优先于其他语言？
>>编辑：SOLT_guy于2012年10月9日下午9:50只是一个疯狂的猜测，但惠普有9000系列计算机我认为运行BASIC。
当然在我的8720D的手册中，它列为兼容的计算机之一“HP 9000系列700工作站与HP BASIC-UX”我不确定是否有其他编译器可用。
我正在为我的HP 8720D编写一些软件 - 我昨晚读了一些合理的数字，并且今天会更加努力。
不用说我不是*使用BASIC。
我正在使用C - 或许有人认为Agilent VEE或Labview会更好，但它们不是免费的，而我的开源C compier（gcc）是！
甚至我的操作系统（Solaris）都是免费的。
实际上，自Oracle收购Sun以来，Solaris不再免费，但我正在运行一个免费的旧版本。
*更新：似乎我错了。
HP9000系列运行HP-UX。
肯定有一个C编译器（我家里有一个旧的HP-UX盒子。）事实上，HP-UX附带了一个脑死C编译器，但它专为重建内核而设计，并且可以
不能用于一般编程。
上次我看，人们不得不为HP C编译器付钱。* DaveEdited：drkirkby于2012年10月10日凌晨3:14



     以下为原文

  > {quote:title=SOLT_guy wrote:}{quote}
> I have observed the IEEE 488.1 protocol that used the IBIC language extensively.
> 
> IBIC and C language are compatible.
> 
> When IIEEE 488.2 was developed, why did HP/Agilent primarily program the network analyzers in some form of BASIC?
> 
> What was the advantage of BASIC over C and IBIC? Why was this language given priority over other languages?
> 
> Edited by: SOLT_guy on Oct 9, 2012 9:50 PM

Just a wild guess, but HP had the 9000 series computers which I think ran BASIC. Certainly in the manual of my 8720D it lists as one of the compatible computers

"HP 9000 series 700 workstation with HP BASIC-UX"

I'm not sure if other compilers were available for it. 

I'm just in the process of writing some software for my HP 8720D - I got it reading some sensible numbers last night, and will work more on that today. Needless to say I'm *not* using BASIC. 

I'm using C - perhaps some would argue Agilent VEE or Labview would be better, but they are not free, whereas my open-source C compier (gcc)  is! Even my operating system (Solaris) is free. Actually, Since Oracle bought Sun, Solaris is no longer free, but I'm running an older version which is free. 

*UPDATE: Seems I was wrong. HP9000 series run HP-UX. There is certainly a C compiler for that (I have an old HP-UX box here at home.) In fact, there is a brain-dead C compiler included with HP-UX, but it is designed for rebuilding the kernel, and can't be used for general programming. Last time I looked, one had  to pay money for the HP C compiler.*  

Dave

Edited by: drkirkby on Oct 10, 2012 3:14 AM

'ibic'是National Instruments的“接口总线交互控制”，它不是一种编程语言，而是一种基于NI的IEEE-488驱动程序的基于命令行的接口/仪器操作的方法。
HP（以及随后的安捷伦）I / O库多年来一直包括“VISA助手”，然后是最近的“安捷伦连接专家”，它可用于交互式发送NI IBIC等命令（我想我们可能提供过）
从那之前的一个类似的基于SICL的工具）。
而HP BASIC确实是一种编程语言。
NI后来推出了LabVIEW和LabWindows编程环境，同时惠普推出了VEE可视化编程环境。
然后两家公司都参与了VXIplug＆amp; play联盟，该联盟定义了可在任何上述编程环境中使用的“VISA”I / O功能集（除了安捷伦停止开发的HP BASIC）以及更多
常见的语言，如C ++，.NET语言等。这些编程环境也支持不同类型的特定于仪器的驱动程序，但这本身就是一个完全不同的主题。
所以，我已经抛出了一些额外的历史:-)。编辑：bhokkan于2012年10月10日上午9:04



     以下为原文

  'ibic' was/is National Instruments' "Interface Bus Interactive Control", which is not a programming language but rather a means for doing command-line-based interface/instrument operations specific to NI's IEEE-488 drivers.  The HP (and then Agilent) I/O Libraries have for years included the "VISA Assistant" and then more recently the "Agilent Connection Expert" which can be used to interactively send commands like NI IBIC does (and I think we might have offered a similar SICL-based tool since before that).

Whereas HP BASIC is truly a programming language.  NI later came out with the LabVIEW and LabWindows programming environments while HP introduced the VEE visual programming environment.  Then both companies got involved with the VXIplug&play alliance, which defined the 'VISA' set of I/O functions that can be used within any of the aforementioned programming environments (except HP BASIC which Agilent stopped development on) and also in the more common languages like C++, .NET languages etc.  There also also the different types of instrument-specific drivers supported by those programming environments, but that's a whole different topic in itself.  So there I've thrown in some additional history :-).

Edited by: bhokkan on Oct 10, 2012 9:04 AM

亲爱的Bhokkan;
谢谢您的回复。
BASIC比C语言和C ++语言有什么优势吗？
或是BASIC被使用，因为它是最初的惠普平台？
顺便说一下“仪器专用驱动器”的主题，目前是否有可编程测试系统可以进行“真正的”并行测量，即在精确的瞬时时间内进行多次测量，另一种测量
正在制作（测量之间没有时间延迟）？



     以下为原文

  Dear Bhokkan;

    Thank you for your reply.    

     Does BASIC have any advantages over C language and C++ language?

     Or was BASIC utilized because it was the original HP platform?

     By the way on the subject of "instrument specific drivers", is there currently a programmable test system in operation that can make "true" parallel measurements, in the sense that more than one measurement is made at the exact, instantaneous time, another measurement is being made (no time delay between measurements)?

> {quote：title = SOLT_guy写道：} {quote}>我喜欢C比BASIC的不同风格好多了。
它更易于使用，开发环境更好。
> {quote：title = SOLT_guy写道：} {quote}> BASIC是否比C语言和C ++语言有任何优势？
>或者BASIC被使用是因为它是最初的惠普平台？
我认为在很多情况下，个人对编程语言的偏好可以通过人们首先学会编程的语言来着色。
在我的情况下，我的第一堂课是在我大约12岁的时候在BASIC（在Commodore上，或者也许是Apple 2e，那是我的日期）。
所以后来当我在大学读完第一个C课程时，C起初感觉更难（处理指针之类的东西）。
但后来我开始欣赏C（以及后来的C ++）并开始喜欢它们。
所以我的猜测是惠普与BASIC一起认为它更加平易近人，尽管我认为C在1970年代后期获得了接受;
但那时候我还在上小学，所以也许有些人可能会长时间参与。> {quote：title = SOLT_guy写道：} {quote}>顺便提一下“仪器专用司机”的主题，目前是否有
一个可操作的可编程测试系统，可以进行“真正的”并行测量，即在精确的瞬时时间内进行多次测量，还会进行另一次测量（测量之间没有时间延迟）？
我认为这取决于你所认为的“测试系统”。
如果您正在考虑多种仪器，那么控制器可以触发一台仪器开始进行测量，然后另一台仪器（在相同的I / O总线或不同总线上）也可以在第一台仪器仍在测量时进行测量
，然后轮询每个仪器以检测它们各自或两者何时完成。
但是，如果你在谈论一个单一的乐器，我会推荐像Dr_joel这样的人在他的知识基础广泛的情况下回答这个问题。



     以下为原文

  > {quote:title=SOLT_guy wrote:}{quote}
> I like C so much better than the different flavors of BASIC. It is easier to use and the development environment is better.

> {quote:title=SOLT_guy wrote:}{quote}
> Does BASIC have any advantages over C language and C++ language?
> Or was BASIC utilized because it was the original HP platform?
I think that in many cases personal preference of programming language can be colored by what language the person first learned to program with.  In my case, my first class was in BASIC when I was about 12 (on a Commodore or maybe an Apple 2e, that dates me).  So later when I had my first C course in college, C felt more difficult to me at first (dealing with pointers and the like).  But then I developed appreciation for C (and later C++) and began to prefer them.  So my guess is HP went with BASIC on the perception it was more approachable, even though I think C was gaining acceptance by that time in the late 1970's; but I was still in grade school back then so perhaps someone who's been around longer might chime in.

> {quote:title=SOLT_guy wrote:}{quote}
>      By the way on the subject of "instrument specific drivers", is there currently a programmable test system in operation that can make "true" parallel measurements, in the sense that more than one measurement is made at the exact, instantaneous time, another measurement is being made (no time delay between measurements)?
I think that depends on what you're thinking of as a "test system".  If you're thinking of multiple instruments, then yes a controller can trigger one instrument to begin making a measurement, and then another instrument (on same I/O bus or different bus) to also make a measurement while the first instrument is still measuring, and then poll each instrument to detect when they each or both have finished.  But if you're talking about a single instrument, I'd defer to someone like Dr_joel to answer that given the breadth of his knowledge base.

亲爱的Bhokkan;
谢谢您的回复。
你的陈述肯定有一点道理：“我认为，在很多情况下，编程语言的个人偏好可以通过人们最初学习编程的语言来着色。”
我绝对同意你的意见。
关于我的问题：“......目前正在运行的可编程测试系统可以进行”真正的“并行测量，在精确的瞬时时间内进行多次测量，正在进行另一项测量
（测量之间没有时间延迟）？我相当肯定，通常，当我们编写程序时，指令是关于对测试仪器进行操作而串行执行的。执行一条指令然后按顺序执行另一条指令（如果我是，请纠正我）
在我原来的问题中我指的是多个乐器，经过一些思考这个问题之后，我意识到编程，类似“多任务”功能，驱动程序和控制器都必须在操作方面进行整合。
完成任务。我意识到“多任务处理”可能是错误的表达，因为在双重，即时，操作方面可能存在固有的延迟。我意识到FPGA硬件和s
软件解决方案可能是我的问题的答案。
我只是想知道安捷伦是否开发了一个测试系统（可能与NI或其他供应商合作），可以立即同时向测试仪器（多个）发送命令，以便多次测量显示没有延迟？
有没有开发过这种类型的系统？



     以下为原文

  Dear Bhokkan;

     Thank you for your reply.

      There is definitely a grain of truth to your statement:

"I think that in many cases personal preference of programming language can be colored by what language the person first learned to program with."

      I definitely agree with your there.   

      With regard to my question:

"...  is there currently a programmable test system in operation that can make "true" parallel measurements, in the sense that more than one measurement is made at the exact, instantaneous time, another measurement is being made (no time delay between measurements)?

       I am fairly certain that, genearally, when we write programs, the instructions are executed in series with regard to operating upon the test instruments. One instruction is executed and then another sequentially (correct me if I am wrong).     I was referring to multiple instruments in my original question and after some thought about this question I realize that programming, something like a "multi-tasking" function, driver, and controller must all be integrated, in terms of their operation to accomplish the task.  I realize that "multitasking" may be the incorrect expression because there may be inherent latency with regard to dual, instantantaneous, operations.

        I realize that the FPGA hardware and software solution may be the answer to my question.    I was just wondering whether Agilent has developed a test system (possibly in cooperation with National Instruments, or some other vendor) that can send commands to test instruments (more than one), instantly and simultaneously, so that the multiple measurement show no latency?  Has any system of this type been developed?

SOLT_guy，根据您的进一步描述，我相信您正在描述多个仪器的同步测量触发，这通常通过将触发驱动信号路由到您想要触发的所有仪器的后面板外部触发输入来实现。
您将首先以顺序方式向每个仪器发送一些命令，以使它们进入外部触发模式。
然后手动或以编程方式提供驱动信号以开始测量。
这基本上是例如当PNA被指示控制外部源并外部触发它时，PNA将其测量接收器与外部源同步。



     以下为原文

  SOLT_guy,

From your further description I believe you're describing simultaneous measurement trigger of multiple instruments, which is typically accomplished by routing a trigger drive signal to the rear-panel external trigger input of all the instruments you wish to trigger.  Where you would first send some commands in sequential manner to each instrument to put them into external trigger mode.  Then manually or programmatically provide the drive signal to begin the measurements.  This is basically how for example the PNA synchronizes it's measurement receivers with an external source when the PNA is instructed to control the external source and external-trigger it.

亲爱的Bhokkan;
非常感谢你的回复。
我刚刚购买了一个软件产品（LABVIEW），声称“并行”可以回答我自己的问题。
我很抱歉没有及早回复这篇文章。
我最近很忙。
也许，这将是我的解决方案。
我想感谢你的回复，如果你愿意，我可以告诉你我发现了什么（我相信回馈讨论）。
实验结果可能会在几个月后完成。
我还没有收到邮件中的产品。
如果您想阅读我发现的内容，请告诉我。
再次感谢您的反馈。
很感激。



     以下为原文

  Dear Bhokkan;

     Thank you so much for your reply.

      I just purchased a software product (LABVIEW) which claims "parallelism" which may answer my own question.   I apologize for not replying to this post sooner.  I have been very busy.

      Maybe, this will be my solution.   I would like to thank you for your reply and if you would like I can keep you informed about what I have found (I believe in giving back to the discussion).    The experimental results will probably be made many months from now.  I haven't even received the product in the mail yet.   Let me know if you would like to read what I have found.  Again, thank you for your feedback.  It was appreciated.

亲爱的柯比博士;
谢谢您的回复。
我喜欢C比BASIC的不同口味更好。
它更易于使用，开发环境更好。
顺便说一句，我下载了一个C编译器免费软件程序，但我放弃了使用该语言。
您可以使用Microsoft的免费Visual C ++包运行C程序。
开发环境更易于使用。
你应该试一试。
由于缺少文档，因此很难开始使用Visual C ++环境。
但是一旦开始使用它就会容易得多。
那么，你使用你的C代码和编译器来调用* .dll库吗？



     以下为原文

  Dear Dr. Kirby;

      Thank you for your reply.

      I like C so much better than the different flavors of BASIC.   It is easier to use and the development environment is better.

      By the way, I downloaded a C compiler freeware program but I abandoned using the language.

       You can run C programs with Microsoft's free Visual C++ package.   The development environment is easier to use.  You should give it a try.
Getting started in the Visual C++ environment is difficult because of the lack of documentation.  But once you get started it is much easier to use.

       By the way, do you use your C code and compiler to call *.dll libraries?

> {quote：title = SOLT_guy写道：} {quote}>亲爱的柯比博士;
>谢谢你的回复。
>我喜欢C比BASIC的不同口味更好。
它更易于使用，开发环境更好。
是的，C是一种很好的语言。
尽管C ++应该是一个优势，但在我看来它有太多的缺点，尽管我应该更好地学习C ++。
>顺便说一句，我下载了一个C编译器免费软件程序，但我放弃了使用该语言。
什么一个？
我假设它可能基于GNU C编译器GCC，这是一个命令行工具 - 没有图形用户界面。
但我怀疑至少有一个用于Windoze的GUI。
>您可以使用Microsoft的免费Visual C ++包运行C程序。
开发环境更易于使用。
你应该试一试。
由于缺少文档，因此很难开始使用Visual C ++环境。
但是一旦开始使用它就会容易得多。
那么，你使用你的C代码和编译器来调用* .dll库吗？
我在Windoze下做的编程非常少 - 我非常喜欢Unix。
如果我要写一个Windoze程序，我可能会使用Qt工具包，因为它具有可移植性。
我目前正在运行Solaris 10的Sun Blade 2000工作站上编写8720D VNA的代码。这台机器有一个SPARC处理器，因此无法运行任何版本的Windoze。
我正在编写代码来生成.s2p文件。
我不是按照你的意思使用“开发环境”。
我只是用vi编辑器编写文本文件，然后用gcc编译它们。
如有必要，我用gdb调试它们。
虽然这个Sun是一个工作站，拥有相当不错的显卡，但我实际上是将它作为服务器运行，没有连接键盘或鼠标 - 只是一个以太网连接。
我从Sun Ultra 27工作站（这是我常用的计算机）访问它，它运行OpenSolaris，或者偶尔从Windoze 7笔记本电脑运行。
代码可以很容易地重新编译以与Linux一起工作，老实说，这对于它来说是一个更合理的平台，但我碰巧在其中设置了带有GP-IB板的SPARC机器，所以我正在使用它。
代码可能也会在Windoze上重新编译，但是由命令行驱动，不会吸引许多Windoze用户。
Solaris有一段奇怪的历史。
*首先是商业广告。
* Solaris 7几乎免费。
媒体和许可证的名义费用。
*然后它是半自由的，即使是商业用途。
*它是半自由的，但有更多的限制，主要取决于机器可以拥有的CPU插座数量 - 无论实际安装了多少CPU。
我认为你最多允许8个CPU。
*然后它变得完全自由，但仍然是封闭源。
*然后Sun开源99％的Solaris - 他们都可以，因为有些部分不属于Sun，但是Sun支付了许可证。
这被称为OpenSolaris，这是我在我的主桌面计算机上运行的（Sun Ultra 27，带有四核Xeon处理器）。
*然后甲骨文收购了Sun，停止了OpenSolaris的开发，现在Solaris不再免费用于“生产”，但是可以免费用于开发目的 - 甚至是商业开发。
根据月亮的相位和金星的位置，Sun经常免费提供Solaris媒体，但在其他时候你需要支付运费。
（他们关于自由媒体的政策似乎随机变化，但它一直是，现在仍然是免费下载）。
但正如我所说，自从甲骨文收购Sun以来，它不再合法免费用于生产，尽管与Windoze不同，没有激活码 - 甲骨文依赖你的诚实。
因此，我可能没有按照您的期望进行操作，但我可以使用C代码轻松地从VNA获取数据，使用“ibwrt”等使用命令的National Instruments卡来写入数据，使用“ibrd”来读取数据。
作为命令行驱动，没有GUI，如果我愿意，它很容易编写脚本。
我使用相同的技术从HP 70000系列频谱分析仪，HP 8970A噪声系数仪和HP 3457A万用表中读取数据。
如果我为没有GP-IB的N9923A编写代码，那么我可能会考虑获得一个LAN GP-IB板。
NI有一个，但我不确定安捷伦。
戴夫。



     以下为原文

  > {quote:title=SOLT_guy wrote:}{quote}

> Dear Dr. Kirby;
>       Thank you for your reply.
>       I like C so much better than the different flavors of BASIC.   It is easier to use and the development environment is better.

Yes, C is a nice language. Even though C++ is supposed to be an advantage, it appears to me to have too many disadvantages, though I should get around to learning C++ better. 

>       By the way, I downloaded a C compiler freeware program but I abandoned using the language.

What one? I assumed it was probably based on the GNU C compiler GCC, which is a command line tool - no graphical user interface. But I suspect there is at least one GUI for Windoze. 

>        You can run C programs with Microsoft's free Visual C++ package.   The development environment is easier to use.  You should give it a try. Getting started in the Visual C++ environment is difficult because of the lack of documentation.  But once you get started it is much easier to use.  By the way, do you use your C code and compiler to call *.dll libraries?

I do very little programming under Windoze - I'm very much a Unix person. If I was to write a Windoze program, I'd probably use the Qt toolkit, due to its portability. 

I'm currently writing the code for my 8720D VNA on a Sun Blade 2000 workstation running Solaris 10. This machine has a SPARC processor, so could not run any version of Windoze. I'm writing the code to produce .s2p files. I don't use a "development environment", in the way you mean. I simply write text files with the vi editor, and compile them with gcc. If necessary I debug them with gdb. 

Although this Sun is a workstation, with a fairly good graphics card, I am actually running it as a server, with no keyboard or mouse attached - just an ethernet connection. I'm accessing it from my Sun Ultra 27 workstation (which is my usual computer), which runs OpenSolaris, or occasionally from a Windoze 7 laptop. 

The code could easily be recompiled to work with Linux, which to be honest would be a more sensible platform for it, but I happen to have the SPARC machine set up with a GP-IB board in it, so I'm using it. The code would probably recompile on Windoze too, but being command line driven, would not appeal to many Windoze users. 

Solaris has a bit of a strange history. 

* First it was commercial. 
* Solaris 7 became almost free. There was a nominal charge for the media and license. 
* Then it was semi-free, even for commercial use. 
* Them it was semi-free, but had more restrictions, primarily on the number of CPU sockets the machine could have - irrespective of how many CPUs one actually had fitted. I think you were allowed up to 8 CPUs. 
* Then it became totally free, but remained closed-source.  
* Then Sun open-source 99% of Solaris - all they could, as some parts did not belong to Sun, but Sun paid licenses for. This was known as OpenSolaris, which is what I run on my main desktop machine (a Sun Ultra 27, with a quad core Xeon processor). 
* Then Oracle bought Sun, stopped development of OpenSolaris, and now Solaris is no longer free for "production" use, but is free for development purposes - even commercial development. 

Depending on what the phase of moon was, and the position of Venus, Sun would often ship Solaris media free, but at other times you needed to pay the carriage charge. (Their policy on free media seemed to change seeminly randomly, but it was been, and still is a free download). But as I said, since Oracle bought Sun, it is no longer legally free for production use, although unlike Windoze, there is no activation codes - Oracle rely on your honesty. 

So I'm probaby not doing what you expect, but I can get the data from the VNA quite easily using C code, with a National Instruments card using the using commands like 'ibwrt' to write data and 'ibrd' to read it. Being command line driven, with no GUI, it is very easy to script if I want to. I've used the same techniques to read from an HP 70000 series spectrum analyzer, HP 8970A noise figure meter and an HP 3457A multi-meter. If I write code for my N9923A, which has no GP-IB, then I'll probably look at getting a LAN GP-IB board. National Instruments make one, but I'm not sure about Agilent. 

Dave.

> {quote：title = drkirkby写道：} {quote}>如果我为没有GP-IB的N9923A编写代码，那么我可能会考虑获得一个LAN GP-IB板。
我不认为购买LAN-to-GPIB设备与N9923A一起使用是有意义的。
LAN-to-GPIB是一种GPIB控制器，用于* *具有GPIB端口的仪器，您的PC或工作站通过LAN控制LAN-to-GPIB设备（因此可能远离该设备和仪器）
）。
当/如果您为N9923A编写代码时，当您向I / O库指定该仪器的I / O地址时，地址字符串将指示您正在打开SCPI-LAN类型的会话，而不是SCPI-GPIB
。
完全没有涉及物理GPIB。
但是你的PC或工作站当然仍然可以远离N9923A。



     以下为原文

  > {quote:title=drkirkby wrote:}{quote}
> If I write code for my N9923A, which has no GP-IB, then I'll probably look at getting a LAN GP-IB board.
I don't think procuring a LAN-to-GPIB device would make sense to use with your N9923A.  A LAN-to-GPIB is a GPIB controller used with instruments that *do* have a GPIB port, where your PC or workstation controls the LAN-to-GPIB device via LAN (and so can be far away from that device and the instrument).  When/if you write code for your N9923A, when you specify to your I/O libraries the I/O address of that instrument, the address string would indicate you're opening a SCPI-LAN type of session, rather than SCPI-GPIB.  No physical GPIB involved at all for that.  But your PC-or-workstation could of course still be located far away from the N9923A.

> {quote：title = bhokkan写道：} {quote} >> {quote：title = drkirkby写道：} {quote} >>如果我为我的N9923A编写没有GP-IB的代码，那么我可能会看一下
获得LAN GP-IB板。
>我不认为购买LAN-to-GPIB设备与N9923A一起使用是有意义的。
不，当然你是对的 - 当我写这篇文章的时候，我不知道我在想什么。
我很清楚N9923A没有GPIB。
但我正在考虑为我拥有的具有GPIB的仪器获取一个基于LAN的GP-IB控制器。
我正在运行Sun工作站以提供GP-IB功能。
这就是机器正在做的事情。
看起来很奇怪，但我的房子/车库里必须有20台计算机，但除了太阳之外没有其中一台SPARC CPU在运行我的基于PCI的GP-IB板时非常实用。
我运行Linux的基于Xeon的服务器太吵了。
我的笔记本电脑不能拿PCI卡，并且试图将PCI卡插入我妻子的iPad已经证明是不成功的！
我可以安装GP-IB板的唯一一台计算机是带有Xeon处理器的Sun，但是在OpenSolaris上没有我的GPIB板的驱动程序，我没有在Sun上安装Linux或Windows的意图。
所以现在，我将使用Sun SPARC工作站，但是获得基于LAN的GP-IB板将会有所作为。
它会比太阳小得多，耗电量远低于太阳。
另一个（更便宜的）选择是获得一台非常小的PC并在其上安装Linux。
我不知道我是否会编程N9923A。
我目前没有看到任何需要，但也许我会找到一个。
我不认为我已经看过它的编程手册，但也许有一本。
人们为他们编程的原因是什么？
我更多地将其视为现场工具，其中一个人收集数据并稍后在计算机上对其进行后处理。
但对于较旧的HP 8720D VNA，拥有与之通信的软件非常重要，否则从中移动数据的唯一方法是通过软盘，这不是很明智。
戴夫



     以下为原文

  > {quote:title=bhokkan wrote:}{quote}
> > {quote:title=drkirkby wrote:}{quote}
> > If I write code for my N9923A, which has no GP-IB, then I'll probably look at getting a LAN GP-IB board.
> I don't think procuring a LAN-to-GPIB device would make sense to use with your N9923A.  

No, of course you are right - I don't know what I was thinking when I wrote that. I'm well aware the N9923A has no GPIB. 

But I am thinking of getting one of the LAN-based GP-IB controllers for the instruments I own which do have GPIB.  At the minute I'm running a Sun workstation to provide the GP-IB functionality. That's all the machine is doing.  

Strange as it might seem, but there must be 20 computers in my house/garage, but not one of them apart from the Sun with the SPARC CPU is really practical to run my PCI based GP-IB board. My Xeon-based servers, which run Linux, are far too noisy. My laptops can't take PCI cards and attempts to fit the PCI card into my wife's iPad have proved unsuccessful! 

The only computer I have which I could install the GP-IB board in is a Sun with a Xeon processor, but there are no drivers for my GPIB board on OpenSolaris, and I have no intension of installing Linux or Windows on that Sun. So for now, I'll use the Sun SPARC workstation, but getting a LAN based GP-IB board would make sence. It will be far smaller, and consume far less power than the Sun. Another (cheaper) option is to get a very small PC and install Linux on it. 

I don't know whether I will ever program the N9923A. I don't currently see any need, but perhaps I will find one. I don't think I've seen a programming manual for it, but perhaps there is one. What sort of reasons do people program them? I see it more as a field instrument, where one gathers data and post-processes it later on a computer. 

But for the older HP 8720D VNA, having software to communicate with it is pretty essential, as otherwise the only way to move data from it is via a floppy disk, and that's not very sensible. 

Dave

要迁移，sourceId：104378



     以下为原文

  to be migrated, sourceId: 104378

> {quote：title = bhokkan写道：} {quote} >> {quote：title = drkirkby写道：} {quote} >>但我想为我拥有的乐器获得一个基于LAN的GP-IB控制器
哪个有GPIB。
>您可以考虑使用USB-to-GPIB（例如Agilent 82357B或使用过的82357A），因为它们的成本较低，可以与您的笔记本电脑或任何带USB的PC一起使用。
我相信有那些Linux驱动程序。
您可以对这些型号进行网络搜索以获取更多信息。
谢谢，但能够从仪器远程编程的想法吸引了我，所以局域网对我来说比USB更具吸引力。
但是正如你所注意到的，USB比LAN便宜，但我宁愿坚持使用它的GP-IB板的Sun工作站，而不是使用USB设备。
对我来说，关于Linux的一个令人烦恼的事情是向后兼容性很差。
什么适用于版本N，通常无法在N + 1版本上工作。
一旦像USB - > GP-IB适配器失去了支持，人们可能会发现它非常无用，除非运行旧版本的Linux。
这是我宁愿不买USB设备的另一个原因。
相比之下，基于LAN的设备是独立于操作系统的。
这与Solaris有很大的不同，Solaris具有出色的向后兼容性。
我可以从15岁的Solaris版本中获取二进制文件，它将在最新的Solaris版本上运行。
你根本无法用Linux做到这一点。
我花了一些时间开发Sage开源数学软件。
http://www.sagemath.org/我花费的时间比以前少得多，但我完成了将Sage移植到Solaris的95％的工作。
我注意到，由于不同Linux版本和发行版的差异，很大一部分开发人员时间似乎用于修复问题。
我认为Sage的部分问题在于编码的质量 - 由数学家完成，其中许多人对计算知之甚少，并编写了一些非常糟糕的代码。
但我认为这是Linux的普遍问题。
我想你可以用我通常拼写的方式来猜测我对微软Windows的看法（Windoze）！
戴夫



     以下为原文

  > {quote:title=bhokkan wrote:}{quote}
> > {quote:title=drkirkby wrote:}{quote}
> > But I am thinking of getting one of the LAN-based GP-IB controllers for the instruments I own which do have GPIB.
> You might consider a USB-to-GPIB (such as the Agilent 82357B or a used 82357A) as they're less costly, to use with your laptop or any PC you have which has USB.  I believe there are Linux drivers for those.  You could do a web search on those model numbers for more information.

Thank you, but the idea of being able to program remotely from the instrument attracts me, so LAN is more attractive to me than USB. But as you note, USB is cheaper than LAN, but I'd rather stick with my Sun workstation with it's GP-IB board, than use a USB unit. 

One of the annoying things to me about Linux is the very poor backward compatibility. What works on version N, will often fail to work on verson N+1. Once something like a USB -> GP-IB adapter drops out of support, one is likely to find it pretty useless unless one runs an old version of Linux. That's another reason I'd rather not buy a USB device. In contrast, a LAN based device is operating system independant. 

This contrasts very much with Solaris, where there is excellent backward compatibility. I can take a binary from a 15 year old version of Solaris and it will run on the latest Solaris release. You simply can't do that with Linux.
I spend some of my time developing the Sage open-source maths software.

http://www.sagemath.org/

I spend far less time on it than I used to, but I done 95% of the work in porting Sage to Solaris. What I notice is that a huge percentage of developer time seems to be used fixing issues due to differences in different Linux versions and distributions. 

I think part of the problem with Sage is the quality of coding - done by mathmaticians, many of whom know little about computing, and write some really poor code. But I think it's a general problem with Linux.

I think you can guess my thoughts about Microsoft Windows the way I usually spell it (Windoze)! 

Dave

Re：N9923A或FieldFox编程....我没有关于FieldFox编程人数的实际统计数据，但根据我们已经回答的编程问题的数量，这并不是无关紧要的。
一个常见的用例是N9912A的频谱分析仪，用户在一段时间内监测信号或干扰，捕获数据或触发某些事件;
远程监控很常见。
或者对于VNA（无论是N9912A还是N9923A或更新的型号），他们将其用作测试系统的一部分并使用软件控制它。
虽然FieldFox绝对是作为现场仪器设计的，但它在实验室或制造环境中工作得很好，而且价格很有吸引力，人们已经想出了:-)。



     以下为原文

  Re: N9923A or FieldFox programming ....

I don't have actual stats on how many people program a FieldFox, but based on the number of programming questions we've answered, it's not insignificant.  A common use case is the N9912A's spectrum analyzer, and users are monitoring the signal or interference over a period of time, and capturing the data, or triggering upon some event; remote monitoring is common. Or in the case of the VNA (whether with N9912A or N9923A or the newer models), they're using it as part of a test system and have software controlling it. While FieldFox is definitely designed as a field instrument, it works just fine in the lab or mfg environment, and the price is attractive, and people have figured that out :-).

> {quote：title = am95405写道：} {quote}> Re：N9923A或FieldFox编程.... >>我没有关于有多少人编程FieldFox的实际统计数据，但根据编程问题的数量我们
回答说，这并不是无关紧要的。
一个常见的用例是N9912A的频谱分析仪，用户在一段时间内监测信号或干扰，捕获数据或触发某些事件;
远程监控很常见。
我可以看到这将非常有用。
>或者对于VNA（无论是N9912A还是N9923A或更新的型号），他们将其用作测试系统的一部分并使用软件控制它。
虽然FieldFox绝对是作为现场仪器设计的，但它在实验室或制造环境中工作得很好，而且价格很有吸引力，人们已经想出了:-)。
谢谢。
我不打算在生产线或实验室中使用FieldFox。
（我有一个较旧的20 GHz 8720D供实验室使用）。
我打算几乎只在外面使用FieldFox。
也就是说，我确实需要FieldFox没有的设施，但我可以很容易地在笔记本电脑上编写程序。
遗憾的是，用户无法编写他/她自己的应用程序以在FieldFox中运行。
DaveEdited：drkirkby于2012年10月12日下午1:45



     以下为原文

  > {quote:title=am95405 wrote:}{quote}
> Re: N9923A or FieldFox programming ....
> 
> I don't have actual stats on how many people program a FieldFox, but based on the number of programming questions we've answered, it's not insignificant.  A common use case is the N9912A's spectrum analyzer, and users are monitoring the signal or interference over a period of time, and capturing the data, or triggering upon some event; remote monitoring is common.

I can see that would be very useful. 

> Or in the case of the VNA (whether with N9912A or N9923A or the newer models), they're using it as part of a test system and have software controlling it. While FieldFox is definitely designed as a field instrument, it works just fine in the lab or mfg environment, and the price is attractive, and people have figured that out :-).

Thank you. I don't intend using the FieldFox on a production line or in a lab. (I have an older 20 GHz 8720D for lab use). I intend using the FieldFox almost exclusively outside. That said, I do have a need for a facility the FieldFox does not have, but which I could write a program for on a laptop quite easily. It's a shame there is not the facility for a user to write his/her own application to run in the FieldFox. 

Dave

Edited by: drkirkby on Oct 12, 2012 1:45 PM

亲爱的AM95405和柯比博士;
我想感谢你们的投入。
我不拥有fieldfox，但我正在考虑购买一个。
它似乎是一个了不起的测试仪器。
我希望它花费少一点。
即使提供半价优惠，它也超出了大多数人的价格范围。
只有公司才能在这个价格范围内进行购买。
我不是说它不值得。
我绝不暗示这一点。
我对它能做的事情印象深刻 - 给人留下了深刻的印象。
顺便说一句，如果有人能回答这个问题。
我注意到Fieldfox上有一个LAN和USB端口。
如果要将数据流式传输到外部存储器，您是否曾测试过数据流以查看信号流数据是否中断。
大多数频谱分析仪都无法连续监听数据，你能告诉我fieldfox是否会因持续监控数据而闪烁吗？
如果它确实闪烁，你能告诉我这件事眨眼需要多长时间？



     以下为原文

  Dear AM95405 and Dr. Kirby;

     I would like to thank you both for your inputs.   

     I don't own a fieldfox but I am considering purchasing one.   It appears to be an amazing test instrument.  I wish it cost a little bit less.  Even with the half price offer, it is out of the price range for most individuals.  Only corporations can make purchases of this magnitude - in this price range.

      I am NOT saying it isn't worth.  I am by no means implying that.  I am really impressed with what it can do - really impressed.   

      By the way, if anyone can answer this question.   I noticed a LAN and USB port on the Fieldfox.   If you want to stream data to external memory, have you ever tested the data stream to see if there is a break in the signal stream data.  Most spectrum analyzers can't listen to data continuously, can you tell me if the fieldfox blinks with regard to continuously monitoring data?  If it does blink, can you tell me about how long it takes for this thing to blink?

关于fieldfox，请不要知道，但PNA有一个特殊模式调用Fast CW，它可以在测量固定频率的同时测量和传输数据。
它用于扫描天线的近场响应，而不是其他东西。
此模式下的数据速率最高为每秒400,000点。



     以下为原文

  Dont konw about fieldfox, but PNA has a special mode call Fast CW which contrinually measures and streams data while measuring a fixed frequency.  It is used for scanning the near filed response of an antenna, amoung other things.  The data rate in this mode is maximum at 400,000 points per second.

亲爱的柯比博士;
回答你的问题：“顺便说一下，我下载了一个C编译器免费软件程序，但我放弃了使用该语言。”
“什么？我认为它可能基于GNU C编译器GCC，这是一个命令行工具 - 没有图形用户界面。但我怀疑至少有一个用于Windoze的GUI。”我放弃的编译器是MingGW。
编译器在仪器控制应用程序（受保护的操作系统问题和其他问题）方面存在问题，我不想研究它们的补救措施。
由于Visual C ++可用于编译我的C代码而没有问题，并且有一个更好，更好，更好的开发环境，我选择了Visual C ++。
这是正确的选择。



     以下为原文

  Dear Dr. Kirby;

      To answer your question:

"By the way, I downloaded a C compiler freeware program but I abandoned using the language."

"What one? I assumed it was probably based on the GNU C compiler GCC, which is a command line tool - no graphical user interface. But I suspect there is at least one GUI for Windoze. "

The compiler I abandoned was MingGW.   There were issues with compiler with regard to instrument control applications (protected O/S issues, and others) that I didn't want to research for a remedy for.   Since Visual C++ can be used to compile my C code without issues and had a much, much, better development environment, I went with Visual C++.  It was the right choice.