LabVIEW Data Storage Application Note 154

[instrumento]

Is there a more update manual or application note, than the LabVIEW Data Storage, Application Note 154, from April 2003?

I thought I ran into that somewhere else but can't find it now and searching here or on google just returns a large haystack with no needle.

Thanks.

[wiebe@CARYA · Accepted solution]

It's in the (online) help now.

[instrumento]

Thanks!

I had actually bumped into that page, but the fact that flattened data and type descriptors are buried at the bottom, as links to other pages, made me overlook the fact that all that was in the application note is indeed there.  And it has been updated with the type codes for 64 bit quantities, which I had seen already, probably in that same help page.

However, a few things are missing, as my old code which I'm trying to update (don't ask) handles what seems to be a type code of 0xF1 (for typedefs?) and storing the variable names along with the data.   I don't remember whether I deduced that or saw it explained somewhere else.

[wiebe@CARYA]

---

@instrumento wrote:

However, a few things are missing, as my old code which I'm trying to update (don't ask) handles what seems to be a type code of 0xF1 (for typedefs?) and storing the variable names along with the data.   I don't remember whether I deduced that or saw it explained somewhere else.

---

You mean it's flattened data type is 0xF1? I think only enums stores their names in their types.

There are only a few use cases where using flattened data is appropriate. In almost all cases, variants are a lot easier\clearer\safer to use. Problem with using flattened data is that it's totally unreadable without proper comment (as you are probably finding out right now).

[rolfk]

Typecode 0xF1 is not a useful Flatten type at all. It may exist internally in LabVIEW for some reason but generally typecodes above 0x80 do not exist or are for internal types that are not exposed through LabVIEW data types. 0xF0 is the functionCode and 0xF1 is the typeDefCode, but they can only happen when you try to flatten a strict typedef VI refnum, which for flattened data is pretty useless as a refnum is non-persistent, meaning flattening and transferring to another LabVIEW instance, on the same computer or another one, is pretty useless as it means really just as much as a pointer value, which is only valid inside the process that "created" the memory location.

[wiebe@CARYA]

---

@instrumento wrote:

I'm trying to update (don't ask) handles what seems to be a type code of 0xF1

---

Guess we can't do much more without asking.

[instrumento]

---

wiebe@CARYA

---

@instrumento

I'm trying to update (don't ask) handles what seems to be a type code of 0xF1

---

Guess we can't do much more without asking.

---

We have these (getting old) LabVIEW programs that talk to each other via some custom TCP/IP code that uses FlattenToString (7.x variants) and UnflattenFromString, to send variants back and forth.

The (don't ask) above was more to avoid suggestions of "don't do that, instead do ...", as that is not the point.

I want to replace one of those programs with a non LabVIEW program, and trying to make sure we can send (and receive) the exact same packets, and some of them do have 0xF1 typcodes.

I'm not trying to create a completely generic replacement, just for the cases that are present in the programs above, and trying to understand the encoding ot typecode 0xF1 packets.

I've already done most, if not all of it (again, for our types case) , and was just looking for documentation to make sure my guess of what the 0xF1 packet can be is somewhat accurate.

[wiebe@CARYA]

---

@instrumento wrote:

---

wiebe@CARYA

---

@instrumento

I'm trying to update (don't ask) handles what seems to be a type code of 0xF1

---

Guess we can't do much more without asking.

---

We have these (getting old) LabVIEW programs that talk to each other via some custom TCP/IP code that uses FlattenToString (7.x variants) and UnflattenFromString, to send variants back and forth.

The (don't ask) above was more to avoid suggestions of "don't do that, instead do ...", as that is not the point.

---

Exactly what I was thinking (in other words: it worked).

It might be worth the effort to figure out if (and how) 0xF1 is ever used. That could be difficult if the code is bad... You can put a breakpoint or probe in there. If you can test with enough coverage, you might be able to rule out the usage of 0xF1.

Even if it's used, I'm not sure how a program other then LabVIEW would deal with it, other then using it's name for logging or something like that.

[instrumento]

---

It might be worth the effort to figure out if (and how) 0xF1 is ever used.

Maybe I should have made it more clear from the start.

All I am asking is whether there is documentation for all the type codes in flattened data, including the ones NOT in the original App Note 154 or its online replacement, be it 0xF1 or another.

[rolfk · Accepted solution]

---

@instrumento wrote:

All I am asking is whether there is documentation for all the type codes in flattened data, including the ones NOT in the original App Note 154 or its online replacement, be it 0xF1 or another. 

No there isn't! What is mentioned in App Note 154 and the online help is all NI is willing to document in terms of making users rely upon, that it will not change in the future. Anything not documented in there can change at any time. It's one of the reasons not to document things that are considered internal implementation details, as documenting something basically is similar to writing it in stone. It can never again be changed!

I'm really not even sure where one would get this typecode from in a flattened data stream. Maybe if you could show us how to get it we could give you some more information about how it may be meant to be used but as already said, relying on this to stay the same in future versions of LabVIEW is building a bomb in your software.