Data Acquisition Idea Exchange

Post an idea

Dear NI Idea Exchange,

I had a service request recently where the customer wished to use a mass flow meter, using the HART protocol (massive industrial protocol used worldwide with over 30 million devices) to communicate updated values to a cRIO 9074 chassis using a NI 9208 module.

They did not know how they could use this protocol with our products. There was only one example online regarding use of this protocol using low level VISA functions. There is currently no real support for this protocol.

I suggested that if they wished to use this sensor they would be required to convert it to a protocol we do support, for example Modbus or to RS-232 (using a gateway/converter).

Then they could use low level VISA functions to allow the data communication.

They were fine with doing this but they felt that NI should probably support this protocol with an off-the-shelf adaptor or module. This is the main point of this idea exchange.

There is clearly a reason why we do not currently provide support for this protocol in comparison to PROFIBUS or Modbus.

I thought I would pass on this customer feedback as it seemed relevant to NI and our vision.

Regards,

Dominic Clarke

Applications Engineer

National Instruments UK

View All (4)

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

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?

Hardware Idea/requests exchange

It would be nice to have a hardware request forum as well so NI could see the demand for producing hardware for us.

Just A few things I could use or want:

cDaq counter modules, like a 6602 in cDaq form so I can add more counters to my compact daq module, a lower end crio 'brick', think like a 6009 morphed with a single board rio, something under 1k for simple embedded data logging prototypes. Maybe support for PIC micros (FPGA is so empowering, more microcontroller programming native to labview would be very nice to add to our toolbox).

would a seperate HW forum be helpful?

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)

NI-VISA and MAC OSX Lion

View All (5)

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

How can we help?

Please enter your information below and we'll be intouch soon.

This field is required

Preferred communication method

Email Phone call

What do you need our team of experts to assist you with?

Request a quote Find the right product Place an order Get support on a product

Data Acquisition Idea Exchange

Add 64bit Linux support to DAQmx

C Series HART (Highway Addressable Remote Transducer) Module/ HART Adapter

Hardware-Triggered Count Reset

Ability to split between multiple TDMS files while logging

Hardware Idea/requests exchange

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

NI-VISA and MAC OSX Lion