Potential data flow issue

[JP2020]

I have two DASYLab programs, one with a couple of analog input modules and one with a RS232 module. These both function and work well. I have now combined them into a single program and have been encountering some issues. For example, the RS232 Monitor window displays a continuous data stream that updates at the expected intervals. However, when start DASYLab, the digital display modules take very long to update and the recorded text file also lags behind.

I believe this is a data flow issue. My process until now has been to set the sample rate under the Measurement Setup window to what I required and let the block size fall out using the Specify automatically setting. My understanding is that this should provide DASYLab with an ample response time for processing. I don’t usually change the system clock settings under Time Base Setup as I believe all this does is set the timer. Are there any issues or misunderstandings in my approach?

I have tried adjusting the sample rate and block size in the Measurement Setup window. This hasn’t improved the issue and I seem to get the best results on the Specify automatically setting. I have also been adjusting the system clock settings under Time Base Setup. Any ideas on what I could do to fix this issue?

[CJ_Butler__DASYLab_Pro]

You may need to call in for help on this one. 

Modules that generate data, like the Analog Input or the RS232 Input, need a timing source. 

Most Analog Inputs create a Time base (or two) as their timing source that links directly to the driver and the hardware clock. 

RS232 defaults to assigning the current time to the input values. However, it uses a block size of one. If the input is fast, then you may be overwhelming the system with a lot of small blocks at a data rate that is faster than 10 samples/sec. 

Open the Options for the RS232 module, and choose "Output measurement value blockwise", click on Time base and either specify the approximate input rate or select the hardware time base that your Analog input is using. 

See how that works. 

[JP2020]

CJ,

Thank you

I'll make sure to try this right now.

Just to clarify, my understanding was that all modules sampled data according to a clock signal. This clock signal was set in the Time Base Setup window. Following your response, my understanding is that the Analog Inputs create their own time base using this clock signal as their timing source. Is this correct? Why wouldn't the Analog Inputs just use the clock signal directly for timing? The RS232 Input module by default does not use the clock signal for timing but instead uses a block size of one. I can alter this by either choosing an already existing Time base or specifying one under Options. Is this correct? Also, where does the 10:1 sample rate to block size ratio come from? This seems to only apply to the Time base and not the measurement sample rate.

[CJ_Butler__DASYLab_Pro]

Let me start at the bottom. 

The 10:1 ratio was introduced with DASYLab 2016. Prior releases used "the sample rate divided by two and rounded up or down to the nearest power of two". 

Over the years, our testing has determined that the 10:1 ratio is a sweet spot of performance and keeping the screen updated. The earlier setting was tuned to a now-obsolete requirement that FFT be done on blocks of power of two size. So, with DASYLab 2016, we switch all of the drivers that changed to the 10:1 ratio for the default. 

Unfortunately, the legacy "Driver" interface could not be updated for DASYLab 2106, and older drivers, notably IOtech and the Sound Card driver, were not able to pick up the new setting. The "Driver" time base still uses the original default setting, and limits the maximum blocks size to 32K (as opposed to 1000K). With DASYLab 2016, software generator modules default to using the DASYLab time base. Prior releases it was the Driver time base, even if there was no driver hardware connected.

Each newer (most of them) driver has the ability to create its own time base, depending on the driver and device features. In the case of NI tasks, each task has a time base (set in MAX). MCC typically creates two time bases, sometimes three -- Input HW, Input SW, Output HW. Each driver may have taken its own approach to optimize the hardware features that the driver supports. 

The entire time base list is exposed to other modules, so that software generator modules can opt to use them to help with data synchronization.

So - DASYLab with no additional drivers loaded will have two time bases. A software-paced DASYLab time base and a legacy Driver time base. Each driver may add one or more time bases. It's very driver-specific how it does it.

When you create an Analog input it should use its own time base. If you change it to use another time base, it will go to a "software paced" mode that does not use the hardware device's clock. You want to use the hardware clock for sample rates of more than 100 samples/second. It's just more accurate than software pacing. For MCC, it changes the read mode from read sample to scan samples to a buffer, allowing much higher speeds. 

For modules like the RS232, there is no hardware clock. It's just the data coming in the COM buffer. DASYLab has to make a decision about how to time stamp. The default mode puts the "now" time on the sample with a block size of 1, flags the block as "triggered, short block" to indicate that the data channel does not contain equidistant samples, and outputs all channels at the same time (and time stamp). For 100 input lines a second, this would mean 100 blocks per channel output to the next modules. 

That causes trouble with synchronizing with other channels, as you see. For fast RS232 inputs, as I suspect you have, it's overwhelming and causing delays. 

If you know the data rate from the RS232, then use the setting where you set the sample rate. Is it 100 lines/second? If so, make the block size 10. Or, to sync up with the Analog Input, try using its time base.

Now, I would go into trial and error. Get it running, watch or plot the input from the RS232, and then make a change to the sensor. Is it real time? Does the change show up right away? 

And, you are more than welcome to contact us directly at Measurement Computing or contact your local reseller.