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
Kalle

Terminal Block layouts

Status: New
by Member Kalle on ‎09-18-2012 01:58 PM

NI Terminal block layout should be designed so that wiring can be done straight from terminal to wire trunking.

 

For example TBX-68 has 68 wire terminals aligned to inside of the terminal block. This causes that each wire should make tight curve to wire trunking. Another problem with TBX-68 is that wires are heavily overlapped because of the terminal alignment.

 

Also the cables from terminal block to DAQ device should be aligned to go directly to wire trunking (not straight up).

 

terminalBlocks.jpg

 

 

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

 

 

 DaqMxSimulatedAPI.PNG

 

Every time I have to work with a NI daq device the first thing i need to know is what pins can or cant do something.

Currently this involves looking through something like 7 diffrent documents to find little bits of information and bringing them back to your applicaiton.

 

A block diagram could easily be a refrence point for the rest of the documentation (you want to know about pin IO for your device look at this document)

Plus a good block diagram can tell you what you need to know quickly, and clearly. A picture is worth 1000 words?

 

Some might find the current documentation adiquite, but personally i would really like to have a block diagram that represents the internals and capiblities of the pins and device in general. Most Microcontrollers have this and it is an extremly useful tool. So why not have one for the Daq devices as well?

dougm

Add support for SCXI-1600 in 64-bit Windows

Status: New
by Member dougm on ‎09-08-2011 05:21 PM

Hello,

 

I recently discovered that the SCXI-1600 is not supported in 64-bit Windows.  From what NI has told me, it is possible for the hardware to be supported, but NI has chosen not to create a device driver for it.

 

I'm a bit perplexed by this position, since I have become accustomed to my NI hardware just working.  It's not like NI to just abandon support for a piece of hardware like this -- especially one that is still for sale on their website.

 

Please vote if you have an SCXI-1600 and might want to use it in a 64-bit OS at some time in the future.

 

Thanks,

Doug

 

 

TCPlomp

Add LabVIEW events based on hardware

Status: New
by Trusted Enthusiast on ‎08-26-2010 12:47 AM

Based on this question, I would like to add a new category of events to LabVIEW: Max-events.

 

This category could contain the following events:

-Hardware Added

-Hardware removed

-Configuration changed

    -Scales

    -Channels

    -Tasks

 

If you know other events, please post them.

I find myself quite often needing to modify the DaqMX tasks of chassis that aren't currently plugged into my system.  I develope on a laptop, and then transfer the compiled programs to other machines.  When the other machines are running the code and thus using the hardware I have to export my tasks and chassis, delete the live but unplugged chassis from my machine, then import the tasks and chassis back in generating the simulated chassis.  When I'm finished with the task change and code update, to test it I have to export the tasks and chassis, plug in the chassis, and re-import to get a live chassis back.

 

Can it be made as simple as right clicking on a chassis and selecting 'simulated' from the menu to allow me to configure tasks without the hardware present?

 

Thanks,

Brian

Certified LabVIEW Developer

GE Appliances

Vrmithrax

cRIO Analog In/Out Combination Modules

Status: New
by Member Vrmithrax on ‎04-12-2012 03:59 PM

As someone who migrated entire product lines from PLCs to cFieldPoint platforms, and now is in the process of migrating further into cRIO platforms, I am finding some cRIO module selection limitations.  One big gap I see in the selection is with analog in/out modules.  A set of 2-in / 2-out analog modules would be very welcome, offering standardized +/- 10V or 0-20mA ranges.  There are a many times in our products that we need to process just a single analog signal, which now with cRIO requires 2 slots be used, with many unused inputs and outputs (which just feels like a waste of money and space).

NI supports almost any bus.  Why not SSI (synchronous serial interface) ?  

 

Of course, there is always the option to use an R series card and then build an interface.  Why not have a low-cost PCI or USB card? Also, perhaps a C-series module, so that we don't have to take up FPGA space?

Dear NI Idea Exchange,

 

I had a service request recently where the customer wished to use a mass flow meter, using the HART protocol (massive industrial protocol used worldwide with over 30 million devices) to communicate updated values to a cRIO 9074 chassis using a NI 9208 module.

 

They did not know how they could use this protocol with our products. There was only one example online regarding use of this protocol using low level VISA functions. There is currently no real support for this protocol.

 

I suggested that if they wished to use this sensor they would be required to convert it to a protocol we do support, for example Modbus or to RS-232 (using a gateway/converter).

 

Then they could use low level VISA functions to allow the data communication.

 

They were fine with doing this but they felt that NI should probably support this protocol with an off-the-shelf adaptor or module. This is the main point of this idea exchange.

 

There is clearly a reason why we do not currently provide support for this protocol in comparison to PROFIBUS or Modbus.

 

I thought I would pass on this customer feedback as it seemed relevant to NI and our vision. 

 

Regards,

 

Dominic Clarke

 

Applications Engineer

National Instruments UK

Dear NI, please consider a future hardware feature addition:

 

Add a "Power Up Delay DIP Switch" to the back of the PXI Power Supply Shuttle.

 

It would allow end users to reliably sequence the powering-up of multi PXI chassis solutions. It could also be handy to sequence any other boot-order sensitive equipment in the rack or subsystem. This would also be a world-voltage solution since this capability already exists in the power shuttle. We are seeing the need for more input-voltage-agnostic solutions. I'm sure you are too.

 

It might offer time delay choices of 1,2,4,8,16 seconds, etc.

 

We run into this problem on every multi-chassis integration. We have solved it several ways in the past like: human procedure (error prone), sequencing power strips ($$$ and not world-voltage capable), custom time-delay relays ($$$).

 

Imagine never having your downstream chassis(s) disappear. Or worse yet, having them show up in MAX, but act strangely because of not enough delay time between boots.

 

Thanks for reading this, and consider tossing me a Kudos!

Dan_K

USB Counter Device

Status: New
by Active Participant Dan_K on ‎04-08-2010 11:52 AM
It would be great if NI offered a simple 4 Counter bus-powered USB device, like a USB-6601, but with the counter capabilities of the new X Series DAQ devices. This would give people who only need to perform counter operations a low-cost alternative to the bus-powered M Series, with double the counters.
vix

New board with "sensor failure" information

Status: New
by Active Participant vix on ‎05-31-2013 02:20 AM

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!

NI should make sure that the measurement uncertainty specifications for its DAQ hardware are aligned with uncertainty analyses that are performed according the ISO "Guide to the expression of Uncertainty in Measurement" (GUM). See http://www.bipm.org/en/publications/guides/gum.html. Furthermore, the language used could conform to the ISO "International Vocabulary of Metrology" (VIM). See http://www.bipm.org/en/publications/guides/vim.html.

Absolute encoders have been around for some time, but NI's motion hardware still supports only incremental encoders.  I would like to see support for absolute encoders in NI Motion or NI Soft Motion.

 

Currently when streaming analog or digital samples to DAQ board, output stays at the level of last sample received when buffer underflow occurs. This behavior can be observed on USB X Series Multifunction DAQ boards. I have USB-6363 model. The exact mode is hardware-timed, buffered, continuous, and non-regenerating. The buffer underflow error code is -200290 “The generation has stopped to prevent the regeneration of old samples. Your application was unable to write samples to the background buffer fast enough to prevent old samples from being regenerated.”

 

I would like to have an option to configure DAQ hardware to immediately set voltage on analog and digital outputs to a predefined state if the buffer underrun occurs. Also, I would like to have an option to immediately set one of PFI pins on buffer underrun.  

 

I believe this could be accomplished by modifying X series firmware and providing configuration of this feature in the DAQmx API. If no more samples are available in the buffer the DAQ board should immediately write predefined digital states / analog levels to outputs and indicate buffer underrun state on PFI line. Then it should report error to PC.

 

Doing this in firmware has certain advantages:

  1. It can be done quickly (possibly within the time of the next missing sample – at 2Ms/s that’s 0.5us).
  2. Handles all situations (software lockups, excessive CPU loading by other processes, loss of communication do to bus traffic, interface disconnection…)
  3. It does not require any additional hardware (to turn off outputs externally).
  4. Buffer underrun indication on PFI line could provide additional safety measure (it could be used for example to immediately disable external power amplifier connected to DAQ AO). 

Doing this using other methods is just too slow, does not handle all situations, or requires additional external circuitry.

 

Setting outputs from software, once error occurs, is slow (~25ms / time of 50000 samples at 2MS/s) and does not handle physical disconnection of the interface. Analog output does eventually go to 0 V on USB-6363 when USB cable is disconnected, but it takes about half a second.  

 

Using watchdog timer would also be too slow. The timer can be set to quite a short time, but form the software, I would not be able to reset it faster than every 10ms. It also would require switching off analog channels externally with additional circuitry, because watchdog timer is not available for analog channels.

 

The only viable solution right now is to route task sample clock to PFI and detect when it stops toggling. It actually does stop after last sample is programmed. Once that occurs, outputs can be switched off externally. This requires a whole lot of external circuitry and major development time. If you need reaction time to be within time of one or two samples, pulse detector needs to be customized for every possible sampling rate you might what to use. To make this work right for analog output, it would take RISC microcontroller and analog electronic switches. If you wanted to use external trigger to start the waveform, microcontroller would have to turn on the analog switch, look for beginning of waveform sample clock, record initial clock interval as reference, and finally turn off the switch if no pulse is received within reference time.

 

I’m actually quite impressed how well USB-6363 handles streaming to outputs. This allows me to output waveforms with complexity that regular arbitrary generators with fixed memory and sequencing simply cannot handle. The buffer underflow even at the highest sampling rate is quite rare. However, to make my system robust and safe, I need fast, simple, and reliable method of quickly shutting down the outputs that only hardware/firmware solution can provide.

 

Thanks,

Sebastian

A-T-R

New Terminal Block for 100-Pin-Devices

Status: New
by Member A-T-R on ‎11-19-2012 04:14 AM

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

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

 

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

      (http://sine.ni.com/nips/cds/view/p/lang/en/nid/13600)

- 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

 

Troy

USB X-Series needs mass termination option

Status: In Development
by Member Troy on ‎12-10-2010 05:11 PM

May be speaking for myself here, but the M-Series DAQ in USB forms have mass termination option (to connect to VHDCI connectors) and the X-Series do not.  Why?

 

We have hardware that is already setup for the 68-pin cables, and I would like to take advantage of the portability of the USB, and the extended performance of the X-Series vs. the M-Series.  Specifically I was comparing teh USB-6361 X Series and the USB-6251.  The price difference is minimal for the added sample rates and extra counters.  But without the mass term option, I am forced to settle for lesser hardware.  This should be fixed.

Status: In Development
Kevin_Price

Hardware-Triggered Count Reset

Status: Completed
by Active Participant Kevin_Price on ‎03-16-2010 03:13 PM

To save a bunch of typing, the following is copied verbatim from a post I made years ago: 

While the thread is fresh and FWIW, I'd like to add my own additions to a counter/timer wishlist:

1.  Hardware-reload of count register based on signal edge.  Currently, the only feature that's fairly close is the "Z-index reload" feature for encoder position measurement.  There are many limitations and at least one quirk as presently implemented.

 

A. It only works in "position measurement" (a.k.a. "encoder") mode.   At minimum, it should also be supported in edge-counting mode provided the other limitations/quirks are addressed.  I've done a lot of measurements with an encoder mounted to a step-and-dir stepper motor.  The step-and-dir motor must be measured as an edge-counting task with hw-controlled direction.  The encoder's z-index pulse CAN'T be used to hw-reload the count of the edge-counting task in sync with the encoder task.  It'd be GREAT if it could.  Hw-reload of count could also be useful in other counter tasks, especially pulse(train) generation.  I can imagine some clever tricks in the other modes (such as period measurement) as well.

 

B. It must be programmed to be "active" only during a specific 1 of the 4 possible states of encoder channels A & B -- LL, LH, HL, HH.  This works out fine for real-life encoders that supply their own z-index signal.   However, I've had numerous occasions where I would have logically preferred to reset the count value based on some other system pulse signal (can you say "Limit switch"?).   I'd have liked to say, "perform hw-reload on rising edge of Z-index signal regardless of A&B state".  But no such designation exists.  I'd rather have the choices {Low, High, Either} for both A & B config.

 

C. The Z-index signal must be hard-wired to the counter's default GATE pin on the 6602 board.  I *think* but haven't verified that it's user-selectable on the M-series.  Dunno if it supports just PFI inputs or also RTSI signals.  I would like to see a next-generation Counter/Timer allow user-programmable inputs for Z-index as well as encoder A & B channels.

 

D. At least on the 6602, the Z-index behavior is STATE-driven rather than EDGE-driven.  Z-index reload happens whenever A&B are in the programmed state and Z is High.  I tested by hard-wiring the Z-index signal to +5V and my X4 quadrature task counted 0,1,2,3,0,1,2,3,0,1...   I don't recall this being spelled out clearly in the documentation -- I remember expecting it to be sensitive to a rising edge rather than a high state.  I would very much like the option of making the hw-reload sensitive to an EDGE -- ideally {Rising, Falling, Either}.

Note: wishlist item "1C" has been fulfilled in M-series counters and probably also in X-series which I haven't yet tried.

 

-Kevin P

 

Status: Completed

Implemented in DAQmx 9.2.0 for X Series devices and 2nd generation cDAQ chassis (NOT the 9172).

I would like to see a C series module just like the NI 9474 only with push-pull outputs.

 

MOSFET_Push_Pull_Amp.png

Peasoup

PCI express versions of PCI AO cards

Status: New
by Member Peasoup on ‎06-13-2011 04:04 AM

Hi

 

I'd like to see PCI express versions of existing PCI Analogue Output cards eg PCI6713 and PCI6733.

 

I'm finding it quite difficult (and quite a bit more expensive) to source desktop PCs featuring PCI slots.

 

 

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
User Kudos Count
2
1
1