Data Acquisition Idea Exchange

Community Browser
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 
Post an idea
While using NI USB-6008/6009, I am encountering a strange error which I have failed to find the source of it. As you can see, there are 2 types of outputs. When I comment out one of the outputs, other one works fine. However, when I use them both, it gives me an error as shown below in the picture. What could be the problem?
Error : Invalid data format for digital channel
However, error direct to analog output.Error.JPG

It would be great if NI offered something similar to the PLC world in the form of expandable IP20 I/O slices that don't require a chassis. It could offer the same kind of functionality in the modules that the CompactDAQ line offers, but without the need to lock into a chassis. I've found myself leaning towards using PLC I/O for some projects where the end-state is a bit murky, but the programming gets really awkward when using third-party APIs like PVI.

The interface to the PC could be similar to that of a cDAQ chassis: USB or Ethernet. Given the applications of most slice I/O users, 24 VDC would be the preferred way to power such a system.

NI offers some Oscilloscope Devices (see here) but they come with PCI or USB interface only.

These interfaces are good enough for a laboratory device, but they have some limitations if you want to use it in a custom product.

 

I think that an ethernet interface would be a great improvement (it allows a longer cable and it's much more flexible).

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

Make the hardware capable of having more than one task tied to the Analog outputs . Each analog output should be capable of having the hardware timing for every analog output, so each output can generate its own separate hardware timed waveform.

 

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.

I have an application where I need to continuously acquire data, but I want to start logging that data (With file spanning) concurrent with a hardware trigger.  Pause logging will only align to a read block so that isn't useful in this application.  As it stands now (LabView 2016), this type of functionality requires manual buffering of data, use of TDMS file VIs, and custom logic for spanning TDMS files to implement.

The NI-9203 noise probelem is discussed in http://forums.ni.com/t5/Multifunction-DAQ/NI-9203-generates-noise-pulses-when-acquired/m-p/3546439

 

Attached document describes how noise measurements were perfromed with oscilloscope. 9203 emits peaks with the same frequency as acquisition rate. These spikes do affect 4-20mA measurents accuracy quite a bit. It should not be like that. Probably 20pF capacitance on each input inside the module shoud be increased to 200pF or 2nF. I am sure that NI R&D knows better how to improve 9203 🙂

 

Support reference#: 2703970

Hi,

 

It will be great if VirtualBench have an option that we can choose 7 or 8 digits to be decoded for I2C address. I understand that we usually decode 7 digits for address and the eighth digit for read/write for I2C protocol but sometimes we need to decode 8 digits for I2C address and the eighth digit still for read/write to satisfy our work.

 

Thanks,

 

Brian

The minimal range and the test current for resistance measurement of NI's DMMs (ex PXI-4072) are :

 

NI.jpg

 

A DMM with a lower range and a higher test current (eg Keysight M9183A) would be very useful in some cases.

 

Keysight.jpg

 

Hi all, 

 

Biomedical applications have become more popular. Specially in bioimpedance field (see link for more information), where usually the equipment used for this is quite expensive... so researchers and students with low budget usually stick to a custom design systems.

Currently, I am using a Red Pitaya board which has these 2 fast analog outputs and 2 fast analog inputs up to 125MHz sampling frequency to develop my own. This board uses the same processor and fpga as myRIO. However, sampling frequency's myRIO is 500ks/s much lower than Red Pitaya. 

 

My idea would be to develop further hardware to have at least these 2 fast analoge input and 2 fast analog output to be able to compete with Red Pitaya board. I believe that having these characteristics into myRIO will be greatful for those researchers who dont have either the money or the knowledge to put together a system capable of doing that.

 

Cheers,

Albert

 

 

I need a (or more) DAQ - USB like 6210 (to replace my 10x PCI 6031-36) for the  old scsi (68 or 100 pin) cable.

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 Maximum Rate?

 

 

 

 

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?

 

 

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.

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.

 

 

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