jgcode

Hey Guys! Thanks heaps for the testing and feedback, much appreciated. Here are some more of my observations from further testing that tie in with yours - so I think this is starting to make sense! Using a smaller array (1 element instead of 100) as the element of the buffer, the issue went away I also made some changes that sped up the X-Control (e.g. update graph by explicit reference in subVI to implicit reference on facade) which also helped with the above If I smash the X-Control (fast, as per the demo) and hit the stop button, the VI stops but the X-Control continues updating for what can be a while. So yes, I am inclined to believe the data is being queued somewhere -> because it can't keep up, and hence this is the cause of the allocations The concerning thing is: my application (whilst doing other things in parallel) was only updating the X-Control every 1000ms and was still causing a 1-2+MB/s leak! This X-Control could, instead of queuing if it ran late, just ignore data and catch up (given I am not buffering anything inside it) - but that is out of my control. For the design I initially wanted to define the interface as a '2D Array of DBL's' (the buffer). So to allow if I want to user the buffer for something else. Maybe I will have to look at something else. Ideas: I could buffer the data inside the X-Control so the behavior is like a Chart not a Graph - so the interface just becomes a '1D Array of DBL's'? Or I could reference an external buffer (i.e. using a DVR)? - but didn't want to do that. Thoughts? Cheers -JG <edit>Tried toggling Synchronous Display but it did not help the allocations, thanks for suggestion tho</edit>

Ok, the X-Control seems to be a bug? that I can replicate with a default X-Control. I have posted my findings here and will also follow up with NI support. Please check it out if you have the time. I have posted video and the code to replicate it. Cheers -JG

[LV2009] [Cross-posted to ni.com] I have found that if I pass a large data array (~4MB in this example) into an X-Control, it causes massive memory allocations (1 GB+). Is this a known issue? The X-Control in the video was created, then the Data.ctl was changed to 2D Array - it has not been edited in any other way. I also compare the allocations to that of a native 2D Array (which is only ~4MB). Note: I jiggled the Windows Task Manager about so that JING would update correctly, its a bit slow, but it essentially just keeps rolling up and doesn't stop. Demo code attached. Related to this thread by separated as posted to NI for support. Cheers -JG <object id="scPlayer" class="embeddedObject" width="921" height="858" type="application/x-shockwave-flash" data="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/1bfce9bd-6cea-4622-ad26-8da61f63adc7/jingswfplayer.swf"> <param name="movie" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/1bfce9bd-6cea-4622-ad26-8da61f63adc7/jingswfplayer.swf"> <param name="quality" value="high"> <param name="bgcolor" value="#FFFFFF"> <param name="flashVars" value="thumb=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/1bfce9bd-6cea-4622-ad26-8da61f63adc7/FirstFrame.jpg&containerwidth=921&containerheight=858&content=http://content.screencast.com/users/jgcode/folders/LabVIEW/media/1bfce9bd-6cea-4622-ad26-8da61f63adc7/X-Control%20Memory%20Leak%20Demo.swf&blurover=false"> <param name="allowFullScreen" value="true"> <param name="scale" value="showall"> <param name="allowScriptAccess" value="always"> <param name="base" value="http://content.screencast.com/users/jgcode/folders/LabVIEW/media/1bfce9bd-6cea-4622-ad26-8da61f63adc7/"> Unable to display content. Adobe Flash is required. </object> X Control Bug LV2009.zip

Hi Mikael To confirm, yes you get the same normal behaviour. Cheers -JG

I have been playing with them more and more lately and getting a good feel for the style thats required to use them. I have a few gripes too that make me stay away from them, e.g. I can't include it's reference as a member of a Class (works in src not in build) etc... But some really powerful stuff there - they just need a little make-over IMHO.

I am easily confused. The problem was I was hunting for a weird run-time issue, one that only ended up getting resolved after a full install of LabVIEW. If I had known about the ? it would have been ok. But as I didn't I thought there may have been something sinister there. I am not fussed what happens, but if it has potential to trip someone else up then blanking it would only be a good thing.

Yer, it still blows my mind at how crazy it went with just a 4MB array! And don't worry, I still have another installment (X-Control) waiting for me tomorrow! At first glance there is no Build Array's etc... but there are options to transpose the buffer, then th buffer gets reformatted to an XY Graph. That should be fun, can't wait!

Thx Ben I will check it out.

Hi Ben! Can you go into more detail or post a link? ...Bad news is that I squashed this leak only to find out my X-Control that displays the buffer is causing the same massive allocations! Time to get my hands dirty again....

I had a memory leak that I had to plug and just want to share and discuss the results: Background Nothing new, but I have a Buffer Interface Class that is composed of an array LabVIEW Objects. I does all the required transactions for a buffer on the array. I inherit from this Parent and create wrappers for specific datatypes to create a much nicer API for my application code. After discovering the memory leak for a specific datatype (1D DBL + timestamp) I was able to squash it. I have a 100 pt array of DBLs + timestamp (6528 bits) in a 5000 element buffer = (6528 * 5000)/(8*10^6) = 4.08 MB buffer What really surprised me was the ferocity of the leak. Check out the stats! I initially used Build Array primitive originally, thinking that an allocation has to occur here anyways. As you can see from the Test VI on the left, these means that I am using Build Array in a loop which is LabVIEW 101 of what not to do. That is fine, but what this resulted in was a 250+ MB with 50+ MB swings of memory allocations! It was running so slow after 3000+ inserts I gave up waiting. Switching to Insert Array primitive, the allocation was only 12MB which makes sense: the buffer, the FP of the test VI and most likely a subVI interface. A gradual allocation occurs because as the buffer fills up as the Buffer Interface returns a subset of the full buffer. Once the buffer is full tho, the full buffer is returned and no further allocations occur (yay!). I am really surprised at the difference between the two primitives, I thought from using the build array I would get some of it back, instead it went crazy. But it sure was a fun testing it all.

I am with you however, I did confirm this, and here is an extract from the conversation. So, originally I interpreted the comp rules as yu want us to create LabVIEW Example VIs (like in the NI Example Finder), but really its an open slate? Full blown Games, Tools, Plugins etc... are all good? In other words: Go Mad!

I agree! Below are the finalists for each category from LAVA, please vote for them. Voting opens 29th October 2010. If I have missed anyone who is a member here, please post. Also, there are some awesome entries, so I recommend heading over and checking out all of them. Data Acquisition - Error Logger - Jonathon Green (jgcode) File I/O - Resolve Shortcut Path - Phillip Brooks Game - Word Hunt - tst (Yair) Math Analysis - 3D Picture Interaction, 3D Surface Editor - Vugie VI Server/Scripting - LVOOP Assistant - Jonathon Green (jgcode) Note: sorry for the shameless self-plug, but my intention is directed at LAVA An extra plug for: UI Controls - Congnoscent UI - JackDunaway Cheers -JG

Thanks Oliver. I still can't work out out what was happening before with the old data (RE: last post). But I have now managed to get the comms going between the processes on a new example. Cheers for your posts -JG

You will be glad to know there is a VISA Run Time @ ~40MB which will keep your Application Installer down in size.

Vote Mark For President.

Yes, the reason for that is as explained above. 10-pt would still 'fit' if you always less characters. (Are you using the LECC2010 version - v0.16?) Hmm, I saw this once too, but never with LV 2009, only in LV2010. And like you said it was fine after reloading. I can't seem to replicate it, but will have to keep an eye out. If anyone has any info on this or seen anything similar before when working with Classes + scripting, please post

Hi neil Thanks for the kind words. I set the Class to defaults (8) if the IE2009 (layer) data was empty, and I always use 8 internally (so this hasn't cropped up for me). The other reason is I decided to leave all other settings that exist alone is - in case they have been set for a particular reason. But I could override the 10 to an 8 if this is always preferred (like I do currently for Caps)? Also, would you mind posting a screenshot of what it looks like? Cheers -Jon

[LV2009] Hi Oliver I tried your method but I still am having a problem. Nothing happens when writing to the value-signalling property in the dynamicVI the first time. Subsequent writes cause an event to be fired but I get data from the previous event! I have tried with different styles of dynamic processes just to see if that changes anything - but I get the same results launching a non-reentrant VI/reentrant VI/VI template with a static or dynamic reference. Any thoughts? FWIW: The Value Signalling PN works fine when it is on the X-Control. And the above runs fine when the dynamicVI is separated out of the X-Control. Cheers -JG

Hi loco Try this snippet:

Hi Oliver Thanks for the reply - I will give this a shot. I like the datatype you have suggested too. Cheers -JG