Jump to content

Stobber

Members
  • Posts

    213
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by Stobber

  1. I saw that when researching this feature, but the whitepaper says it's implemented as an FGV. I need a multi-instanceable circular buffer and a stateless decimator so they can be used on several displays simultaneously. I wrote a one using a DVR and got it working nicely today; I plan to clean it and share it when I get some breathing room.
  2. Yeah, I kind of hijacked my own thread. And I still need more advice on how to make the graph behave well!
  3. No, that's the answer to why any one would exist. Why are there three competing APIs to the same functionality?
  4. Good grief, why are there three?! Is there no functional overlap among them?
  5. No time to play with it now; unfortunately, I'm in crunch mode and have to find a workable solution to this problem with the skills I already have. I'll check it out later this year when I'm off project.
  6. Wow, that would be incredible! I need to set aside time before my next project to learn SQLite so I can use it where appropriate. "Fixing" LV UI features with native code is a massive pain in the butt and generally a waste of my clients' money. It carries a noncommercial license. How do I get a commercial license? None of the work I do is noncommercial.
  7. A tongue-in-cheek name for the thread, but frankly it seems to cause more problems than it solves. I have to display several waveforms of 1.5-3 million points each in several graphs simultaneously. I can't change this requirement. More specifically, I need to write that data, in chunks, to a System Waveform Graph in an application. It has to be a graph because of other restrictions (signals in the data will be edited in-place while other signals remain constant). A quick test VI shows that the Waveform Graph and Chart (in all their variants) choke with about 250,000 samples in the buffer. I found the LV Help article that explains the design of a max-min decimator, and I successfully wrote a single-waveform implementation that seems to work efficiently. (Code attached; the subVI is the decimator.) My problem now is getting the rest of the graph to play nicely when I use the decimator to adjust the waveform being displayed. If I monitor the "Scale Range Change" event and fire a draw update notification when the x-scale changes, everything seems to work smoothly if I type in a new max value on the x scale by hand. But the graph doesn't play nicely when any of the following happens: If I type a new min value on the x scale by hand, the graph scrollbar position goes out of control, and my waveform isn't in the viewable plot area. If I try to drag the scrollbar back to my data, several "Scrollbar Range Change" events are fired, and the display gets totally messed up. [*]If I use any of the graph palette tools (the zooming and selection tools on the middle palette), the display gets messed up. I wrote the decimator exactly as described in the LV Help, but I can't find any documentation on getting the graph to play nicely with a manually decimated waveform. I'm certain at least some of the people who post here have had to deal with the issue of displaying too-large data sets...how did you get the graph to play nicely in your application? Code attached, in case you'd like to see exactly what I'm doing wrong. Side question: How do you get the X scrollbar to size properly when the graph's pane resizes? Mine slides all over the pane. Waveform Graph Decimation POC (LV11).zip
  8. That's fine; if the drag fails or is canceled, the subpanel won't load a new subVI and the picture indicator will hide itself. The user can try again if they want.
  9. The LV Help defines the Drag Ended event: This event occurs after a drop operation, after the user cancels the drag and drop operation by pressing the <Esc> key, or the drag source window loses focus. I take this to mean it'll fire if anything unexpected happens during the drag, which is why I'm using it to decide when to hide the picture indicator.
  10. I just installed this package into LV 2011, and the palettes weren't shown anywhere. VIPM couldn't find them, either. I looked around and found all the code and the .mnu files in <user.lib>\_LavaCR\UI Tools, so I just manually added functions_lava_lib_ui_tools_treeoop_addon.mnu to my palettes. It looks like this UI Tools addon needs to be coordinated with the others so each can safely install its own palettes without stomping on anyone else's. Very nice tool, by the way!
  11. Just to clear the air, I never register for any events on the subpanel itself. I laid a transparent 2D Picture indicator over the panel and registered for Drag Enter and Drop on that. When Drag Started fires on the tree control, I make the transparent picture visible so it can fire events. When Drag Ended fires on the tree, I make the picture invisible again so it doesn't interfere with mouse clicks in the now-loaded subpanel VI. It works really well, and since I'm controlling the picture indicator's state in sync with the user's actions, there's no need to initialize anything before the container VI starts running.
  12. Got it working by expanding on AQ's suggestion. Here's an incomplete example for reference. DND Subpanel (lv11).zip
  13. Yeah, I need to drag data names from a tree onto different views. The two-step handler wouldn't bother me; I just need something that works for unfilled subpanels. I'll try the suggestions you gave and report back on what works.
  14. Can it be done? I registered for the Drag Enter? and Drop events on my subpanel, but they don't fire when I Drag onto them. The same event cases fire when linked to a string control.
  15. Easy there, pokey. I recall asking via PM or contact email (or something) back when I left the company. Regardless of when notice was first given to whom, thanks for handling it.
  16. That's what mje was talking about with the "lookup table".
  17. AQ's workaround for a deployed application (always my situation) is to add the .lvclass files to specific paths inside the built EXE, then provide a path to the class file using the Application Path primitive and a relative path inside the EXE. It doesn't actually pull an instance of the object from the application's memory space using the qualified name, but it's a workable approach since the EXE path can be obtained using a prim. To specify the location of the .lvclass file inside the EXE, add it to the "Always Included" list in the build spec, then create a "Destination" for it with the full path. For XYZ.lvclass, an example Destination Path would be C:\build\MyApp.exe\XYZ\. When you want to load an object of XYZ at run time, you provide the path C:\build\MyApp.exe\XYZ\XYZ.lvclass AQ told me that all the classes to be loaded need to be either inside the EXE or outside it; they can't be mixed. I didn't test that assertion b/c all my classes will be shipped in the built EXE.
  18. mje understood the question correctly. I'm storing the qualified name of the class in the string, and I want to use it to create a new object of that type when I deserialize. I looked at those Open_G VIs before posting. Maybe neither of us understands how to use them to solve this problem?
  19. I need to get an instance of a class that I know will be loaded with my application, but "Get LV Class Default Value" seems only to work with a full on-disk path to the .lvclass file. I tried passing in a string with the fully qualified name of the class, but it gives me error 7. Is there a way to get an instance of the class on my block diagram by referencing it in memory? (This is for a generic object deserializer, so I can't simply drop a constant of the class on the block diagram.) (No, I'm not trying to reproduce AQ's work in the other thread on serialization. Although the VI I'm writing is generic, the serializer is mostly special-purpose.)
  20. Here's a post on the NI forums detailing which characters aren't allowed in property names: http://forums.ni.com/t5/DIAdem/Properties-in-TDMS-file-not-visible-in-Diadem/m-p/1747404/highlight/true#M14082
  21. I'm surprised nobody else noticed this. NI used to have an API for a subset of HDF5 that shipped with their Modular Instruments (Scope, FGEN, HSDIO) drivers called NI-HWS. It was pretty solid but needed some bug fixes that never got attention. The HWS format, and all HDF5 support along with it, was ultimately canned in favor of promoting TDMS as the platform-supported file format for waveform data storage. You won't hear anyone from NI marketing talking about HDF5 again. Again, I'm surprised nobody else has mentioned the data types that TDMS doesn't support. One I can immediately think of is multi-dimensional (>3 dims) arrays: TDMS doesn't support them, while HDF5 does. Oh, another is that you can't put array or cluster types into TDMS properties. That can lead to some unfortunately creative restructuring of your metadata in order to facilitate the format.
  22. Is anybody using LVOOP in LVRT? I don't see any mention of it on the NI site or here in a cursory perusal. I'd like to bring modern programming methods to my LVRT development, but I'm nervous about uncited claims of slow execution and memory leaks. If you're using LVOOP in LVRT, what's it like? Any issues with performance? Any special considerations you have to follow to optimize memory utilization? Any weird bugs you keep running into? If you're deliberately not using them together, why? I haven't started yet simply because nobody else I know has, and being the first adopter usually means being the first to get burned! -------------------- Edit: I'm not NI anymore. I wish the mods would fix that for me...
  23. Bug report: BitMan creates several empty folders in the User Controls palette. It looks like this is because it installs a tree of several non-underscored folders under user.lib, which causes LV to auto-populate a Controls palette.
  24. James, any chance of you sharing the source for your custom tool or contributing it to a new community project to develop an "Actor Manager" we can all use?
×
×
  • Create New...

Important Information

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