Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
skipped seconds in time stamp loop
dewey21
Member
01-04-2006 01:01 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hi all,
I have a two 6024E cards which I am synchronizing via a RTSI cable. I have an 860mHz Dell dimension with 512 MB of RAM. I am simply logging analog signals from the cards to a text file on a 1s timebases. The problem is that the output data file shows a time stamp is missed every once and a while. I have tried adjusting the rate of sampling and number of samples, but there always appears to be a hiccup in the timestamping. I even tried hardware timing with a timed loop and one of the on-board counters. The hiccups were even more frequent then. Maybe the code needs to be more efficient, but I am stumped. I attached the data logger vi. I appreciate any input.
Thanks,
dewey
I have a two 6024E cards which I am synchronizing via a RTSI cable. I have an 860mHz Dell dimension with 512 MB of RAM. I am simply logging analog signals from the cards to a text file on a 1s timebases. The problem is that the output data file shows a time stamp is missed every once and a while. I have tried adjusting the rate of sampling and number of samples, but there always appears to be a hiccup in the timestamping. I even tried hardware timing with a timed loop and one of the on-board counters. The hiccups were even more frequent then. Maybe the code needs to be more efficient, but I am stumped. I attached the data logger vi. I appreciate any input.
Thanks,
dewey
Travis G.
NI Employee (retired)
01-05-2006 02:40 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
Hello Dewey,
A couple recommendations for your program:
You are manually generating a timestamp for your signals using an elaborate algorithm that I haven't really taken the time to understand. I might be easier, more efficient, and more accurate to just acquire your data as a Waveform data type from the DAQmx Read Analog VI instead of acquiring data as an array of doubles. The Waveform data type includes a built in timestamp that you could parse out and log to file instead of calculating your own timestamp using the Tick Count (ms) VI. Take a look at the LabVIEW Help and there is a section under File I/O about Writing Waveform Data to a File Using Storage VIs.
I would also highly recommend you remove any Wait or Wait for Next ms Mutlitple VIs from your program. You are already configuring the sampling rate of your continuous acquisition earlier in your program using the DAQmx Timing (Sample Clock) VI. This is configuring the DAQ tasks to use the hardware clock to use the onboard sample clock of Dev1 for your acquisition. With the sample clock timing configured, the NI-DAQmx driver will automatically take care of the speed of execution of your while loop based on the rate you specify in the DAQmx Timing VI. By manually including waits in your while loop, you are conflicting with the timing parameters you set up in your DAQ task. This could lead to buffer overflows, missed samples, and otherwise non-deterministic sample timing. I would suggest taking a look at the LabVIEW DAQmx shipping example Multi-Device Synch-Analog Input-Continuous Acquisition.VI which can be found in the NI Example Finder (Help >> Find Examples) in the following category: Hardware Input and Output >> DAQmx >> Synchronization >> Multi-Device.
I hope these suggestions help!
Regards,
Travis G.
Applications Engineering
National Instruments
www.ni.com/support
A couple recommendations for your program:
You are manually generating a timestamp for your signals using an elaborate algorithm that I haven't really taken the time to understand. I might be easier, more efficient, and more accurate to just acquire your data as a Waveform data type from the DAQmx Read Analog VI instead of acquiring data as an array of doubles. The Waveform data type includes a built in timestamp that you could parse out and log to file instead of calculating your own timestamp using the Tick Count (ms) VI. Take a look at the LabVIEW Help and there is a section under File I/O about Writing Waveform Data to a File Using Storage VIs.
I would also highly recommend you remove any Wait or Wait for Next ms Mutlitple VIs from your program. You are already configuring the sampling rate of your continuous acquisition earlier in your program using the DAQmx Timing (Sample Clock) VI. This is configuring the DAQ tasks to use the hardware clock to use the onboard sample clock of Dev1 for your acquisition. With the sample clock timing configured, the NI-DAQmx driver will automatically take care of the speed of execution of your while loop based on the rate you specify in the DAQmx Timing VI. By manually including waits in your while loop, you are conflicting with the timing parameters you set up in your DAQ task. This could lead to buffer overflows, missed samples, and otherwise non-deterministic sample timing. I would suggest taking a look at the LabVIEW DAQmx shipping example Multi-Device Synch-Analog Input-Continuous Acquisition.VI which can be found in the NI Example Finder (Help >> Find Examples) in the following category: Hardware Input and Output >> DAQmx >> Synchronization >> Multi-Device.
I hope these suggestions help!
Regards,
Travis G.
Applications Engineering
National Instruments
www.ni.com/support
