Data Acquisition Idea Exchange

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

The request is for NI to prioritize development of VIs that allow integrators’ CAN data to be measured and stored in standardized formats.

 

While TDMS and XNET are decent tools, it’s lack of modern development and open compatibility in industry makes it somewhat difficult to deal with. NI could probably expand and service its user base if it supported XNET and MDF4 better.

 

Currently our process is as follows:

  1. LabView XNET data comes from the cRIO FPGA (eg. NI-9853) as an array of 6 U32s
    1. https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000PASzSAO&l=en-CA
  2. LabView XNET default data structure is the typdef ‘XNET Frame CAN.ctl’
    1. See XNET help ‘XNET Convert (Byte Array to Frame CAN).vi’
    2. There are obscure (near obsolete) VIs or the end user must write code to convert from 6 U32 to XNET Frame CAN on poor documentation.
  3. As an aside, there doesn’t seem to be a clean standardized way to store either of these structures in the TDMS files
    1. There is a way to configure a TDMS channel for CAN frame logging, but it is not easy for signal post processing because it is only one channel of frames.
    2. We believe a much better way would be something like this if we stuck with TDMS.

KineticsTestEng1_0-1747240261033.jpeg

 

However as to this feature request we have found that the industry standard MDF4 file format to be advantageous in most aspects. 

Our tests found that a 1 hour 1.1GB raw CAN frames and analog data TDMS file could be stored as a 200 MB file in the compact MDF4 file ! When the CANbus data was expanded into actual signals, the MDF4 file was 900 MB (still less than the raw TDMS). Further this MDF4 file loaded into FAMOS for review in ~1 sec !

We would prefer to output directly to MDF4 rather than having to script this conversion process.

    1. One key detail is the storage of raw CAN frames such that other industry tools (eg. MATLAB, FAMOS, PYTHON, MDFvalidator, ASAMmdf GUI) can natively interpret and process with various DBC files (the standard includes tools to extract CAN signals).
    2. Secondly with high channel counts of fast sample rates, the file size quickly becomes enormous. MDF4 allows excellent compactness, further compression, and usability of data (including but not limited to CAN).
    3. However, NI’s DataPlugin needs work as it fails to read much of the structure, properties and data of MDF4 files (as seen from ‘Data File Viewer.vi’ utility below). To unlock the true power of MDF4, the CAN frame has to be written correctly. Currently this is impossible.
    4. We were surprised that NI as an ASAM member had not fully supported the MDF4 format.
    5. KineticsTestEng1_1-1747240261034.pngLV vs. free ASAMmdf GUI KineticsTestEng1_2-1747240261040.jpeg
    6. Vector’s free MDFvalidator tool useful for seeing the file structure                    KineticsTestEng1_3-1747240261043.jpeg

       

APPENDIX: here are some links and resources to summarize importance of MDF4 file format.

    1. Link to the standard’s homepage ASAM MDF [asam.net]
    2. Link to the MDF4 format’s documentation asammdf "7.3.14" documentation [asammdf.readthedocs.io]
    3. Link to a founding company’s page Measurement Data Format MDF | Vector [vector.com]
    4. Link to NI MDF4 plugin showing features https://www.ni.com/pdf/manuals/asam-ev-dataplugin-mdf4-2023-q3.html (note that #10 ByteArray is not supported).
    5. Why MDF4 is Popular for Testing:

      • Efficient Storage: As a binary format, MDF4 allows for the efficient storage of large volumes of data, which is crucial in extensive testing scenarios.
      • Standardization: Being an ASAM (Association for Standardization of Automation and Measuring Systems) standard ensures interoperability between different tools and systems used in the industry.
      • Metadata Support: MDF4 allows for the inclusion of rich metadata, providing context and facilitating the interpretation of the raw measurement data. This includes information about the signals, units, and test conditions.
      • High Performance: The format is optimized for fast read and write access, which speeds up the analysis of large datasets.
      • Flexibility: MDF4 supports various data types and allows for extensions, making it adaptable to evolving testing needs.

 

I have a cDAQ-9185 with the 'advertised' TSN feature, yet I can't use it unless I buy LabView and the Ethernet IP Industrial Network Driver. If FlexLogger is for data acquisition, why is it not supporting the TSN features of the cDAQ-9185? I'm disappointed in the way NI advertised the TSN features of the cDAQ-9185 by the way the require all this additional software to be purchased to actually use it. If FlexLogger doesn't support TSN and OPC they should state it.

This is a continuation of another forum post, from here.

 

Hooovah, the capability I need is very similar to how the "ID CRC" feature currently works, I just need a little bit more flexibility in how the ID is added to the payload bytes, prior to CRC calculation.  As you described it, the 4-byte CAN ID is concatenated to the front of the CAN payload, and by your example, it is being added in "big endian" fashion.  What I require for my application, is to add that same 4-byte CAN ID to CAN payload, but I need it added in "little endian" format, such that:

 

if CAN ID = 0x1FFF313

and CAN payload = 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x[CRC]

 

then the CRC is calculated on:

0x13 0xF3 0xFF 0x01 0x01 0x02 0x03 0x04 0x05 0x06 0x07

Just what the title says!

Would be great to support NI USB TC01 Type K in Flexlogger to log the data from the device.

When I drop a DAQmx Task constant on my LabVIEW block diagram, I have the right-click menu option to Generate Code >>Configuration 

 

This scripts out a sub.vi that creates the Task by adding each channel with channel specific properties sequentially, one channel at a time, to repeated calls of DAQmx Configure Channel.vi.

 

I have a hard time saving that vi output!  I have not really learned how to name it properly without Using:  "BLEEP_BLEEP_BLEEP_Configuration_that_cannot_be BLEEPING_scaled.vi"

 

I believe that an autoindexing loop would be much nicer.

 

My grandmother thanks you for improving my manner of speach.

Current implementation is that FlexLogger ignores the default values as configured in the CAN database.

 

As a bonus, use the default value, max/min values for the control that points to a transmitted signal in the CAN database.

The current FlexLogger implementation requires you to connect DAQ output channels to input channels and an additional XNET port to log output CAN signals, which adds to the cost of the DAQ setup/limits the amount of DAQ/chassis.

Very annoying this isn't possible in FlexLogger (or VeriStand)

I need to frequently check the existence of an overtemperature or any health parameters of the NI card PICe-6323 for my application.

I am using the DAQmx ANSI C library for my application.

 

I have tried using the DAQmxGetReadOvertemperatureChansExist function but found that's for C Series Devices.

 

Please help me out.

I would like to see a version of the 4-slot cDAQ-9185, but where the 4 slots are arranged the long way, and the whole thing fits in a 1U slot on a standard 19" rack.

As far as I'm aware there is no current way to export the quadrature conversion clock from an encoder task. It would be great to be able to export that signal to use for other things.

 

For example, you could use this signal to perform an analog acquisition each time your encoder passed a mark, giving you position vs. signal. This would be useful for something like a roughness tester where you drag a stylus across a sample and get roughness vs. position. Or a pressure sensor reading pressure versus crankshaft angle.

Why is there no way to determine Trigger Status in NI-Scope? 

 

No, "Acquisition Status" is NOT the same thing. As Acquisition Status only tells you if acquisition is complete. I suppose you could say if it's not complete then it is still waiting for trigger, but you could be wrong. Specially in the case of a slow acquisition (seconds/div).

 

Any modern DSO I have used had a VI to determine Trigger Status and would return several states.

 

Such as:

Stopped

Ready, Armed, or Waiting (pre-trigger acquisition complete, ready and waiting for trigger) 

Pre-trigger (pre-trigger acquisition in process)

Triggered (post trigger acquisition in progress)

 

当我使用网络流将数据从CRIO传输到PC时,程序正常运行几秒钟后,它提示我断开与CRIO终端的连接。此时FPGA的采样时间为1 uSec。当我将采样时间增加到大于 1 uSec 时,程序运行良好。也就是说,当程序的采样率低于1MS/S时,程序可以正常运行,当采样率等于1MS/S时,程序就会出错。是不是因为队列和网络流写得太慢了?请帮帮我,谢谢。

QQ图片20220412152952.png

Note: this might only be relevant & useful for multiplexing AI devices.

 

It was an important technique used to investigate channel-to-channel ghosting influence on a multiplexing device.  For example, suppose you had a large signal A and a small signal B.  You could set up a channel list to read "A,B,B,B,B", and thereby *investigate* the trend of these successive readings of the same channel and use *evidence* to determine when the ghosting influence had dissipated.   THIS WAS IMPORTANT!

 

I recall hearing of others use the capability to be able to get faster sampling for one of their fast-changing channels, using a channel list along the lines of "A,B, C,B, D,B, E,B".

 

The feature that used to be supported on multiplexing MIO devices as far back as I could remember working with NI DAQ products.  I only recently discovered that such support was inexplicably removed from DAQmx sometime in the last few years, now producing a fatal task error.   I tested a few available systems and found that it was still supported under DAQmx 16.0, not supported by DAQmx 18.1, and not yet restored as of DAQmx 20.1.  (All verifications were done with desktop or PXI X-series devices.)

 

Why was this ability taken away?   Stop being so overzealous trying to protect us from ourselves!  Multiple readings of the same channel is a legitimate and sometimes almost necessary technique.  Maybe you lacked the imagination to understand why we'd want this, but guess what?  We knew what we were doing.  So stop stopping us.

 

 

-Kevin P

dear

attached picture for universal test machine

it is seemingly that this machine cannot be interfaced to computer 

we need this interface to visualized data

so can you suggest or guide me any DAQ or controller to override such problem

 

 

Download All

Attempting to add a channel (Ch8) to an existing task which already uses that channel as a result of having already assigned its paired differential channel (Ch0) results in that channel correctly not being added to the task but also does not generate a warning or error.  Thus when attempting to configure a task with 2 channels as Ch0 differential and Ch8 RSE, the resulting task only contains 1 channel.  This may be not be apparent because the channels 0 and 8 appear as different from each other.  Having a warning could give notification of this fact. 

 

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019KxoSAE&l=en-US

 

I'd like to expose an opportunity to make FlexLogger easier to use around shunt calibration. With various internal shunt calibration resistors between different hardware, is there a way that the software would know the appropriate location and resistance value when performing a shunt calibration? It is tedious, and a possible point of error, having to manually enter, for example, the correct shunt resistor between using our 9236 cards and the strain based FieldDAQ units.

The use of NI DAQmx Global Virtual Channels is the best way that I have found to configure and manage parameter scaling to provide measurement data directly in engineering units. The software architecture of our data acquisition applications is centered around the use of Global Channels (aka Virtual Channels). Configuring Global Channels using NI MAX (Measurement & Automation Explorer) is convenient for a small number of measurement channels. However, in system configurations with hundreds of channels, to create and manage them effectively, you need to build your own application for this task.  We have built custom Global Channel creation VIs in LabVIEW for each type of analog input or sensor type that we use. These VIs are designed to read a configuration table in CSV format, and then loop through creating a Global Channel for each table row of information.  This process allows for more flexibility in naming the channels as well as setting different scaling and storage of other channel-specific metadata.

 

We employ multiple networked data acquisition systems with Linux-based NI controllers, and we manage those DAQmx Global Channels across our network.  Currently, to create DAQmx Global Channels on these systems, we must directly connect to the NI controller in the LabVIEW Project View and run our suite of Global Channel creation apps on that particular controller using their accompanying, locally-stored CSV configuration file.  Currently, our networked distributed data acquisition system has grown to 10 controllers, each with their own set of common I/O.  The creation of those Global Channels has now become cumbersome because we have five I/O types to manage and hence five custom LabVIEW applications each with a specific configuration file to run on 10 controllers individually.

 

A potential simplification to the process would be to run our custom LabVIEW applications on a Windows host PC and create the DAQmx Global Channels remotely.  That would eliminate the need to directly connect to each controller from the LabVIEW Project View and copy a common set of config files to each controller and run the same applications on individually on each controller.  However, the current version of DAQmx makes no provision for remotely creating DAQmx Global Channels.  Note that NI-MAX is able to create DAQmx Global Channels remotely, but this functionality is not exposed for LabVIEW programmers to utilize.  My idea/suggestion is that NI make this functionality available in LabVIEW.

It would be great if there is c series CAN interface module which doesn't need an external power supply. This makes it easy to use and saves time to set up because we don't have to find or prepare an additional power source.