Help with write cluster to TDMS

[doyles]

How do I loop through a cluster and write the elements' names and data to a TDMS file in human readable form?

The attached TDMS Save.vi gives an idea of what I would like to do programmatically.  You can open the created TDMS file and you can see how I would like the file to look as well.  I want the TDMS file to have human readable data so as to allow it to be opened using the TDMS viewer.

I have been searching the forums, Lava, and Google, and I have experimented with the openG vi's but I haven't figured it out yet.

[AdnanZ]

I don't understand the problem here. You should be able to run this VI and see the values through the TDMS Viewer. One suggestion would be to just use the Build Array instead of Initialize Array to make things simpler.

[doyles]

Sorry I wasn't clear.  You are right Adnan, I can run that vi and I can generate and view the TDMS file just fine.  The TDMS file is just how I want it to look as well.  But I want to be able to create that file without the explicit mapping of each element.

There are technically two things I want to do that I can't figure out:

1. I want to programmatically go through the elements of any cluster and write to a TDMS file the cluster elements' name as the channel and value as the data.

2. I want to programmatically read that TDMS file and put the data into a cluster based upon matching the cluster element's name and the TDMS channel name.

I believe if I can get help with the first I can figure the second out.

[Ben · Accepted solution]

This nugget may give you some ideas.

And before you click that link I will I will say it for you, "ouch!".

But don't give up to fast. Read through the replies and the other links. One of them should get you where you want to go, if you choose to go there.

Ben

[doyles]

Hello Sir Ben,

Thank you for your time, as always.  I have previously looked at that nugget (and many others of yours btw) a couple of times and hope to fully understand it after a couple more read-throughs. 

I'm currently working through this thread on Lava. It's been frustrating using Lava since all of the links are now broken.  Am I the only one who only goes to the main Lava page when I click on any link to a Lava page these days?    Either way, I am currently looking at the VarianttoTDMS.llb and seeing where that will lead.  Based upon what Herbert said in this follow up thread though, it looks like I'm not the first to ask and the not the first to be told "now you know what it's like to want".  Do these Lava links work, btw?

After I look at the VariantToTDMS.llb, I will go through your nugget again.  The work I've done in the past couple days trying to get this functional might help explain some things.  I actually looked up this exaxt nugget on purpose yesterday but didn't see it getting me where I wanted to go (at least not without the very large amount of work you put into that).  Mind you it was late in the day after a full day of not getting something working that I keep thinking "has" to be soo common that it's been solved numerous times and I scrolled through it quite fast.

I keep finding solutions that I think are close but not quite right.  I tried this example but I don't want to use the vi reference for all FP controls and the TDMS file wasn't human readable.  I did try to use it with the cluster reference but ultimately the TDMS file isn't human readable for the viewer and I don't know how to modify that to get it there without changing it completely.  It's nice code, but not quite what I want to do.

Thanks again,

Scott

[Ben]

LAVA recently got a face lift and I am still trying to figure out the new version.

If you keep you data structures simple (no arrays of clusters or arrays) my Nugget code should lead you to writing the cluster to TDMS with the fancy stuff (recursive calls to parse the cluster).

Both the OpnG and Good Ieas version may also be to your liking.

That is all I can say now. That code that I posted in my nugget was displaced by LVOOP versions so I have not used anything like that on TDMS.

If you come up with something useful, I am sure there will be people in the future that would benefit from your efforts. If you can not post don't worry. I would be curious what you finally decide to do tho.

Have fun!

Ben

[doyles]

So you have the Save / Restore code in both AE and LVOOP formats?  Barring any ip issues, the comparison of the two code sets sounds like another interesting nugget to me....

[Ben]

---

@doyles wrote:

So you have the Save / Restore code in both AE and LVOOP formats?  Barring any ip issues, the comparison of the two code sets sounds like another interesting nugget to me....

---

"There's the rub" (Hamlet's Uncle? Shakespear)

I am working two avenues to enhance my support of the cummunity without violating the terms of employment. One of them is in the works now and eventually the second will open up and allow me to continue with my Nuggets.

Until then let me say "LVOOP is just AE's turned inside out" so in the case of the contraqst between the two version. My published NUgget tells the cluster what its setting shoudl be.

In the LVOOP version I have a method that can be understood as "Go load yourself".

Q:

Has the nut started to crack yet?

Curious,

Ben

[doyles]

Yes, I believe so.  Good call on redirecting me back to your nugget.

I had a fairly good idea of what you were doing after I read through the nugget the second time a month or so ago, but not exactly how you were doing it nor a good enough understanding to do much with the code.  I had downloaded the code and played with a it a bit then too, but there were a few too many things that were a bit beyond me at that point.  I grabbed the code again yesterday (after having quickly realized the VariantToTDMS.llb was already installed on my machine through VIPM and those were the vi's I had already been experimenting with) and went through your code and replaced all of the config file associations with TDMS related vi's / references.  It took me a little while on the recursive cluster vi calls to properly get the appropriate strict type vi refnum that is needed.  Following that down to the config.llb in the utility folder opened my eyes a bit more as well. I thought I was sunk for a minute when I realized you were using a native LV file reference and I couldn't find any such thing for TDMS.  But I do believe I have worked around that properly.  I have also added cases for Enums throughout, just so can I use my own cluster.  I am in the process of testing it out right now.  The enums get through the init part, but I doubt I'll actually have the correct value when I get it into the TDMS file (likely to be the index value, but we'll see).  I am currently working through it erroring out when "learning" an array.

Thank you once more.  Half the battle was my frustration of struggling with something that "should be easy" in LV. Seeing the effort you put into this is not only inspiring, but also a relief that I was struggling for a reason.  And now I believe I am on a good track to have a reusable TDMS code set.  (Only replacing a cluster for a new project is acceptable as reuse, imho, especially when the alternative is unbundling / bundling every single element for every single project and then managing any changes - scary.

[doyles]

Hi Ben,

I have successfully updated your save/restore example from your nugget to use TDMS.  I also incorporated the GetTypeInfo.vi in the "learn" portion, as suggested by JPD in the nugget, and the alternate method to get the array size in the example posted by Shoneill, also within the same nugget.

Everything seems to work well so far: I've only done some quick testing and have yet to integrate it into a functional project.

I did notice that a couple of the vi's would not close properly a few times.  I have not been able to create a repeatable fail case, but I believe it happens when I open up one of the recursive vi's (that open in [clone] mode) and put it into Edit mode, along with some combination of making changes, saving, and running the clone instances of the vi.  LabVIEW never hung per se, but that specific vi wouldn't close.  And after I end the LabVIEW task, I couldn't restart LabVIEW until I had completely restarted my laptop.  I've never played with recursive vi's before now, and I only know enough to be dangerous.  Is this behavior expected?  I couldn't find anything relating to reantrant vi's and that behaviour.

I will look into my ability to post the code.  I don't think there will be a problem, but I need to be sure, of course.  Would you suggest I post it here or at the bottom of your nugget thread?

Scott