Data Acquisition Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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

Hello,

 

How often you have build Labview applications using simulated DaqMx boards ...

And how often you were limited by the default behaviour of simulated boards ... ( Sinewave for analogic inputs, Counter square signal for digital inputs ... )

 

It would be nice to integrate in DaqMx simulated boards, the abilty to modify the default behaviour of simulated inputs ... thru dedicated popups

 

It would be nice, for each task linked to a simulated daqMx board, to launch a popup window ...

 

  • For digital input, give the abilty to modify for each configured channel , the current binary value.
  • For analog input, give the ability to choose between a fixed value, a sine wave, a square signal ... white noise ...
  • For digital output, give the ability to view the current setted values
  • For analog output, give the ability to view the current simulated output value on a waveform chart ...

 

A more powerfull tool could also integrate a simulated channels switching mechanism ... A simulated output could be linked to a simulated input 

 

This feature could be a good way to create an application which could simulate a complete process ... this application could be used to validate a complete system

(such a kind of SIL architecture)

 

Other idea .... A complete daqMx simulation API ...

 

  • Creation of an API which could instanciate a simulated daqMx board (Wich could be seen via MAX)
    • Takes place of the actual limited daqMx simulated board
  • This device could then be accessed by other application thru daqMx
  • This API could have access to all channels of this simulated device.
  • This API could force, programmatically, the value of the simulated input channels according to a realistic process model

 

Something like this ...

 

 

 DaqMxSimulatedAPI.PNG

 

It would be great to develop software on 64bit Linux sytem using DAQmx.

Since we`re developing software for 64bit Linux this is a must for us - this means a 64bit Kernelmodule as well as 64bit libraries.

Just ran into a situation where I need to stream a lot of data to TDMS.  The only problem is that I need to store additional metadata with the channels.  I could go through all of the generated TDMS files and insert them after the fact, but this is kind of tedius.  I propose a way to add metadata to the channel.  My first thought was to use a variant input on the Create DAQmx Channel, but some of the polymorphics already have really fully connector panes.  So I am now thinking to just add a property to the Channel Property Node that is just a variant.  When logging to TMDS, the variant attributes can be put in the metadata of the channel.  Do something similar for the group so that we can have additional group metadata.

 

Metadata that I'm currently thinking about could include sensor serial number and calibration data.  I'm sure there is plenty of other information we would like to store with the TDMS file.

Hello,

 

For those of us who develop using DAQmx all the time, this might seem silly.  Nonetheless, I'm finding that users of my software are repeatedly having a tough time figuring out how to select multiple physical channels for applications that use DAQmx.  Here's what I'm talking about:

DAQmxChannels.png

 

Typically a user of my universal logger application wishes to acquire from ai0:7, for example.  They attempt to hold down shift and select multiple channels, only to assume that one channel at a time may be aquired.  For some odd reason, nearly everyone fears the "Browse" option because they don't know what it does.

 

 

While, as a developer, I have no problem whatsoever knowing to "Browse" in order to accomplish this, I was just asked how to do this for literally the fifth time by a user.  Thus, I'm faced with three choices: Keep answering the same question repeatedly, develop my own channel selection interface, or ask if the stock NI interface may be improved.

 

I'm not sure of the best way to improve the interface, but the least painless manner to do so might be to simply display the "Browse" dialog on first click rather than displaying the drop-down menu.

 

Please, everyone, by all means feel free to offer better ideas.  What I do know for certain, though, is that average users around here continually have a tough time with this.

 

Thanks very much,

 

Jim

 

When doing PWM with DAQmx, error -200684 is thrown if a 0% duty cycle is attempted.  For situations where a true 0% is needed, this is problematic. There are a few workarounds available, but some are less than ideal.  

 

The suggestion here is to pause the output if a 0% duty cycle is attempted.

Hello,

 

I recently discovered that the SCXI-1600 is not supported in 64-bit Windows.  From what NI has told me, it is possible for the hardware to be supported, but NI has chosen not to create a device driver for it.

 

I'm a bit perplexed by this position, since I have become accustomed to my NI hardware just working.  It's not like NI to just abandon support for a piece of hardware like this -- especially one that is still for sale on their website.

 

Please vote if you have an SCXI-1600 and might want to use it in a 64-bit OS at some time in the future.

 

Thanks,

Doug

 

 

It would be great if the full DAQmx library supported all NI data acquisition products on Windows, Mac OS X and Linux. The situation right now is too much of a hodge-podge of diverse drivers with too many limitations. There's an old, full DAQmx library that supports older devices on older Linux systems, but it doesn't look like it's been updated for years.  DAQmx Base is available for more current Linux and Mac OS systems, but doesn't support all NI devices (especially newer products).  DAQmx Base is also quite limited, and can't do a number of things the full DAQmx library can.  It's also fairly bloated and slow compared to DAQmx.  While I got my own application working under both Linux and Windows, there's a number of things about the Linux version that just aren't as nice as the Windows version right now.  I've seen complaints in the forums from others who have abandoned their efforts to port their applications from Windows to Mac OS or Linux because they don't see DAQmx Base as solid or "commercial-grade" enough.

 

I'd really like to be able to develop my application and be able to easily port it to any current Windows, Mac or Linux system, and have it support any current NI multi-function DAQ device, with a fast, capable and consistent C/C++ API.

 

Anyone else see this as a priority for NI R&D?

By default, DAQmx terminal constants/controls only show a subset of what is really available.  To see everything, you have to right-click the terminal and select "I/O Name Filtering", then check "Include Advanced Terminals":

 

Untitled 1 Block Diagram _2013-06-04_16-16-29.png

AdvancedTerminals.png

 

I guess this is intended to prevent new users from being overwhelmed.  However, what is really does is create a hurdle that prevents them from configuring their device in a more "advanced" manner since they have no idea that the name filtering box exists.

 

I am putting "advanced" in quotes because I find the distinction very much arbitrary.

 

 

As a more experienced DAQmx user, I change the I/O name filtering literally every time I put down a terminal without thinking about it (who can keep track of which subset of DAQmx applications are considered "advanced").  The worst part about this is trying to explain how to do something to newer users and having to tell them to change the I/O name filtering every single time (or if you don't, you'll almost certainly get a response back like this).

 

 

 

Why not make the so-called "advanced" terminals show in the drop-down list by default?

Hi,

 

I was suggested to post the issue with nidaqmx not supporting the upcoming version 3.9 of Python in this group. Here is my original post: https://forums.ni.com/t5/Multifunction-DAQ/Deprecation-warning-for-nidaqmx-using-Python/m-p/4051990/highlight/true#M99324

 

In short this is the warning currently seen:

DeprecationWarning: Using or importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3, and in 3.9 it will stop working

 

... it doesn't seem like an issue that would require a large effort to solve, so I hope this will be prioritized accordingly.

 

BR Jesper

 

 

I find myself quite often needing to modify the DaqMX tasks of chassis that aren't currently plugged into my system.  I develope on a laptop, and then transfer the compiled programs to other machines.  When the other machines are running the code and thus using the hardware I have to export my tasks and chassis, delete the live but unplugged chassis from my machine, then import the tasks and chassis back in generating the simulated chassis.  When I'm finished with the task change and code update, to test it I have to export the tasks and chassis, plug in the chassis, and re-import to get a live chassis back.

 

Can it be made as simple as right clicking on a chassis and selecting 'simulated' from the menu to allow me to configure tasks without the hardware present?

 

Thanks,

Brian

Certified LabVIEW Developer

GE Appliances

As documented in a previous post, it is currently impossible to install the nidaqmx-python library into a Docker container. Enabling this functionality would create an opportunity for software teams to build cutting edge big data pipelines for measurement instruments using container technology. This could also optimize development time by including custom DAQ code in continuous integration pipelines.

Hello,

 

Some of application needs voltage level of 3.3 V, 2.5 V & 1.8 V. (Low Voltage IC families).

In this case we need to operate digital/counter output at desire voltage level.

It will be good if NI provide it.

Also, with reference to following link,

https://forums.ni.com/t5/Data-Acquisition-Idea-Exchange/0-PWM-duty-cycle-with-DAQmx/idi-p/3819545

PWM output can be set to 0% duty cycle (Idle Low) & 100% duty cycle (Idle High).

 

BR & Stay Healthy

The DAQmx API is extremely useful; one especially useful part of the API is the automatic logging feature. This part of the API is efficient, easy to set-up, and largely bug free, well-done NI.

 

One problem with the automatic logging feature is the value of the t0. This value is determined by the system clock, which is the clock onboard the controller. A lot of PXI systems have the ability to use GPS modules or other timing modules. It would be good to use this clock instead.

 

In NI-Sync we can create an event at a specific time and use this to trigger the DAQmx data acquisition. It would be nice to use this "event time" instead of the system clock. There is a property in the DAQmx Timing Property Node, under Advanced, called First Sample Timestamp:Value Property. However, this property is read only, please change it to writable also. In this case we can then write an exact GPS time start to the data acquisition.

 

Below is one simple use case of the property node.

 

mcduff

snip.png

 

 

 

Counter tasks can only take 1 channel, due to the nature of timed signals, obviously. When setting up a system with 16 DUTs with counter outputs, this requires 16 tasks. Every single one has to be painstakingly created and configured. (As an aside: Defining a tabulator sequence still seems a mystery to NI's programmers, even though LabVIEW supports this)

Wouldn't it be nice to have a Ctrl+c,Ctrl+v sequence for tasks and then only modify physical channel? IMHO: yes.

 

KR

nimic

At the new client.. no shock to many of you I "Get around"

 

I explained to some of my new compadres the DAQmx "Tasks" need to be created once.... Preferably during development!

I even created a new task in MAX using the DAQmx wizard, Dragged it to the LabVIEW project explorer and all of that!

 

I even went so far as to name the "AUX" temperature channel "armpit"- Trust me, after 5 minutes delivering a .lvproj based on the "Contineous measuement and logging (DAQmx) project template" it was impressive to the client that the plot "armpit" showed 37C on the chart.  Guess where the thermocouple was.

 

So, Because I am that amazing, I showed them that they could Drag-n-Drop the Task to MAX and use MAX to monitor my armpit temperature.  I even showed them that MAX could show them the wiring diagram!

 

"HOLD IT"! they said, The wiring diagram is right there! On SCREEN! per channel! 

That is where I just about lost my mind!  They wanted to see this connection diagram for another Channel--- that worked! BUT there was no way to output that wonderful data!

 

"Can I create a Wiring Diagram for this channel, device or task?" were the next words out of their mouths.  I WAS STUNNED!  "Not today" I said, "I'll post that excellent idea!"

 

Hi,

 

it would be really nice to be able to set user defined scalings in MAX and daqmx-tasks.

It's possible to do this in common analogue input module like NI-9203, NI-9205 and so on, but I miss this option in NI-9212, NI-9217 and so on.

 

The goal is to set a calibrated scaling to several sensors to get best results and accuracy.

 

Thanks for upvoting my idea!

Yves

When a DI change detection task runs, the first sample shows the DI state *after* the first detected change.  There's not a clear way to know what the DI state was just *before* the first detected change, i.e. it's *initial* state.

 

This idea has some overlap with one found here, but this one isn't restricted to usage via DAQmx Events and an Event Structure.  Forum discussions that prompted this suggestion can be seen here and here.

 

The proposal is to provide an addition to the API such that an app programmer can determine both initial state just before the first detected change and final state resulting from each detected change.  The present API provides only the latter.

 

Full state knowledge before and after each change can be used to identify the changed lines.  (Similarly, initial state and change knowledge could be used to identify post-change states.)

 

My preferred approach in the linked discussions is to expose the initial state through a queryable property node.  The original poster preferred to have a distinct task type in which initial state would be the first returned sample.  A couple good workarounds were proposed in those threads by a contributor from NI, but I continue to think direct API support would be appropriate.

 

 

-Kevin P

The term "Incomplete Sample Detection" comes from DAQmx Help.  It affects buffered time measurement tasks on X-series boards, the 661x counter/timers, and many 91xx series cDAQ chassis.  It is meant to be a feature, but it can also be a real obstacle.

 

How the feature works ideally: Suppose you want to configure a counter task to measure buffered periods of a 1-channel encoder.  You use implicit timing because the signal being measured *is* the sample clock.  The 1st "sample clock" occurs on the 1st encoder edge after task start, but the time period it measures won't represent a complete encoder interval.  Reporting this 1st sample could be misleading as it measures the arbitrary time from the software call to start the task until the next encoder edge.

   On newer hardware with the "Incomplete Sample Detection" feature, this meaningless 1st sample is discarded by DAQmx.  On older hardware, this 1st sample was returned to the app, and it was up to the app programmer to deal with it.

 

Problem 1: Now suppose I'm also using this same encoder signal as an external sample clock for an AI task that I want to sync with my period measurement task.  Since DAQmx is going to discard the counter sample that came from the 1st edge, my first 5 samples will correspond to edges 2-6.  Over on the AI task, my first 5 samples will correspond to edges 1-5.

   My efforts to sync my tasks are now thwarted because their data streams start out misaligned.  The problem and workaround I'm left with are at least as troublesome as the one that was "solved" by this feature.

 

Problem 2:  Suppose I had a system where my period measurement task also had an arm-start trigger, and I depended on a cumulative sum of periods to be my master time for the entire system.  In this case, the 1st sample is the time from the arm-start trigger to the 1st encoder edge, and it is *entirely* meaningful.  On newer hardware, DAQmx will discard it and I'll have *no way* to know my timing relative to this trigger. 

   Older boards (M-series, 660x counter/timers) could handle this situation just fine. On newer boards, I'm stuck with a much bigger problem than the one that the feature was meant to solve.

 

So can we please have a DAQmx property that allows us to turn this "feature" OFF?  I understand that it'd have to be ON by default so as not to break existing code.

 

 

-Kevin P

"Without needing to clear "all" associated events, or EVEN opening MAX, I would like the ability to replace NI-USB Device "Doohickey123" serial number "junkgarbagestuff" with another NI-USB device of the same type-  perhaps a pop-up option like.... ""Replace no longer installed NI-53xx alias "gizmo"  with new NI-53xx?""  

 

Sure would help when I swap NI-xxxx devices amongst systems- especially the USB devices!