My clever design...is NOT clever

[pete_dunham]

Looks like a move to a database is in order if you are shifting that much info around. Is MySQL or Access a viable option?

Hmm. I was thinking about that.

Any thoughts on saving objects as binary text? And then opening up and acting on data and then resaving as binary?

Does anyone have ideas about how this would perform?

My framework is really just collecting and acting on serial data so I may have some performance time to spare.

My original architecture was built with the thought of saving each UUT object's data somewhere. I was hoping to implement the ability to pull up any tested UUT's object data (maybe with a custom viewer) to see all the data that was collected during the test. This seemed easier than creating a custom database and spending time converting each LV piece of data to a corresponding field value.

-Pete

[ShaunR]

Hmm. I was thinking about that.

Any thoughts on saving objects as binary text? And then opening up and acting on data and then resaving as binary?

Does anyone have ideas about how this would perform?

My framework is really just collecting and acting on serial data so I may have some performance time to spare.

My original architecture was built with the thought of saving each UUT object's data somewhere. I was hoping to implement the ability to pull up any tested UUT's object data (maybe with a custom viewer) to see all the data that was collected during the test. This seemed easier than creating a custom database and spending time converting each LV piece of data to a corresponding field value.

-Pete

You can save the cluster as a "Blob" (Binary Large Object). Although I'm not sure what you mean by "binary text" You wouldn't have to save the object data piecemeal style But databases are built for this kind of stuff and I think that if you went down this path you would see major benefits to saving each piece of the cluster as a separate field.

Performance is pretty good if the DB resides on the same machine as the application. You could also look at "SQLite API". This release doesn't support "Blobs", but you could serialize the data using the flatten to string primitive.

[pete_dunham]

WOW. It took me a long time to figure this out. Thanks for all the replies. Each one of them helped me work through this.

It turns out that I DID need to upgrade to 8.5 to be able to use the In-Place structure.

However, I was forced to make some significant redesigns in order to use the In-Place structures effectively.

While this was a significant effort it made senses to keep a consistent architectural design to act on my "object".

In the code that was causing me problems I had created subVIs to act on individual parameters of one of my "objects" in a loop.

This did indeed cause LabVIEW to make memory allocations (this was brought up in response to my 2nd code post).

I think this happened because I was sending both the most top-level cluster along with a unbundled array of objects through the same loop (then rebundling).

Now that I have figured out viewing memory allocations I think will be using it in a lot of my future designs.

THANKS again for all the input.

I would be happy to discuss this problem/solution or similar problems if anyone comes across something similar.

-Pete

Kudos.

Have you tried using the in-place element structure?

To me that sounds like an array that has is growing and need to allocate more memory. LV allocates a chunk of memory for the array when it is created, if that memory space is about to run out it allocates another chunk of memory. Have you tried using Initialize Array to define the array siza from the start?

//Martin

Something to try might be to replace that 1 vi that is gathering serial data with a dummy vi that just outputs a string of the same size you are expecting. See if that still produces a memory problem.

My most confusing memory loss issues in the past was with a driver that wasn't playing well with a new computer, and not a code problem. If there's no other smoking gun, maybe you have something similar.

URL for Dark-side discusion.

http://forums.ni.com.../481919#M231529

Ben

Hi,

Even if you convert to a newer LabVIEW version I think you will still have to do some major redesign;

In the picture posted in response to Bens question, you are entering the loop with both the complete cluster as well as an individual cluster element.

Doing so should force LabVIEW into copying data.

/J

Looks like a move to a database is in order if you are shifting that much info around. Is MySQL or Access a viable option?