From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

Data Acquisition Idea Exchange

Post an idea

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

View All (2)

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: http://www.ni.com/product-documentation/54597/en/

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

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

View All (1)

AutoStart Property.PNG

Currently AutoStart is a feature of XNET that is not intuitively obvious. One of my co-workers was trying to test out the idea of having several queued sessions start with slight delays between them (using the Start Time Offset CAN Frame property). The code wasn't working properly due to preloading the array of frames to transmit using XNET Write (which caused some frames to transmit early). Note that a NI Applications Engineer on a support request was not able to figure out that AutoStart was the issue before the co-worker noticed the AutoStart property a few hours later.

Note that no documentation on XNET Write mentions the AutoStart Feature. The XNET Start VI context help doesn't mention it, but the documentation does indirectly mention being optional and points you to the AutoStart property's help for additional details.

I would recommend an optional input to XNET Write (defaulting to true) to activate AutoStart. This would match the DAQmx API's Write VI. It also would be a good idea to note that input sessions always start automatically somewhere in the XNET Read documentation.

View All (1)

This Topic is base on other topic in PXI Forum (Link).

The main problem is the Range passing the Min/Max limitation.

I would like to simulate a channels in "Nominal" Case.

1. The range should be based on the Min/Max limitation.

2. I could select input style (Sin Wave, Triple Wave, Random in sub range, DC with error range, based on external data,...)

3. Near to Real timing simulation include cases of sync between different channel rates.

Currently,

1. The range is limited to the Min/Max Values. Excluded the cases show below.

2. Only Sin Wave. Excluded an Odd Case show below.

3. I tried case of sync between 2 channel with different rates. the simulation is not close to the real DAQ case.

Here are the cases from the PXI Forum (Link😞

1st problematic case

1. Define a Simulated Device - PXIe-4353 in MAX.

2. Open "Test Panel"

3. Use the default parameters of the test:

a. Measurement type - thermocouple

b. Max Input Limit - 100

c. Min Input Limit - 0

d. Units - Deg C

e. Thermocouple type - J

f. CJC Source - Built In

4. Click Start.

The result is Sin Wave.

The sample values range ~[-1030,-74.7], out of the Max/Min Limits.

=> BAD sample results, values lower than -273 C ?!?!?!?!

2nd Problematic Case

If I change the Max/Min Limits to other valid range like [-200,1200]

The sample values range is BAD

And, the result is some kind of Non-Sin Wave

3rd Non-temperature Case

If I change the Measurement type to Voltage.

The sample values range is based on the Max/Min Limits.

=> So it is OK

Tnx,

Raz

View All (1)

View All (3)

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)

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

View All (6)

Today, we can create a DAQmx custom scale in MAX or Labview via the "DAQmx Create Scale" VI. This VI changes a pre-scaled value, e.g. 5Volts, to a scaled value in a physical unit, e.g. 100Newtons. This scale can be Linear, Map Ranges, Polynomial or Table.

For all of these four options, only a mono-channel sensor can be used.

However, multi-channel sensors are not so rare and there is actually no way to scale a 6-components load-cell, for instance. For this kind of transducer, F = M*U where F is a 6-components vector including the 3 forces in Newtons and the 3 moments in Newtons*meters, U is a 6-components pre-scaled vector including the 6 input channels in Volts and M is a 6*6 matrix. M is never diagonal, because the forces affect the moments.

Finally, what I'd like to have is an extension of the "DAQmx Create Scale" VI which could enable a multi-channel pre-scaled input to be scaled in physical units through a matrix.

Thanks.

This is something I had to design for our company's test benches because nothing existed off-the-shelf. (What does exist off-the-shelf is beyond incredibly expensive.) It's a card chassis holding 4 cards with 8 individual (5 amp) relay channels per card. Each relay channel has eight selectable sources or sinks. In our case, we have V+ (from a programmable bench power supply), ground, 4 individual resistive dummy loads each with analog DAQ channel, digital input, and an external header connector. There are four programmable 50 watt resistive dummy loads ranging from 1 ohm to 255 ohms. There are also two analog output channels. All of the switches, power supply, and dummy loads are controlled from a PC serial port (I would use USB now, if I had a chance to re-design it.) The inputs are all fed to a PCI-6221 and a PCI-6514. Again, if I had a chance to re-design it, I would ditch the PCI cards and use an FPGA with several A/D converters and digital opto-isolators. I would also consider getting rid of the mechanical relays and try solid-state relays, although we have not had a relay failure in any of the 292 relays (per chassis) in over ten years of daily use.

Something like that, only more widely expandable would be very useful to anyone testing a wide range of devices with different signal connections and high output currents. I would design these myself to sell, if I were more ambitious.

View All (4)

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

Available configuration parameters stored & read from device

Copy and Paste tasks in NI-MAX

Let FlexLogger use Global Virtual Channels

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

Make First Sample Timestamp Property Writable

4 port USB CAN Interface Device

AutoStart Should be an Input to XNET Write

0% PWM duty cycle with DAQmx

Range Problem with Simulated PXIe-4353

Additional sensitivity units for accelerometers in NI MAX

Expand Number of inputs on 9218 Card

Problem with unknown initial pre-change DI state in Change Detection tasks

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

Add RSI Support to 9361 for Scan-Mode in EtherCAT 9144/5 Chassis

DAQmx Create Scale VI for multi-components sensors

MAX system profiles

One task for every analog output

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

Track Entire History of Recording in DAQExpress

Hardware idea: High current switching matrix and multi-channel dummy loads