Bug in "Unflatten from String" (LV7)

I have binary files with different versions of a certain datatype. When loading a file, I try to unflatten the data using the newest dataversion. If I get an error, I try the 2nd newest dataversion and so on until I found the right datatype. This methode was ok up to LV6.01.
Now I updated to LV7.0ger and I found following bug:
When unflatting certain binary datas from string I get an error msg window "Nicht genügend Speicher zum Abschließen dieser Operation". The error-output of the vi is incorrect.
Does anybody know a workaround of that bug?
You can test the bug with the attached vi. Include also the two typedefs.
Attachments:
f_mancalib_UnflattenTypeCalibList.vi ‏184 KB
f_mancalib_TypeCalibrationParams.ctl ‏24 KB
f_mancalib_TypeCalibrationList.ctl ‏28 KB

Hi,
From the LV's help: "National Instruments recommends reworking any
application that uses the Convert 4.x Data mode as a long term solution.".
Data types may vary with differenct versions of LabVIEW. So, if types are
not the same, this does not need to be a bug. Right click the Unflatten From
String, and select Convert 4.x Data. This might not work, because the data
is stored with Lv 5 or 6, but when you get it working, it will keep working
for future versions of LV.
The attached VI shows that a sting in a cluster does not convert to the same
type string for lv4.x and lv7. Perhaps they are the same for lv4.x and lv6.
If so, using convert 4.x data would be sufficient. If not, you need to read
the data in 6, save the binary 4.x strings
, and use 4.x from then on.
You might also do the following: (also from the help) "If you use this
function to flatten data from a custom control or indicator that you saved
as a type definition, the function strips the type definition of its type
definition wrapper. If you do not want to strip this wrapper, right-click
the function and select Expose Typedefs from the shortcut menu."
Regards,
Wiebe.
"albertz" wrote in message
news:[email protected]..
I allready told this to a NI tech support in Germany. They told me,
the bug is known, but they do?nt have a workaround.
So I hope for LV7.1 or maybe LV7.01.
[Attachment Different Types.vi, see below]
Attachments:
Different_Types.vi ‏22 KB

Similar Messages

  • Unflatten from string takes long time to execute in x64

    Hi All,
    I am running into an issue where "Unflatten from String" is taking enormous amout of memory n time in LV 2012 SP1 x64 to execute. I pass in a NOT flattened string to this function and it consumes ~5 Gigs of memory and takes more than 10 minutes to execute it. On x86, it executes almost instantly.
    It only happens if the input is not a flattened string. 
    Is this a known bug?
    I have attached the vi here for you to see the problem. If you run it on x64, it might take more than 10 mins to execute and your system will be in a hung state. 
    Ritesh
    Attachments:
    Flat String to Data bug.vi ‏9 KB

    LVCoder wrote:
    With "x64" I meant LV x64. It executes instantly on LV x86 running on Win 64 bit but on LV x64 it takes like eternity. 
    I know it cannot unflatten it and I want it to return an error. My actual code can receive a flattened or NOT flattened string and I have a case structure which handles different strings differently. 
    Be careful with that terminology, it only applies to the Windows Operating System with respect to 32-bit and 64-bit processors.  There is no such thing as LabVIEW x64, or LabVIEW x86.  The property terminology is LabVIEW 32-bit (the most common one, most people use, even on 64-bit OS's since it is the most fully supported), and LabVIEW 64-bit (not commonly used, doesn't have full support of all add-on modules and toolkits, and is mainly only used by people who need LabVIEW to analyze very large datasets.)

  • CRIO: Unflatten from string into lvclass not working in deployment

    Hello,
    I am working on a problem for some hours now and I need some help.
    I am using a cRIO-9022. I need to do some tasks, and I created a couple of classes which contain the parameters and the methods. They contain using dynamic dispatch VIs. I have an array of these classes (all derived from a parent class) which is my "configuration". I am using "flatten to string" and saving those file on disk. "Unflatten from string" is working fine. These file is created on a LV WIndows Application.
    I need to use this file on my cRIO: Unflatten from string, and then work with the array of my classes. When running the cRIO Main VI it's working fine. But when building the application and deploying it as startup, it's not working. I am getting:
    Error 1403 occurred at Unflatten From String in Gantry CommEngine.vi->RT Main.vi
    Possible reason(s):
    LabVIEW:  Attempted to read flattened data of a LabVIEW class. The data is corrupt. LabVIEW could not interpret the data as any valid flattened LabVIEW class.
    What I tried so far:
    - Added the whole lvlib containing the classes and also every single class to "Source files / always included".
    - Created constants of the array (containing the classes) to the VI (forcing LV to include the classes?)
    - Loaded the file from cRIOs flash and also by shared variable
    What else can I do?
    Thanks a lot for support!

    I tried to reproduce the matter, but couldn't. 
    I attached my example to the post. 
    What it does:
    It creates a class with only a string a bool and a number. This class oblect is saved to C:/somename.xml. The number is a random number.
    In the second case the same file is read and the number broadcasted to a variable.
    It worked quite fine building it as a startupexe.
    Nothing else was necessary. Does it work for you?
    Attachments:
    class exe.zip ‏45 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

  • Error 116 at Unflatten from string.....

    Hi I want to save and load the control values of
    the tab pages I am getting the following error
    "Error 116 occurred at Unflatten From String     
          Unflatten or byte stream read operation
    failed due to corrupt, unexpected, or truncated data."
      the attached is the VI can
    anyone tell me what is wrong ….thank you
    Attachments:
    save n load example.vi ‏70 KB

    All that you need to do is right-click on the Read from Text File and Write to Text File functions and uncheck "Convert EOL".
    Other comments:
    You should not hard-code the path inside the VI. Either place a front panel control to specify the path (perhaps with a default value set), or generate the path so that it is relative to the VI (such as being in the same directory as the VI).
    You are not wiring all your errors through so some errors can be lost.
    You do not need to have the VI open a reference to itself. If you delete the Open VI Reference function the code will still work.

  • How do I unflatten from string to an array of strings in labwindows

    New to Labwindows so please forgive.  I am trying to use STM to read messages from an existing LabView program.  I am using ClientTCPCB from the example that came with the STM library, but it reads in doubles, I want to read in strings.  I can see that I have the correct number of elements in my receive buffer, but I can't figure out how to convert the receive buffer into an array of char arrays (or strings as it were) something like labview's "unflatten from string" with 1-d array of strings as the type.

    So I figured it out... from the lack of info on the web and forums I doubt it will be useful to anyone else, but will post a brief solution.
    So I dumped the raw bytes to a file to look at how they are packed.  The first 4 bytes (int) is the number of strings in the message.  The next 4 bytes (int) are the number of chars that follow, then the corresponding chars, sans any null term character, then the very next int would be the number of chars in the next string and so on and so forth.  So I ended up writing my own charArrUnflatten function.  Anyway, after all this I might try to recode everything to use network vars.  Cheers.

  • Error 74 Unflatten from String in video streaming using TCP

    I am working on video streaming ( source: USB camera) using TCP. However, am constantly getting held up in "Unflatten from String" with Error 74 occuring stating "Memory corrupt". Kindly help me through in solving the issue.
    Attached is the VI having both the send/ recieve together and communicating using localhost. 
    Attachments:
    Image acquisition & transmit.vi ‏189 KB

    Shoaib Akhtar wrote:
    Thanks  for the reply!
    Restricting the TCP sent dta to two bytes was a mistake, that has been rectified.
    However, we are unable to resolve the "Unflatten from String". their just doesn't seem to be any sub-VI or function, that I can find which could convert the string to IMAQ image!
    Kindly help in the same!
    Best. 
    Actually at least in earlier versions of IMAQ the normal Unflatten from string should be able to createthe IMAQ image when you transmit the right data. You can try that by writing the string from IMAQ Flatten.. to a file and reading it back and unflattening. If that works, you know you are making some errors in the TCP communication.
    Message Edited by rolfk on 01-11-2010 08:37 AM
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Whats happening internally within the unflatten from string function?

    I am getting unflatten from string error intermitently in my program. I can't post the program to get help but essentially I am storing a GOOP object reference as a string. The reference is flattened to a string and stored upon creation, at a latter time the string is then unflatterned to retrieve the reference and then the data. This works most of the time but occansionaly the unflatterned from string function fails. Prior to passing the string to the function I am checking that the string isn't null. I am assuming something else is corrupting the string prior to passing to this fucntion and would like to know what would trigger the error in the function as it may help me realise what is happening
    prior.
    Cheers,
    Wayne

    Hi,
    It really seems strange this problem, but one thing that might be the cause is how you store the flatten string. You do not mention that. I have once had problems when storing GOOP references as a sting and passing them between test VIs in TestStand using a string parameters in TestStand. A flatten string might have special chars that not all applications (such as TestStand parameters) can handle that and just trunkate the string when such a char is present, mistakenly inteprets that as end of string. Have you tried to check that string length is the same?
    However to make sure you get rid of all problems with string termination, you really should cast your GOOP reference into something else. I would instead cast the reference to an U32, or
    if you want, to solve the string problem for other types than GOOP reference, then flatten the type into string and then convert the string to an array of U8 before storing it. This would by sure solve your problem.
    Regards,
    Mattias Ericsson
    Endevo
    Sweden
    Main developer of the new GOOP2 and GOOP Wizard 3.
    PS! Have you seen that there is a new GOOP release that also may handle inheritance? Please check out: http://www.endevo.se/default.asp?lang=eng and click on "Products". There are examples, demos and white papers describing the new GOOP Inheritance Toolkit.
    Attachments:
    CastRefExample.vi ‏18 KB

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

  • Unflatten From String Not Functioning in Mobile Module 2011

    Mobile Module does not get updated since version 2011. I am not sure my question will be solved. 
    I have been using Simple Messaging Reference Library (STM) for a couple of years. I use them in my Mobile Module code too. It has been working fine until lately I updated to the latest version of STM.
    I noticed that 'Read Message (TCP).vi' was not functioning properly in the Mobile Module code. After a long debugging, I found the source of the problem. 'Unflattern From String.vi' does not work in Mobile Module any more. I did a test as shown above. 
    My questions are
    1). 'Unflattern From String' was changed so it is not supported in Mobile Module 2011?
    2) Why the same code worked before, but not now?
    I use LabVIEW 2011 and Mobile Module 2011. Thanks. 

    MengHuiHanTang wrote:
    Mobile Module does not get updated since version 2011. I am not sure my question will be solved. 
    I have been using Simple Messaging Reference Library (STM) for a couple of years. I use them in my Mobile Module code too. It has been working fine until lately I updated to the latest version of STM.
    I noticed that 'Read Message (TCP).vi' was not functioning properly in the Mobile Module code. After a long debugging, I found the source of the problem. 'Unflattern From String.vi' does not work in Mobile Module any more. I did a test as shown above. 
    My questions are
    1). 'Unflattern From String' was changed so it is not supported in Mobile Module 2011?
    2) Why the same code worked before, but not now?
    I use LabVIEW 2011 and Mobile Module 2011. Thanks. 
    Is that the real code or just a mockup to demonstrate the issue?  I'm asking because the code is set up to run once and then wait until the stop button is pressed.  Then the VI will complete and exit.  Is the the desired behavior?
    Bill
    (Mid-Level minion.)
    My support system ensures that I don't look totally incompetent.
    Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.

  • Strange problem with unflatten from string

    Hi all,
    Attached are the VIs that make me crazy.
    The problem is simple, Creat fake signal creats datas and uses a strict type def control (cluster) then this cluster is flatten to a string and written into a text file.
    Test read opens one of that file and unflatten the datas with the same stric type def. There is the problem it does not work!
    If I wire a cst arry into the data terminal of the bundle by name, then there is no problem. By if I wire other array it does not work always... It seems random.....
    I hope that somebody can help me. Even people reproducing the error are welcome, to know if it comes from my computer.
    Thanks a lot for the help
    Attachments:
    vis.zip ‏43 KB

    I changed the write to binary sting file with write to binary file and it seemed to fix the problem. I had to change it in your gen fake data file too.
    Tim
    Johnson Controls
    Holland Michigan
    Attachments:
    vis.zip ‏44 KB

  • Strange "Scan From String" to Timestamp Error

    hi,
    i am trying to parse my time-string into a Time Stamp with "Scan From String" but i get some strange Error(1).
    The Code:
    The Error:
    can anyone confirm? do i have an error in my parser-string?
    is it possibly related to this Bug
    461196
    Scan From String VI returns Error 1 with "%t" as the format string input
    http://www.ni.com/product-documentation/52151/en/
    that should be fixed?
    my labview version is
    LV 2014 Service Pack 1 -- Version 14.0.1 (32bit)
    with the RealTime addon (but the code in question was not run on RT)
    thanks for your time.
    Solved!
    Go to Solution.

    Why do you have the square brackets around the scan from string format string? They are not there when you generate the timestamp string so it will fail when trying to convert it back as they are expected to be there.
    Certified LabVIEW Architect, Certified TestStand Developer
    NI Days (and A&DF): 2010, 2011, 2013, 2014
    NI Week: 2012, 2014
    Knowledgeable in all things Giant Tetris and WebSockets

  • Unflatten from xml on class in lvlib

    I am using Flatten To XML and Unflatten From XML on a class in LV2009.  This works fine until I put the class in a lvlib.  Then the Unflatten From XML returns an error 1527: Attempted to read flattened data of a LabVIEW class that is not currently loaded into LabVIEW.  In my test case the flatten and unflatten are in the same VI, so the class was there when it was flattened.
    Any help is appreciated.

    I don't know of a good workaround at this time if the class has to be inside a LabVIEW library. I tried a few things that I hoped would work that didn't:
    Bundling the class into a single-element cluster before flattening to XML, then unflattening and unbundling.
    Inserting the class into a Variant before flattening. Then unflatten as a variant and do Variant to Data. This would have added a <LVVariant> tag to the XML, but otherwise would have been harmless.
    Trying the same with a single-element array of the class.
    None of those worked. The best workarounds I have for you if the class is inside a library are:
    Manually serialize and unserialize the class contents to XML using LabVIEW's XML Dom parser. This is a decent amount of work, and won't work with other XML files you create using LabVIEW's default schema.
    Flatten the class to string using Flatten to String. Then wire the string into the Flatten to XML. To get the data out, Unflatten from XML as a string, then Unflatten from String into your class. The XML text isn't pretty or really representative of the data stored in it, but hey, it at least saves and loads the data.
    Jarrod S.
    National Instruments

  • Day of year bug - format date/time string and scan from string?

    I've noticed that the day of year returned by "Format Date/Time String.vi" starts with a value of 1 for Jan-1 while "Scan from String.vi" wants a 0 index.  Is this a bug or feature?  
    (I'm using Labview 2010 Service Pack 1)

    I think the best idea is to use seconds since for your arithmetic, because it is going to be the most consistent and robust solution. Knowing that a day has 86400 seconds is all that is needed and you won't run in possible inconsistencies with date time implementations caused by our anything but logic calender. I would hazard that the functionality of converting a timestamp into year and day of year and back is impossible to make consistent without sacrificing other possibly conflicting transformation in the Timestamp into String and Timestamp from String manipulations.
    "Seconds since" being the actual base unit in all LabVIEW timestamps, it is best to do any arithmetic on it in this base unit.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • "scan from string" to timestamp doesn't work for 18:00:00 (6PM)

    I just found a strange issue in LabVIEW.  I hope I'm doing something silly, but I just may have found an unusual bug.
    run the snippet below with the following for the input string: 03:00:00,18:00:00,17:00:00
    Time converts fine for just about any other time EXCEPT 18:00:00 (6 PM) for which it is returned as 00:00:00 (midnight). If you even add a second to it (18:00:01) you get back the expected result.
    Here's hoping I'm not loosing my mind
    Matt Holt
    Certified LabVIEW Architect
    Solved!
    Go to Solution.
    Attachments:
    TimeParseBug.vi ‏11 KB

    As annoying as it may seem, this exact scenario is an abuse of the timestamp. A timestamp is meant to be used for absolute times. And that includes a date. As Ravens Fan already pointed out, the 0 seconds since January 1, 1904 GMT is used in all timestamp display routines to mean the canonical invalid timestamp and hence the timestamp control displays the default string indicating the actual date/time format rather than a specific date/time.
    If you need an absolute timestamp, for instance because you do want to have a local time indication, although the date is not relevant, adding an offset of 86400 to all values would fix it once and for all. Now the timezone offset can't cause the timestamp to reach 0 ever, even if you reside west of GMT, and it will be fine (until you start to do timestamp arithmetic that involves subtraction of relative timespans, then you would have to make the offset big enough that this will never get an issue). The current date would serve as a nice offset for that, which would be MattH's last suggestion. Nice to see that the Scan from String routine actually does use the passed in timestamp as default value and only replaces the values it is configured to parse.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

Maybe you are looking for