Data Acquisition Idea Exchange

Top Authors

User

Kudos

Post an idea

I know it is possible to listen for multiple DI lines when performing a Change Detection (with a pxi 6511, for example), however it appears to not be a feature to know which channel was the cause of the event trigger without building your own comparison logic around the DIO reads.

I would like to see an additional property, either under 'Timing', or under 'Channel' that would allow me to ask, for the specific channel / line in the task that caused the change-event instance rather than having to search for it manually in a 1D boolean array.

Currently, DSA devices that use voltage excitation have no method to provide that excitation to a particular device within test panels. The only method to do this would be to create a task in Measurement and Automation Explorer which takes much more time that doing a simple test panels test. This should be a fairly simple addition to the test panels user interface. One could simply have a box to check if they require excitation, and a control to determine the voltage level to provide to the DUT. They currently have this for IEPE devices, and it makes sense that voltage excitation should be the same.

View All (3)

While in the development environment it is easy to get a reference to a Fieldpoint IO channel - just drag and drop it from the target in the project file. Things are much more cumbersome if you need to create such a refnum dynamically. (If you are making software that should be possible to just copy onto different controllers (without involving LabVIEW) and then configure to match the available/required IO, static refnums are not usable. )

To dynamically get access to an IO point in a built general purpose application you currently have to save and download an iak file to the controller from Measurement and Automation Studio and then open that iak file in your code (Using FP Open) to get the server reference you need as an input to the FP CreateTag function. The need for FP Open and the iak file to create a server refnum is the main problem.

If FP Create Tag could do its job without any iak-file (e.g. just with the IP of the controller as an additional input)...OR even better - if there was a Create Fieldpoint IO Refnum VI avilable (no such today!?) that took the controller IP (use local if not wired), device name (or ID number) and channel name (or ID number)..then things would be much more flexible and intuitive.

There is one function that allows you to address channels just by the use of slot and channel numbers - and that is the Input Range function (which should not be called the input range either by the way as it could be an output...), so another good solution would be to offer that same functionality for the IO read and write functions.

View All (2)

I would like to be able to have multiple and distant Labview development environments installed (e.g. Labview 7, 8.0.1,8.2 and 2010). As I understand it, this is mainly limited by the DAQmx drivers.

The problem I run into is that I need to support many applications beyond 5 years. We have some test equipment on our production line that has been running software since the 6.0 days. Management will come along and ask me to add one little feature to the software.

As it is now, I have to drag out my old computer with Labview 6.0 installed on it, develop on that, and then go back to my new development in LV 2010. I cannot just upgrade the application to 2010, for several reasons.

1) I can't have all the versions co-exist on one computer, so It needs to move from one machine to the next, upgrading along the way.

2) Different versions can change things in dramatic ways and break other pieces of code (e.g. Traditional DAQ vs DAQmx)

3) Because of #2, I need to do a full revalidation of the code, for what should be a minor change.

One thing that the NI architects do not seem to understand is that revalidation is not a trivial activity. This can interrupt the production schedule since I often cannot test on anything but the production equipment. This interruption can take days to weeks, even if no problems are uncovered, and much longer if we find that upgrading caused an issue. If I keep my old development environment, all I need to test is the changes to the code. If I change the compiler, I need to test ALL the code to be sure that the compiler change did not introduce any more bugs.

This is especially challenging in tightly controlled environments such as medical device manufacturing, where any change to the process requires a great deal of scrutiny.

Please make an effort to consider this in the future. Until then, I will be stuck with 4 computers under my desk all running different versions of Labview.

View All (2)

Right now lossy and lossless compression can be achieved as presented here: Data Compaction for High-Speed Streaming to Disk where AI.RawDataCompressionType and AI.LossyLSBRemoval.CompressedSampleSize are used (see figure below).

In this case raw data are stored and additional header info has to be added. The idea is to implement and optimize it in DAQmx (DAQmx Configure Logging VI). This will allow high-speed streaming and to save disk space for higher sampling rates or long-term measurements.

Afterward implementation in the TDMS API could help to read directly compressed raw data without additional operations in LV. This will allow to work on TDMS files in Excel or Matlab using nilibdds.dll.

The issue is discussed a little here: Why the TDMS file is larger than it should be.

What do you think about it?

Lukasz Kocewiak

View All (3)

Add LabVIEW events based on hardware

Touch Screen For PXI

Hey all,

Just passing an idea for some new HW and SW for the PXI and LV. I think a touch panel PC monitor would be an ideal O/P for a PXI as you could plug it in the back and eliminate the use for a mouse and keyboard whilst using the PXI chassis. This also leads onto my second idea, the creation of a front panel customization tool kit. This tool kit will enable users to easily customize the front panels of their VI's much in the way a function pallet would work. This way you are able to quickly customize your front panel to suit the end users needs.

It has come up a few times from customers, and I wanted to gauge interest and solicit ideas on how this should work.

Currently, with the built-in TDMS logging support, if you want to change to a new file in the middle of logging, you need to stop the task and start again. For some use cases, this isn't practical (for example, http://forums.ni.com/t5/LabVIEW/Why-the-TDMS-file-is-larger-than-it-should-be/m-p/1176139#M511099).

The question is: How would you like to specify the "new file" behavior and what are your use cases?

For instance, a couple ideas to get the ball rolling:

Add an interval attribute like "Change file after n samples". We would then auto-increment the file name and change to that file when we have logged "n" samples.
Make file path attribute changeable at runtime. We have a file path attribute for logging. The idea here would be to support changing the file path "on the fly" without stopping and starting the task. The problem here is that it would not suit very well a use case where you want a specific file size. Additionally, it wouldn't be as easy to use as #1; it would be more flexible though.
(Any additional ideas/use cases?)

Thank you for your input!

Andy McRorie

NI R&D

It has come up a few times from customers, and I wanted to gauge interest and solicit ideas on how this should work.

The question is: How would you like to specify the "new file" behavior and what are your use cases?

What I'm currently thinking (because it seems the most flexible to different criteria and situations) is to simply allow you to set the file path property while the task is running (on DAQmx Read property node). The only downside I can think of with this approach is that you wouldn't know exactly when we change to the new file. We could guarantee within (for example) 1 second, but you wouldn't be able to specify the exact size.

Would this be a good solution for you? Can you think of a better way to specify this behavior?

ASIO integration into DAQmx

To save a bunch of typing, the following is copied verbatim from a post I made years ago:

While the thread is fresh and FWIW, I'd like to add my own additions to a counter/timer wishlist:
1. Hardware-reload of count register based on signal edge. Currently, the only feature that's fairly close is the "Z-index reload" feature for encoder position measurement. There are many limitations and at least one quirk as presently implemented.

A. It only works in "position measurement" (a.k.a. "encoder") mode.   At minimum, it should also be supported in edge-counting mode provided the other limitations/quirks are addressed. I've done a lot of measurements with an encoder mounted to a step-and-dir stepper motor. The step-and-dir motor must be measured as an edge-counting task with hw-controlled direction. The encoder's z-index pulse CAN'T be used to hw-reload the count of the edge-counting task in sync with the encoder task. It'd be GREAT if it could. Hw-reload of count could also be useful in other counter tasks, especially pulse(train) generation. I can imagine some clever tricks in the other modes (such as period measurement) as well.

B. It must be programmed to be "active" only during a specific 1 of the 4 possible states of encoder channels A & B -- LL, LH, HL, HH. This works out fine for real-life encoders that supply their own z-index signal.   However, I've had numerous occasions where I would have logically preferred to reset the count value based on some other system pulse signal (can you say "Limit switch"?).   I'd have liked to say, "perform hw-reload on rising edge of Z-index signal regardless of A&B state". But no such designation exists. I'd rather have the choices {Low, High, Either} for both A & B config.

C. The Z-index signal must be hard-wired to the counter's default GATE pin on the 6602 board. I *think* but haven't verified that it's user-selectable on the M-series. Dunno if it supports just PFI inputs or also RTSI signals. I would like to see a next-generation Counter/Timer allow user-programmable inputs for Z-index as well as encoder A & B channels.

D. At least on the 6602, the Z-index behavior is STATE-driven rather than EDGE-driven. Z-index reload happens whenever A&B are in the programmed state and Z is High. I tested by hard-wiring the Z-index signal to +5V and my X4 quadrature task counted 0,1,2,3,0,1,2,3,0,1...   I don't recall this being spelled out clearly in the documentation -- I remember expecting it to be sensitive to a rising edge rather than a high state. I would very much like the option of making the hw-reload sensitive to an EDGE -- ideally {Rising, Falling, Either}.

Note: wishlist item "1C" has been fulfilled in M-series counters and probably also in X-series which I haven't yet tried.

-Kevin P

Data Acquisition Idea Exchange

Add a Property for 'Changed Channel/line #' in when running a multi-channel Change Detect configuration

Ability to switch a device from a real to a simulated one and vice versa

Allow test panels to provide voltage excitation for bridge/strain modules

Make it easier to programmatically create Fieldpoint IO refnums or tags

Post the NI-DAQmx base C Function Reference Help pages on your fora somewhere

Ability to have multiple and distant Labview development versions installed

Software lossy and lossless compression in DAQmx.

Add LabVIEW events based on hardware

Touch Screen For PXI

Ability to split between multiple TDMS files while logging

ASIO integration into DAQmx

Hardware-Triggered Count Reset