Enqueue flatten string vs cluster

I have seen someone flatten a cluster into string and enqueue the string instead of enqueuing the cluster directly. Is that a reason why he would do that? It was code for LabVIEW 7.0. Maybe a limitation in previous version of LabVIEW? What is the pros and cons of doing that?
Kudos and Accepted as Solution are welcome!

Unless you need to pass the data to something other than a LabVIEW application there is no real benefit to flattening the cluster to a string.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Similar Messages

Bug with Base LVOOP object variants and flatten string.

I found a bug when if the base LabVIEW Object is wrapped in a variant (even indirectly), it cannot sucessfully be flattened to and from a string.
Neither of these should produce an error.
And if you try to work around it with XML, it can lockup or crash.

The first is the simplest demonstration of the problem.
The second is to show that problem is indirect (through multiply layers of different structures).
As for the purpose I was writing a SQLite interface that could write any form of LabVIEW data while maintaining variant attributes. I have to serialize the data somehow so the first attempt I just packed it into a variant then turned that into a string with flatten to string (since the variant contains the type info for what it holds I just need to use the type info for a variant to unserialize it). That failed with the first bug if I tried to store a variant with a attribute holding something down classed to the LabVIEW base object.
So instead of wrapping it in a variant I tried directly flattening it to a string and storing the type info from variant to flatten as a pascal string at the front of serialized data (of course this breaks if a LabVIEW object two variant levels deep is passed in). But that destroys variant attributes. So I tried wrapping that in a cluster then flattening the cluster (hence error two, and since it's indirect I can't wrap it in anything to avoid the problem).
So the current work around is to never store anything in the LabVIEW base object. So If I wanted a generic LVOOP container I would have to make a class for storable items then everything that can be stored would have to inherit from that.
I'm mainly posting since unknown bugs are rarely fixed, and this one is a bit obscure.

Fixed size string and cluster files.

Hi, i need help for 2 things :
- How can i limit the string size that a user can fill. (example, 8 characters max).
- I 'd like to make a file containing 1 (big)cluster / record, with the possibility to modify then with the record number , but when i read it back, it says EOF reach. ( i join my .vi). I wish I could make files that work like those in basic/C programs.
Thank for help.
Attachments:
lecture_direct.vi ‏23 KB

Okay, I see where you made your mistake. In the read VI, wire the datatype to the Open File function and not the Read File. You can also write the data without converting everything to a string. I've attached modified versions of your VIs that do it that way.
Attachments:
enregistrement_direct_mod.vi ‏20 KB
lecture_direct_mod.vi ‏24 KB

Unflatten string to cluster, cluster includes a string

I am reading in a binary string written by a C++ application. For example, let's say the string is made up of the following 3 data types:
1. 16 bit signed integer
2. string (10 characters long)
3. 16 bit unsigned integer
This is a simplification, but it exposes the problem with unflattening a binary string to a cluster with a string in it.
I use the Unflatten From String function and the type is a cluster of the above listed elements. The problem is that Labview has no way of knowing how long the string is. One work around that I an not very fond of is to insert the string length into the binary string immediately after the 16 bit signed integer.
I attached a simple example.
Can anyone suggest any other ideas?
Thanks,
Chris
Chris Reyerson
Optical Systems Engineer
Arete Associates
Tucson, AZ
Attachments:
Unflatten from string.vi ‏11 KB

Hi Jean Pierre,
Thanks for your response. Labview 8 offers and even easier way to unflatten a string than what you show in your second example. One of the inputs for the Unflatten from String VI is, “Data Includes Array or String Size (T)”. Wire up a false to this node and the string (or array) does not need the four byte length header.
Also, Labview 8 asks for the endian type, this is a major improvement for me since previous version of Labview assumed big endian and all my data was little endian. I can't tell you how long I had to work to find a solution to the problem.
Thank you,
Chris
Chris Reyerson
Optical Systems Engineer
Arete Associates
Tucson, AZ

Hex string to cluster

Bonjour,
j'ai la solution a mon pb mais je ne peux pas ouvrir le vi car il est en v9
Quelqu'un peut-il me le mettre en version inférieur à 8.5
Merci beaucoup
Julien GELAY
Tecsup
Technicien BE - Software
Pièces jointes :
Build cluster.vi ‏9 KB

Bonjour,
c'est toi qui generes la trame ?
si oui tu devrais pouvoir proceder ainsi voir attachement
avec ton modele des deux cotés pour reinterpreter la trame puis le cluster
La il me faudrait un bouchon pour tester ( que je n'ai pas)
est ce bien ça que tu cherches a faire ?
@+
Tinnitus
CLAD / Labview 2011, Win Xp
Mission d'une semaine- à plusieurs mois laissez moi un MP...
RP et Midi-pyrénées .Km+++ si possibilité de télétravail
Kudos always accepted / Les petits clicks jaunes sont toujours appréciés
Don't forget to valid a good answer / pensez à valider une réponse correcte
Pièces jointes :
trame.vi ‏24 KB

Flatten to string for sending through TCP/IP contains CRLF characters

Hi,
I'm using a 'flatten to string' function to send some data through TCP/IP.
To minimise delays, I use the CRLF mode so that the receive function returns as soon as it receives a CRLF sequence (termination character).
I noted that every now and then only part of the data is transmitted because the flattened string itself sometimes (albeit rarely) contains CRLF characters.
I was wondering if this is correct behaviour, or if I'm missing something.I expected flatten to string to produce pure ASCII strings without special characters.
Now I first have to scan the string and replace possible CRLF characters by some known series of characters and do the opposite on the receiving side, and hope that this particular sequence never occurs.
Any comment is appreciated,
Manu
Certified LabVIEW Developer (CLD)
Solved!
Go to Solution.

mkdieric wrote:
Hi,
thanks for the feedback. I'll use the way you describe, by first sending the number of characters to expect.
Manu
Make sure you are consistent with the format for the number of butes. That is, always use an 8, 16 or 32 bit value. Which one you use is up to you and will depend on the size of your data. A 32 bit value is the most common size to use. Anyway what I am basically saying is that if you are inconsistent with what size number you use for the size you will get inconsistent results when you read the data since you will be interpretting the size incorrectly some of the time.
Mark Yedinak
"Does anyone know where the love of God goes when the waves turn the minutes to hours?"
Wreck of the Edmund Fitzgerald - Gordon Lightfoot

Variant Data vs Flattened to String

Hi All,
I haven't worked much with the variant data type in LabVIEW and after reading some basics about it, I am wondering what is the basic difference between a variant data type and a flattened string.
I read somewhere that variant data types also contain the meta data which includes the type of the data it has and still we have to wire the data type to the function "Variant to Data'. Why?
What is the use case of variant data type? I am basically thinking of a use case where flattened string can't do a job what variant data type can do.
Thanks,
Ritesh
Solved!
Go to Solution.

[quote]
If a LabVIEW variant knows its own data type, why must you specify a data type in the Variant to Data function? Why can the variant not just unflatten itself? This is by design rather than by necessity. Variants must fit within the existing LabVIEW paradigm, namely that the data type of every wire is defined at design time. If a variant unflattened itself, what color would the wire be? While it is understandable that LabVIEW does not allow a variant to unflatten itself, LabVIEW needs a function that returns the data type of the variant as an enumerated type, similar to the VarType function in Visual Basic. Without any way to check data types before attempting a conversion, the only recourse is to guess an acceptable data type and then check for an error when the conversion fails.
[/quote]
http://www.ni.com/white-paper/4998/en/
Variant to Data still faster than Flatten to String (3x Approximatelly), cause no data conversion is required.
Flatten to string: Labview make an entire data structure copy and reallocate to conversion in single memory block.
Variant to Data&colon; Labview just allocate pointer to memory allocation that actually carries the data.
With Small datatypes, that performance doesn't make any difference,but it's important to understand this concepts.
PS: Sry for bad english. I'm brazilian.
"In theory, theory and practice are the same. In practice, they’re not."

Flattening LV Timestamp to String

Hardware:
cRIO 9004 with 9103 FPGA.
I am running your standard Low-Priority, High-Priority / Host PC
split-architecture to acquire data via my 9004/9103 and sending that
data via TCP/IP to my host computer.
I want to send a unique timestamp generated in the High Priority loop
with my FPGA data over the TCP/IP , but need some advice on how to
break it up and append it to my flattened string. The reason I
want to do this is that I want to generate a waveform from my data when
it gets back to my host PC. The data is in an array from my FPGA
call.
I can cobble something together, but am wondering whether someone
cleverer than I has run into this and has some advice / sample code.
Thanks!!
Wes
Wes Ramm, Cyth UK
CLD, CPLI

Hi Wes:
If I understand correctly, all you are trying to do is to essentially transport a waveform from your RT system to your Host?
If so you can simply take the data point and the time stamp and use the Build Waveform function on your host side.
Best Regards,
Jaideep

Flatten Variant to String vs. Flatten Data to String in case of variant data type

May be a dumb question, but I want just understand what is the principal difference and what are the restrictions for both methods? Also I noticed that in case of "Flatten Variant to String" it looses all its attibutes, and this is not in case of flatten generic data to sting. Where I can find a more detailed info on this?
LabView Ver. 6.0,6.1

defuflo,
See OpenG.org >> Site Docs >> LabVIEW Data 1 of 2.
On non variant data, "Flatten to String" and "Variant to Flattened String" have the same output.
On Variant data, "Variant to Flattened String" ouputs the flattened string and type string of the sub-type held in the variant. All variant attributes are lost in the process since they belong to the variant, not to the subtype.
"Flatten to String" operates on variants like on any other types, returning the type string of a variant and all its flattened data, including any attributes.
LabVIEW, C'est LabVIEW

Unflatten data using only the output from flatten to string

Using the Unflatten from String vi requires that you provide the type. This is not always possible - you may not know it (or you have a number to choose from). In a situation where the original data is flattened, then the Type String & Data string are clustered & flattened again, you have a common structure no matter what the source data. Unflattening will return the Type & Data strings of the original data, however I have seen no vi anywhere that either converts Type String to Type, or Unflattens data given only the Type & Data strings. How is either of these done?
Attachments:
Type_conversion.vi ‏48 KB

You are asking too much from LabVIEW or any compiler for that matter. When the the datatype is unknown or undefined at compile time, it can't change the code to adapt to the incoming data. That is the programmer's job to do this and provide code to detect the incoming datatype and branch to appropriate routine to handle each datatype after it has been cast to a known type.
The compiler has to know the datatype before generating the code. Can you imagine executing your diagram in debug mode and see the wire change type from one iteration to the other as the incoming data changes type? That's the programmer that knows what datatypes are to be expected.
The original poster suggested to bundle typestring and flat data: you essentialy have
a structure similar to a variant. If you want to use undefined datatype, you should use variants instead of flattened strings since it includes the datatype. See my presentation on OpenG.org http://openg.org/tiki/tiki-index.php?page=2003-05-06+Group+Meeting
to see how to manipulate variant data at run-time.
LabVIEW, C'est LabVIEW

Storing cluster data in a file

I have a cluster array of numeric indicators.
How to store this data in an excel format?(or anyother format from which I can read the data back) I use Version 6.0
Veena

If your purpose is to simply restore a previous set of values from one session to another, or to provide a choice of different data sets, your easiest method is a flattened string file.
Just wire your cluster array into the Flatten To String function and into Write Characters To File VI.
To read the file, just wire Read Characters From File into Unflatten From String. Use the empty cluster array indicator as the data type.
Another option is to write an XML file, but that requires LV61 or the OpenG toolset.
Michael Munroe, ABCDEF
Certified LabVIEW Developer, MCP
Find and fix bad VI Properties with Property Inspector

Cluster Version control Design question

Hi All,
I have an application where I store the data in a cluster. Suppose this is my ver. 1 of the application and the cluster consists of 3 I32. and I ship this application to the customer.
Now for the ver 2 I want to store a string to the cluster so I updated my cluster to 3 I32 and 1 String. But this ver 2 should also be able to read ver 1. just like MS Word 2007 is able to read .doc files
In my design, I am stroing the version number and data(as variant) in a cluster and convert that cluster to variant and do a 'variant to flattened string' before saving it to a file.
I am attaching my desing protoype here so you get a better idea of what I am talking about and suggest me if you think it can be done in a better way.
Thanks,
Ritesh
Attachments:
ClusterVersionControl_Design.vi ‏17 KB

Any Ideas?

Unflatten From String causes runtime error in LV2009

I found this error when trying suggestions made in this thread.
http://forums.ni.com/ni/board/message?board.id=170&thread.id=458335
Unflaten from string causes runtime Error 74 possible reason(s) Memory or data structure corrupt.
Attachments:
Unflatten runtime error.vi ‏8 KB
error1.jpg ‏13 KB

Of course you are getting the error. The data types are inconsistent. You convert the cluster to an array. You then define the type of flattened string as a cluster. Either don't convert to an array or define the data type as an of paths. Look again at the examples in that post.

How can I get a variant's string data?

Greetings!
When I view a variant indicator, I see a (generally) human-readable block of text. This makes sense to me, since, as I understand it, a variant is, internally, a kind of flattened string. My question is: is there a way that I can get that string in LabVIEW, and can I then load that string back into a variant?
I'm trying to preserve the human-readable aspect of the variant data. Flatten to/Unflatten from String is not human readable, and the variant versions of Flatten/Unflatten drop the variant's attributes. I've also tried Flatten to/Unflatten from XML, which drops the attributes AND does not unflatten correctly.
Any help you can offer would be appreciated.
Thanks!
Allen C. Smith
Ktech Corporation

I think Allen wants to have access to the plain string that is displayed in the variant container and I have not found a way to get it. The method should require no code and should be independent on the complexity of the data contained in the variant.
I agree this could be somewhat useful and should be supported. For example, we could have a readable property for the variant indicator similar to the text.text property of string indicators.
The text.text string property gives the text formatted as shown in the indicator and thus depends on the display style (normal, '\'-codes, password, hex). It can be e.g. used to convert a plain string to a plain string that incorporates '\'-codes that is available to the code. (See image). This could be useful in a case where you want to mix '\'-codes and plain codes in a descriptive display, for example containing the following three lines:
"The received string in '\'-codes is:
ABC\tDEF\tGHI\n
please verify there are no unexpected characters"
Message Edited by altenbach on 01-17-2007 09:40 AM
LabVIEW Champion . Do more with less code and in less time .
Attachments:
StringDisplay.png ‏10 KB

How does "Unflatten From String" take a type and return a value of that type?

http://zone.ni.com/reference/en-XX/help/371361E-01/glang/unflatten_from_string/
How exactly does the "type" argument for "Unflatten From String" work? I need to create a VI that takes a type, passes it as an argument to several calls of the "Unflatten From String" function, and returns an array containing elements of the type originally passed. The "Unflatten From String" function seems to do some magic though, because the type of the "value" that it outputs changes depending on the type it is passed as input. How do I do the same magic in my VI?
Ultimately, what I need to accomplish is an unflatten-list operation. Given a type T and a byte string of length L (which contains a concatenation of T elements that are flattened to their bytes), create a VI that unflattens all the types in the string and return an array of length (L / sizeof(T)) that contains each type.
Note: performing the unflatten-list operation is trivial, but I cannot for the life of me figure out how to do it in a VI that takes a type and returns an array of the appropriate type. By the way, my data is being given to me from another source, so please don't bother suggesting that I should be flattening an array using LabVIEW's "Flatten To String" function in the first place. My data is not given in LabVIEW's array format: http://zone.ni.com/reference/en-XX/help/371361B-01/lvconcepts/flattened_data/
Thanks a ton!
-Wakka

Take a look at this example: You can see that the flattened string contains several bytes. The first four bytes contain the length of array (number of elements). Since the data type is U32, the next 32 bits (4 bytes) contains the value of the first element, and so on. Could you possibly use this scheme to do what you want to do? Other data types present different outputs. You would have to experiment with them.
- tbob
Inventor of the WORM Global

Enqueue flatten string vs cluster

Similar Messages

Maybe you are looking for