Leaderboard

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.

This is a preview of wrappers for well known physics simulator (ODE) I'm working on. I mentioned it already some time ago. [[ CLICK ]] Unfortunately, the framerate is not impressive. Available veeery soon. And... yes - you can simulate rocket with it. [EDIT] Slightly better domino movie:

About four years ago, the topic of discusion turned to one of the test in the VI Analyzer that did not make sense and even Darren could not explian why it was doing that check and could only tell us that "Greg McKaskle said to put that in there." (paraphrasing of course). The check in question was enusirng the connector on the VI icon connector where located on the root of the diagram. I posted that I shut that ceck off since it did not make sense blah blah blah. Well it turns out that if we constrcut our sub-VIs correctly LV can "look into" the sub-VI call and determine if it can pass the data as a ref or by value. The thread in qwuestion can be found here http://forums.ni.com/t5/LabVIEW/case-structure-parameter-efficiency/m-p/383019#M191864 I included benchmark code so you can try it for yourself. Ben

This is what the current Front Panel looks like. and this is what you want it to look like To me they look very different. Cycle Number, Peak Number, Base Number and Magnitude do not exist on the current front panel. Currently the code does not "Print Graph" or "Print Results" so to make the code do these functions is new. If you only want to change the look of the front Panel you can try some of these techniques. Color: 1: Shift Right Click to bring up the tools pallet and select the paint brush. Right click on the item you want to color and then select a color If you want to change the look of controls you can do this by using the Control Editor. To find help on this go to LabVIEW help and "editor controls" in the search box then select "Customizing Controls and Indicators tat are Parts of Controls and Indicators" and read to the right how to use the editor. Try this first and let me know where you are having problems. Here is a video by Christina Rogers on how to use the control editor There are also some UI videos here. http://decibel.ni.co...10-presentation Mark