topic Re: LabVIEW Data Storage Application Note 154 in LabVIEW

LabVIEW Data Storage Application Note 154

instrumento — Thu, 03 May 2018 19:58:53 GMT

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.

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Mon, 05 May 2025 16:00:23 GMT

It's in the (online) help now.

Re: LabVIEW Data Storage Application Note 154

instrumento — Fri, 04 May 2018 13:03:27 GMT

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.

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Fri, 04 May 2018 13:11:06 GMT

@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).

Re: LabVIEW Data Storage Application Note 154

rolfk — Sun, 06 May 2018 22:30:56 GMT

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.

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Mon, 07 May 2018 07:36:04 GMT

@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.

Re: LabVIEW Data Storage Application Note 154

instrumento — Mon, 07 May 2018 13:29:36 GMT

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.

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Mon, 07 May 2018 14:07:53 GMT

@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.

Re: LabVIEW Data Storage Application Note 154

instrumento — Mon, 07 May 2018 14:21:43 GMT

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.

Re: LabVIEW Data Storage Application Note 154

rolfk — Mon, 07 May 2018 14:37:43 GMT

@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.

Re: LabVIEW Data Storage Application Note 154

instrumento — Mon, 07 May 2018 14:46:10 GMT

No there isn't!

Thanks, that completes the answer to my original question. I already accepted the answer pointing to the online help as solution, not sure I can also mark this one as solution too.

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Mon, 07 May 2018 15:09:55 GMT

You can mark two solutions.

Re: LabVIEW Data Storage Application Note 154

instrumento — Mon, 07 May 2018 21:49:49 GMT

@rolfk
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.

This is to interface to old stuff that won't be recompiled, so it will stay the same.

To get 0xF1 from a flattened stream, create any typedef, wire it to a "To Variant " conversion, then wire the variant to "Flatten to String". The flattened string will contain the 0xF1 type code.

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Tue, 08 May 2018 08:22:38 GMT

@instrumento wrote:

This is to interface to old stuff that won't be recompiled, so it will stay the same.

Yes! Nurture that technical debt!

OK, OT, especially since you mentioned this a few times. Just saying I think it's a bad decision. Sooner or later, someone will pay the price. Might even be happening right now...

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Tue, 08 May 2018 11:52:27 GMT

wiebe@CARYA wrote:

@instrumento wrote:

This is to interface to old stuff that won't be recompiled, so it will stay the same.

Yes! Nurture that technical debt!

OK, OT, especially since you mentioned this a few times. Just saying I think it's a bad decision. Sooner or later, someone will pay the price. Might even be happening right now...

@instrumento wrote (PM):

Not sure this type of replies adds too much to the discussion.

It's wasn't mend as condescending, just a fair (and somewhat funny) warning. In fact a very serious warning.

Not sure how else to help.

PM me all you want, but at least accept PM's back.

Re: LabVIEW Data Storage Application Note 154

JÞB — Tue, 08 May 2018 18:43:05 GMT

wiebe@CARYA wrote:

You can mark two solutions.

You could too. Just saying...

Re: LabVIEW Data Storage Application Note 154

JÞB — Tue, 08 May 2018 18:47:52 GMT

@rolfk wrote:

@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.

Which really sucks when the implementation does not match the documentation.

We all write bugs, it takes an engineer to really screw things up! What is the Russian Phrase? "Доверяй, но проверяй"

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Wed, 09 May 2018 07:40:47 GMT

@JÞB wrote:

wiebe@CARYA wrote:

You can mark two solutions.

You could too. Just saying...

True. But I'll leave it to OP in this thread.

Re: LabVIEW Data Storage Application Note 154

wiebe@CARYA — Wed, 09 May 2018 07:56:47 GMT

BTW (trying to make amends):

In \National Instruments\LabVIEW 20xx\vi.lib\Utility there is a .llb called GetType.llb.

This might not solve anything, it's definitely not the documentation you're looking for. But if you (are forced to) work with flattened types, it is definitely an interesting library to get to know.