Jump to content

Preserving cluster version among different LabVIEW versions


vivante
Go to solution Solved by ThomasGutzler,

Recommended Posts

Hi,
I'm facing this issue with LabVIEW 2014.
I have made a program with LV 2012 that passes some clusters to another application, made with LabVIEW 2012 also.
All clusters are passed as strings between the two programs, using "Flatten to String" and "Unflatten From String" VIs.
Well, everything works smooth when both applications are compiled with the same release of LabVIEW.
I have rebuilt the application that send data with LabVIEW 2014 and the receiver generates an error because cluster version is not recognized
 

 

Is there a way to preserve cluster version (i.e. maintain LabVIEW 2012 version, in my case) so that I do not need to rebuild all applications with LabVIEW 2014?
Link to post

Hi,

 

Hi,

I'm facing this issue with LabVIEW 2014.
I have made a program with LV 2012 that passes some clusters to another application, made with LabVIEW 2012 also.
All clusters are passed as strings between the two programs, using "Flatten to String" and "Unflatten From String" VIs.
Well, everything works smooth when both applications are compiled with the same release of LabVIEW.
I have rebuilt the application that send data with LabVIEW 2014 and the receiver generates an error because cluster version is not recognized

 

I don't have a solution immediately, but try flattening your cluster with both LabVIEW 2012 and 2014. Save the flattened strings to disk, and then compare them with a hex editor. What differences do you see?

 

They've changed the internal format of flatten to string between 2012 and 2014. This is what you want to do on your 2014 application:

attachicon.gifpic.png

 

I believe that setting  is for compatibility between LabVIEW 7.x and 8.x http://www.ni.com/pdf/manuals/371780e.pdf

 

Anyway, could you please provide a link to any documentation/discussion about the change in the internal data format between 2012 and 2014? The latest changes I could find are between LabVIEW 2011 and 2012: http://forums.ni.com/t5/LabVIEW/Why-is-a-flattened-variant-different-in-LabVIEW-2012-and-LabVIEW/td-p/2329878

Edited by JKSH
Link to post

Thomas is right, the flatten to string format was changed between LV 2013 and 2014.

To be backwards compatible you need to use flatten the string to the 7.x format in LV 2014 if you like to read that file/format in LV2013 or earlier.

This should only be needed if you want to go back to LV 7,x according to the documentation, but if you test it you'll see that there is a difference between 2014 and 2013

Link to post

Thomas is right, the flatten to string format was changed between LV 2013 and 2014.

To be backwards compatible you need to use flatten the string to the 7.x format in LV 2014 if you like to read that file/format in LV2013 or earlier.

This should only be needed if you want to go back to LV 7,x according to the documentation, but if you test it you'll see that there is a difference between 2014 and 2013

 

The official advice is to use some arbitrary primitive hidden in the utilities directory (VariantFlattenExp.vi) that takes a version number  :blink:. I wonder what potion they were drinking when they came up with that gem?

  • Like 1
Link to post

The official advice is to use some arbitrary primitive hidden in the utilities directory (VariantFlattenExp.vi) that takes a version number  :blink:. I wonder what potion they were drinking when they came up with that gem?

Wow, awesome. I was under the impression you could just use variant to flattened string which includes the type info, but maybe your VI is what I heard about. And that VI also has a different connector pane than everything else, 3:2 :/

Link to post

Wow, awesome. I was under the impression you could just use variant to flattened string which includes the type info, but maybe your VI is what I heard about. And that VI also has a different connector pane than everything else, 3:2 :/

 

Let me know if you come across a crystal ball.vi to compliment it that tells us what LabVIEW version the VI reading our data is. :P 

  • Like 1
Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By Fred chen
      Hi
       
      When I call the DLL, there is a structure:
      struct Signal { uint32 nStartBit; uint32 nLen; double nFactor; double nOffset; double nMin; double nMax; double nValue; uint64 nRawValue; bool is_signed; char unit[11]; char strName[66]; char strComment[201]; };  
       
      There is another  Message structure to the above Signal:
       
      struct Message { uint32 nSignalCount; uint32 nID; uint8 nExtend; uint32 nSize; Signal vSignals[513]; char strName[66]; char strComment[201]; }  
        The point is  Signal vSignals[513];
       
      I've tried to solve it like this,but the program will crash.
       
      How to create struct Message ,any good suggestions?  Thanks a lot.
       

      message.vi
    • By Taylorh140
      After working on the set cluster element by name xnode, it made me realize i could use the same concept to convert a variant array to a cluster. The technique is actually pretty simple, the xnode generates a case structure for each element in a cluster in cluster order, wherein a bundle by name is used to set the value and an unbundle by name is used to get the type, a variant to data is used to convert the data. This has some benefits over some methods, you are not limited to 255 elements, although that is not usually the case some of us are paranoid that clusterosaurus giganticous will be larger than expected. It also has a draw back  that is that when converting from a variant array all the elements must have unique, non-blank names, and this is usually the case. 

      I think this technique (though very brute-force) might be useful for some other things let me know what you guys think.

      VariantArrayToCluster.zip
    • By Taylorh140
      This Xnode allows setting a cluster element by label string without using references. I pulled a great deal of inspiration from Hooovahhs Variant Array to cluster xnode, which i suppose this could be used for, another benefit is its not limited to 255 elements. Its mostly experimental because I haven't used it much. 
       
      SetClusterElement.zip

      SetClusterElementLV2013.zip
    • By Porter
      Is there any way to automatically wire an index array block to a bundle by name block?

      Auto-wire (pressing space) just adds one wire.
      Note that my cluster contains data of different types so converting the cluster to an array doesn't work.
      If there is a quick-drop shortcut for this I would be very impressed.
    • By GregFreeman
      Edit: found this in context help: Arrays and strings in hierarchical data types such as clusters always include size information.
       
      http://forums.ni.com/t5/LabVIEW/Write-to-Binary-File-Cluster-Size/td-p/3199224
       
      I have a cluster of data I am writing to a file (all different types of numerics, and some U8 arrays). I write the cluster to the binary file with prepend array size set to false. It seems, however, that there is some additional data included (probably so LabVIEW can unflatten back to a cluster). I have proven this by unbundling every element and type casting each one, then getting string lengths for the individual elements and summing them all. The result is the correct number of bytes. But, if I flatten the cluster to string and get that length, it's 48 bytes larger and matches the file size. Am I correct in assuming that LabVIEW is adding some additional metadata for unflattening the binary file back to a cluster, and is there any way to get LabVIEW to not do this?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.