LabVIEW
Logging ECU data into a tdms file? Guys!!!!! I need your help!!!!!
Solved!
Hey guys!!! I am trying to log data from ECU. On my black diagram I have two signals (SIGNAL A and SIGNAL B) that have to be written into a tdms file. I just don't understand the fact I only see one signal (signal A) when TDMS file VIEWER is opened. Why am I not seeing "signal B". I attached my VI and pictures for reference.
You have two separate loops. One is reading data, and once you stop it, the last read is then sent to the logging loop where it continually logs the same last reading of data until you press stop. This loop is not limited by any thing and will write to this file very quickly, writing the same data.
Why are you using version 1.0 of the TDMS file?
Can you confirm that the "data" indicator has two signals worth of data? It is possible that only one signal is actually reading data from the CAN bus which might explain why only one signals' data is logged. This might be likely if the signal writes data to the CAN bus at a rate slower than 0.025s. Your reading loop is running so fast that it is possible the read will read nothing since the rate of the frame on the bus is slower than that.
I don't log the waveform data type often so I'm wondering if this a Decimate or Interleave option on the write. I'd test both.
If you are interested in logging all raw CAN frames using XNet, check out the CAN Input Stream to TDMS Log file in the Help >> Find Examples. This allows for logging all CAN traffic to a TDMS file in a stream format. This can be read back with the Display TDMS Logfile (also an example). You may also want to look into logging raw CAN frames as a BLF since this is a more common CAN log format which other tools can consume like Vector's CANalyzer.
If you are interested in logging the Signal values, then you can use the Database palette (under XNet) which can do things like list all signals with some condition and read and log those. I've used this in the past to read all signals from an ECU I'm interested in.
@GRC5000 wrote:
I only have LabView 2019. I would download 2018 if I had more storage on my labptop.
You can go to File >> Save for Previous Version. This back saves the VI into an older format so others on the forum can help.
Thanks a lot for your awesome instructions. I'm able to solve the problem again. I used the Database palette under XNet as you suggested (see attached VI) since I'm interested in logging the signal values. But one thing I noticed is that when I opened the excel sheet of the tdms file. The signals do not have a names. It says "untitled" for all of them as shown below. Is this normal? Have you experienced the same problem? Will I need to hardcode the names of the signals? If not what did you do to solve it?
Notice that the first two signal names are "Signal A" and "Signal B". These are the hard coded names you passed in. All other writes likely didn't have a channel name specified in the TDMS Write function and so it just made an Untitled one. Using the XNet Signal Property node on each signal you are reading you can get the "Name (Short)". This will return the XNet Signal name as a string. You can use this as the Channel Name (assuming you don't have two Signals with the same name).
I am able to log data into the tdms file, but the data comes untitled (as shown below). I tried using a property node, it is still not working for me. Maybe, I am doing something wrong. Can someone please help me?
Thanks in advance.
I attached my VI .
Okay there's lots wrong with this code. Have you taken LabVIEW training? If not check out some of the free training online. During the lock-downs, NI has put lots of their training online for free.
Your loop is running 100 times, with the same scalar input value. This is not getting the signal names, but instead getting the cluster name (the input you provided) 100 times. The single cluster name doesn't change and so you have an array of the same 100 things in it, none of which are the signals.
You are reading the data over and over again in a loop until you press Stop. You are concatenating the outputs. Each read will return a waveform for each signal, on each iteration of the loop. This means if you have 100 signals in your database, you will get 100 waveforms, every 25ms. If this runs for 10s you will get an array with 4,000 waveforms in it. Many of which may be empty.
Lets ignore the 0 iteration for loop, it is probably a test. You are writing to an array indicator, then reading that array indicator and using it as the Channel names. This is a race condition and you can't guarantee it will read from the array after writing it. Use data flow to ensure the data is updated.
Also as mentioned if you ran your code for 10s you will have 100 columns, 40 rows, and each waveform will have an unknown number of data points in it depending on the transmission rate of the CAN data. This will call the write function many times likely with no data.
I also saw you weren't closing your XNet session. This can lead to memory issues, and access issues if it is ran multiple times.
Attached is a simplified version that I think works. It just grabs the first 100 signals from the database to read. There is potential for memory issues since the waveforms will keep getting appended until you stop or run out of memory. A better design might be to write data to a file once so much data has been read. Then after you press stop (or an error happens) the loop stops, we create the file, and write it with a single write function.
