BenchLink Data Logger 3如何使用新版本快速采集

嗨，没有349076A，所以我假设您正在使用带有其中一个多路复用器模块的34970A。
50 ms意味着它必须能够以（通道数）/ 50 ms的速率完全通过扫描列表。
对于最快的模块，34902A 16通道干簧多路复用器，这将是320通道/秒。
BLDL软件使用的数据格式的最快速率是150读数/秒。
这些都使用最快的测量参数设置：0.02电源线周期测量光圈，自动调零关闭，自动调整关闭和通道延迟0.因此，您的扫描列表只能是7通道使用这些设置。
但是，BLDL软件的速度尽可能快，如果小于最大速度，则忽略扫描间隔设置。
因此，无论扫描列表的长度如何，您都不应该看到任何问题，即使您使用的是34901A电枢继电器多路复用器，这是最流行的模块，并且只能达到60 ch / sec。
不幸的是，BLDL没有弹出具有最大实际速度的消息，但数据时间戳将为您提供测量配置的实际最大速度。
BLDL这类问题的主要原因是使用图表。
绘制多个通道可能会阻塞CPU并耗尽过多的内存。
尝试关闭图表标签，直到您确实需要查看它。
您始终可以向后滚动图表以查看之前的数据。
使用RS-232时，通常会出现丢失通信的问题。
RS-232不是一个非常强大的接口，因为它不使用硬件握手。
我希望这有帮助。



     以下为原文

  Hi,

There is no 349076A, so I assume that you are using a 34970A with one of the multiplexer modules for it.  50 ms means that it must be able to a complete pass through the scan list at a rate of (No of channels)/50 ms. For the fastest module, the 34902A 16 channel Reed multiplexer this would be 320 channels/sec.  The fastest rate for the data format that the BLDL software uses is 150 readings/sec.  This is all using the fastest measurement parameter settings: 0.02 power line cycles measurement aperture, autozero off, autorange off, and channel delay 0.  So your scan list could only be 7 channels ong with these settings.  However, the BLDL software simply goes as fast as it can and ignores the scan interval setting if it's less than the maximum speed.  So you shouldn't see any problem regardless of the length of the scan list, even it you are using the 34901A armature relay multiplexer which is the most popular module and can only go 60 ch/sec.  It's unfortunate that BLDL does not pop up a message with the maximum actual speed, but the data timestamp will give you the actual maximum speed for your measurement configuration.  

The main cause of this type of problem with BLDL is using the graph.  Graphing many channels can choke the CPU and use up excessive memory.  Try keeping the graph tab closed until you actually need to look at it.  You can always scroll the graph backwards to see earlier data.  There are often problems with losing communication when using RS-232.  RS-232 is not a very robust interface because it does not use hardware handshaking.  I hope this helps.

嗨，是的，我的错，这当然是Agilent 34970A。
遗憾的是，新的Data Logger 3（版本4.3）软件无法每50毫秒获取一次数据。
我只使用一个通道（这意味着只启用一个通道），直流电压（-10到+10 V），5.5位数。
没有图形，在50毫秒扫描之间的时间延迟，程序使用几乎100％的CPU和4GB内存，它只是挂起。
我和安捷伦工程师谈过，他建议用GPIB / USB线代替RS232。
好吧，他们的电缆超过500美元....最好的问候，JG



     以下为原文

  Hi,

Yes, my mistake, this is of course Agilent 34970A.  Unfortunately, new Data Logger 3 (Version 4.3) software
cannot acquire data every 50 milliseconds.  I am using only one channel (this means, only one channel is
enabled), DC Voltage (-10 to +10 V), 5.5 digits.  Without graphics, at time delay between scans of 50 ms, the program uses 
almost 100% CPU and 4GB memory, and it simply hangs. 

I talked to the Agilent engineer, and he suggested to use GPIB/USB cable instead of RS232.  Well, their cable is over $500.00....

Best regards,
JG

有趣！
我已经运行相同的配置30分钟没有任何问题。
我平均有40％的CPU使用率和2.8G的内存，我使用的是RS232。
我已经开始使用2.67 GHz CPU和4G内存运行Win 7.您可能已经注意到必须输入5 ms才能获得50 ms的采样间隔。
如果输入50，则获得500。



     以下为原文

  Interesting!  I've been running the same configuration for 30 minutes without any problems.  I'm averaging bout 40% CPU usage and 2.8 G of memory and I using RS232.  I've goit a 2.67 GHz CPU and 4G of memory running Win 7.

You have probably noticed that you have to enter 5 ms to get a 50 ms sample interval.  If you enter 50, you get 500.

我跑了一夜，今天早上来的时候还在跑。
但是，我确实看到一些事情表明BLDL根本无法跟上这个50毫秒的采样率。
首先，当我点击停止按钮时，34970A停止扫描，但BLDL似乎挂起了。
弹出窗口询问您要对数据执行的操作永远不会出现。
当我再次点击停止按钮时，我收到了消息：警告：正在进行中停止。
我关闭了BLDL，然后查看了扫描期间不断更新的数据文件。
落后大约45分钟。
另一个奇怪的事情是，尽管扫描间隔设置为50毫秒，但数据时间戳仅相隔37毫秒。
关于RS232，它似乎总是在我的笔记本电脑上正常工作。
这是运行Windows 7 64位的HP Elitebook 8440p。
请参阅随附的有关RS232故障的文章。



     以下为原文

  I ran it overnight and is was still running when I came in this morning.  However, I did see some things that indicate that BLDL simply can't keep up with this 50 ms sample rate.  First of all, when I clicked on the stop button, the 34970A stopped scanning, but BLDL appeared to hang. The pop-up that asks you what you want to do with the data never came up.  When I clicked on the stop button again, I got the message:  WARNING:  STOPPING UNDER PROGRESS.  I closed BLDL and then looked at the data file that is continuously updated during scanning.  It was about 45 minutes behind.  Another weird thing is that although the scan interval was set to 50 ms, the data time stamps were only 37 ms apart.  

Regarding RS232, it always seems to work fine on my laptop.  It's an HP Elitebook 8440p running Windows 7 64 bit.  See the attached article about RS232 troubles.

附件

• Agilent Problems Using RS-232 on Agilent Instruments with Laptop PCs running any Microsoft OS.mht376.3 KB
  

“BLDL软件使用的数据格式的最快速率是150读数/秒。这都是使用最快的测量参数设置：0.02电源线周期测量孔径，自动调零关闭，自动调整关闭和通道延迟0。”
你能告诉我如何在BLDL中设置这个设置吗？
非常感谢你。



     以下为原文

  "The fastest rate for the data format that the BLDL software uses is 150 readings/sec. This is all using the fastest measurement parameter settings: 0.02 power line cycles measurement aperture, autozero off, autorange off, and channel delay 0."

Could you tell me how to set this set-up in BLDL? Thank you very much.

我不知道你在哪里或如何提出150读数/秒。
您应该首先查看硬件限制。
如果你看一下34970A数据表，你会发现34901A多路复用器最多可以以60 rdgs / sec的速度扫描。
34902A簧片继电器多路复用器可以达到210 rdgs / sec。
如果你坐在一个通道上，你可以通过总线达到440 rdgs / sec，500到内部存储器。
BLDL没有弄清楚你有多快可以自动限制设置。
你必须自己做。
在Configure Channels选项卡中，单击Range，Res（olution）和More框以设置最快的设置。
如果您将扫描间隔设置得比硬件更快，则不会出现任何错误，只会尽可能快地执行，您可以从时间戳确定。
软件开销很大，因此无法始终达到硬件限制。



     以下为原文

  I don't know where or how you came up with 150 readings/sec.  You should look at the hardware limitations first. If you look at the 34970A Data Sheet, you will see that the 34901A mux can scan at 60 rdgs/sec max.  The 34902A reed relay mux can get to 210 rdgs/sec.  If you sit on a single channel, you can get to 440 rdgs/sec across the bus, 500 to internal memory.  BLDL doesn't figure out how fast you can go and automatically limit the settings.  You have to do that yourself.

In the Configure Channels tab, click on the Range, Res(olution), and More boxes to set the fastest settings.   If you set the scan interval faster than the hardware can go, you don't get any errors and it will just go as fast as it can, which you can determine from the timestamp.  There is significant software overhead, so you can't always reach the hardware limits.

我的安捷伦使用34901A。
我已按照您的指南进行操作，并且能够达到10毫秒扫描之间的时间（仅使用1个通道）。
这对我有帮助。
非常感谢你 ：）



     以下为原文

  My agilent uses 34901A. I have followed your guide and be able to reach the time between scans of 10ms (using 1 channel only).
That will help me a lots.
Thank you verymuch :)

很抱歉再次给你烦恼。
我仍然想知道扫描速度。
我正在使用安捷伦34970A和34901A多路复用器，单通​​道并通过RS-232连接来测量DCV。
在34970A数据表中，有两部分提到“速度”，即“单通道测量速率”和“系统速度”。
在“单通道测量速率”中，最大速度为490读数/秒（对于固定功能和范围，内存读数，缩放和报警关闭，自动归零关闭）。
但是，在“系统速度”中，INTO和OUT存储器的速度有不同的设置。
所以，请你解释一下我的扫描速度是多少？
就像我之前说的那样，我可以达到100读数/秒的扫描速度（间隔时间扫描10毫秒）。
另一个问题是，当我将间隔设置为低于10毫秒（例如5毫秒）时，我得到的时间戳是一个混乱，间隔波动很大。
这是因为Benchlink数据记录器还是我的笔记本电脑？
我的笔记本电脑有核心i5和4Gb RAM。
非常感谢您的帮助和您的患者：P最好的问候，编辑：BrokenSmile于2014年5月20日下午10:19



     以下为原文

  Sorry to bug you again. I still wonder about the scan speed.

I am using agilent 34970A with the 34901A mux, single channel and connected by RS-232 to measure DCV. In the 34970A datasheet, there are two parts mentioning about the "speed", which are "Single Channel measurement rates" and "System speed". In the "Single Channel measurement rates", the maximum speed is 490 readings/s (For fixed function and range, readings to memory,scaling and alarms off, autozero OFF). But, in the "System speed", there are speed of INTO and OUT memory with different settings. So, could you please explain to me what is my scan speed in my situation? Like I said before, I could reach the scan speed of 100 readings/s ( interval time scans of 10ms). 
Another problem is when I set the interval lower than 10ms ( for example 5ms) the time stamp I got was a mess with the interval fluctuated wildly. Is this becaus of the Benchlink data logger or my laptop? My laptop has core i5 with 4Gb RAM.

Thank you very much for your help and your patient :P

Best regards,

Edited by: BrokenSmile on May 20, 2014 10:19 PM

使用Benchlink DataLogger软件无法达到最大可能的速度，因为它有很多开销。
在BLDL运行时，查看ACE IO监视器（安捷伦IO库的一部分），如果您只是优化了34970A SCPI命令，您将看到大量的IO。
这就是数据表性能数据的基础。
你看到的是你用BLDL得到的。
没有什么可以做的来优化它。
它建立在多通道扫描模型上，扫描列表中有任意数量的通道。
它不断发送状态请求和错误查询命令，查询内存中的读数数量，然后请求读数。
当您知道已编程了多少读数时，设置TRIG：SOURce IMMediate并发送单个READ会更快？
命令尽可能快地传输所有这些读数。
100 rdgs / sec可能与使用BLDL的单个通道上的速度一样快。



     以下为原文

  You can't reach the maximum possible speed with the Benchlink DataLogger software because it has a great deal of overhead.  Take a look at the ACE IO Monitor (part of the Agilent IO Libraries) while BLDL is running and you will see the extensive amount of IO that would be unnecessary if you just optimized the 34970A SCPI commands.  That is what the data sheet performance data is based on.  What you see is what you get with BLDL.  There's nothing you can do to optimize it.  It's built on a multiple channel scanning model with an arbitrary number of channels in the scan list.  It continuously send status request and error query commands, queries the number of readings in memory and then requests that number of readings.  It's faster when you know how many readings you have programmed, have set TRIG:SOURce IMMediate, and send a single READ? command to transfer all those readings as fast as possible.  100 rdgs/sec is probably as fast as you can go on a single channel with BLDL.

TomC，我正在使用Bench Link（我也试过Bench Vue）和34970a单元。
我正在尝试在没有通道延迟的情况下进行1PLC测量。
我将积分时间设置为1 PLC，扫描间隔设置为0.由于某种原因，测量之间的时间戳为35毫秒。
我尝试了更长的集成时间，比如20 plc。
我发现我的时间戳总是2倍于我的预期。
1 plc = 60 Hz还是1/60 s？
我真的被这个难倒了。



     以下为原文

  TomC,

I am using Bench Link (I have also tried Bench Vue) with a 34970a unit. 

I am trying to do a 1PLC measurement without a channel delay. I set the integration time to 1 PLC,and the scan interval to 0. For some reason the time stamps between measurements were 35ms. 

I experimented with longer integration times, say 20 plc. What I found was that I would always have a time stamp that was 2x what I expected. 

Is 1 plc = 60 Hz or 1/60 s? 

I am really stumped by this one.