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

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
While running a test I developed I noticed an odd DAQmx behavior.  After a USB 6212 connection was momentarilly interupted all read and write tasks associated with the device hung until the USB cable was disconnected.  It would have been easy to code around if there was a Dev connection event and a Dev disconnection event that I could use to pause operations and trigger a Device reset.  Since the devices are PnP couldn't the DAQmx API simply make the system hardware connect/disconnect events visable?

Hello All,

 

I would like to know that, why XNET sessions can not be configure in NI-MAX?

It will will be great, if developer can create session in MAX, and use in VI like DAQmx tasks.

 

BR,

Aniket Gadekar. 

With NI 9234 board you can use 4 IEPE sensors but you don' have IEPE open/short detection capability.

NI 9232 board has IEPE open/short detection capability but has only 3 channels.

 

I think that a board with 4 channels (as 9234) and an IEPE open/short detection capability would be great!

When it comes to documentation of an measurement, you need to report ALL settings of a device that effects that measurement.

From a core memory dump written as a hex string to a XML document.... anything that shows up a difference in the settings that affect the measurement would be fine for documentation.

Something like a big property node readout followed by a format into string .... but make sure not to miss a property.... and a bit more complicated when it comes to signal routing....

 

A measurement that isn't sufficiently documented is all for naught. 

or

Just think of a nasty auditor 😉

 

It's so easy to make measurements with LabVIEW, please make it easy and consistent to document it.

 

Example:

A quick measurement setup with the DAQ-assistant/Express fills Gigabytes but after a certain time they are useless because nobody knows how they where taken. A simple checkbox could add all this information in the variant of the waveform. (or TDMS or ...) even if the operator don't have a clue of all the settings that affect his measurements.

 

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?

There is currently no API available to develop applications that will use the functionality of the GPIB Analyzer. There are customers who would like to be able to monitor the GPIB bus from LabVIEW, so this would be helpful.

Since version 19, NI stopped distributing the "run time only "installer of DAQ MX. This is a terrible idea.

Here is the thread where no good solution was given.

https://forums.ni.com/t5/Multifunction-DAQ/DaqMX-19-0-runtime/m-p/3994378#M98483

 

Please, NI, if you find it easy enough for the user to build an installer, do it yourself, like you did before.

Would like to be able to collect a couple channels of analog inputs to the iPad.  This is nice but I need a minimum of 2 analog inputs and I would rather have NI:  http://www.oscium.com/

 

Response from coorporate:

"We don't currently have anything that would meet the customer's requirement of being able to plug in directly into the iPad for data acquisition.

I don't believe that the iPad supports Silverlight which is a framework developed by Microsoft.  Also, wireless DAQ has to communicate with a host running DAQmx, so the customer would still need a 2nd computer even if using wireless DAQ.

If you want to connect data acquisition hardware (of any form-factor) to a machine running LabVIEW and DAQmx,  then use LabVIEW Web Services to publish the front panel to the web and view/control it from his iPad.

We do have several USB products that will work with Windows-based netbooks that could be an alternative solution if topic is open to a non-Apple platform.  For example, the 5132/5133 are bus-powered digitizers with much higher sample rate, bandwidth, and buffer size compared to the Oscium device.  However, the price is also quite a bit higher."

NI provides some 100-Pin-DAQ devices, e.g. one for INDUSTRIAL DIGITAL IO

https://www.ni.com/en-us/shop/model/pci-6515.html

 

But why doesn't you offer also a basic connector block for a reasonable price, especially for industrial applictations, where it is common to wire (DIO) signals through DIN rail mounted terminal blocks?

 

This connector block should have the following features:

 

- DIN rail mountable

- simple wire connection, best with spring terminals

- 100 Pin-cable connection

      (https://www.ni.com/en-us/support/model.sh100m-100m-flex-cable.html)

- relatively small for installation in a switch cabinet

- no signal conditioning, just clamps

- much cheaper than then currently available SCB-100 block

 

Please see also this related idea:

http://forums.ni.com/t5/Data-Acquisition-Idea-Exchange/Terminal-Block-layouts/idi-p/2160542

 

Regards

A-T-R

 

The possibility to use simulated devices, so that you can design software without having the hardware available is very nice.  Sometimes, specific signal profiles are needed.  It can be tested using additional software, but you really have to change the software (add test-software in the code).  In some cases this is not wanted.

Therefore adding in DAQmx a possibility to force specific output can be very helpful.  Different possibilities exist (TDMS-files, LlabVIEW(/compiled LabVIEW)-code, ...).  Different people will want different possibilities, but some extra possibilities are useful.

I am using DAQmx Physical channel controls in user Interface to select the particular DAQ modules.I would like to display only the particular type (AI,DI,AO,DO.....) of modules which is connected in the system.For example i need to display only, DO-NI-9477 cDAQ modules in the physical channel not the other DIO models like NI 9403...IO name filtering option not useful to filter the other models which is same type.

 

That should be great if NI provides the option for filtering the modules name based on their  product type or user configurable naming (for example, if cDAQ1 device renamed as "DEV1" means user can enter filter the device based on the string "DEV").

I would like to have an programmable gain amplifier in the analog output path that I can use to adjust the amplitude of an output signal.  In control applications, this would be much better than having to stop a continuous task, reload the data with a new amplitude, and start the task again.

 

Ideally, for some of my applications, it would be nice to be able to generate a basic waveform scaled to +/- 1V and then have a property that I can write to while the task is running to set the gain.

When I want to do an installation build of my project, I have to include the whole NI-daqmx into my build in order to insert my (in this case) USB-6251-driver. Thus my install package expands from about 150 MB to more than 1 GB. This is way to much!

 

It would be nice to be able to choose only the wanted driver (in my example the NI-6251 and the SCC68) in the "adding additional driver's" menu and just add this one to the distribution instead of "adding them all".

 

Many users (such as our customers) expect from devices in the mid-price segment like the USB-62xx family a proper input signal handling adapted to the selected input sampling rate.

 

Proposal:

Include anti-aliasing filters in mid-class hardware,such as the USB-62xx family. As an immediate action, please include at least a warning remark in the user manual of the devices.

Every application with variable sampling rate needs appropriate and adaptable input signal filtering.

Many NI DAQ devices do not contain anti-aliasing filters corresponding to the sampling frequencies (e.g USB-62xx family).

Signals containing higher frequency components than nyquist frequency will be folded to lower frequencies causing wrong spectrum information.

Many applications need different sampling frequency settings but use the same external hardware. In these cases, hardware including filters have to be designed for the highest possible frequency. This situation leads to unrecoverable errors in the frequency spectrum, if input signal components do not meet the nyquist criteria.

 

Thanks

Klaus

www.rfbeam.ch

 

 

 

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

FutTimeEvent2.jpg

There is a need for a quick low cost device to controlling/communicating with the popular low-voltage differential signaling (LVDS).  There is a need for transmit only, receive only, and transmit/receive USB devices.  The current solution is to buy the NI USB-6501 and build a daughter board with TTL-LVDS ICs on it to interface to digital equipment in the military/defense industry. Lots of time and energy is wasted on designing, building, and cabling boards as as additional interface step, where a simple USB solution could be made available.

I could use a USB X series multifunction device with more than 4 AO analog output channels.  My current application does not require them to have waveform generation capability.  There are devices available with more than 4 AO but I need AI and DI/DO and CTR as well and prefer them all on one device.

 

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

I use Daqmx a lot for writing .NET based measurement software.

 

Whereas the API itself is quite decent, the docs are horrible. Accessing them is convoluted at best, requiring the VS help viewer. Almost nothing is available online and decent examples are quite scarce, which will definitely be an issue for absolute beginners...

 

This definitely deserves some attention!

 

Cheers,

 

Kris

Currently it is hard to find out whether a property can be set for a specific channel, or only per module. An example is the Strain Gauge Excitation property, which can only be set per module. Other properties can be different per channel.

 

Idea: Add a device specific comment in for example Max, about the different properties.  For example:

 

MAX idea.png