我之前发布了一个关于我在涉及8753ES网络分析仪的测试设置中遇到的问题的问题。
我注意到在测试数千个模具时,该装置会间歇性地冻结。
经过一些测试运行后,我发现8753ES在循环的16,384次迭代后会失败。
在某些情况下,确实那么多,比那少一百左右。
该循环由4个子组成:1)a)MARK1的GPIB写入; CAL1; CORR OFF;
1b)POIB的GPIB写__; POWE __; CENT __; SPAN__;
1c)S21的GPIB写入; LOGM; IFBW __; TRACK ON; CORR ON;
2)a)GPIB写入* OPC ?; SING;
2b)15毫秒等待,2c)GPIB读取10个字节和长超时(10分钟 - 以便我的NI间谍捕获没有填充失败的读取),3)a)GPIB写入CORR ON; MARKCENT;
SPAN __; IFBW __; POIN __;
4)a)GPIB写入* OPC ?; SING;
4b)一个15毫秒的等待,4c)一个GPIB读取10个字节和一个长的超时(10分钟 - 这样我的NI Spy捕获没有填充失败的读取),这是发生的事情:1)当我用这些运行循环时
4个子系统,用* RST命令启动它并调用校准状态:•在16,200或16,300次迭代后,它将像钟表机构一样失效。
•有一次,它恰好是16,384次迭代。
•对于任何GPIB命令以及除
电源按钮或本地然后预设硬键之外的任何前面板控件,它都不会响应。
2)当我进入网络分析仪并手动预设时,调用校准,并设置IFBW,点数,功率,中心和跨度,然后仅运行第2(或第4,它们完全相同)subvi -
写一个* OPC; SING;
并等待读取“1” - 在一个while循环中:•它运行不会超过40,000次迭代。
•网络分析仪未以任何方式锁定或无响应。
所以这里有我的问题:1)8753ES网络分析仪中是否有一些内存单元或分区正好是16kbits,32kbits,16kbytes或32kbytes,这些都被我发送的命令填满了?
2)此代码的某些部分是否写得不正确会导致此周期性故障?
3)定期发送PRES;
命令(然后调用校准文件)不能防止这种失败,但是发送* RST命令可以解决这个问题吗?
谢谢,即使您不知道答案,我也非常感谢您对此问题的任何见解。
编辑:Cheenu于2013年1月31日下午6:29编辑:Cheenu于2013年1月31日下午6:30
以上来自于谷歌翻译
以下为原文
I
previously posted a question about issues I was having with a test setup involving the 8753ES network analyzer. I noted that the unit would intermittently freeze up when tes
ting thousands of dies.
After some test runs, I figured out that the 8753ES would fail after 16,384 iterations of a loop. In some cases exactly that much, in some a hundred or so less than that.
The loop consists of 4 subvi’s:
1) a) A GPIB Write of MARK1;CAL1;CORR OFF;
1b) A GPIB Write of POIN __;POWE __;CENT __;SPAN__;
1c) A GPIB Write of S21;LOGM;IFBW __;TRACK ON;CORR ON;
2) a) A GPIB Write of *OPC?;SING;
2b) A 15msec wait,
2c) A GPIB Read with 10 bytes and a long timeout (10 minutes – so that my NI Spy capture isn’t filled with failed reads),
3) a) A GPIB Write of CORR ON;MARKCENT;SPAN __;IFBW __;POIN __;
4) a) A GPIB Write of *OPC?;SING;
4b) A 15msec wait,
4c) A GPIB Read with 10 bytes and a long timeout (10 minutes – so that my NI Spy capture isn’t filled with failed reads),
Here’s what happens:
1) When I run the loop with these 4 subvi’s, starting it off with an *RST command and recalling the calibration state:
• It will fail, like clockwork, after 16,200 or 16,300 iterations.
• One time, it was exactly 16,384 iterations.
• It will be unresponsive to any GPIB commands, and
any front panel controls except for the power button, or Local then Preset hardkeys.
2) When I go the network analyzer and manually preset, recall the calibration, and set the IFBW, number of points, power, center,
and span and then run
only the 2nd (or 4th, they are exactly the same) subvi – the one which writes *OPC;SING; and
waits to read the “1” -- in a while loop:
• It runs without failing for more than 40,000 iterations.
• The network analyzer is not locked up or unresponsive in any way.
So here are my questions:
1) Is there some memory unit or partition in the 8753ES network analyzer which is exactly
16kbits, 32kbits, 16kbytes, or 32kbytes large that’s getting filled up by the commands I’m sending?
2) Is there some part of this code which is written incorrectly which would cause this periodic failure?
3) Periodically sending the PRES; command (and then recalling the calibration file) doesn’t work
to prevent this failure, but would sending the *RST command do the trick?
Thanks, and I would appreciate any insight any of you might have about this problem, even if you don’t know the answer.
Edited by: Cheenu on Jan 31, 2013 6:29 PM
Edited by: Cheenu on Jan 31, 2013 6:30 PM