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.
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.
At the new client.. no shock to many of you I "Get around"
I explained to some of my new compadres the DAQmx "Tasks" need to be created once.... Preferably during development!
I even created a new task in MAX using the DAQmx wizard, Dragged it to the LabVIEW project explorer and all of that!
I even went so far as to name the "AUX" temperature channel "armpit"- Trust me, after 5 minutes delivering a .lvproj based on the "Contineous measuement and logging (DAQmx) project template" it was impressive to the client that the plot "armpit" showed 37C on the chart. Guess where the thermocouple was.
So, Because I am that amazing, I showed them that they could Drag-n-Drop the Task to MAX and use MAX to monitor my armpit temperature. I even showed them that MAX could show them the wiring diagram!
"HOLD IT"! they said, The wiring diagram is right there! On SCREEN! per channel!
That is where I just about lost my mind! They wanted to see this connection diagram for another Channel--- that worked! BUT there was no way to output that wonderful data!
"Can I create a Wiring Diagram for this channel, device or task?" were the next words out of their mouths. I WAS STUNNED! "Not today" I said, "I'll post that excellent idea!"
It gets a bit annoying that PXI1Slot2 is listed after PXI1Slot14 when doing an ascii sort. I (ok, admittedly, my coworker) proposes having naming conventions that will allow for a better ascii sort. For instance, PXI1Slot002 PXI1Slot014.
I try to read data from SPS (SAIA SPS) with cgi technik. I have to read the values of 933 variables at the time.
I wrote a labview programm that you can find in Attachement. My problem ist, i can only read
170 values of the 933 values, i want, at the time.
Questions: Ist there a maximal numbers of variable to read or to write with Data socket at the time?
Thank you for your contribution
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?
Hi Everyone. I have an old Kistler type 7001 pressure sensor and type 5007 charge amplifier and I'm going to use NI USB 6009 DAQ board to measure in-cylinder pressures of a single cylinder diesel engine.I'm very much new to Lab view and using all these sensors.Can some one kindly tell me how to start and I would be very grateful if someone could post a program (block diagram) to collect,convert the voltage to pressure and write the final output to a text file.Thanks alot in advance.
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!
Including me, there are couple of other LabVIEW users, those wish to have this feature available, wherein we could be able to create Virtual channels (or even Global tasks) for an internal channel of a DAQ or SCXI.
This feature implementation should also include, allow to configure and use internal channels while using DAQ Assistant (though I personally don't prefer using DAQ Assistant).
Check this post here. This feature wish is around the same line.
Occasionally, I need to create global virtual channels that are used to acquire AC voltage signals. Currently, I just acquire the instantaneous values and take the RMS average in LabVIEW. However, this does not let you calibrate the global virtual channel in MAX (because the acquisition is the instantaneous DC voltage).
It would be nice to have the custom scales allow user customizable LabVIEW programming plug-ins, such as RMS average point by point, so that I can calibrate an AC voltage channel in MAX.
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.
I want to buy a small standalone controller based NI Data Acquisition system which would have the following features,
By standalone i mean that the DAQ system should be such that, it does'nt require a permanent PC connection (i.e. just program once). And it sends the acquired signals to a remote location via ethernet interface.
Please suggest me a DAQ system with the above mentioned features.
By default, DAQmx terminal constants/controls only show a subset of what is really available. To see everything, you have to right-click the terminal and select "I/O Name Filtering", then check "Include Advanced Terminals":
I guess this is intended to prevent new users from being overwhelmed. However, what is really does is create a hurdle that prevents them from configuring their device in a more "advanced" manner since they have no idea that the name filtering box exists.
I am putting "advanced" in quotes because I find the distinction very much arbitrary.
As a more experienced DAQmx user, I change the I/O name filtering literally every time I put down a terminal without thinking about it (who can keep track of which subset of DAQmx applications are considered "advanced"). The worst part about this is trying to explain how to do something to newer users and having to tell them to change the I/O name filtering every single time (or if you don't, you'll almost certainly get a response back like this).
Why not make the so-called "advanced" terminals show in the drop-down list by default?
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
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.
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
Texas Instruments makes a superb line of 16-bit Sigma-Delta ADCs with sampling rates up to 10MHz: ADS 1610, ADS 1602, etc.
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?
We use our acquisition software with a variety of hardware configurations. We validate our configurations using simulated hardware, but every time we need to check out a different configuration, we have to delete and create simulated devices. It would be nice to have a better method for switching between different simulated configurations.