Jump to content

Thoric

Members
  • Content Count

    150
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by Thoric

  1. 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
  2. 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?
  3. 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.
  4. 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...
  5. 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 happen
  6. 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 pri
  7. 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.
  8. 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...
  9. 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
  10. 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 ha
  11. 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 in
  12. 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.
  13. I'll relax then and ignore this. Thanks for taking the time to reply!
  14. 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!
  15. 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.
  16. 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?
  17. 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
  18. Thanks for the reply Jack. Really? Maybe I'm missing something then? In my master library I have a bunch of classes, sublibraries (containing more classes) and XControls. I wish for some class functions not to be publicly callable so as to prevent end-users messing around, so I'm to choose from scope choices of Community, Protected or Private. Private is for callers within the class itself. Protected is similar, but also accessible to child classes. Community (and this is from the LV Help) "The item is visible when users view the LabVIEW class. Only friends and VIs within the project
  19. I'm encountering this exact issue when test installing my toolkit in LabVIEW 2013. Built in VIPM, I get this error when first loading the newly installed library into memory. LabVIEW first asks me for the password for the various libraries, but it can't be provided so I end up with the error mentioned in the original post attributed to numerous VIs. I've opened a support request with JKI as this is a known issue with VIPM, but I wonder if there's any advice I can get here on how to circumvent this issue? Or why I only see the error in LabVIEW 2013? I'm quickly trying to catch up with t
  20. Note that in LV2013 you can flush events. Although I haven't used it yet, I'm pretty sure this means you can flush the event queue of any further resize events. Special care may need to be taken to ensure you get the current resized dimensions when handling the event though.
  21. Very similar to your experience, the project reports fine but it's VIPM package builder that's failing to build. Once I sorted out these oddities it builds fine (albeit very slowly now?) I'll check out your link Neil, I think it might be great to dissolve the mutation history. I can't see why that would be useful once a library is set in stone (which I hope it now is).
  22. Creating a virtual folder, moving everything into that, and using the "convert to library" feature seems to have worked. It needed a mass compile to resolve the masses of errors that were created, but it may be I have a working structure now. Some further testing is needed to be confident... Edit: After further testing it appears that some of the friendships between XControls and classes were not migrated, so a friend of the XControl previously at: PTP_Sequencer.lvlib:class.lvclass that moved to PTP_Sequencer.lvlib:ptp_sequencer_core.lvlib:class.lvclass was still listed in the XControl
  23. Hi Aristos, This is LV2011SP1. I wanted to try discussing the issue without code because it's part of the PTP Sequencer toolkit. However, I guess it doesn't really matter too much, so I'll be more accurate. I was rearranging my classes to the following structure: PTP_Sequencer.lvlib - ptp_sequencer_public.lvclass - ptp_sequencer_core.lvlib - ptp_sequencer_element.lvclass - ptp_sequencer_container.lvclass - ptp_sequencer_loop.lvclass - ptp_sequencer_branch.lvclass - ptps_ps_service.lvlib - ptps_pub_sub_service.vi - (lots more classes) I h
  24. I've been bashing my head against the proverbial wall for a couple of days now trying to understand what was corrupt in my LV project hierarchy. On the face of it, all appeared to be fine, but I was getting some very unusual errors when executing my VIs. Errors that hadn't occurred before I rearranged stuff. In my project I have a number of classes, with various inheritances and other defined relationships, and I recently moved some things around to make it, well, better organised. I ensured I didn't destroy the relationships required to maintain access to class methods etc. Indeed, after the
  25. I suspect this is an ideal job for the Champions. Over to another forum.....
×
×
  • Create New...

Important Information

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