Data Acquisition Idea Exchange

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

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:

1. 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.
2. 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.
3. (Any additional ideas/use cases?)

Thank you for your input!

Andy McRorie

NI R&D