Data Acquisition Idea Exchange

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

Reasoning: Those of us who work with multiple systems need to import/export configurations often, to switch from system A to B to C and so on, since names are often interfering between projects.

Idea: Provide selectable profiles in MAX - this way you could choose which of systems configurations you would like to work with without exporting/importing the systems all the time.

To change a signal name within the Digital Waveform Editor, you double-click on it and in the box that pops up, you enter a new name.  But that same name-entry box does not allow cutting and pasting of text for more mass-production of similarly-named signals. It should (allow cut and paste).

In SignalExpress, you are able to simultaneously acquire new data and view the entire history of your log in a single plot. In DAQExpress, you can drag a recording into a new tab, but it only lets you see the data of the recording from it's start time up to the time you performed the drag operation. It would be nice if DAQExpress allowed you to somehow view your entire recording history in the same graph that is acquiring new data.

Have had this feature idea passed on to me. Person sees this popup every time they wake up their computer:

 

capi1.PNG

This person was confused at how to prevent this from showing again. They did not know you had to scroll:

 

cap2.PNG

 

Maybe make this easier to discover? 

As far as I can tell, DAQmx Configure Logging only allows for raw data and scaling information to be saved as part of a DAQmx task. This is great for throughput and disk space considerations, but a problem arises when using DIAdem to analyse the TDMS files with raw + scaling info - it is incredibly slow for large files (~500MB).

 

Some basic tests show it's around 10 times slower to process raw + scale TDMS files (stored as I16s) vs. already scaled TDMS files (stored as SGLs). DIAdem crawls when trying to generate calculation previews, zoom in and out of graphs, and so on.

 

It'd be great if the DAQmx logging provided the option to log scaled data (in the user's preferred datatype), and an option to not include the scaling information in the TDMS metadata.

Hi, It would be useful if daqmx has a property node to read the device pinouts.

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

Hi!


PCI Express bus became more and more popular.
PCIe has a new type of interrupts - MSI/MSI-X.
Today VISA driver is able to work only with old style interrupts (Legacy).

 

Let me explain the main difference:

Legacy interrupt mask intA/B/C/D signals (these signals was in PCI bus, but not exist in PCIe bus).
These signals (for PCIe actually packets with Message setA/B/C/D) are shared between all PCIe devices.
So VISA driver spend a lot of time when it looks who produced this interrupt.

 

MSI interrupt is actually a Memory Write packet to preallocated address.
In this case VISA should already know which device produced this interrupt.
Also MSI interrupt can contain different interrupt vectors inside of Memory Write packet. So it would be very helpful to get access to vector value too.

 

Requesting MSI/MSI-X interrupts support to VISA driver.

 

Thanks a lot!

Since the drivers support the basic communication for the GPIB-USB-HS+ devices, the code should be ported to support the analyzer functionality as well. Create the driver API to support analyzer and then make that available to LV.  Create cross platform LV routines for the analyzer functionality so it is available on all platforms.

In order to TDD code, one has to be able to isolate dependencies.  A very handy trick to isolate external dependencies is to create an interface with the same methods and properties signatures as the external class, and then create an empty class which inherits from the external dependency and implements the interface.

 

For example, I'm trying to isolate the HardwareResourceBase class, because I'm attempting to test some code the uses the result of SystemConfiguration.FindHardware("").

 

However, I cannot isolate the HardwareResourceBase class by doing:

public interface IHardwareResourceBase
{
  String UserAlias{get;}
  String MacAddress{get;|
  /* Other methods and properties of HardwareResourceBase */
}

public class HardwareResourceImpl : HardwareResourceBase, IHardwareResourceBase
{}

because the constructor to HardwareResourceBase is hidden.  In order to isolate HardwareResourceBase, I now have to create a full wrapper class, which is a major pain.

 

Please do not fully seal classes by hiding the constructor.  If a method should not be overriden, use the "sealed" keyword.

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.

 

 

Hello.  I'm working on an app to interface with a couple of ANT devices (Garmin Vector, Garmin heartrate monitor).  I've seen a couple of posts on this topic but nobody has posted code.  I talked to Frank Lezu at an NI day in DC a month or so back and he recommended I post about it here.

 

Anyone else looking for ANT/ANT+ support?  I'd be happy to share my code when it's not in a ridiculously embarrassing state but for now see this post for a braindump of my progress.

 

Thanks,

-Jamie

All of the JAT's VIs output results as "sequence" and "timestamp", eg. the "Max and Min Voltage.vi".

I use the JAT to analyze high speed differential signals with unit interval of just 300ps. Because of this, the timestamp output cannot meet the required resolution. However, if timestamp is replaced with double precision float, it should be able to.

I have brought this up with NI's tech support and this is what they recommend, which is to suggest this change over here.  

This is pretty trivial to achieve through LabVIEW itself, but...

 

Signal Express is a simple, stand alone data acquisition system that allows those with limited exposure to LabVIEW set up simple test and measurement routines. One area where this is ideal - at least, for me - is in environmental or long life testing. Instead of crafting a beautiful piece of custom software for my colleagues, I can hand them a DAQ, point them in the direction of the SignalExpress and DAQmx installers, and off they go. With a little fiddling, they can create a logger that suits their needs.

 

One thing I've noticed, however, is that when sampling with non-simultaneous cards such as the USB 6225, users will select 1-pt-on-demand, set to some big interval, and then come back screaming at the top of their lungs - "OHMYGOD THERE'S CROSSTALK BETWEEN CHANNELS!". With a little bit of fault-finding, it's easy to point out that it's not crosstalk, but ghosting between channels, because I would guess that 1-pt-on-demand uses interval sampling and rattles through the multiplexing as quickly as it can.

 

My idea: give users the option to either select round-robin mode with a sensible delay, or complete control over the interchannel delay.

 

I realise that the standard line is usually "use LabVIEW" - I do - but I'd rather spend my time working on the important stuff and empowering those with less experience and/or exposure to make accurate measurements.

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.

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. 

Hello everybody,

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

 

kind regards

colains

 

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?