From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Memory Error with Cluster

I orginally wrote this code in Labview 6.1 and have upgraded it to 7.1 for optimized memory usage.  However, a new problem related to memory was generated.  I've posted a simple Labview 7.1 vi that illustrates this problem.
 
My code uses the flatten and unflatten commands to pass data throughout the program.  The example I've attached contains some example flattened data into a cluster constant.  When I open this file I receive the error: "Not enough memory to complete this operation" and upon execution, it generates no additional errors.
 
But, try removing the wire from the cluster constant, reconnect it to the unbundle, and then run the vi.  Notice the memory error returns.  Upon subsequent runs, the error does not repeat.
 
I need to make certain this error does not occur the first time.  Any ideas what could be causing this issue?
 
Best regards,
Charles
0 Kudos
Message 1 of 12
(3,522 Views)

When I run it in 8.2 it gives an error 116 everytime. "Unflatten or byte stream read operation failed due to corrupt, unexpected, or truncated data." The reason is that it doesn't know how long the string is. There's a boolean input "data includes array or string size? (T)." You don't have this wired up, meaning the function is looking for the string size at the beginning of the string. Change this to false and you don't get an error.

One question though, why are you unflattening a string to a string?

0 Kudos
Message 2 of 12
(3,515 Views)

Marc,

I'm unflattening a string to a string due to other sections of my code where I flatten a double, array of doubles, or array of strings to this cluster.  This way I can use a common bucket for any type of data, and it was necessary to handle strings as well.  It was for consistency.

The error I receive in Labview 7.1 occurs before the unflatten command.  Could the data in this constant be corrupted and cannot be read onto the wire?

Best regards,

Charles

0 Kudos
Message 3 of 12
(3,487 Views)

Reed,

I ran your program in LV 7.1 and I was able to see the same error you did. Running it in 8.x the problem does not appear becaue the Unflatten to String has been re-written. It has the option to specify if the size of the string is included with the byte string. This is what Marc A was refering to. Marc A's fix is valid for LV 8.x and you can read the byte string. In my case it did not convert it to a ascii characters. It was still showing it in binary. I will have to do some more research to figure the reason for your error message.

By the way, do you have access to LV 8.x?

Best regards,

Kalin T.
0 Kudos
Message 4 of 12
(3,460 Views)

Kalin, his problem is not with the unflatten VI, as I had also originally thought. He's saying that the error is before the unbundle.

Charles, I can't see any errors other than the one I replied about. Do you mean that there is an actual error with the wire causing a red 'X', or is it just a message that pops up when you open the VI? Everything seems to work fine in 8.2, so whatever you've run into might have been fixed. I don't have 7.1, but maybe someone else can use it to open your VI and see if they get any errors.

0 Kudos
Message 5 of 12
(3,451 Views)

Marc / Kalin,

Originally, the problem occurs before data is written to the wire (in highlight operation mode).  I've further reduced the problem where the string constant is removed from the bundle and directly connected into an unflatten.  In this case the same error occurs.  However, when I connect this string to an indicator instead of the unflatten, no error occur.  It may be some relationship in how the data is handled or prepared for an unflatten command.

I don't have access to Labview 8, only 7.1.  The error is only a pop-up window that states "Not enough memory to complete this operation"; there are no red "X" denoting a bad wire connection.

This code was upgraded from Labview 6.1 to correct other issues.  This problem occurs only in Labview 7.1, and Marc has noticed a patch for 8.2 which appears to handle or ignore this error.

Best regards,

Charles

0 Kudos
Message 6 of 12
(3,439 Views)
Charles,

Do you know what the original data was? If so, try to create a new flattened string and see if it works. Also compare the two strings. This may help to determine whether the problem is in the Unflatten, the saved data in the string, or something else. Flatten/Unflatten has changed with some versions of LV, so that may be the problem. I do not recall when changes were made.

Lynn
0 Kudos
Message 7 of 12
(3,428 Views)

Hi Charles,

Your binary string did not contain size information. According to the description of the Unflatten to String VI you have to specify the size of the binary string. Check the attached VI. It works fine now.

Binary string contains header information before each nonscalar component describing its size. The elements of binary string are in machine-independent, big-endian form.

The string constant input to the Unflatten from String VI is in HEX format. 0000 0008 specifies the size of the binary string in HEX.
Note: If you don't specify the exact size of the data, you will get an error.

Hope this helps!

Kalin T.
0 Kudos
Message 8 of 12
(3,425 Views)
Hello,

I am having the same problem with Unflatten from string in LV 7.1. I understand that the problem is the size of the binary string.

But how to tell the unflatten from string.vi not to expect a size of the binary string since in LV 7.1 you can not do that..it is a functionality of LV versions 8?

Thanks,


Message Edited by TinoMK on 06-02-2008 04:10 PM
0 Kudos
Message 9 of 12
(3,056 Views)
Hi TinoMK,

You tell the Unflatten From String.vi in LabVIEW 7.1 the size of your binary string by prefixing the size to the string.  Thus, if your string is "Hello" (4865 6C6C 6F in Hex), you need to modify it to be "0000 0005 4865 6C6C 6F", where 0000 0005 represents a size of 5.
0 Kudos
Message 10 of 12
(3,011 Views)