是德科技
直播中

陈鹏

7年用户 222经验值
私信 关注
[问答]

8753ES是16kbit,16kbyte,32kbit还是32kbyte内存分区?

我之前发布了一个关于我在涉及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; SI​​NG;
并等待读取“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 testing 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  

回帖(4)

陈鹏

2019-4-18 15:26:15
另一个问题:可以增加CORR ON;
在第四个subv导致周期性失败?
我应该注意到我正在使用488.2 GPIB写入和读取。
此外,我已关闭自动停止。
此外,我有针对失败运行的NI Spy捕获 - 导致锁定的特定命令是* OPC之后的GPIB读取?; SING;
GPIB写命令。

以上来自于谷歌翻译


     以下为原文

  One other question:  could the additional CORR ON; in the 4th subvi be causing the periodic failure?

I should note that I am using 488.2 GPIB Write and Read.  Also, I have turned off autopolling.  Further, I have NI Spy captures for the failing runs -- the specific command which causes the lockup is the GPIB Read immediately after the *OPC?;SING; GPIB Write command.
举报

孔德羲

2019-4-18 15:42:14
引用: 瓦德瓦155 发表于 2019-4-18 20:00
另一个问题:可以增加CORR ON;
在第四个subv导致周期性失败?
我应该注意到我正在使用488.2 GPIB写入和读取。

首先要记住的是:8753是在现代计算机普及之前设计的。
它本质上具有用于CPU的洗衣机控制器。
第二,事情,如果有固件问题,它永远不会被修复。
我甚至不确定固件构建系统是否已经存在。
第三,当你询问开启/关闭校正时,我认为你走在正确的轨道上。
我想知道你为什么这样做(打开和关闭),而不是只是打开它。
在8753中,它是第一个使用共享内存进行校准的VNA,这意味着,如果你保存了一个带校准的状态,然后改变了一些东西(标记,显示的痕迹)并再次保存,那么它就不会保存两份
校准,但指向常见校准集的校准。
要知道什么时候它可以吹走一个校准集,它将保留已分配了多少保存/调用状态的计数器。
我猜,(这只是一个猜测)打开和关闭校准可能会影响使用校准次数的次数,当你将其打开16K次时,则会超出14位数。
我想我们可以去2 ^ 15(有一点符号)但也许其他东西加倍数字(例如2个通道)。
还有其他事情以类似方式失败。
如果计数变为负数,固件会说“吹掉卡路里,不需要它”,但你仍然需要它。
所以,事情就会迷失。
因此,如果您需要使用和不使用cal进行测量,为什么不设置2个通道并相应地触发它们。
编程8753的艺术正在弄清楚哪些解决方法可以使用它。

以上来自于谷歌翻译


     以下为原文

  First thing to remember: 8753 was designed before modern computers were common.  It has, essentially, a washing machine controller for a CPU.

Second, thing, if there is a firmware problem, it's never gonna be fixed.  I'm not even sure the firmware build system is around any more.  

Third, I think you're on the right track when you ask about turning correction on/off.  I wonder why you do that (turn it on and off), rather than just leave it on.  In the 8753, it was the first VNA to use shared memory for calsets, which means, if you had saved a state with a calibration, then changed some things (markers, displayed traces) and saved again, then it would not save two copies of calibration but pointer to the calibrations of a common calibration set.  To know when it could blow away a calibraiton set, it would keep of counter of how many save/recall states had been assigned. I would guess, (and this is only a guess) turning on and off the calibraiton maybe affects a count of how many times a cal is used, and when you turn it on an off 16K times then you overrun a 14 bit number.  I thought we could go to 2^15 (with a bit for sign) but maybe something else doubles the number (2 channels, for instance).  There are other things that fail in similar ways.  If the count goes negative, the firmware says "blow away the calset, it's not needed" but you still need it.  So, things get lost.

So, if you need a measurement with and without cal, why not setup 2 channels and trigger them accordingly.  The art of programming the 8753 is figuring out what work-arounds work with it.
举报

陈鹏

2019-4-18 15:51:54
引用: 脑洞大赛9 发表于 2019-4-18 20:16
首先要记住的是:8753是在现代计算机普及之前设计的。
它本质上具有用于CPU的洗衣机控制器。
第二,事情,如果有固件问题,它永远不会被修复。

我认为CORR ON可能是从结构比现在更复杂时剩余的代码的残余;
我摆脱了其他子vi但保留了那些命令。
让我摆脱多余的CORR ON;
和CORR OFF;
命令,看看会发生什么。
(实际上,CAL1命令让我觉得是另一个代码残余;我不知道为什么我会需要它。)我觉得令人惊讶的是,这最终会产生下游效果,当我尝试读取时它只会挂起8753ES
* OPC后的“1”;; SING;
命令。
谢谢,我会在修复后再次发布。

以上来自于谷歌翻译


     以下为原文

  I think the CORR ON might have been a remnant of the code remaining from when the structure was more complicated than it is now; I got rid of the other sub-vi's but kept those commands.

Let me get rid of the excess CORR ON; and CORR OFF; commands and see what happens.  (Actually, the CAL1 command strikes me as another code remnant; I'm not sure why I would need it.)  The thing that I find surprising is that this ends up having a downstream effect which only hangs the 8753ES when I attempt to read the "1" after the *OPC?;SING; command.

Thanks and I will post again once I get this fixed.
举报

陈鹏

2019-4-18 16:07:57
这似乎已经成功了,令人惊讶的是。
摆脱不必要的CORR ON;
和CORR OFF;
命令现在允许网络分析仪测量超过55,000个模具而不会冻结。
这个要点:* PRES;
和* RST;
通过GPIB发送的命令不完全等同于前面板Preset和循环电源。
*有一些计数器可以计算CORR ON的循环次数;
和CORR OFF;
并且在2 ^ 14(或2 ^ 15,取决于)迭代之后失败。
*此故障不会在GPIB Write命令不起作用,而是在OPC的下一个GPIB读取命令中表现出来,这可能会混淆调试尝试。
乔尔博士,非常感谢你的帮助;
我非常感谢。

以上来自于谷歌翻译


     以下为原文

  That seems to have done the trick, amazingly enough.  Getting rid of the unnecessary CORR ON; and CORR OFF; commands has now allowed the network analyzer to measure more than 55,000 dies without freezing up.

The takeaways from this:

* The PRES; and *RST; commands sent via GPIB are not fully equivalent to the front panel Preset and cycling the power.
* There is some counter which counts the cycling of CORR ON; and CORR OFF; and fails after 2^14 (or 2^15, depending) iterations.
* This failure will not manifest itself in the GPIB Write command not working, but rather in the next GPIB Read command of the OPC;, which can confound attempts to debug.

Dr. Joel, thank you very much for your assistance; I greatly appreciate it.
举报

更多回帖

发帖
×
20
完善资料,
赚取积分