Distributed Control & Automation Framework (DCAF)

cancel
Showing results for 
Search instead for 
Did you mean: 

Unexpected sampling rate for TDMS datalogger module

Hello,

On my standard engine I have a Timing Source Type of 1MHz Clock, and a Timing Source dt of 1000. For the TDMS datalogger module with a decimation of 1 I would expect it to log every loop. And with a dt of 1000 on a 1MHz clock I am expecting a logging frequency of 1kHz. But when I log data and look at the samples and timestamps it is collecting at about 510Hz. Are my expectations wrong? If so any guidance would be appreciated! Thanks!

0 Kudos
Message 1 of 5
(4,741 Views)

What are you running DCAF on? A cRIO? Use Distributed System Manager to check CPU usage. 

I recall I had a similar problem - it was caused by another module I wrote hogging the CPU due to a bug. 

Message 2 of 5
(4,732 Views)

Thanks for the thought, I will look into that possibility! It will run on a cRIO at some point, but at the moment I'm just testing the module on PC as I don't have access to the cRIO.

0 Kudos
Message 3 of 5
(4,726 Views)

In the engine settings you can enable timing diagnostic tags. You can then display these in a local ui. The easiest one to use is the "late" boolean and late count, these tell you if the engine isn't able to stick to the loop time. It's also possible to add a while loop to the local ui and plot the actual loop time as a graph.

 

That will tell you whether it's the tdms module doing something different to what you'd expect, or the engine loop running late. 

Message 4 of 5
(4,716 Views)

As Nick says, it's probably something unexpectedly blocking. Another possibility is the data source. If you use the DAQmx module, it's acquiring on-demand, single-point measurements that are timed by the main engine. This is fine for slow measurements, but it's really inefficient. If I remember correctly, I saw a similar delay when I tried to use that module for higher speed AI reads. I ended up building a DAQmx waveform acquisition module to make synchronized, high-speed measurements. Unfortunately, I can't share that one, but DM me if that's something that you're interested in.

 

As Matt pointed out, the engine parameters are a great way to debug that kind of issue. I've started adding a tdms module instance to all of my projects just to log the engine parameters so I can monitor engine operation as the project is developed. Another tool that I find especially useful for debugging unexpected delays in my DCAF applications is the memory and performance profiling tool (https://zone.ni.com/reference/en-XX/help/371361R-01/lvconcepts/using_profile_window/). It's a super helpful way to figure out which vis might be taking longer than you expect.

 

James

Message 5 of 5
(4,697 Views)