Jump to content

Thoric

Members
  • Posts

    155
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Thoric

  1. I want to clear a VI's undo history, programmatically, from another VI. I see in 2013 that saving doesn't clear the history, so my original plan to simply save my target VI somewhere isn't working. Is there a scripting technique that will obliterate the undo history?? A quick search didn't find anything.

  2. For what it's worth, there is a private VI property that returns the OS window handle so you don't need to use FindWindow. It's somewhere on lava but I can't link to it via the mobile site. I think it's called OSNativeWindow or something. The thread has a VI containing the property node which can be dropped in any other VI (it's a private property). That should fix any issue with window titles not matching.

     

    Here: http://lavag.org/topic/13803-getting-the-window-handle-for-a-fp-with-no-title-bar/

  3. OK, so this is where I'm at. Taking Darren's code segment above and slowly adding my own code to it until the Save Request issue arises, I see that it occurs as soon as I dock both the front panel and block diagram of the scripted VI into two individual containers. If I dock just one, or neither, LabVIEW doesn't ask me to save the VI when I close it.

    By 'docking into a container' I mean changing the parents of the scripted VI windows, using a winapi call. My intention is to 'contain' these two windows to control their access from within my own environment.

     

    I presume that once both the front panel and block diagram windows are re-adopted LabVIEW internally identifies unsaved changes?

  4. 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.

  5. I think I understand why NI would want users to not be able to use scripting in a built application but I find it hard to believe that is there no way around the limitation.

    :ph34r:

    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?

  6. 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?

  7. 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?

  8. 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.

  9. 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?

  10. 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?

  11. 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.

  12. Oh my God I've been a complete idiot!  :oops:

     

    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...  :P

     

     

  13. After modifying Jack's EventsAndSundry vi #02, I must amend my statement on the NI forum. If a dynamic event is registered but not handled, that does not directly cause a leak. The leak starts if either: the loop in which the event structure resides stops; or the event structure handles events slower than they are generated.

    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.

     

    I your app working normally while this memory is building up?  If one of your components' event loop were somehow paused (by something that happens only in an exe) then User events would build up as observed.

    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?

  14. 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!?

  15. 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.

  16. 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...

  17. 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/

  18. 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??

  19. 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!

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.