完善资料让更多小伙伴认识你,还能领取20积分哦, 立即完善>
我们刚刚从Vee 8.5升级到9.3,Windows XP升级到Windows 7.过去两周左右,我们在软件中运行了一些先前的测试。
没有出现任何问题。 不,我们正在进行下一次测试,在过去3天内,软件已经崩溃了4次或更多次。 现在得到:错误号:751异常类型:System.Runtime.InteropServices.COMException Agilent34980A:IO错误:VI ERROR_NCIC:不是控制器负责。错误代码:0x80044212调用.NET对象时出错错误调用是 在事务编号1中,事务正在调用Reading = agilent34980AClass.Measurement.Read(ChannelList)对象标题:读取传感器对象类型:IVI-COM在UserFunction中:readSensor ----------------- To 我这似乎表明安捷伦34980A走出了远程模式。 问题是当这个错误弹出时,没有人在34980A的前面板附近...有关如何调试此问题的任何想法? 谢谢,格雷格 以上来自于谷歌翻译 以下为原文 We had just recently upgrade from Vee 8.5 to 9.3 and Windows XP to Windows 7. We had run some previous tests in the software over the past 2 weeks or so. No issues popped up. No we are running our next test and in the past 3 days the software has crashed 4 times or more. It now gets: Error number: 751 Exception type: System.Runtime.InteropServices.COMException Agilent34980A: IO Error: VI ERROR_NCIC: Not the controller-in-charge.returned error code: 0x80044212 Error occurred while calling a .NET object Erroring call was in transaction number 1 Transaction was calling Reading = agilent34980AClass.Measurement.Read(ChannelList) Object title: Read Sensor Object type: IVI-COM In UserFunction: readSensor ----------------- To me this seems to indicate that the agilent 34980A went out of remote mode. Problem is that nobody was anywhere near the front panel of the 34980A when this error pops up... Any ideas of how to debug this issue? Thanks, Greg |
|
相关推荐
3个回答
|
|
我使用Agilent 8720ES网络分析仪收到此错误消息。
这是在长时间的写作过程中,然后从仪器中读回数据。 它只是一次又一次地出现。 发生时,没有人碰过仪器的前面板。 安装在控制PC上的是Agilent Libraries Suite 17.1。 操作系统是Windows 7.我怀疑这是写入之间的时间问题,然后仪器没有为随后的读取做好准备 - 我将进行调查。 原始评论的海报是否以任何可以在这里分享的方式解决? 以上来自于谷歌翻译 以下为原文 I have been getting this error message with an Agilent 8720ES Network Analyzer. It was during an extended period of writing and then reading back data from the instrument. It just occurs now and again out of the blue. No one touched the front panel of the instrument when it occured. Installed on the controlling PC is Agilent Libraries Suite 17.1. The OS was Windows 7. I suspect it is a timing issue between the write and then the instrument not being prepared for the subsequent read - I will investigate. Did the poster of the original comment resolve in any way that could be shared here? |
|
|
|
哦,这将是很难调试,特别是因为它只是偶尔发生。 它是否是同一个消息(不是控制器错误)? 我对所有间歇性进行dealling的技术是首先制作(手写)日志。 从中你可以了解频率,规律性,白天发生的事情,是否总是出现在代码中的同一个地方等等。 要么提供线索,要么添加更多调试,例如: 如果它总是在代码中的同一个地方崩溃,你可以尝试在那里捕获错误,也许从该事件中保存更多细节等等。 HTH,Mike Watts 以上来自于谷歌翻译 以下为原文 Oh that's going to be difficult to debug especially as it only happens occassionally. Is it exacly the same message ( not the controller error )? My technique for dealling with all intermittents is to first make a ( handwritten ) log. From that you can gain an idea of frequency, regularity, when it happens during the day, whether it always occurs at the same place in the code and so forth. Either that will give you a clue or you can add more debugging e.g. if it always crashes at the same place in the code you can try trapping the error there, maybe save more details from that event and so forth. HTH, Mike Watts |
|
|
|
我似乎已经解决了我遇到的问题,在OUTPDATA或OUTPFORM关键字的写入和随后的数据系列读取之间等待了10毫秒。
从那时起我就没有关于神秘辍学的报道。 以上来自于谷歌翻译 以下为原文 I seemed to have solved the issue I was experiencing, by putting a wait of 10 milliseconds between the write of the OUTPDATA or OUTPFORM key words and the subsequent read of the data series. I have not had reports of mysterious dropouts since. |
|
|
|
只有小组成员才能发言,加入小组>>
1251 浏览 0 评论
2360 浏览 1 评论
2173 浏览 1 评论
2041 浏览 5 评论
2925 浏览 3 评论
996浏览 1评论
关于Keysight x1149 Boundary Scan Analyzer
725浏览 0评论
N5230C用“CALC:MARK:BWID?”获取Bwid,Cent,Q,Loss失败,请问大佬们怎么解决呀
825浏览 0评论
1252浏览 0评论
小黑屋| 手机版| Archiver| 电子发烧友 ( 湘ICP备2023018690号 )
GMT+8, 2024-12-3 02:10 , Processed in 1.381314 second(s), Total 81, Slave 64 queries .
Powered by 电子发烧友网
© 2015 bbs.elecfans.com
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 (电路图) 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证:合字B2-20210191 工商网监 湘ICP备2023018690号