Data Acquisition Idea Exchange

Post an idea

allow scales to be copied

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 ...

View All (3)

NI-MAX SWITCH channel connection colors

View All (1)

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.

View All (5)

Add LabVIEW events based on hardware

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?

View All (4)

Hi!

PCI Express bus became more and more popular.
PCIe has a new type of interrupts - MSI/MSI-X.
Today VISA driver is able to work only with old style interrupts (Legacy).

Let me explain the main difference:

Legacy interrupt mask intA/B/C/D signals (these signals was in PCI bus, but not exist in PCIe bus).
These signals (for PCIe actually packets with Message setA/B/C/D) are shared between all PCIe devices.
So VISA driver spend a lot of time when it looks who produced this interrupt.

MSI interrupt is actually a Memory Write packet to preallocated address.
In this case VISA should already know which device produced this interrupt.
Also MSI interrupt can contain different interrupt vectors inside of Memory Write packet. So it would be very helpful to get access to vector value too.

Requesting MSI/MSI-X interrupts support to VISA driver.

Thanks a lot!

View All (4)

When I drop a DAQmx Task constant on my LabVIEW block diagram, I have the right-click menu option to Generate Code >>Configuration

This scripts out a sub.vi that creates the Task by adding each channel with channel specific properties sequentially, one channel at a time, to repeated calls of DAQmx Configure Channel.vi.

I have a hard time saving that vi output! I have not really learned how to name it properly without Using: "BLEEP_BLEEP_BLEEP_Configuration_that_cannot_be BLEEPING_scaled.vi"

I believe that an autoindexing loop would be much nicer.

My grandmother thanks you for improving my manner of speach.

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":

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?

View All (2)

0% PWM duty cycle with DAQmx

MAX system profiles

View All (5)

When using TDMS on cRIO systems, there are a couple of considerations that doesn't normally play in too much when storing data as TDMS files and they are:

* The current version of the file system used on cRIO controllers degrades significantly in performance if -any- folder on the cRIO contains more than ~100 files. (work-around> more elaborate folder structures, but a lot of this structuring would be only to work around this shortcoming of the (old) version of the file system

* The drives are SSD with limited life-length and wear-leveling etc. Writing and re-writing these index files add un-necessary overhead and wear on the disks

* They use up space which is (very) limited on some cRIO's (even if not much). (people may be quick to point out that you can add a thumb-drive, but down-sides to that is the thumbdrives (as far as I know) needs to be FAT. Compared to storing on the cRIO file system which is atomic and fail-safe where you pretty much don't have to worry about sudden power outages and interruptions mid-write.. on a thumb drive you would have all these issues that could worst case corrupt your whole thumb drive.)

I propose to add a boolean (default to false) on the TDMS Open called "supress writing tdms index to disk" or some smart name along those lines. What this would do is still allow for the tmds index to be created, but it will remain in memory only and never be written to disk. When the TDMS Close is called, the memory is released and the tdms file is written to disk without the index file. If the same file is opened again, extra time would be needed since the index file would be re-created (again in memory only if boolean indicates this), but I think for the most part this overhead would be more than acceptable.

I'm not sure how "simple" modifying the TDMS open and close functions would be, but I do know that there are many cases where this flag would make sense.

View All (2)

View All (5)

We need a way to query an output task to determine its most recently output value. Or alternately, a general ability to read back data from an output task's buffer.

This one's been discussed lots of times over the years in the forums but I didn't see a related Idea Exchange entry. Most of the discussion I've seen has related to AO but I see no reason not to support this feature for DO as well.

There are many apps where normal behavior is to generate an AO waveform for a long period of time. Some apps can be interrupted unexpectedly by users or process limit monitoring or safety range checking, etc. When this happens, the output task will be in a more-or-less random phase of its waveform. The problem is: how do we *gently* guide that waveform back to a safe default value like 0.0 V? A pure step function is often not desirable. We'd like to know where the waveform left off so we can generate a rampdown to 0. In some apps, the waveform shape isn't directly defined or known by the data acq code. So how can we ramp down to 0 if we don't know where to start from? This is just one example of the many cases where it'd be very valuable to be able to determine the most recently updated output value.

Approach 1:

Create a DAQmx property that will report back the current output value(s). I don't know if/how this fits the architecture of the driver and various hw boards. If it can be done, I'd ideally want to take an instantaneous snapshot of whatever value(s) is currently held in the DAC. It would be good to be able to polymorph this function to respond to either an active task or a channel list.

Approach 2 (active buffered tasks only):

We can currently query the property TotalSampPerChanGenerated as long as the task is still active. But we can't query the task to read back the values stored in the buffer in order to figure out where that last sample put us. It could be handy to be able to query/read the *output* buffer in a way analogous to what we can specify for input buffers. I could picture asking to DAQmx Read 1 sample from the output buffer after setting RelativeTo = MostRecentSample , Offset = 0 or -1 (haven't thought through which is the more appropriate choice). In general, why *not* offer the ability to read back data from our task's output buffers?

-Kevin P

Every n encoder pulses callback

It is a frequent requirement to make measurements on production lines. Position on these is often tracked with Rotary Encoders https://en.wikipedia.org/wiki/Rotary_encoder . Many NI devices can accept the quadrature pulse train from such a device, and correctly produce a current position count. The information in the 2 phase pulse train allows the counter to correctly track foward and reverse motion.

What would be very useful would be a callback in NI-DaqMX that is called after every n pulses, ideally with a flag to indicate whether the counter is higher or lower than the previous value, i.e. the direction.

This has recently been discussed on the multifunction DAQ board here: http://forums.ni.com/t5/Multifunction-DAQ/quadrature-encoder-based-triggering/td-p/3125468 . So I am not alone in requesting something more programmer friendly than the workaround offered there.

wish: Linux support for DAQ

View All (2)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

Data Acquisition Idea Exchange

allow scales to be copied

Interactive DaqMx simulation interface ... (Popup panels for simulated hardware) ... Or better, DaqMx Simulation API for process simulation ...

NI-MAX SWITCH channel connection colors

Additional TDMS Metadata

Add LabVIEW events based on hardware

Full cross-platform compatibility for DAQmx

Add MSI/MSI-X interrupts support to VISA

Support installation of nidaqmx-python in a Docker container

Support dynamic events for all driver...

Change DAQmx Generate Code >> Configuration output vi

Show "Advanced" DAQmx Terminals by Default

0% PWM duty cycle with DAQmx

Create simulated version of real device by right-click in MAX

MAX system profiles

Supress storing .tdms_index files (useful when generating logs on cRIO and other SSD devices)

Change Detection Event Should Include Line Information

Support for Absolute Encoders in NI Motion or SoftMotion

AO, DO - query for current output value

Every n encoder pulses callback

wish: Linux support for DAQ