Thoric

Thanks for replying Shoneill, XP Embedded is essentially the same as XP, so the LabVIEW code is identical. Real-Time is a wholly different kettle of fish, and there you have no static events, but you can still have user events. Anyway, the crash turned out to be a memory leak issue, which turned out to be due to my own coding error. I had a "Register for Event" node inside a while loop when it should have been before it, so consequently I was creating a new reference to the user event with each iteration of the while loop. Ooops.

This component is part of a much bigger system that needs to work optionally on a machine without LabVIEW. I'm conducting a feasibility study at the moment, so if this doesn't work out too confidently I'll pull the plug.

I'm not at my PC today, but I am making a few winapi calls to the vi to change its parent. I'm kinda docking it in a container, so that must affect LabVIEW? I can modify your code tomorrow to mimic mine, most likely.

I can only think up one workaround, and that would be a lot of work - it would involve wrapping each scripting function in a wrapper VI, and using standard VI server calls to open each VI, populate the VI terminals and execute them, sequentially, to achieve the equivalent scripting requirements. This moves the scripting session into the IDE, yet it remains controlled from the external executable. I bet it would be frightfully slow though. Alternatively I guess you could keep the scripting elements of the executable as separate source VIs, and use VI server calls to load and execute them. Less clunky than the above idea. Any other ideas?

Darren: This is all programmatically. Darin: Thanks, I was beginning to wonder if I might need to do this.

Gleichman: you misunderstand. I don't want to inspect the exe. I want the exe to be able to use scripting calls on other VIs that are in the IDE. Think of it as a compiled version of VI Analyzer. Darren: I can understand why creation isn't supported, but if we're using Remote Server access to the LabVIEW IDE to purely read info about block diagrams then it's a benign process. Is there a reason this is blocked? Security concerns?

Hypothetically, if one created a LabVIEW executable that used a remote application reference to interact with the LabVIEW IDE, how much of the scripting function set would work? I've already discovered "New VI" doesn't work, but what about the non-creative functions, such as programmatically showing a block diagram, traversing the block diagram, inspecting nodes and other objects etc.? It seems to me that it should be ok to perform inspection, just not manufacture, right? So why are a load (if not all) of the scripting methods denied when attempted from a remote interface?

I've used scripting (which I'm still learning) to create a New VI, create some objects, show the front panel and show the block diagram. Now I want to close the VI and lose it, but because it has unsaved changes I get a dialogue box asking if I want to save it. I've set the options input to New VI to 0x0, which means it shouldn't be marked as modified and it shouldn't prompt to save changes. How do I close the VI silently? I have no interest in keeping the changes, so saving it first isn't what I want to do.

My mind is buzzing with new insight wrt user events schematics. I hadn't previously appreciated the potential that the register for events node provides us. The ability to nullify the registration, change to a different source etc. gives you much more control over how your system components can behave.I do remember your presentations Jack on the foibles of User Events, and I can see better why you spent time delving into all this. And I agree that multiple handlers per registration has many valid use cases, so let's hope NI are attempting to clean up this particular oversight. Is there an Idea Exchange for this, or campaign thread?

Thorough and informative, as ever, Jack :-) My buggy scenario was Handle Event and Leak as true (no shift register to store registration but then I didn't expect to need one as event registration was supposed to be outside the while loop). Interesting idea Piranha Brigade. I like the idea of a troop of asynchronous slaves chomping away at tasks from a single publisher. What advantages would you expect events to have over queues though?

In all the testing I did the problem didn't initially appear to occur in the IDE, but later I realised that it was just harder to spot. Task Manager isn't ideal for determining memory usage, which didn't help, and I suspect the LabVIEW IDE memory manager is taking care of a lot more business than what the exe will be, so the memory usage fluctuates by values in excess of the leak rate, which I guess made it difficult to identify the slow increases. In the exe this was much easier to see.

Oh my God I've been a complete idiot! The source of the problem does lie with one of the subpanel VIs. I had the Register for Event function inside the while loop that contains the event structure, so it was creating a new event reference with each iteration. Rookie error, but such an easy thing to miss when you're looking hastily at the code for a problem. Thanks everyone for your attention. This CLA is now off to question his qualification and career choice...

Yes, I can see how not running the event case structure would cause the queue to build up, or indeed if the events are created faster than can be processed. But neither is the case in my code, it runs as expected. Yes, my app is working fine. One of the events was "new value available" raised by the hardware acquisition component which runs at 100Hz, and provided the latest value to all listeners (UI component, logger etc.) When I remove this event and use a named notifier for sharing this value the memory leak is reduced, but still there (there are other low rate events still happening). If I create a new event and raise it at 1kHz the memory leak is increased. So last night I created a wholly new project, with a main VI that generates User Events, dynamically calling another VI that registers to the same User Event, which calls another dynamically launched VI which also registers to the User Event. Build it into an exe and....... no memory leak. Gahh! The following has just occurred to me, and may be important - hopefully someone with more knowledge than I can advise: In my User Interface component (which is called dynamically) I have a subpanel. The subpanel shows one of four VIs, all four of which are loaded into memory and swapped into and out of the subpanel control as required. Two of these subpanel VIs have event structures in them that are registered to the User Event. When I load these subpanel VIs I set them running using invoke method "Run VI" with "Wait Until Done" set to false so they're all running independent of whether they're actually shown in the subpanel or not. But, could it be possible that the three subpanel VIs that are not in the subpanel control are unable to react to the user events, and hence have an ever-increasing queue stack?

Apprarently it's due to Dynamic Events! I've trimmed my code down, painfully removed all classes and DVRs (legacy fears) and the memory leak was still apparent. Now I've realised the rate of memory absorbption is exactly proportional to the rate of User Event Generation. I didn't think unhandled User Events caused any issues, but in any case I handle all my Dynamic events in every Event Structure (one per component) so there are no unhandled dynamic events here. But for some reason LabVIEW is gobbling up RAM per user event I generate. The user event is now just a cluster control on the primary caller, which shares a Create User Event reference with all the dynamically called components such that they can message each other using the cluster content (which includes an enum subject and a variant data). That's progress, but now what!?

I have one Notifier, which I obtain and hold open just two references. No named queues. However I do have lots of event structures with dynamic user events, lots of generated user events that send class instances around. Could it be that the class instances aren't being released after they're handled by the event structure? That could part explain the ever-increasing memory allocations.

I tried that. The memory leak is slightly reduced with debugging enabled, but still exists. In fact, the numbers above are from my latest tests, which have debugging enabled. So in the original exe the leak rates were higher :-/ I'm stuck for ideas now. I'm thinking I might try remote debugging, but not sure how useful that will be... Edit: Remote debugging wasn't much help. I'm now trying to backport it to LV2012...

So I have a LabVIEW application, which works fine under the IDE, but when built into an executable it suffers from a memory leak in the order of 5-10kB/s. The code uses several dynamically spawned components, including an acquisition component, controller component and user interface (viewer) component, and a couple of viewer sub-components. These all communicate through user events, which uses a class factory pattern for the datatype. In this situation I'm simply launching the executable and not performing any hardware interfacing or data gathering etc., my code is just sitting there waiting for me to start something. During this idleness, there are still some user events flying around, but not many (up to two or three per second to about 5 subscribers) and the contained data of each user event class instance is either nothing, or a few bytes max. Therefore, even if each event's contained data was being duplicated per subscriber, I can estimate that about 100 bytes of data is being allocated per second (and that assume the memory is not deallocated after use). I cannot fathom how the code is gobbling up around 5 to 10 kB/s, and especially why this should only occur when built as an executable. Any thoughts anyone?? A bit of cross-post from here, but the topic changed as I discovered more about the issue: http://lavag.org/topic/17825-bad-crash-under-xp-embedded/

OK, so I was wrong. There's still a memory leak, but only in the built executable! In the development environment LabVIEW's memory usage remains fixed (according to Task Manager left running for many minutes), but the executable is eating about 10 kB/s. My code has a few individual components that communicate through User Events. There are events flying about pretty much all the time. The user event type is an abstract class, who's children are the actual event messages. So I have a small number of class instances being created and passed around every second. That's about the only thing happening in the code when you launch it, a handful of events being fired every second to inform the user interface of state changes etc. Anyone have a theory as to why the IDE code runs without a memory leak, but the built executable leaks like a sieve??

I'm working on a LV 2013 application that will run on an XP Embedded platform. Under my development environment it runs great, but when installed on the XP Embedded system it will run for a few minutes, and then pop with a very ungraceful "DAbort in ThEvent.cpp" message. I've tried to track this down to some action or event, but it appears to be relatively random. I had noticed, in older versions of the code, a memory leak, but that's been resolved since and yet the crash persists. I know XP Embedded is not officially supported, but this embedded installation is virtually a full XP installation, so there shouldn't be any concerns there (I hope). Anyone know where I can start with diagnosis of a crash like this? Google isn't helping, so I need to perform investigative effort but I really can't think where to start!

Just to close this thread from my input. I've abandoned Community Scope. It was too much of a headache, and the inability to password protect everything safely has led to a need to revert to Public scope. A bit disappointing, but in the end I'll live.

I'll relax then and ignore this. Thanks for taking the time to reply!

This looks like a great idea Jack, and I wish I could help but I doubt I have the free time (or knowhow) so let me instead wish everyone involved the best of luck with the development!

Jack, did you learn anything or have any further comment? I see this too, and there are no apparent side effects, the libraries are happy, and the classes are happy. But still I get dozens of items listed as 'not belonging' in my library. Mainly class private data ctl files, which clearly can't be moved out and back into a class to fix the association.

I'm seeing this too. LabVIEW 2011 SP1, I have dozens of libraries, and if I use the shortcut menu item Find > Items Incorrectly Claimed by a Library, a get plenty of results. Including class private ctl files!? This can't be correct, so what measures can be taken to correct for the corrupted ownership?

I've managed to keep Community scope by avoiding the password-protection features of VIPM, which is otherwise responsible for damaging the library (Known issue 13790). I now perform my own project cloning and password protection through a bit of scripting, and leave VIPM to just apply the license file. I really don't think I can live without Community scope in my toolkit, so this workaround will have to do