Mike Le

Bumping this thread because I'm running into the same problem a year later, with the same LabVIEW version. I suspect it's related to dynamically loading classes in an exe, which is functionality I tried to add in just before the error started showing up. The application runs fine in development and a build completes without errors. The error shows up as soon as the exe starts running. I've tried to add a unique path in the exe for every class. This is a frustrating undertaking because there are probably a couple dozen classes being loaded dynamically, and the error doesn't tell me which class I'm forgetting (if any). So I'm trying to fix the problem by assigning unique paths for each class, but I can't tell where my mistake is because the error codes returned are opaque. And of course, the worst part is that I have to complete a build between every fix attempt, which sucks up massive amounts of time. For all I know, I've successfully assigned unique dynamic paths for every class, but the exe is returning this error for some completely unrelated reason. Anyone dealt with this before? I was hoping to use some of the new class loading primitives in 2013 to do this without having to assign individual exe paths, but the entire 2013 development environment crashes when trying to load my project. So, hurray for that problem, too. Mike

I think what's confusing me about your setup is why everything needs to know the camera's settings. If you have what's essentially an "External Trigger Detector," then all it needs to do is pass an "Acquire" message to the Camera. I don't think it needs to know the camera's settings to do that. I also don't think you need a "Settings" actor. Changes from the UI should push to a Controller, which then forwards it to the relevant Actor. So if a Camera setting is changed, the UI pushes the setting up to the Controller, the Controller then pushes the setting to Camera. If an Analysis setting is changed, UI pushes it up to Controller, and Controller pushes it to the Analysis actor. I don't think there needs to be an Actor floating out there with all the settings for everything, waiting to be pinged. It's also possible I don't understand the intricacies of the application, but those are my kneejerk (and somewhat layman) reactions to this Actor layout.

Ahhh, much clearer now, thank you. I use Actor Framework extensively, so all my Actors have their own library and are organized with their associated messages. I think that's why I assumed the classes were in libraries as well. Thanks for all the lengthy explanations; sorry it took so long for me to grasp.

Sorry, I think I'm still missing something here. What's the goal of placing the "optional VIs" OUTSIDE the lvclass, but inside the same LVLIB as the class? I thought this was to avoid being forced to load the class when you want to use the optional VI. But if it's in the same LVLIB as the class, then won't both load anyway? In that case, is the advantage purely from an "organizational" standpoint? I guess I'm asking: why not just stick the optional VIs into the lvclass given that they're both going to load together either way?

Thanks, James, super informative and helpful. So given this, then I think I'm a bit confused about this part: Given that loading a single member VI loads an LVLIB, which subsequently loads any lvclasses, then isn't including the optional VIs in the same library problematic? Sorry if I'm misunderstanding something fundamental, but I really want to understand this as we untangle our dependencies. Thanks again!

Thought I'd give this thread another bump as I'm again jumping through the hoops to make classes load dynamically in an exe.

Thanks for all the great advice, guys. My coworker ran Paul's suggested experiment of dropping a class into a new project. The number of dependencies was surprisingly large, but at least now we have a baseline from which to work on better encapsulation. One question: if a single member of an LVLIB is loaded into memory, then do all the members of the LVLIB also get loaded? We have a library with some of our commonly used "primitives." We're afraid that any time we use one of those primitives, we're loading the entire library into memory. Is this the case? If so, should we work on making our LVLIBs smaller and more compact?

This could very well be the root cause. Is there a good way to determine how interdependent the code is? Also, could you point to one or two of your papers that might be applicable here? One of the very big problems with our code is that it's been slowly developed over the past 3-4 years. Naturally there's been a lot of "extension" (what might be less politely called "feature creep"). For the first 2 years, our code was exclusively task-oriented, so we had lots of state machines that just spiraled out of control and now talk to each other in whatever way was convenient to tack on at the time. All our new code is OO, and I think we've done a pretty good job of encapsulating functionality with our new classes. But we haven't had the time to "stop the presses" and re-factor all of our projects into OO.

Yes, there's that. I don't suppose you have a rope to toss down to us trudging through the deep end?

My coworker Tom found this presentation describing building a parent class into a packed library and then having plugins inherit from it. This seems exactly like what we were thinking about doing. One thing that the presentation lacks (perhaps because it's considered obvious?) is the advantages of having a parent in a packed library. For example, does it partially resolve the extended project open and build times? Does it just reduce the time to load the parent class? It seems like many people are interested in packed libraries for clean, professional-seeming deployments. While that's all well and good, I'm more interested in if it can do anything to mitigate our pain as developers.

Hi all, We've been running into serious problems with our project load and build times lately. One suspected culprit is how complex our class inheritance has become. Over time, we've created a lot of abstract classes to organize useful methods. For example, we have our own Actor Base Class, which contains some methods we've found useful (debugging, error handling, etc). In addition, we have base classes for certain broad categories of functionality, like Hardware Communication, UI, Calculation, etc. The UI tree in particular goes very deep. For example: Our Actor Base Class --> UI Actor --> Subpanel Actor --> Subpanel Abstract Type for Specific App --> Subpanel Concrete Class. We're hesitant to restructure, because the way methods are separated into different layers now is extremely useful. But we've also heard that simpler inheritance improves loading and build performance. It would be easier to prune levels off the non-UI trees, but those are (1) already less complex than UI and (2) those classes aren't used that often. Would that help or would that be a wasted effort? Basically, how are other people balancing load times with the utility of inheritance? Pitfalls? Other organizational tips? Thanks. EDIT: More extensive forum searching turns up this old thread, which seems related. I'll look into the solutions suggested there for improving load times, too. The thread suggests packed libraries. If we throw some of our higher-level parent classes into a packed library, then would that improve loading times at all? Is it even possible to inherit from a class inside a packed library? In other words, are using packed libraries a good way to mitigate lots of inheritance levels? We ideally wouldn't be messing with the parent classes very often.

I'm using 2012f4. Thanks for the tip on recompiling; I didn't think that would be enough to clear the problem. I'll try it next time.

We're trying to simplify the class inheritance structure at work to decrease loading times. I've run into a strange problem as I change the inheritance of some classes. I've noticed that sometimes class wires break when crossing across structures. My suspicion is that while the constants and terminals are being updated with the new inheritance information, somehow the tunnels are not. When I delete the tunnel and reconnect all the wires across structures, then everything's fine. Has anyone seen something similar to this before? Any way to avoid the problem? I've only changed a few inheritances so far and fixing all the errors related to this is quite repetitive and mindless. Thanks.

I was using Build Array; factoring it out led to a substantial performance improvement. Thanks for that! I'm still seeing some issues with GUI slowdown plotting at 30Hz, so I still have to play around with it, but that definitely helped a lot.

This is an idea that's also been pitched around the office. My main hesitation is that the data needs to be passed not just to the Plotter, but also to at least one other Actor (maybe two down the line). Because of that, it made sense to me to isolate Hardware and Plotting, because then the Controller can decide which Actors need access to Hardware data. If I couple the Hardware and Plotter actors, then suddenly that actor also needs to make the decision to forward the Hardware data to another Actor. At that point, it feels like I'm creating a bloated Controller/Hardware/Plotter actor and tightly coupling all of those functions/responsibilities. I was playing with a flush queue at the Chart updating end and couldn't get a performance improvement. It actually slowed down the front panel updates immensely, but that could've been a problem with how I implemented it. Do you mean a flush queue for the Actor messaging? I've never done anything like that before; is it even possible? It doesn't seem consistent with Actor philosophy... This might be the most expedient way to go if I can't get batching to work. It still concerns me to pass around a "back-channel" reference, but it might be necessary to bypass the overhead of Actor processing.

I could move the batching to the Hardware Actor, but I'm not sure this would clear the bottleneck? It seems like the Plotter would see about the same frequency of messages. I can try it and see if there's a performance improvement. I was originally pushing updates through a property node, but as you point out, this was very slow. I switched to pushing the updates to an internal queue, which is then read in a parallel loop of Plotter Actor Core. This queue dumps out directly into the Chart indicator terminal. In terms of update speed, it's desirable by the client for the graphing to appear smooth. Around 20Hz seems to be acceptable for them. I'll try adding a small delay to the queue-to-terminal loop (switching to a flush queue operation) and see if that improves things.

I've created a set of Actors that pick up data from a hardware source and display that data live in a Chart indicator. The organization is pretty simple: 1) Controller Actor: Launches the Hardware, Plotter, and Analysis actors. Mediates messages between them. 2) Hardware Actor: responsible for setup and shutdown of communication with the DUT. As it picks up data, passes them up to the Controller. 3) Plotter Actor: picks up hardware data from the Controller and plots the data to the Chart. Also provides controls that let the user change what signals are plotting and what they look like. 4) Analysis Actor: picks up hardware data from the Controller for analysis; results and/or raw data can be saved to file. The DUT produces data at a rate of 1kHz. It's theoretically possible to stream about 200 signals at this rate, though in practice it would be exceptional if someone were to gather more than 50 at once. At first, I had the Hardware Actor pick up each data-point individually and immediately forward each point to the Controller. But the Plotter Actor down-stream had trouble keeping up with the 1kHz rate. My fix was to have the Controller "batch" the messages. The Hardware Actor is still producing at 1kHz, but the Controller builds an array until 30 data-points have been received and then forwards the 2D array to the Plotter. Now the system was fast enough for a few signals, maybe 5-10. But as I add more signals, I find that my software starts to fall behind the hardware data. A colleague suggested using a DVR to store the picked up data and passing the reference around instead of the data array. My concern is that this breaks the "contract" of Actors communicating only through Actor Messages. This thread was helpful, but I thought I'd start a new thread for this particular use-case. I imagine others have used Actors for streaming hardware data and have come up with better, more elegant solutions than I could!

I'm running in the Development Environment, not an executable. I'll try explicitly running LabVIEW as an Administrator and see how that goes. Thanks for all the info.

As best I could, I changed the Ownership and Permissions for the folder and files I was trying to edit. Unfortunately, it never seemed like the permissions "took." UAC would still prevent LabVIEW from editing the files. I tried setting the Owner to "Everyone" and setting full access permissions. Nothing worked and it was very frustrating. It's a new problem for me; I've used LabVIEW on other systems at work with Windows 7 and they've been fine. This is my personal machine, however.

Originally, the file was being written to the root drive, C. I thought this might be causing the problem so I moved it to a different folder on the C drive. The problems persisted. The original file extension was ".config." I renamed it to ".txt" just to see what would happen and the file permission errors disappeared. It seems like there's some setting that prevents access to certain file extensions or unknown file extensions?

Thanks for the info, Martin. I did try playing with the Set Permissions function, but I ended up getting more permission errors. Trying to set the permissions of the file I wanted to open returned error 8.

I'm running a Windows 7 Ultimate virtual machine on a Macbook Retina. There's only one account setup on the virtual machine and it's the admin account. I tried setting the file permissions such that "Everyone" has "Full Control" on all files/folders. This took a while and the permissions couldn't be set on certain files. It also didn't resolve the problem, which was constant IO errors from LabVIEW complaining about lack of file permissions. I tried cranking the User Access Control / UAC setting down one level at a time and the problems finally went away when I shut it off completely. Is there any other way to fix this problem besides shutting it off totally? Thanks.

Hey guys, running into an application error that crashes LabVIEW entirely. The project file is about two years old and we've been doing builds on it a couple times every month with updates to the original application. Recently, we were getting an error 1003 on build attempt, claiming one of the VIs was broken. Everything ran fine in Developer mode and the "broken" VI ran fine as well, no broken arrow. We did a mass compile, which didn't resolve the problem. Finally, I took the "broken" VI and renamed it. Then I saved a copy of the renamed VI back to the original file location. The 1003 error during builds went away. Instead, the build would progress maybe 1/6th of the way through the progress bar, then completely crash the LabVIEW developer environment. Here's the error message we get from LabVIEW Crash Reporter: DAbort 0x9b027400 in drawmgr.cpp. Version: 12.0.1f4 (32-bit) Any ideas? Attached is the error data. Compile Error Report b73bd0d6-4f5d-400e-8b1a-071df67cf3c3.zip

Well, for what it's worth, Tom and I both used Actor Framework, so thanks for that.

I passed! As others, I'm a little baffled by some of the comments - apparently I got docked for both Error and Timing modules, even though I felt like I had a solid amount of coverage for both. I actually went out of my way to complete the Error module very solidly to mesh with the sample solution and because I'd memorized an error handling methodology to use. Well, strange remarks aside, what matters is the end result, and I'm quite happy with that. Thanks to everyone here for the loads of great advice, even the bits I ignored at my own peril.