Data Acquisition Idea Exchange

Community Browser
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea

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.

 

Differential Analog Out Card

1. on page 2-4 of the manual (http://www.ni.com/pdf/manuals/375865a.pdf😞

here is a sketch or a picture helpful to understand the text. 

It is easier to understand page 2-4 with a small picture how to connect the AI SENSE for exapmle.

 

2. a terminal diagramm in the manual for each card (PXI, PCI) is also very helpful.

Alternatively a paper with the terminal diagramm to send with the devices.

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?

We use often the NI CompactDAQ 9234 for sound measurements.

Our standard microphones with iepe amplifier have a noise level of about 16 dB(A) and sensitivity of 40...50 mV/Pa.

The noise of the 9234 is about 50μV rms, corresponding to a sound level about 32 dB(A). So we can use this microphones only for measurement above 35 dB(A).

A better version of a card 9234 with 2 ranges 5V and 0.5 V would be very useful. The noise in the lower range should of course  not exceed the range of 5...10 μV (12..18 dB(A)).

And many monitoring systems have only one Microphone, so we use only one channel of the 9234.

For this cases would be a lower priced one channel card OK.

A two channel card would be perfect: two channel measurement of one microphone signal in both ranges. The  sound level program can measure from 20 dB(A) ... 136 dB peak without range switching.

 

 

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!

Currently we are using LabWindows/CVI with a 96 bit DIO card (PXI-6509).

 

What we have found and NI support confirmed is that with the following the software needs to be aware of the bit offset during a write to one or more lines on a port.

 

Virtual Channel                    Physical Channel

dataEnable                          dev1/port0/line 2

 

Our assumption was that writing to 'dataEnable' a value of 1 using DAQmxWriteDigitalU8() would write to the virtual channel 'dataEnable'.  What we found is that is not the case.  We need to write a value of 0x04.  But that the bits that are set to zero in this value written to 'dataEnable' have no affect on other lines on the port that are already set.  This gives us the impression that the driver has knowledge of what bit position we are trying to write too.

 

So based on this why is it not possible that when I call from LabWindows/CVI to do a write to a virtual channel I cannot just do something like this:

 

Virtual Channel                    Physical Channel

dataEnable_Clk                   dev1/port0/line2:3

 

Line 2 = dataEnable

Line 3 = dataClk

 

write( dataEnable_Clk, 1)               // to set enable line high

write( dataEnable_Clk, 3)               // to keep enable line high and raise clk line

write( dataEnable_Clk, 1)               // keep enable line high and lower clk line

write( dataEnable_Clk, 0)               // lower enable line

 

** assumption is that seperate lines on another port are used to present the data to the external hardware and are not shown here.  The data would have bee setup before the sequence above and then change data and repeat sequence as needed.

 

Here I don't have to keep in mind that Enable is on line 2 and Clk is on line 3 or have to setup values of 0x04 for hte Enable and 0x08 for the Clk.  If I have to do this I would rather have direct access to each port to just write the values directly.  i know there is the register level I can use but doing this at a higher level is better.

 

In our code when a internal function is called to write data we would like to just write a value out to the virtual channel and not have to figure out the bit alignment to shift over the value to use one of the current functions.

 

Let me know your thoughts.

 

Bob Delsescaux

Hi all,

I need to acquire signals from an incremental encoder and I have a board NI USB6259 to do this.

It seems that this hardware has special inputs for position acquisition from incremental encoders.

 

Looking at USB6259 datasheet I could make the data acquisition using inputs Counter/Timer.

If that is right I should send the square waves TTL generated from the encoder to these inputs but my encoder has sinusoidal outputs with a certain phase between two signals.

If I need to send TTL signal to my USB6259 I should convert sinusoidal signals with additional hardware.

 

Is everything right? Did anyone acquire encoder signals before? Suggestions?

Thanks in advance

 

Vito

 

Texas Instruments makes a superb line of 16-bit Sigma-Delta ADCs with sampling rates up to 10MHz: ADS 1610, ADS 1602, etc.

See  http://www.ti.com/lit/ds/symlink/ads1610.pdf

They sell for about $25 each in modest quantities.

 

Using these converters would provide much better fidelity than any available products as there is no need for external analog antialiasing filters. 

 

I'll place my order now. I personally need 1,2,4,8 AIs and 1,2 AOs with same sampling frequencies from same clock. I don't need all those digital I/Os and quadrature decoders.

 

Just give me analog I/O with sigma-delta converters.  When can I place an order?

 

 

 

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.

 

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?

Hi everyone, I have new project of measuring pressure and temperature, the problem here is I must put everything in a box with IP 65 (High safety) and the data will be logged about 5 minutes of period, after each week I will take the data and load to computer. Can I using NI product to do it? is there any NI products with large memory inside for storage?

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

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

 

I've been told that in order to change module settings, you have to connect a development machine to the network has has the cRIO hardware. Most systems I build have a deployed application and are located somewhere else (i.e. no connected to my machine). It'd be nice if the cRIO module setting could be ported to the cRIO unit without having to connect a development machine and hit "connect" in the project.

 

For example, I had a cRIO unit in my office and set it up for a project. They installed it, wired it, and tested it. A few months later we needed to add a NI 9213 (16 ch Thermocouple module). It defaults to type J and degree Celcius. In order to switch it to type K, I had to bring my desktop out to the unit, connect to the network, and redeploy the cRIO. I called support twice and was told this is the only way to deploy the module settings. If i'm wrong, someone please correct me.

 

 

I'm thinking it could be another type of application builder or something you could add to an existing application.

 

 

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

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

 

 

For test systems that use several daq devices and need to associate them with specific hardware tasks in a LabVIEW program, it is desirable to allow the user to specify which daq device is to be used with a certain function in the program.  For example Dev1 may perform sensor measurements, Dev2 may perform control tasks.  There can also be situations where the same type of task is performed more than once in the program by more than one daq device, again requiring that the specific daq device be associated with the specific task.  The serial embedded number can be read from the daq hardware and displayed to the user for them to choose and match with the appropriate task.  It would be easier and less error prone if there was a way to program (via MAX ?) a custom serial number/name into the daq hardware (in addition to the NI supplied one) that could then be read and shown to the user.

 

Steve

 

I need to computer 16 ADC lines simultaneously. 9239 is great except when I use 4 of them, each start with a random delay. Also after about minutes, they start drifting and the phase shift is very obvious.

 

My signals have to be isolated from each other and the USB port.  It would be ideal to have them connected through a second port or the DB9 which already exist so that they share the same synch signal and clock. Once one of them starts, it kick start the rest.

 

Thanks,

Omid