Data Acquisition Idea Exchange

Top Authors

User

Kudos

Post an idea

New option for number of samples per channel

Screenshot from the help for number of samples per channel for a Read task :

Please add an option for a continuous sample task to read all currently available samples (-1) but with a wait for a minimum number of samples (#min). Behavior of this configuration :

#available samples >= #min : read all available samples
#available samples < #min : wait until #min samples are available or until timeout

This would be very useful in several cases. For example :

No extra coding to handle or avoid the error that appears if 0 sample is available.
Avoid the use of a wait function in the loop to ensure a minimum number of samples are available.

View All (5)

Touch Screen For PXI

Hey all,

Just passing an idea for some new HW and SW for the PXI and LV. I think a touch panel PC monitor would be an ideal O/P for a PXI as you could plug it in the back and eliminate the use for a mouse and keyboard whilst using the PXI chassis. This also leads onto my second idea, the creation of a front panel customization tool kit. This tool kit will enable users to easily customize the front panels of their VI's much in the way a function pallet would work. This way you are able to quickly customize your front panel to suit the end users needs.

H-Def Video Frame Grabber

I have a USB-6509 and a USB-8951 connected to a computer through an external USB Hub. MAX locks-up hard when I disconnect the External USB Hub from the computer, always requiring a reboot. When I connect/disconnect the individual devices on the other side of the External Hub, leaving the External Hub connected and powered, I do not get any problem.

Should there be problems when the External Hub is connected/disconnected, instead of the individual devices??? I'm thinking this is a "USB Problem", but the Windows Device Manager seems to roll smoothly with all the connection/disconnection variations. It is MAX (and any subsequent LV prog) that has the hangup.

Any ideas? Thanks!

The request is for NI to prioritize development of VIs that allow integrators’ CAN data to be measured and stored in standardized formats.

While TDMS and XNET are decent tools, it’s lack of modern development and open compatibility in industry makes it somewhat difficult to deal with. NI could probably expand and service its user base if it supported XNET and MDF4 better.

Currently our process is as follows:

LabView XNET data comes from the cRIO FPGA (eg. NI-9853) as an array of 6 U32s

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PASzSAO&l=en-CA

LabView XNET default data structure is the typdef ‘XNET Frame CAN.ctl’

See XNET help ‘XNET Convert (Byte Array to Frame CAN).vi’
There are obscure (near obsolete) VIs or the end user must write code to convert from 6 U32 to XNET Frame CAN on poor documentation.

As an aside, there doesn’t seem to be a clean standardized way to store either of these structures in the TDMS files

There is a way to configure a TDMS channel for CAN frame logging, but it is not easy for signal post processing because it is only one channel of frames.
We believe a much better way would be something like this if we stuck with TDMS.

However as to this feature request we have found that the industry standard MDF4 file format to be advantageous in most aspects.

Our tests found that a 1 hour 1.1GB raw CAN frames and analog data TDMS file could be stored as a 200 MB file in the compact MDF4 file ! When the CANbus data was expanded into actual signals, the MDF4 file was 900 MB (still less than the raw TDMS). Further this MDF4 file loaded into FAMOS for review in ~1 sec !

We would prefer to output directly to MDF4 rather than having to script this conversion process.

One key detail is the storage of raw CAN frames such that other industry tools (eg. MATLAB, FAMOS, PYTHON, MDFvalidator, ASAMmdf GUI) can natively interpret and process with various DBC files (the standard includes tools to extract CAN signals).
Secondly with high channel counts of fast sample rates, the file size quickly becomes enormous. MDF4 allows excellent compactness, further compression, and usability of data (including but not limited to CAN).
However, NI’s DataPlugin needs work as it fails to read much of the structure, properties and data of MDF4 files (as seen from ‘Data File Viewer.vi’ utility below). To unlock the true power of MDF4, the CAN frame has to be written correctly. Currently this is impossible.
We were surprised that NI as an ASAM member had not fully supported the MDF4 format.
LV vs. free ASAMmdf GUI
Vector’s free MDFvalidator tool useful for seeing the file structure

APPENDIX: here are some links and resources to summarize importance of MDF4 file format.

Link to the standard’s homepage ASAM MDF [asam.net]
Link to the MDF4 format’s documentation asammdf "7.3.14" documentation [asammdf.readthedocs.io]
Link to a founding company’s page Measurement Data Format MDF | Vector [vector.com]
Link to NI MDF4 plugin showing features https://www.ni.com/pdf/manuals/asam-ev-dataplugin-mdf4-2023-q3.html (note that #10 ByteArray is not supported).
Why MDF4 is Popular for Testing:
- Efficient Storage: As a binary format, MDF4 allows for the efficient storage of large volumes of data, which is crucial in extensive testing scenarios.
- Standardization: Being an ASAM (Association for Standardization of Automation and Measuring Systems) standard ensures interoperability between different tools and systems used in the industry.
- Metadata Support: MDF4 allows for the inclusion of rich metadata, providing context and facilitating the interpretation of the raw measurement data. This includes information about the signals, units, and test conditions.
- High Performance: The format is optimized for fast read and write access, which speeds up the analysis of large datasets.
- Flexibility: MDF4 supports various data types and allows for extensions, making it adaptable to evolving testing needs.

View All (5)

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.

Note: this might only be relevant & useful for multiplexing AI devices.

It was an important technique used to investigate channel-to-channel ghosting influence on a multiplexing device. For example, suppose you had a large signal A and a small signal B. You could set up a channel list to read "A,B,B,B,B", and thereby *investigate* the trend of these successive readings of the same channel and use *evidence* to determine when the ghosting influence had dissipated. THIS WAS IMPORTANT!

I recall hearing of others use the capability to be able to get faster sampling for one of their fast-changing channels, using a channel list along the lines of "A,B, C,B, D,B, E,B".

The feature that used to be supported on multiplexing MIO devices as far back as I could remember working with NI DAQ products. I only recently discovered that such support was inexplicably removed from DAQmx sometime in the last few years, now producing a fatal task error. I tested a few available systems and found that it was still supported under DAQmx 16.0, not supported by DAQmx 18.1, and not yet restored as of DAQmx 20.1. (All verifications were done with desktop or PXI X-series devices.)

Why was this ability taken away? Stop being so overzealous trying to protect us from ourselves! Multiple readings of the same channel is a legitimate and sometimes almost necessary technique. Maybe you lacked the imagination to understand why we'd want this, but guess what? We knew what we were doing. So stop stopping us.

-Kevin P

Shared Variable - Validate Scale

So I have a cRIO with a 9203 mA input module. I also have sensors etc that are 4-20mA. So when it came to using the scaling feature of the shared variable as below see if you can spot the bug.

So I was thinking in mA from sensor to mA input to the 9203 which is a mA module - but the RAW scale is in Amps! (Which is obvious once your colleague points it out!) Consequently I wasn't seeing any signal readings from the cRIO as 20mA << 4A.

Since there is an error if you get Full and Zero around the wrong way... can there also be an error or warning if its outside the range of the module?

Regards

Nick

Download All

View All (2)

XNET Sessions as Task

View All (7)

Basically, FlexLogger limits the range of readings to the values used in the 2 point calibration. For example, if your sensor has a range of -10 to 10 PSI, and the 2-point cal is done at +/- 10 PSI, FlexLogger will only display values within +/- 10 PSI (and will saturate otherwise).

I totally understand why this is done, but sensors in fact DO read above (and sometimes below) their stated ranges and have documented accuracy (i.e. 1% above 95% full scale) , so clipping the value to the scaling settings in the cal page is the wrong thing to do...the sensor can still be measuring correctly, but FlexLogger will only show the saturated value.

The scaling, however it is done, probably result in a Y=mX + b equation, and FlexLogger should display Y, whatever Y is, regardless of stated sensor range or 2-point cal/scaling.

A worse case is if the sensor has a range of +/- 10 PSI but your cal/verification system is only capable of +/- 5 PSI, you will be limited to +/- 5 PSI with the FlexLogger 2-point cal implementation.

Yes, there are way around this, but why should the user, usually technicians who don't necessarily understand the math or ins/outs of software, have to figure out a way around FlexLogger?

View All (1)

DAQ MX run-time

Future Time Events in Event Structure

Not sure if this should be in another category, but here is the idea.

In DAQmx you can register for events like Change Detection Event, Sample Complete Event, etc. These events occur in the Event structure.

Idea: Extend this capability to NI-Sync.

For example allow a future time event to occur in an event structure, instead of firing a TTL pulse. The steps would be:

1. Create a new NI-Sync instrument driver session;
2. Read the current time of the clock;
3. Define when the event will be generated by introducing a delay to the current 1588 time;
4. Program when the event will occur at the specified time;
5. Register for Event
6. Event Occurs - do something.
7. Clean Up

See below for diagram.

mcduff

I can't say I've investigated this at all, maybe it's already moving this way; all hardware should have it's own available parameters stored on-board, available to be read back by software, for example on startup. Things like available, valid, ranges in volts, current, frequency, channels etc...

It would always be a good idea to read those parameters from hardware by software, instead of relying on model number, manuals, drivers. Then, software could easily adapt to different models of the same main type. Plug in a new hardware and it would announce what it's main capabilities are.

My2c

Hi,

I am aware of the previous idea here on a filter for the USB DAQ devices, this time I propose a different solution.

Some cDAQ moduls include an anti-aliasing filter, see a documentation here: https://www.ni.com/en/support/documentation/supplemental/18/c-series-modules-with-anti-aliasing-filters.html

In many cases our cDAQ and cRIO system could be the solution to higher frequency (100 kS/s - 1 MS/s) voltage signal acquisition if the signal could be (from LabVIEW) programmatically conditioned prior acquisition. Two main processes are required most: amplification/attenuation and filtering.

I think amplification/attenuation is a trivial processing step, I just mention here a flat frequency and phase transfer requirement in the working range, allowing a bypassing of this stage.

Filtering is a little more challenging. My proposal is a "tunable" anti-aliasing filter, fo the sake of simplicity with one programmable cut-off frequency and fixed roll-off charasteristics. Similarly high pass and band pass filters could be implemented but these are just nice-to-have features. Please note that all filters should be in hardware, e.g. some ASIC before any ADC.

Thanks for your attention

Cheers

Istvan Pinter | Sales Development Engineer, EMEIA

4 port USB CAN Interface Device

View All (1)

View All (3)

Expand Number of inputs on 9218 Card

Currently there are only two options available if you want a C-series card that has ±10V analog inputs with internal excitation voltage. Both of the available options have serious limitations which makes them impractical in dynamic testing environments.

9218: With two input channels, it is impractical for large channel count testing. As an example at our test facility, we may run 60 analog channels which would require 30 of these cards. That would require 4 cRIO chassis'

9219: With a max sample rate of 100 s/s, it cannot be used in a dynamic environment to accurately record data.

There are two options that would be very beneficial to dynamic testing:

1) Add more input channels to the 9218 card so that high channel count tests don't need 3+ cRIO's.

2) Make a new card similar to the 9218 with less capability but more input channels (No bridge, no IEPE, no ±20mA).

For example:

± 5V, ±10V, ±60V Input Range

± 1V, ± 5V, ± 10V Internal Excitation

Minimum of 4 analog input channels.

Sample Rate 5 Ks/s

Does anyone else have a need for a card like this?

View All (2)

Data Acquisition Idea Exchange

New option for number of samples per channel

Touch Screen For PXI

H-Def Video Frame Grabber

External USB Hub Connection/Disconnection

Add functionality to write CAN frames to MDF4 files

Change DAQmx Generate Code >> Configuration output vi

Restore ability to include multiple instances of same AI channel in a task

C series CAN interface module without external power supply

Shared Variable - Validate Scale

User defined scalings for all NI-temperature modules

XNET Sessions as Task

FlexLogger's 2-point calibration implementation is flawed

DAQ MX run-time

Future Time Events in Event Structure

Available configuration parameters stored & read from device

Signal conditioning modul in NI C Series incl. anti-aliasing filter

4 port USB CAN Interface Device

Additional sensitivity units for accelerometers in NI MAX

Expand Number of inputs on 9218 Card

NI Digital Waveform Editor needs to allow cut and paste within signal name entry window