Hi All,
This question is for the support personell at OPTO22. Does the OPTO 22 people have any information regarding what is the fastest reliable DataLogging rate for the Opto22 Historic DataLogger? I am presently using an OPTO 22 PAC R1 system for data logging Voltages and 6 isolated temperatures at a rate of 20 HZ (50 msec). I have the OPTO 22 system connected to a laptop for the storage of data using a fast ethernet connection. When viewing the data, the timestamp for the data acquisition time is alllllll over the place. It is anywhere from 40 msec to 80 msec (according to the time stamp). This is on a R1 system running absolutely nothing as far as controlling goes.
So basically, is there anyway to get the OPTO system to deterministically take data at discrete (or even close to discrete) desired data acquisition rates?
A few questions pop into my head as I’m reading your questions. Keep in mind that with a SNAP PAC system, there are many ways to approach a particular task, so I’d want to take a step back on this one.
First, I was surprised that you’re measuring temperatures in millisecond intervals. This is unusual. More common would be seconds or minutes since typically temperature values don’t change very fast (and whatever you have hooked up to measure might not be that sensitive).
Second, you’re using the word “deterministic” but you have Windows in the mix. Here’s a quote which talks about this: “… the vast majority of general-purpose operating systems (GPOS) are not deterministic… there is large variation in the time it takes for the operating system to context switch… Additional delay is incurred in hardware when the CPU switches tasks…” (Source, top of p. 2): http://download.intel.com/embedded/processor/whitepaper/324510.pdf
However, you can record your data locally on your R1 a couple of different ways (in a table or a file, for example). Check out form 1646 for info on how much space you have in the different types of memory and the file system(s).
Which options you choose might be determined by what you need to do with the data next, and how much data you need.
For example, can you do some of your logic on the R1 itself? One of the great things about a PAC system is the ability to distribute your control system. Share the load! That R1 can do a lot of logic to perhaps avoid having to slam your network with unnecessary traffic.
Can you tell us more about you’re doing so we can get a bigger-picture view?
First up, you mention that you are not running a control strategy.
If this is going to be the case the whole time you are needing to log these temperatures, then you might consider turning off the control engine on the controller… This will give the controller more time slices (CPU cycles) to address the TCP/UDP stack.
Check out page 141 of form 1704, the PAC Manager Users Guide, on how to do this.
(While you are there, are you using any digital I/O modules? If not, also consider turning off the digital scanner as well. Just add the two values together and put that into the scanner flag).
We had to do this on a customers job late last year and it made a measurable improvement in throughput. (Just how much will depend on a lot of factors, so its impossible to give hard numbers).
Next up, if you can, get the controller and the laptop on their own network.
The whole TCP/IP network traffic issue needs to be removed from the controller… The very nature of TCP/IP means that the controller has to check each packet and see if its addressed to it.
Don’t be tempted to simply use the second port on the controller, this will not remove the CPU load from the controller.
You will need to use a single cable between the controller and the laptop and put a fixed IP address in the laptop that matches the one in the controller (ask Google how to do this if you are not sure, Im told it knows stuff like this ;-))
Lastly, at the rate you are talking about, I have to raise the question of the module freshness.
If you look at the data sheets on our modules, they all have a ‘freshness’ value.
For example, the SNAP-AIRTD, a pretty typical module that uses 100-Ohm Platinum RTD probes to measure temperature, has a ‘Data Freshness’ rate of 100ms.
You can read it more often than that, but you will simply be reading the same value over and over.
(And keep in mind, like Mary said in the post above, this module freshness value does not take into account any thermal inertia that the probe itself might have).
Lets know how you get on. Pretty interesting application.
