无法通过E5805A USB转RS232与E3633A对话

我有一台运行Win XP sp3的Dell XPS 630工作站和一台Agilent E5805A USB转4端口RS232扩展器，我试图远程控制E3633A。
E5805A配置实用程序启动并识别该框，并将4个端口配置为COM3到COM6。
系统驱动程序和E5805A配置实用程序接口均指示4端口设备正常工作.Agilent Connection Expert版本15.1.12008.0将电源标识为IDN字符串：HEWLETT-PACKARD，E3633A，0,1.7-5.0-1.0。
我能够通过交互式I / O窗口发送命令和接收响应。
例如，发送“SYST：VERS？”会在显示屏中显示“1996.0”x0D»“。
使用“SYST：REM”后跟“APPL 5.0,1.0”，可以获得在5 V和1 A时激活的功率显示输出，如预期的那样。
发送“* TST？”会得到“+ 0«x0D»”的回复。
发送远程系统后，前面板应该被禁用。但是，“OUTP OFF”似乎没有做任何事情。
“* RST”确实起作用，这将允许我超越系统中输出关闭命令的失败。在我的应用程序中，我使用Willies计算机软件公司的旧版Windows API通信库，COMM-DRV / Lib。
基于C。
我的应用程序开发是Visual Studio 2008中的C ++，我在三个或四个其他项目中使用过的组合，以及一个总能完美运行的组合。
它的调用是在应用程序内报告良好的串行通信配置。
comm库初始化参数是：BAUD9600，PAR_NONE，LENGTH_8，STOPBIT_2，PROT_DTRDTR ...这些是不言自明的，它们与手册页面64的表格参数和电源设置相匹配。
电源前面板上的I / O配置按钮显示9600 BAUD和NONE 8 BITS，设备手册的第66页告诉我握手设置为DTR + DSR，这是comm库的“PROT_DTRDTR”选项选择的
。
但是，我还尝试了COMM-DRV / Lib的PROT_NONDTR选项，该选项选择远程设备DTR + DSR协议，但在计算机端没有。
两种选择的结果相同。
单个起始位是RS232C标准，既不能在电源上配置，也不能在通信库中配置。当我通过通信库RS232接口发出ASCII字符串时，只有“SYST：REM”无法在电源侧产生错误
。
“SYST：VERS？”开启了电源的ERR指示灯。
“APPLY 5.0,1.0”和“OUTP ON”也是如此。
从前面板中插入该错误会显示错误-113，“Undefined Header”。
这个错误的描述提到了不正确的短命令形式作为一个可能的问题...所以我尝试了完整的命令，如“SYSTem”和“APPLy”。
这些不会产生任何错误......但根本不会发生任何事情。
在任何情况下都没有对任何interogation命令的响应。很明显，我在设置中遗漏了一些东西，或者通信库和Agilent E5805A之间存在问题。
我也在调查。
有什么突出的东西在这里突出？



     以下为原文

  I have a Dell XPS 630 workstation running Win XP sp3 and an Agilent E5805A USB  to 4-port RS232 extender through one port of which I’m trying to remotely control an E3633A. The E5805A configuration utilities come up and identify the box and have configured the 4 ports as COM3 through COM6. System driver and E5805A configuration utility interfaces both indicate the 4-port device is working properly.

Agilent Connection Expert Version 15.1.12008.0 identifies the power supply as IDN string: HEWLETT-PACKARD,E3633A,0,1.7-5.0-1.0 . I’m able to send commands and receive responses with the interactive I/O window. Sending “SYST:VERS?” for example, gets me “1996.0«x0D»” in the display. Using “SYST:REM” followed by “APPL 5.0 , 1.0” gets me the power display output activated at 5 v and 1 A, as expected. Sending “*TST?” gets me a response of “+0«x0D»” . After sending the system remote the front panel is disabled as it should be.

However, “OUTP OFF” doesn’t seem to do anything.  “*RST” does function, which would allow me to overstep the failure of the output off command in my system.
In my app I’m using an older windows API communications library from Willies Computer Software Company, COMM-DRV/Lib. C based. My application development is C++ in Visual Studio 2008, a combination I’ve used on three or four other projects, and one that’s always worked flawlessly. Its calls are reporting good serial communications configuration within the app. The comm library initialization parameters are:

BAUD9600,PAR_NONE,LENGTH_8,STOPBIT_2,PROT_DTRDTR

… which are self-explanatory and which match the parameters of the table of page 64 of the manul plus the power supply settings. The I/O Config button on the supply front panel shows me 9600 BAUD and NONE 8 BITS, and page 66 of the device manual tells me that the handshaking is set to DTR+DSR, which is what the comm library’s “PROT_DTRDTR” option selects. However, I’ve also tried COMM-DRV/Lib’s PROT_NONDTR option, which selects remote device DTR+DSR protocols but none at the computer’s end. The results are the same for both choices. The single start bit is an RS232C standard and is configurable neither on the power supply nor within the communications library.

When I issue ASCII strings via the communications library RS232 interface, only “SYST:REM” fails to generate an error on the power supply side. “SYST:VERS?” kicks the power supply’s ERR light on. So do “APPLY 5.0 , 1.0” and “OUTP ON”.  Interogating that error from the front panel shows me an error -113, “Undefined Header”. The description of this error mentions incorrect short forms of commands as a possible problem… so I tried complete commands like “SYSTem” and “APPLy”. These don’t generate any errors… but neither does anything happen at all. There is no response to any interogation command in any case.

Clearly, either I’ve missed something in the setup or there’s a problem between the communications library and the Agilent E5805A. I’m looking into that too. Anything obvious stand out here?