Here are a few miscellaneous things that will help in your data acquisition.
Time interval limitation
The smallest timing value that you can use largely depends on your processor speed, and whether you have any other programs running besides DAQFactory. Due to limitations with Windows, a timing interval of less than 10 ms (Timing of 0.01) is not suggested, no matter how fast your computer. If you need faster acquisition, we suggest you use hardware paced acquisition, usually done using device functions or channel commands. The availability of hardware paced acquisition depends on your hardware.
Timing in sequences is a different issue and is discussed in the chapter entitled Sequences.
Determining timing latency
To determine how well your data acquisition is performing in terms of reading data at expected intervals, you can make a graph showing the difference between consecutive data points by doing the following:
1. Create a blank graph.
2. For the trace's Y Expression enter GetTime(channelname) - GetTime(channelname[1,3600]), where channelname is the name of the channel you would like to check.
3. Leave the trace's X Expression as Time.
The graph will display the time of each point minus the time of the previous point.
Reading data at non-uniform intervals
You can setup a sequence to read data at any time given. For example, the following sequence reads data once, waits 9 seconds, reads it again, waits another second, then loops around and reads again.
while (1)
MyChannelName.read()
delay(9)
MyChannelName.read()
delay(1)
endwhile
The data from the sequence gets stored just like normal data. Note that we use the delay() function instead of wait(). The wait() function is non-propogating, so any delays in actually reading MyChannelName will not cause the data acquisition times to vary. However, this only works with devices that have short and constant read times otherwise the reads may get back-logged and probably hang DAQFactory. You should always use delay() instead of wait() if doing any sort of serial or Ethernet communications. Either way, you will want to set the Timing for your channel to 0.
Dealing with slow hardware
To help you deal with slow hardware, we have provided an offset parameter for your channels that allows you to predictably stagger your acquisition. Offset is used in conjunction with the timing information for a channel to determine when exactly a channel is read. It is best illustrated with some examples:
Timing = 1, Offset = 0 |
Data is read every second on the second. |
Timing = 10, Offset = 0 |
Data is read every ten seconds, on the second. |
Timing = 1, Offset = 0.5 |
Data is read every second on the half second. |
Timing = 10, Offset = 5 |
Data is read every ten seconds starting five seconds after a Timing 10, Offset 0 would read. |
All channels with the same timing and offset information are grouped together internally, and each time the timing interval comes up, DAQFactory will read each of the channels in the group in an unpredictable order (although it will read together all channels from a single device). If you have a channel connected to a piece of hardware that is slow to read, the reading of all channels afterwards will be delayed. Offset provides the mechanism to prevent this. If, for example, you have a group of channels you'd like to read at 1 second interval and one of those channels takes half a second to read, you could give all the fast channels a timing of 1 and an offset of 0, then give the slow channel a timing of 1 and an offset of 0.1. This way all your fast channels will read right on the second. The slow channel would begin reading 100ms later, which gives the fast channels plenty of time to finish reading.
Technical Detail: Because each timing / offset setting runs in a different thread of execution of the computer, you can actually simply put a slow channel in any offset, even say 0.01, and provided they aren't on the same device driver (unless the driver is designed for multithreaded access), the reads will occur concurrently. If they are on the same device, you can set the offset at around 40 ms and the slow channel will read when the other channels are done, or 40 ms after they start, whichever is greater. The 40 ms comes from the maximum observed latency in timing plus some additional cushioning.
Reducing your memory usage
There are two ways to reduce your memory load.
1. Drop your screen's resolution or color depth. A screen at 1600 x 1200 x 32 bit color requires almost 50 meg of memory within DAQFactory because of DAQFactory's triple background painting algorithm. By contrast, a 1024 x 768 x 256 color screen requires only 3 meg of memory.
2. Shorten the history amounts of your channels, and consider using channel Persist. Alternatively, by using the History Interval (or # Hst column) parameter of the Channel, you can increase your history length in time in memory, while reducing your total memory load. This parameter determines the interval at which a data point is stored into the history. The default is 1, which corresponds to every point. A value of 10, for example, would mean every 10th data point is stored in the history. If your Channel is being read at 1 hz, you could store a full day's worth of data with a history length of 8640 with a History Interval of 10, instead of 86400 required with an History Interval of 1. Even though every 10th point is saved, the most recent data point is always the first data point in the history array (i.e. channelname[0] always contains the most recent data point.).
Reducing network load
To reduce your network load, connect using the slim data stream, and/or adjust the broadcast interval of your channels. The broadcast interval controls how often a channel's data is sent over the network (broadcasted). A value of 1 means all data is broadcast, a value of 0 means no data is broadcast, a value of 2 means every other data point is broadcast, etc. You can still see the entire channel list and control outputs, but not all channels' data is sent over the network (this does not affect storage). You can even set the broadcast interval to 0 which will stop broadcasting that particular channel. The slim data stream only passes data for the channels marked Broadcast? With the slim data stream only channels that are broadcast are visible, and you can not set any outputs or start / stop any sequences (much less see them). This is designed more for sharing data with a colleague that does not need all the details of your experiment and certainly does not need to fiddle with the experiment.
Network security
When using DAQFactory networking (meaning adding a new Connection), data is encrypted to the level allowed by your location and your Windows installation. The encryption key is based off of the passwords you provide for networking, so it is important to put at least a minimal password in. You can protect yourself further using a hardware or software firewall. DAQFactory uses ports 2345 and 2346 to communicate over the full data stream, and ports 2347 and 2348 to communicate over the slim data stream. If you block traffic on ports 2345 and 2346, users on the other side of the firewall will not be able to connect using the full data stream, but can still connect using the slim data stream. Personal software firewalls are cheap (or even free), readily available, and pretty easy to setup. Just make sure you can block individual ports with your firewall.
Network passwords are discussed in the section on document settings.
