Data Acquisition Idea Exchange

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

Idea:

We've come across a few use cases where it would be nice to pull samples from the DAQ buffer based on position in the buffer instead of sample number. This gets a little hard to describe, but a NI applications engineer referred to it as absolute addressing without regard to FIFO order.

 

In its simplest form we could use a read operation that just pulls from the beginning of the buffer as it is (probably?) in memory, maybe using a RelativeTo option of "Start of Buffer", with no offset.

 

The thought is that sometimes a properly set up buffer can contain exactly the data we need, so it'd be nice and clean to just get a snapshot of the buffer.

 

Use cases:

Our use cases involve continuously and cyclically sending AO and sampling AI in tasks that share a time base, ensuring that every n samples will be the beginning of a new cycle. A buffer of that same size n will therefore be circularly updated like a waveform chart in sweep mode.

 

In other words, the sample at the first position in the buffer will always be the beginning of the cycle, no matter how many times the sampling has updated the buffer.

 

If we could take a snapshot of the buffer at any moment, we'd have the latest readings made at every point in the cycle.

 

Alternatives:

The idea is that the buffer at all times has exactly the samples we need in the form we need them. What's lacking in existing functionality?

 

With RelativeTo First Sample, we don't know exactly what samples are there at any moment. We can query Total Samples and do math to figure out what samples the buffer contained, but while we're doing math sampling continues, leading to the chance that our calculation will be stale by the time we finish and we'll get a read error.

 

RelativeTo Most Recent Sample can return an entire cycle worth of samples, but they'll probably be out of phase. The sample beginning the cycle is likely to be somewhere in the middle of the FIFO order.

 

RelativeTo Read Position requires that we constantly read the buffer, which is a hassle if we only want to observe a cycle occasionally. It kind of means we'd be duplicating the buffer, too.

 

Best alternative:

In talking with engineers and on the forums, it sounds like the best option for us is to use RelativeTo First Sample and Total Samples to calculate the sample number at the beginning of a sample, and then make sure the buffer is many cycles long to mostly guarantee that the sample will still be there by the time we request it.

 

Forum post: http://forums.ni.com/t5/forums/v3_1/forumtopicpage/board-id/250/page/1/thread-id/91133

NI support Reference# 2407745

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.

I am new to posting ideas, so I posted this someplace else and now see this is the more appropriate form for my need.....

My customer wants to be able to calculate mV/Pascal at various pressures to make sure the response is linear over the range.  The problem is I have not been able to find a VI or property node that will give me access to the raw voltage of the input signal when using the DAQMx Pressure Bridge VI, which I would then calculate the actual voltage measured vs Pascals measured.  I find it amazing that I can't easily get this raw voltage from a property node.  I do NOT want to use the Analog Measurement (as suggested by my NI service request 2399613) and then do all the translation to pressure because that would aliminate all the great stuff the Pressure Bridge Measurement VI takes into account.

To help with system recovery in the case of system errors/crashes, it would be useful to have a tool to configure a more frequent backup of the system without having to manually export the system configuration. 

From what I can tell, there is one master DaqException that is used for everything that goes wrong.  This makes checking for certain exceptions extremely difficult, as you are now limited to checking the error message for certain strings.  This is fragile.

 

Please provide typed exceptions in the .NET DAQmx library.  For example, if a task times out, it should throw a "TaskTimeoutException", which might be a child of DaqException.  Or if the timing setup is invalid, the library would throw a "InvalidTimingConfigurationException".

 

Yes, I realize it's a bit of busy work to create a bunch of typed exceptions, but it makes error handling for consumers much easier.

It is a frequent requirement to make measurements on production lines. Position on these is often tracked with Rotary Encoders https://en.wikipedia.org/wiki/Rotary_encoder . Many NI devices can accept the quadrature pulse train from such a device, and correctly produce a current position count. The information in the 2 phase pulse train allows the counter to correctly track foward and reverse motion.

 

What would be very useful would be a callback in NI-DaqMX that is called after every n pulses, ideally with a flag to indicate whether the counter is higher or lower than the previous value, i.e. the direction.

 

This has recently been discussed on the multifunction DAQ board here: http://forums.ni.com/t5/Multifunction-DAQ/quadrature-encoder-based-triggering/td-p/3125468 . So I am not alone in requesting something more programmer friendly than the workaround offered there.

 

 

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

 

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

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.

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.

 

 

 

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. 

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?

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!

 

Cheers,

 

Kris

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.

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":

 

Untitled 1 Block Diagram _2013-06-04_16-16-29.png

AdvancedTerminals.png

 

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?

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

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.

I bought a NI USB-6251 BNC but the support explained me that it would have no Linux support out of the box. I will have to find out how to use it on Linux systems myself now (perhaps with help of the forum). It would be a nice feature, if it would ship with Linux support.