Any version of NI-DAQ and the Measurement and Automation Explorer (MAX) released recently has provisions for “simulated” devices.  You choose which devices you want, and then NI-DAQ will pretend those devices are actually installed on your system, any calls to DAQ functions concerning that device will succeed (or fail) just as if a real device was installed.

This lets you simulate a client’s setup without having their hardware shipped to you and do most (if not all) of the programming on your own terms without being at their site.  The data produced is, of course, simulated data.  For an analog input channel it’s a sine wave, for a digital port, it’s a counting pattern.  It’s enough for you to tell if your software is working correctly with NI-DAQ.

With their hardware simulated on your machine, you can handle the basic communication part to get data in and out. Then you can install conditional-compilation pieces to substitute data more realistic for your particular situation if you need to.

You can be reasonably confident that the DAQ part of a program you develop this way will work on the real hardware, the same as it did on your simulated hardware.  Of course, for any extreme cases (high sample rate, high channel count), the simulation will be less exact, but it’s a useful feature to develop faster with fewer headaches.

Just ran into what at first appeared to be a bug, but turned out to be proper, if misunderstood, behavior.

I have a project which records data files. When the actual recording starts, and again when it stops, I remember the time (by using a GET DATE/TIME in SECONDS function) in a TIMESTAMP variable, which is stored in the data file. There might or might not be some calibration activity after the recording has stopped.  When the DONE button is finally clicked, I record the current time using a FORMAT DATE and TIME STRING function, into another string field called “TEST TIME”

I have a viewer which examines the data files and reports various info about them. The indicator that shows the TEST TIME is on a different window from the one that shows the START TIME and END TIME.

If there’s no CAL operations done, then the TEST TIME has always been just a few seconds later than the STOP time (enough time to react to the test being done and click the DONE button), or it could be a few minutes later.

However, I recently noticed that, on a data file sent from my client to me, that the TEST TIME was almost an hour EARLIER than the STOP time.  How could that be?  Further rummaging thru other files that I had from him shows the same thing: the TEST TIME was short of an hour EARLIER than the DONE time.  If there were CAL operations done, this difference was 45-55 minutes; if not, it was a few seconds short of an hour.

I have run thousands of tests on my machine without noticing this; my client has also run nearly a thousand, and has never brought it up.  Whay is that?

There’s one piece of info missing from the above description that’s critical to figuring out what’s happening: My client is on CENTRAL time, while I am on EASTERN time.

It took a while to figure out what was really happening:  The TIMESTAMP value was being sent whole: encoded with that value somewhere must be the TIMEZONE that it was recorded in.  When the file crossed the timezone line, the value (as it was displayed to me) actually changed.  I confirmed this with my client; a given file showed a START time of 9:39:20 on his machine, but the same file showed a START time of 10:39:20 on my machine.  Of course, those are the exact same moments, just expressed in different time zones.

The TEST TIME, however was recorded as a STRING, and as such, has no mechanism for changing.

Determinism in software is the ability to ensure that any and all paths taken through the code take a consistent amount of time to execute.  Most desktop applications have no interest in this consistency because A) it doesn’t affect anything, and B) the existence of interrupts and preemptive multitasking means that you cannot do anything about it anyway.

In an embedded control application, or one running under a real-time OS however, determinism is often important because it is critical that the control outputs be changed at a consistent time with respect to the control input sampling time. On the input side, when a signal is changing at a relatively rapid rate, any error in the TIME of measurement is just as destructive to the measurement accuracy as an error in AMPLITUDE.  For applications such as PID loops, this is even more important, since derivative terms are adversely affected by timing inaccuracies.

Equally important, but not always equally recognized, is the fact that the timing of the output samples has exactly the same effect.  If your control output is not consistently timed, then loop stability is compromised.

One way to make your code deterministic is to go through it and make sure that all path lengths are identical.  For example, if your code includes an option to scale the signal to percent of full scale or not, then the proper way to make this deterministic is to compute the full-scale percentage in all cases, then decide to use the scaled or the unscaled value depending on the option setting.  This goes against the programmer’s natural instinct to do work only when required; but it’s necessary to ensure that both paths consume an equal time.

Beginners to real-time programming are rightly warned about this situation.  If you look at the larger picture, you realize that the goal of all this is to ensure that the outputs change at a consistent time relative to each other and to absolute time.  The assumption inherent in the idea of equalizing code paths is that you want the outputs to follow as soon as possible after the control inputs are sampled.

That assumption is true in some cases, but by no means all.  There is another way to achieve the same result (consistency of output timing), without the drudgery of counting cycles and finding all the places where such path decisions are made.

By building in a hardware-controlled delay, you can achieve rock-solid precision of output timing, without fretting over every single operation. One way to do this is to use the very same clock signal that drives the input timing to drive the output timing.  For example, in the following code, we:

• Create the task for the Analog Output channels
• Set the AO SAMPLE CLOCK timing parameters to the AI clock signal
• Start the task

This instructs the OUTPUT task to use the same clock as the INPUT.  When you WRITE to the output task, the values you write will stay in the output buffer until the clock ticks; at that point they will be transferred to the actual analog output.

What Does this Do for Me?

By doing this, you have freed yourself from all constraints of cycle-counting and path-equalization. Your control output will change exactly one clock tick after the inputs that produce it. No more and no less.  You have only one constraint: you must get the job done in one clock cycle. If you are running at a loop rate of 100 Hz, then you have 10 mSec to get your work done. If it takes 10 microseconds or 9.99 mSec, it makes NO difference, the output will change at the same point in time either way. You do have to ensure that it’s 10 mSec or less, but that’s a constraint you have in any case.

In most cases, where you are waiting on a clock-controlled input sample, performing some control processing with the measured values and writing control values out, the delay you are introducing is not significant.  And a precisely controlled constant delay is often more easily dealt with in a control loop than an unpredictable jitter, and easier to produce in hardware than in software.

I discussed the idea of a time-alignment scheme in the article Delays, Delays, Delays.  The idea is that signals which have a mechanical delay of some kind (gas transport time, for example) can be time-aligned with signals that have a lesser or no such delay by means of a “logical” delay line inserted into all channels.  If the sum of all channel’s physical + logical delays is a constant, then the final output is time-aligned.

Here is a test of that concept, where three signals are generated, with different phases, and then fed thru that process. The outputs, as you can see, have been aligned.

You have to know the physical delay time, however; it does not guess.  You also have to account for the fact that some data is lost at the beginning, if that’s of concern, then start your recording early enough to account for that.

Even with those caveats, this scheme allows you to shift signals to account for mechanical delays, EVEN IN REAL TIME, if you need to.