Data Acquisition Idea Exchange

It would be great if NI offered something similar to the PLC world in the form of expandable IP20 I/O slices that don't require a chassis. It could offer the same kind of functionality in the modules that the CompactDAQ line offers, but without the need to lock into a chassis. I've found myself leaning towards using PLC I/O for some projects where the end-state is a bit murky, but the programming gets really awkward when using third-party APIs like PVI.

The interface to the PC could be similar to that of a cDAQ chassis: USB or Ethernet. Given the applications of most slice I/O users, 24 VDC would be the preferred way to power such a system.

The vi "DAQmx Tristate Output Terminal (VI)" lacks an input to toggle the drive state of the output.

Current version can only tristate - not enable the output. It is rare that you don't need both options.

Tri-state DAQmx

Without the enable option, it is a superfluous VI which only does half the job.

A workaround is straightforward using the technique here https://forums.ni.com/t5/Example-Programs/DAQmx-Digital-I-O-Toggling-Tristate-on-Individual-Lines-in-the/ta-p/3528571?profile.language=en 

I've been in many threads and seen many, many more where the root issue stems from confusion about the way DAQmx Timing and DAQmx Read interpret the meaning of "# samples" very differently for Finite Sampling vs. Continuous Sampling mode.   (For example, here's just one of the times I tried to address that confusion.)

First, here's what causes the confusion:

• The 'samples per channel' input to DAQmx Timing is *crucial* for Finite Sampling tasks and usually *ignored* for Continuous Sampling tasks.
• The 'number of samples per channel' input to DAQmx Read has a default value of -1 when left unwired.  However, the *meaning* of this default value is *VERY* different,  resulting in very different behavior depending on whether the the task is configured for Finite or Continuous sampling.  (See the first link I referenced.)

While the relevant info is findable in the help, it also often clearly remains unfound.  I got to wondering whether some changes in the DAQmx API could help.

I'll describe one approach, but would definitely be open to better solutions.  The goal is simply to find *some* way to reduce the likelihood of confusion for rookie DAQmx users.

I picture adding more polymorphic instances to both the DAQmx Timing and DAQmx Read vi's, so there can be distinct instances for FInite vs Continuous sampling.

Further, I picture that the task refnum would carry sufficient type info related to this timing config, such that that downstream DAQmx functions can "know" what kind of Timing was set up -- Finite, Continuous, on-demand (the default if DAQmx Timing was never called at all), etc.

Then when that task refnum is wired into DAQmx Read, the most appropriate instance of DAQmx Read would show up.  And the corresponding input parameter names, help, default values, and default value *behavior* can all be tailored to that particular instance of DAQmx Read.  For example, perhaps the "# samples" input should become a *required* input for Continuous Sampling tasks, to force a decision and encourage further inspection of the advanced help.

Don't know how feasible something like this is, but it's definitely something that regularly trips up newcomers to DAQmx.

-Kevin P