Search the Community

Hello! It was found that the function Request Deallocation does not free memory after using an array of strings (or any other multi-dimensional array). Description of the experiment: There is a VI from which subVI is called by command. In the subVI only one-dimensional array (numbers or strings) generated. If the array element type is number (I32), then allocated memory is released (using the function Request Deallocation). If the array element type is string (or any other multi-dimensional array), the memory will not be released. Anyone faced this problem? If yes, what should we do? Excuse for bad english. main.vi memoryusage.vi

Can anyone please tell what a DVR [ Data value reference ] is ? I want to know at what situation it will be used and what are the advantages we get by using DVR. I am really confused in this topic . If someone has any code in which they have worked with DVRs. kindly share it to me. Thank you.

Thought I'd pass this along and see if anyone can reproduce with different versions of LabVIEW. Appreciate it if anyone has seen this and has a fix. I'm using shared variables to communicate between applications (1:N). I'd been seeing some memory creep that was inconsistent and somewhat bizarre. Eventually managed to track it down to that I'm programmatically opening a connection to a shared variable in one loop, then reading the value in a different loop (the different loops have to do with reconnecting on connection loss and startup). There is a functional global used to pass the variable to the second loop. The Read Variable primitive deallocates all but 4 bytes of memory for the previous loop handle and then allocates memory for a new handle on each iteration of the while loop, hence creating a leak. This behavior does not occur if there is only one loop where there is an open, while loop with a read, and a close. Main.vi demonstrates the issue. Main 2.vi is more like the NI example. I've got service request #7728859 with NI going, but I think I got the guy's first day. LabVIEW 2015 SP1 32-bit on Win7 64-bit. Shared Variables memory leak.zip

Hi, I've decided to take the temperature on a known issue, that lvclass files retain knowledge of some of their old content after it's deleted. Proof For some reason I'm not allowed to upload lvclass files, so I'll describe it instead (using LV2014SP1): 1) Create a new class and save it on disk as class1.lvclass. No member data nor methods, file size on disk is 8 kB. 2) Add one piece of significantly sized (to easier see the issue) member data, I added a 1000x100 array of DBL (with random default data in it). Save the class again, and now class1.lvclass is 4604 kB (why so much, should be around 1000 kB?). 3) Delete all member data again and resave the class. File size on disk is now 1171 kB, I'd have expected 8 kB. 4) I can't ever get rid of that extra data in the lvclass file, not even when I "save as" to create a similar class. Questions A) What's the reason behind this issue? B) Is there any way to really delete stuff from a class file, or is the only way to recreate every class from scratch if you want something truly gone? C) Is there a list (perhaps internal to NI) of which problems this issue causes? Here I'm talking about stuff like this and numerous other threads about class data suddenly not being updated or member data or methods not being called correctly with DD. Cheers, Steen

Hi We have an application where we need to have a custom PCIe board transfer data to the PC using DMA. We are able to get this to work using NI-VISA Driver Wizard for PXI/PCI board. The recommended approach is to have VISA allocate memory on the host (PC) and have the PCIe board write to it (as seen below). While this approach works well, the memory allocated by VISA for this task is quite limited (~ around 1-2MB) and we would like to expand this to tens of MB. Note: The documentation (and help available on the web) regarding these advanced VISA function (for instance "VISA Move out 32" and "VISA Move In 32") is parse. If someone has some deep knowledge regarding theses, please feel free to share how we could allocate more memory. Since we are not able to allocate more memory using the VISA function at this time, we investigate doing the same operation using the LabVIEW Memory Manager Functions which allow us to allocate much larger memory block. Below is the resulting code. Unfortunately while we can validate that reading and writing to memory using this work well outside the context of DMA transfer, doing a DMA transfer do NOT work (although the board think it did and the computer is not crashing). We are wondering why this is not working and would welcome any feedback. Note: the DMA transfer implemented on the board requires contiguous memory for it to be successful. I believe that the LabVIEW Memory Manager Functions do allocate continuous memory, but correct me if I am wrong. To troubleshoot this, I did allocate memory using the LabVIEW memory manager function and try to read it back using VISA and I got a "wrong offset" error (Note: This test may not be significant) Another data point; while the documentation for DSNewPtr do not talk about DMA transfer, the one for DSNewAlignedHandle does. Experiment using LV memory manager Handles has not got us anywhere either. We would welcome any feedback regarding either approach and about the LabVIEW Memory Manager Functions capabilities in that use case. Thanks in advance. PJM Note: We are using LabVIEW 2014 if that matter at all.

Hello, I've been using Snap7 library for a while in the client role, so I can communicate with SIEMENS PLCs There is specific LabVIEW info here: http://snap7.sourceforge.net/labview.html I can successfully use the Cli VIs to read/write from PLCs DBs (a DB is just a memory block). For reading I pre-allocate a buffer, but I'm not sure if I'm doing it properly. My main concern is about memory leakage, I don't know if the memory will be freed after the VI exits or it will not be freed as long as the VI is in memory. Attached is what I have just now for reading. I define a typedef for each DB, it is a cluster of booleans, and reserve memory according to the number of booleans, but always in multiple of 8 (I read only bytes). I request the data with the CliDBRead and after that I make some conversions to return the data in a variant that I later cast to the proper typedef. Can you tell me if this is the best way to do this? Thank you!

Hello, I have lately run into a problem of insufficient memory. Basicallly the controller is ever running and i generate data and store it in .tdms file every x sec. and every shift (3 shifts in a day) i ftp the file to the host and delete the file. During accumalation of the data the ram continuosly decreases(contiguous memory also decreases as i have a lot of array manupilations and such). I want to recover this contiguous memory at the end of the shift so that the next shift runs smoothly. this is observed because i saw lot of inconsistency in the data file. Is there a vi which will free up ram and defragment it?. I cannot use preallocated array because i dont know before hand how many data points i need to store. the data that will be put is in variable time. Thanks in advance.

[cross posted to forums.ni.com] Greetings LVOOP masters. I realise this is not a simple question but I would really appreciate your opinion please. I'm trying to make some data handling improvements to a test sequencer application that I've written. User defined tables determine how much data is acquired. Long tests can easily generate 100's of MB's of data. Collecting, analyzing, reporting and saving that data tends to create copies and we can easily run out of memory. It's currently written without any LVOOP methodology but that is about to change. I'm new to OOP but have been reading alot. I have 2 objectives in refactoring the data handling VIs: 1) Enable different measurement types to be collected, analyzed and saved according to their unique properties. Presently any measurement type that isn't a dbl waveform is shoehorned into one and treated exactly the same. XY style data is resampled losing resolution and digital data is converted to dbl. This results in a lot of extra data being generated for no good reason other than to fit in a waveform. 2) Reduce data copies. Because the measurements are shuffled around from one module to another the copies become a problem. I'm hoping to use DVRs to the objects and pass around the references instead, reducing copies. I'm quite comfortable with objective 1, it's number 2 I'm not sure about. After reading this excellent whitepaper here I feel I need to get some expert advice on whether my approach is correct. In particular these two statements have raised questions in my mind: "Be aware: Reference types should be used extremely rarely in your VIs. Based on lots of looking at customer VIs, we in R&D estimate that of all the LabVIEW classes you ever create, less than 5% should require reference mechanisms." "LabVIEW does not have "spatial lifetime". LabVIEW has "temporal lifetime". A piece of data exists as long as it is needed and is gone when it is not needed any more." Q1. With that in mind, will all my effort to use DVRs actually reduce data copies significantly in my case? I plan to have a single FGV VI where the objects are created and stored in an array. Then when other modules need access to the data, a DVR is created and handed out. Once these modules are finished with the captured data, they flag it as deletable and the measurement FGV deletes the DVR and removes the object from the array. Q2. Is that the right way to go about it or am I missing the point of LVOOP and DVRs? Below is a simplified mockup of the way measurement data is currently used in the application. LVOOP Experts: Your feedback/suggestions are much appreciated. LVOOP DVR Measurement Optimization.zip

Cross posted from : http://forums.ni.com...ht/true#M702675 Hi I have a memory leak on my application. By observing with the "Desktop Execution Trace Toolkit", the Power Spectrum function (from NI_AALPro.lvlib) seems to have two "Reference leak". The first one refers to the function "Open VI reference"; I got around this problem by replacing the "Open VI reference" by an "Initialize" input boolean, but I don't understand the second memory leak. Any idea ? Thanks... (See attachments : Desktop Execution Trace + code) LV8.6.1 + Desktop Execution Trace Toolkit 2009 Same problem with LV2012 + Desktop Execution Trace Toolkit 2012 MemoryLeakPowerSpectrum.zip

I am having an issue with memory when reading a TDMS files and converting to an array to write to a spreadsheet file. If I look in task manager when I run the VI the first time it allocates a bunch of memory and only a small fraction of that memory is freed after the VI is run. Even closing the VI and project doesn't free the memory, I have to exit out of LabVIEW before the memory is freed. Basically what happens is I open the VI and in task manager I see the memory increase (duh). Then I run the VI and it increases greatly (up to around 400,000 K), but when it finishes running only about 10 k is freed. Then every subsequent time I run, there is only about 10 k allocated then freed. So, the memory stops increasing, but it still holds on to a big chunk. The reason I worry this could be an issue is that I have many of these subVIs running one after the other, and if each one is hanging onto 300,000 K even after it's done running, I will begin to have memory issues. I am wondering if part of it could be that I'm in the dev environment, so I may build an exe to check. All my SubVIs do not have the panels opened, so I don't believe I should have a big array indicator showing data and taking up all that memory. Any thoughts or suggestions are appreciated. Edit: Is my attachment there? My internet is going super slow so I'm not sure...

I need to provide a customer with a dll library with function prototypes that exactly match a provided .c header file. I would like to use LabVIEW if at all possible, as fast turnaround on source code modificaiton may be required. LabVIEW cannot export a function with a char* return type (verified by LabVIEW R&D), thus the customer application directly calls a thin wrapper dll (written in CVI) which then calls into the LabVIEW based dll. I have a subvi that is called by one of the exported VIs. This subvi acquires and analyzes waveform data from an instrument. Memory for a significant waveform (on the order of a MB) is thus dynamically allocated within the subvi. The waveform is not passed up to the caller, and the exported VI returns only a scalar double. If I remove the subvi from the exported VI's block diagram, other Exported functions behave as expected, However if the offending subVI is added to the block diagram of the exported VI, other exports in the DLL always return a value of "0" (default value for most numeric data types?). This is regardless of whether the Export that includes the SubVI is even called within the client application. It seems that the mere inclusion of the offending SubVI breaks the entire dll. Both the LabVIEW DLL and the wrapper DLL(which is in CVI) use only the cdecl calling convention. I get the same behavior for LabVIEW 2011 and 2011 SP1, and for CVI 2009 and 2010. I'm testing using MS Visual Studio C++, since that is the environment for the client application. Behavior is the same in VS 2005 and VS 2010. I definitely appreciate any insights or ideas regarding how to seek a resolution.

Hello, I've been using the feature of Variant Attributes to store and lookup values in an efficient way. In particular, I've been storing complex objects such as the (simplified) example below where I post messages to "Observers" of those messages. My question is: is this the most efficient way to do this? In particular, I select one attribute, modify it, and then return it to the variant: does this involve copying the entire cluster of objects, or does the LabVIEW compiler identify this as an operation that can be done "in place"? -- James