NI Home > Community > NI Discussion Forums

Data Acquisition Idea Exchange

Showing results for 
Search instead for 
Do you mean 
Announcements
The NI Idea Exchange is a product feedback forum where NI R&D and users work together to submit ideas, collaborate on their development, and vote for the ones they like best. View all of the NI Idea Exchanges to post an idea or add your opinion on an existing one today!
New Idea

The vast majority of my working life is spent with RIO devices or midrange X series cards, but I often come across applications where an inexpensive, reliable DAQ would be handy for low level tasks - monitoring presence sensors, measuring voltages at moderate precision and slow speed, providing interlocks for material storage bins etc.

 

Traditionally, you'll see a lot of USB 600X units being used for applications like these. However, running on USB has a few associated problems: unreliability of the Windows bus, cable strain relief on USB connectors, mounting of USB 600X units, connection type. Don't get me wrong, you can do a lot with these units but they're not an ideal, inexpensive solution for production processes.

 

There's a jump between the functionality of these USB units and X (or even M or E for the vintage crowd) series cards. The only thing that's really in that range anymore is the B series PCI-6010 card, which has the fantastic benefit of using a 37W DSUB connector too, but is a little limited in terms of channel offerings and the like.

 

I'd like to see the B series range revived to provide products that fit between the PCIe-6320 and the USB 600X devices, providing non-USB connection and preferably with a DSUB backplane connector for cost and ease of use. This would provide a more reliable offering for simple acquisition tasks in the industrial environment at a cost-effective price point.

We mostly develop PXIe based high speed (RF) applictions which stores data on one or more RAIDs.

Several customers already asked for a high speed ethernet connection do move this data over the net.

 

Yet there is only one PXIe 10 GBE availible and it is NOT from NI.

We would already need a 40 GBE solution the comming year.

 

PCI Express 40 GBE ist almost commonly avalilible, a mezzanine board solution would be sufficient if nothing else works.

But there is no carrier board availibe, too.

 

I feel kind of left alone with all this data, waiting on those bigg RAIDs for beeing processed / copied.

 

 

0 Kudos

Currently with a multislot chassis, the system will operate at the requested sampling rate even if that rate is above the maximum supported by the module.  In this case, the chassis will replicate the additional required data points from the previous sample, and will not return an error in NI MAX.  With a single slot chassis, this is not an option.  However, it would be helpful if this feature was also supported with the single slot chassis so that data could be replicated at a higher sample rate without returning an error message.

 

Relevant KnowledgeBase article: Why is My Slow Sampled C Series Module Able to Operate at a Higher Sampling Rate than the Specified ...

 

 

 

 

0 Kudos

Chrome Book Capability

Status: New
by Member ellelorica on ‎03-18-2015 12:20 PM

Currently my entire school district is going 1:1 with chromebooks for your students. This is also happing in many other schools around the country. It would be awesome if you could develop a way for your programs to be based off a "cloud". This would allow for students to use the programs at home and in different locations around the school, not just a "computer lab" that has the software loaded onto it. 

Create a new ±60 V version of the NI9205 C-Series Module

Status: New
by Member crcragun ‎03-12-2015 02:32 PM - edited ‎03-12-2015 02:33 PM

Currently there are only two options for acquiring +/-60V input signals:

NI 9221: 8-Channel, ±60V, 12-Bit Analog Input Modules ($582)

NI 9229: 4-Channel, ±60 V, 24-Bit Simultaneous,Channel-to-Channel Isolated Analog Input Modules  ($1427)

 

I would like to see a new module provided that is identical to the NI9205 (32-Channel Single-Ended, 16-Channel Differential, ±200 mV to ±10 V, 16-Bit Analog Input Module, $881) but with an input signal range of ±60 V.

 

 

cRIO support hardware module for LVDT input

Status: New
by Member Gearmiester on ‎02-10-2015 11:22 AM

While I realize that there is already a third party option for this, it only makes sense that NI open an option for the cRIO users out there that can do what this module does...

 

http://sine.ni.com/nips/cds/view/p/lang/en/nid/4309

 

in a cRIO platform module. That way we can have a North Anmerica source for this very important data input device.

 

Optimally two - four channel input on a single module design.

0 Kudos

We're running to issues on a regular basis where the 8360 card to the laptop comes out, get's moved etc. Once the connection is lost, a reboot seems the only way to establish a connection again. This results in too much wasted time.

 

Not knowing what lies beneath and the complexities involved, is there any way to make a hotswappable HW for a PXI connection for laptops?

 

 

0 Kudos

ANT/ANT+ Support

Status: New
by Member jfalesi on ‎12-09-2014 04:42 PM

Hello.  I'm working on an app to interface with a couple of ANT devices (Garmin Vector, Garmin heartrate monitor).  I've seen a couple of posts on this topic but nobody has posted code.  I talked to Frank Lezu at an NI day in DC a month or so back and he recommended I post about it here.

 

Anyone else looking for ANT/ANT+ support?  I'd be happy to share my code when it's not in a ridiculously embarrassing state but for now see this post for a braindump of my progress.

 

Thanks,

-Jamie

NI-DAQmx and NI-Rio driver package size

Status: New
by Member Labuser16383 on ‎12-05-2014 02:51 AM

The size of for example the NI-Rio driver package is 4GB in the most recent version which is comparable to size of common operating systems. This is too much in my opinion if someone needs only a specific driver for a specific NI hardware. Therfore i suggest granularity reduction of driver packages to a more mouth friendly morsel (for ex. 200MB max).

 

Many CAN protocols require a byte in a cyclic message to be incremented each time the message is sent (this is often byte 0). I might have read somewhere that this is possible with VeriStand but I am not using it. So when using only LabVIEW and the NI-XNET API, the only way to achieve this is to call the XNET Write function to manually set the value of this byte. But having to call the API each time the message should be sent removes all the benefits of cylic messages... Moreover LabVIEW can't guarantee the same level of speed and determinism (if the message is to be sent every 5ms for example).

Being able to configure a signal to be an auto-incremented counter would be a huge improvement. To me, this is a must-have, not a nice-to-have...

0 Kudos

When a cDAQ (I'm using both a 9184 and 9188) chassis is energized (or the host computer is rebooted) it is programmatically read as reserved (by either MAX or LAbVIEW program). To gain control of the chassis, one has to either use MAX (MAX deosn't save or remember the previous reservation) and reserve it or programmatically force the reservation in the LabView code. In addition, if a chassis is reserved by a different host, another host can force the reservation by itself programmatically. Both of these can be accomplished by using the reserve chassis function with the 'Override Reservation' input set to True. This really is not a good method - it's effectively a hostile-takeover of the hardware (I've tried this and I can literally reserve hardware that is actively being used by another host).

 

I would recommend the following firmware/driver/software updates/corrections:

 

  1. When a chassis is power-up it should be in an ‘unassigned’ state. Basically it will be in 'standing-by' waiting for a job/task.
  2. When a host interrogates the chassis it should only be able to ‘reserve’ it if it is in the ‘unassigned’ state. Once the chassis is reserved by a host it is locked to it until it is either unreserved by the host or power is cycled to the chassis and it reboots, returning it to the unassigned state.
  3. When interrogated, a ‘reserved’ chassis should provide the identification of what host has reserved it. This would allow redundant or multi-host configurations to find each other and do things like handing-over a chassis between hosts. This is useful if a host error is detected (redundant host system) or a host needs to be taken offline for service and the process can’t tolerate extended interruption (and it's useful to do this programmatically).
  4. The chassis firmware and functions in DAQmx should be updated or augmented consistently to support 1,2, and 3.
  5. There should be example code showing how to implement these features
0 Kudos

All of the JAT's VIs output results as "sequence" and "timestamp", eg. the "Max and Min Voltage.vi".

I use the JAT to analyze high speed differential signals with unit interval of just 300ps. Because of this, the timestamp output cannot meet the required resolution. However, if timestamp is replaced with double precision float, it should be able to.

I have brought this up with NI's tech support and this is what they recommend, which is to suggest this change over here.  

This is pretty trivial to achieve through LabVIEW itself, but...

 

Signal Express is a simple, stand alone data acquisition system that allows those with limited exposure to LabVIEW set up simple test and measurement routines. One area where this is ideal - at least, for me - is in environmental or long life testing. Instead of crafting a beautiful piece of custom software for my colleagues, I can hand them a DAQ, point them in the direction of the SignalExpress and DAQmx installers, and off they go. With a little fiddling, they can create a logger that suits their needs.

 

One thing I've noticed, however, is that when sampling with non-simultaneous cards such as the USB 6225, users will select 1-pt-on-demand, set to some big interval, and then come back screaming at the top of their lungs - "OHMYGOD THERE'S CROSSTALK BETWEEN CHANNELS!". With a little bit of fault-finding, it's easy to point out that it's not crosstalk, but ghosting between channels, because I would guess that 1-pt-on-demand uses interval sampling and rattles through the multiplexing as quickly as it can.

 

My idea: give users the option to either select round-robin mode with a sensible delay, or complete control over the interchannel delay.

 

I realise that the standard line is usually "use LabVIEW" - I do - but I'd rather spend my time working on the important stuff and empowering those with less experience and/or exposure to make accurate measurements.

0 Kudos

I use a PXIe-6363 which a wonderful device.   But it lacks level shifting at the digital I/O.

 

I would recommend that most DAQ multi-io devices support programmable and externally driven level-shifting for digital IOs.   Range for DAC driven level-shift (0.8 - 3.6, 5V),  and support for external input.   It would also be nice if multiple ports are present that some of them allow independent logic levels.  Default level should be 3.3V.    Port configurable pull-up, pull-down and latch-hold.

0 Kudos

It is not possible to build Kernelmodule nirlpk 2.0  on Kernel >= 3.10

 

nimhddk_linuxkernel/LinuxKernel/nirlpk/objects/nirlpk.c:1076:5: error: implicit declaration of function ‘create_proc_read_entry’ [-Werror=implicit-function-declaration]
if (create_proc_read_entry(nNIRLP_kDriverAlias, 0, nNIRLP_procDir, nNIRLP_procRead, NULL))
^

 

create_proc_read_entry appears to have been deprecated in kernel 3.10.

 

See discussion here http://forums.ni.com/t5/Driver-Development-Kit-DDK/VM-RESERVED-and-create-proc-read-entry-deprecated...

Add 64bit Linux support to DAQmx

Status: New
by Member ibm0815 on ‎08-04-2014 06:36 AM

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.

0 Kudos

Task.png

 

 

It would be nice to have the ability to spawn a “Child” Task based upon a “Parent” Task local virtual channels. Today, this can be accomplished with global virtual channels, but not easily with local virtual channels within the Task. Today, we dynamically generate Tasks based upon the physical channels and save it to an external file.  There are many variations of this, but all require a decent amount of programming for complete automation. The external calibration interface in MAX has greatly improved over the years and now it is easy to calibrate multiple sensors at the same time. Not only that, but it is nice to have device setup and calibration information in one location.

 

 

 

0 Kudos

DAQ Hardware like NI PCI-6225 has 8 Correlated DIO (port0) but 24 DIO are supported by DAQ Hardware.

It is not possible to use hardware timing on port1 or port2 outputs, they are not bufferd. Please expand

the buffered outputs also to port1 and port2 in M-Series DAQ Hardware to get 24 correlated DIO.

 

0 Kudos

IMAQdx Timeout is a non settable property. It is fixed on 5s

When I do not trigger my camera for 5 seconds (and that is what I want regularly after aquisitions at 100FPS) , I get a timeout error.

Additional TDMS Metadata

Status: New
by Knight of NI on ‎05-16-2014 02:13 PM

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.

About Data Acquisition Idea Exchange

Have an idea for new DAQ hardware or DAQ software features?

  1. Browse by label or search in the Data Acquisition Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see implemented!
Idea Statuses
Top Kudoed Authors