LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TDMS file viewer not functioning as expected

I'm new to LV so I'm probably doing something obvious to the battle hardened among you, I'd appreciate a hand!

 

I've got a cRio that's running a modified version of one of the datalogging examples, and it's logging to its internal memory, which I FTP into and collect when done. But I'm having some issues with viewing it after. I've created a VI on the host system that looks for the TDMS files on the C drive of the host. I log a file with name "data". I copy over the TDMS and TDMS_Index files to the C drive of the host computer and run the TDMS fileviewer VI on the host, which checks for the file existing and opens it. If the file isn't there it complains, of course (but shows old data in the background). If it is there it opens it. However this is where the problems begin.

 

The index headers for the top of the columns of data seem to be changed inside the files but do not always change in the fileviewer output, and the data seems to never be updated with the new data, despite all files having been erased in between runs. I've tried 4 or 5 re-loggings and always get the old data, and often the old indexes. Out of curiosity I changed the log filename to "data2" and changed the viewer path to the new file, copied it across and opened it and it worked flawlessly. Then delete-all and re-recording with the "data2" filename the problem returns - old data held until filename changed.

 

The files on the CRio and host are definitely changing each time - their sizes vary when copied across - but the viewer VI doesn't seem to reflect any changes unless the filename is changed on each run, which is a pain. I assumed LV may have some sort of cache of the data, so tried closing LV down each time but it didn't help at all.

 

Any ideas? As I say, probably something very obvious but I'm new to LV and haven't spotted it.

 

Cheers

0 Kudos
Message 1 of 13
(3,061 Views)

Hey JBGU,

 

Is chance of getting a look at your code? Is it to my understanding that you do not want to change the names of the files each time a new set is collected, why is this? Have you considered FTP the info directly from the RIO to the host and using the Host VI to save that to a TDMS file? Have you ensured the TDMS setting is “Create or Replace”?

 

Regards

Andrew George @ NI UK
0 Kudos
Message 2 of 13
(3,041 Views)

Hey JBGU,

 

Can we get both the code on the RIO and the Host.

 

Regards

Andrew George @ NI UK
0 Kudos
Message 3 of 13
(3,040 Views)

Hi,

 

Cheers for reading."Untitled" is the Rio VI, "lv" is the host VI for reading the TDMS when I've transferred it across to the host PC with FTP. I'll have a think further on it.

 

Cheers,

James

Download All
0 Kudos
Message 4 of 13
(3,035 Views)

I'd not say I don't WANT to change the filenames, just that it's an added complication I don't need and haven't worked out (yet) how to set up the TDMS viewer to give me a dialog to select a file rather than specifying one. Is there a "standard" TDMS viewer I can use instead of having to create a VI for it? I'd happily have date/time-stamped files, and automated transfer - I've just not got it organised yet!

0 Kudos
Message 5 of 13
(3,033 Views)

Hey James,

 

Your code seems fine; I won’t be able to run it as I don’t have access to the Hardware at the moment our RIO is currently under test. However I would like to get a screen shot of the TDMS file viewer and also a copy of the TDMS file, a brief description of how you want the file edited would be perfect. I have done some small re-architecting to your code also. I have just moved the data display to the host, as in your "untitled" VI you had a timed loop and a normal loop in the same frame. The normal loop in this condition will take priority over the timed loop and this could be the reason behind the strange data logging experienced in your system. Remember your rules of data flow in LabVIEW, so long as all you functions are joining via wires they will execute in order and therefore there is no need for sequence structures.

 

I have attached the modified code to this post.

Regards

Andrew George @ NI UK
Download All
0 Kudos
Message 6 of 13
(3,020 Views)

Cheers for that modification, I see how you've done it now, however that introduces a few problems for me that I've only just come across...

 

The RIO with the old software logs to the RIO internal mem, and the TCP connection is only for viewing the data as it comes in. This meant that when my noisy motor driver upset the network link the RIO continued happily logging away, but with this version the file writing stops and the data is lost. I was under the impression, with the example that I modified (http://zone.ni.com/devzone/cda/tut/p/id/11198) to create the first one, that the main sensing loop would be the one executed with minimum jitter/latency and the file writing and screen update would occur whenever it got chance. I'll do some logs and upload them but I don't think it'll help as the files are now of the format I want, it's just the strange "residual data" problem I'm having. The problem is possibly easier to see than explain, I'll do my best!

 

Thanks for your help so far, much appreciated.

0 Kudos
Message 7 of 13
(3,011 Views)

Hey James,

 

If that’s the case you could move the data logging to the RIO and view the data as it comes in, I just think it’s best to leave as little on the RIO as possible. However I do believe that the error was introduced in your second sequence structure where you have a while loop and timed loop stacked, as LabVIEW will always prioritise as stand loop over a timed loop. If you find the time can you do your data logging on the RIO, however keep your front panel indicators on the host and once you stop the loop on the RIO then view the TDMS. If you want any example code on how to do this then feel free to ask.

Regards

Andrew George @ NI UK
0 Kudos
Message 8 of 13
(3,006 Views)

This may be a Windows problem. I've opened two explorer windows, one at ftp://192.168.1.100/ and one at c:\  - I then copy and paste from ftp to c:\ and the copy appears to happen, the paste appears to happen, however it seems to use the first version of the filename on the paste. For example:

 

Record a log, 100kb long, copy, paste - file on host is ~104kb (expected, switch between storage types/OS's/block sizes).

Delete both files from the RIO and the host. Record new log with same name at 250kb. Check it on ftp:// and it's 250kb. Copy and paste it to c:\ and it becomes 104kb and contains the old data.

 

It's as though windows FTP client keeps a filename-based copy in a cache and only ever takes the first version when pasting, despite re-doing the COPY and the PASTE. This is odd. I'll try a different FTP client and see how I get on. I hate Windows!

0 Kudos
Message 9 of 13
(3,005 Views)

Hey James,

 

You could always try and save to text file and reformat into TDMS later, see if that makes a difference, doubt it though.

 

How long are you planning on running the device for? You could always save to internal drive of the RIO and then FTP the complete file to the host, this may stop issues you having with windows being its normal unforgiving self.

Regards

Andrew George @ NI UK
0 Kudos
Message 10 of 13
(2,997 Views)