完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
扫一扫,分享给好友
我们遇到了需要解决的新53220A计数器的开销问题。
看看附加的驱动程序项目,我附上了新旧驱动程序(LV2011)。 查看5322x驱动程序,您将在Open Counter.vi和Read Counter.vi中看到旧代码周围有禁用结构,我们试图用新计数器复制相同的读取。 使用新代码,我们看到了之前没有的延迟。 我们以前的方式,我们不断初始化并运行计数器,并使用Read Counter.vi读取固定的计数时间。 我试图用新驱动程序复制它。 有人可以看看这个,看看这是否是正确的方法来初始化计数器,以便在累加模式下连续读取(固定臂时间)? 我们可以做些什么来重新获得整体表现? 以上来自于谷歌翻译 以下为原文 We are having overhead issues with the new 53220A counter that need to be resolved. Looking at the attached driver project, I've attached the old and new driver (LV2011). Looking at the 5322x driver, you will see in the Open Counter.vi and Read Counter.vi that there are disable structures around the old code where we have attempted to replicate the same reads with the new counter. With the new code as is, we are seeing a delay that was not there previously. The way we were doing it before, we initialized and ran the counter continuously, and read a fixed time of counts with the Read Counter.vi. I'm trying to replicate this with the new driver. Can someone please look this over and see if this is the correct way to initialize the counter to read continuously in totalizing mode (with fixed ARM time)? What may we do to regain our overall performance? 附件
|
|
相关推荐
7个回答
|
|
这个论坛是发布这些查询的好地方吗?
以上来自于谷歌翻译 以下为原文 Is this forum a good place to post queries such as these? |
|
|
|
是的,抱歉,您之前没有收到回复。 我的手表类别消失了,我只是注意周五,所以我没有意识到有新的帖子。 我会将此案件转发给我的同事进行审核。 以上来自于谷歌翻译 以下为原文 Yes, sorry you had not received a response previously. My watch categories dissappeared, and I just notice friday, so I was unaware there were new posts. I will forward this case to my colleague to review. |
|
|
|
谢谢,我很感激你的回应。 任何你可以发送我的方式将非常感激。 以上来自于谷歌翻译 以下为原文 Thank you, I appreciate the response. Anything that you may be able to send my way would be much appreciated. |
|
|
|
您是否尝试在53132A兼容模式下使用53220A以利用现有代码?
你能用旧的(531xA)驱动程序向我们发送一个完整的例子吗? 我不确定您遇到延迟的时间或地点。 附件是在标准模式下使用532xxA的连续累加示例(不是531xxA兼容模式)。 它使用计数器的连续累加功能而不是INITiate:CONTinous并定期查询连续计数。 该程序使用LabView提供的VISA - 无需额外的驱动程序。 以上来自于谷歌翻译 以下为原文 Are you trying to use the 53220A in 53132A compatibility mode in order to leverage existing code? Can you send us a complete example using the old (531xA) driver? I am not sure what or where you are experiencing the delay. Attached is a continuous totalizing example using the 532xxA in its standard mode (not 531xxA compatibilty mode). It uses the counter's continuous totalizing function rather than INITiate:CONTinous and periodically queries the continous count. The program uses VISA as provided by LabView - no additional driver is needed. 附件 |
|
|
|
子虚道人 发表于 2019-1-4 14:51 感谢您的答复。 我们在兼容模式下尝试了现有代码,并在扫描峰值时遇到错误。 长话短说,它没有修改就行不通,所以我们试图使用标准模式。 不幸的是,我之前见过这个例子。 它没有显示如何在固定的时间内启动累计计数并连续采集样本,就像我们在53132A代码上面的附件(第一篇文章)中的Read Counter.vi中所做的那样。 我们看到的延迟很可能是由于我们试图在Read Counter.vi中实现新的53220A代码的方式,因为调用这两个驱动程序的外部代码没有改变。 我确信这只是对如何在我们的应用中使用新53220A的误解。 以上来自于谷歌翻译 以下为原文 Thank you for the reply. We have tried the existing code in compatibility mode and encountered errors while scanning over a peak. Long story short, it didn't work without modifications, so we're attempting to use standard mode. I've seen this example before, unfortunately. It does not show how to initiate a totalizing count with a fixed amount of time and acquire samples continuously as we were doing in the Read Counter.vi in the attachment above (first post) for the 53132A code. The delay that we're seeing is most likely caused from the way we're trying to implement the new 53220A code in Read Counter.vi, as the external code that called these two drivers has not changed. I'm sure it's just a misunderstanding of how to use the new 53220A in our application. |
|
|
|
附件是执行门控(定时)累计测量的程序。 在门期间,计数器不断累计。 一旦期限到期,将返回计数。 计数器显示 - - - - - - - - - 累计正在进行中。 在门控期间,显示屏不显示运行计数。 只有大门尽头的数量。 那可能是你看到的延迟吗? 以上来自于谷歌翻译 以下为原文 Attached is a program that performs a gated (timed) totalizing measurement. The counter totalizes continually during the gate period. Once the period expires, the count is returned. The counter displays - - - - - - - - - while totalizing is in progress. The display does not show the running count during the gate period. Only the count at the end of the gate. Could that be the delay you are seeing? 附件 |
|
|
|
不,延迟是在计数器读取初始化的某个地方。 我们可能会在每次读取时进行一些不必要的设置,这会缩短采集时间。 如果不是这样,我会在这里触摸。 与此同时,您是否可以看到我们为init和读取计数器设置代码的方式有任何问题? 以上来自于谷歌翻译 以下为原文 No, the delay is somewhere in the initialization of the reads from the counter. We may be doing some unnecessary setup on each read that is slowing the acquisition time. I'll touch base here if this is not the case. In the meantime, can you see any issues with the way we have the code set up for init and read of the counter? |
|
|
|
只有小组成员才能发言,加入小组>>
1294 浏览 0 评论
2377 浏览 1 评论
2199 浏览 1 评论
2068 浏览 5 评论
2955 浏览 3 评论
1131浏览 1评论
关于Keysight x1149 Boundary Scan Analyzer
759浏览 0评论
N5230C用“CALC:MARK:BWID?”获取Bwid,Cent,Q,Loss失败,请问大佬们怎么解决呀
939浏览 0评论
1296浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-27 02:22 , Processed in 1.898490 second(s), Total 90, Slave 74 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号