Mike Le

I believe I've solved this problem, but it's unsatisfying because I still don't understand the problem or really understand why the solution works. I am now launching the Config Dialog from my main application using an asynchronous call to a Launch Actor wrapper: I can now repeatedly call the Configuration Dialog from my main application. I can stop the main application and edit the Actor code, as well as restart the main application and launch without a crash.

FireFox users may be interested in the Long URL Please add-on.

This is an old thread, but I was also working on some OOP probes. I can't offer much help in terms of the first problem (how to display massive amounts of class data), but perhaps I can help with the second issue (having to duplicate code). I'll share my efforts so far. Hopefully since the original post, someone else has come up with something more elegant. Here's the problem I'm trying to solve: Basically, I have tons of abstract classes that end up being wires on the block diagram. During execution, I'd like to take a peak using a probe and see what's going on - but even though the wire is an abstract class, of course there's some concrete class that's running through the wire during execution. I couldn't find a way to do a direct dynamic dispatch probe, so instead I created a simple "plugin" framework: 1) Created a probe for the abstract parent class. 2) Put a Subpanel on the probe's front panel. 3) Created a dynamic dispatching "Probe Facade" method for the abstract class, which takes a Subpanel reference as an input. 4) Dropped the Probe Facade sub-VI in the probe block diagram, inputting the reference to the Probe's Subpanel. Probe Facade MUST be overridden by the child class. The parent Probe Facade must also be called in any override. The default behavior is to simply insert Probe Facade's front panel into the Subpanel reference. The extended behavior of each override is to read any child-specific private data and display it on its front panel. The probe and Probe Facade VIs all need to be reentrant to probe multiple wires. Now for my case, I wasn't especially interested in inheriting a default Probe Facade appearance from a parent class, because my parent was abstract. But I don't see why with a little modification you couldn't create some default Probe Facade and have children override only as necessary. Perhaps this takes care of the "busy" work that Brian referred to in the original post? Though I may have misunderstood what he was concerned about in that case. My solution works most of the time, though I have noticed some inconsistent behavior if I have multiple probes active. Sometimes it looks like the Probe Facade errors out while initializing itself inside the subpanel. It's not super repeatable, though, so it's been tough to debug.

Great minds think alike, Jeff. I did try repairing the LabVIEW installations using the Shared/NIUninstaller tool. It failed to fix the problem so I went to reimage from there.

You're spot on, Jeff. I was trying to run some other LabVIEW executables this morning and ran into the same problem. I'm reimaging the laptop and will try completely fresh installs of everything after. Painful but possibly necessary.

Thanks for the suggestions. I originally used NIUninstaller instead of MSIBlast. I'd rather not go through the hassle of a complete uninstall/reinstall because that's what I JUST did and it took 5 hours yesterday. I'm concerned that if I ask NI about VI Package Manager, they'll bounce me over to JKI, and the reverse if I ask JKI about it.

I did a complete LabVIEW uninstall/reinstall and now VI Package Manager fails to recognize a compatible Run-Time Engine and won't launch. I can't even run the uninstaller to try a fresh installation because apparently the uninstaller needs a copy of the Run-Time Engine present as well. Any suggestions?

Hey Todd, Thanks for replying. Do you mean in my "Stop Subpanel Actors" method, where I pass the Enqueuer Array into a FOR loop with "Send Normal Stop" inside? That method is always called with nothing going into "error in." You're right, though; I was lazy in simply wiring "error in" through instead of creating some more intelligent behavior. If that's not what you're talking about, let me know and I'll take another look.

I've been running into a bizarre issue with some actors. Below are some YouTube links that explain the basic purpose of my code and demo the problem. I've also included some text that describe the issue. VIDEO: Config Demo: Shows how Config Manager works and its basic purpose. http://youtu.be/ZCq6bh_TrfQ Config Crash: Demonstrates the crash bug. http://youtu.be/OhqLOr4RLaY Config Code: Shows the basics of the Launch and Stop code. http://youtu.be/f0DBxiM9St0 TEXT DESCRIPTION: I have a Controller actor which I launch from my GUI. This Controller actor launches 6 nested actors, each with its own purpose. When the Controller finishes its operations, it calls Send Normal Stop to all 6 nested actors (from within its own Stop Core). I built the Controller using demo launching and shutdown code, then moved the launch/shutdown code into my real application's GUI. When in the demo, everything started up and shut down with no problems. When I moved it into the application GUI, I can observe every Actor's Stop Core being called as expected (via breakpoints). But if I then stop the main application, I find that the Controller code and nested Actor code is locked, as though something is still executing. I also can't close the project, because something is still running. After running the main application once, I can try running it again. The application starts as normal - but calling the Controller actor again causes LabVIEW to crash completely! It's a memory Access Violation, though the exact hex code changes. WHAT I'VE TRIED: I wrapped the demo launch/shutdown code into subVIs and dropped them into my main application to ensure the code was as similar as possible. But the demo runs perfectly and shuts down cleanly, while the main application does not. I have verified with breakpoints that the Stop Core of every Actor is reached. I have verified with breakpoints that all parallel UI loops in Actor Core overrides are stopped. Today I will work on checking the condition of all stopped Actors using Handle Last Ack. This will involve some changes, because right now my Controller sends out the Stop Core message to all nested Actors only RIGHT BEFORE shutting itself down. Any other suggestions for things I can try in debugging? Or anyone seen anything similar and can point to what might be causing the Actors to hang? Thanks.

Thanks, AQ. The File IO object IS initialized inside Actor Core.vi, but not on the top-level block diagram of Actor Core. It's initialized in a method "Initialize Config File.vi," which is run before the Actor Core's Call Parent Method node. Is the expected behavior in this case that the reference would persist for the lifetime of the launched actor? Or do I need to move the initialization onto the top-level block diagram of the Actor Core override?

Hey guys, I'm trying to figure out how to keep a semaphore reference persistent in memory so it doesn't get destroyed. At first I had the semaphore reference inside the Actor's private data and that was fine. I could throw the reference into the Actor data and retrieve it at will, no problems. It was never destroyed as long as the Actor was running. Today I moved the semaphore reference into a File IO class and dropped an instance of File IO into the Actor private data. This led to immediate problems when I tried to re-run my code; the reference would get destroyed and I would get 1111 errors. I tried Obtaining the reference directly in one of the Actor methods and then feeding it into the File IO object via an accessor method, but this didn't improve the result. I'd like to have the semaphore in the File IO class; that's where it makes the most sense to have it. That way restricting and releasing access to my data file is handled entirely in the File IO class. But the semaphore reference drops out of memory if it's not directly in the Actor private data (rather than bundled in an object that is then stored into the Actor data). Any suggestions? I haven't used semaphores extensively, so if I'm misunderstanding the root problem, clarification would of course be greatly appreciated.

Actually, in this case, it would be a good thing if they aren't implicitly reentrant. So certain methods are forced reentrant, such as Actor Core, but new methods are not automatically set to reentrant. That's very good to know, thanks for the help!

I have a parent Actor with "Method A." There are several children classes which inherit "Method A." If Child 1 is in the middle of running Method A and Child 2 ALSO wants to run Method A, then what happens? Does Child 2 have to wait until Child 1 is done running Method A? Or did Child 2 get its own copy of Method A, thus making methods inherited from a parent "semi-reentrant"?

I just found this thread today after trying to find a solution. Would also be interested to know if LV2013 provides a simpler dynamic loading method for executables.

I want to programmatically resize an XControl during run-time. The XControl behaves like an array, so when an element is added or removed, I want the bounds of the XControl to resize dynamically. This will allow me to do some dynamic arrangement of controls based on the XControl's new height and width. I get error 1148 ("read only property value") when trying to set the Front Panel Bounds inside the XControl, using the Facade VI reference. I've gotten around this problem by calculating the "visible height" of the XControl and returning that value as a property. But this feels like a very hackish way of solving the problem. Any ideas?

This is excellent advice. I knew I was complicating the system, but wasn't sure what to do about it. I think the guidelines you've laid out will help a great deal. Thanks!

This makes sense, but does that mean EVERY time the UI queries a setting, it has to go through the Controller to query the Hardware Actor? I definitely don't want to use a functional global (Is that what you mean by VIG?). I don't have a lot of experience with OOP, but so far the couple times I've tried mixing in a functional global have made it hard to maintain in the future. If I want to swap new Actors in, then would they ALL rely on this functional global? Sounds problematic... I think there needs to be some logic in the Controller to check for constraint problems, for problems attempting to set Hardware values. For example, the UI tries to set Resistance = 5, but the command fails. I want to be able to capture that sort of thing at the Controller. For those things, it would be very handy to have access to ALL the Hardware settings right away. It COULD ping the Hardware Interface for those settings as needed... I don't know. This is very new to me, too.

I'm somewhat new to Actor framework and this is my first major project using it. I've completed a few simple Actors before and integrated them into larger applications. I am communicating with a device over Ethernet. A proprietary program takes in ASCII commands and passes them to the device. Data is returned along the same TCP connection as ASCII strings. I want to display the data to the user in a UI. In the future, the proprietary communication program may be swapped out for a custom in-house program. There are likely to be different UIs in the future. I decided to create 3 Actors: a Hardware Interface / Listener actor, a Controller actor, and a UI actor. I want to keep communication between the three Actors simple and consistent, so potential future Actors are able to handle the same messages. The Listener and UI actors may be substituted for other actors in the future (a certainty in the case of the UI actor). A critical task of the UI is to be able to display the parameters/settings of the device. There are several dozen different settings. The UI is interested in displaying some of them as indicators, issuing warnings depending on other parameters, and ignoring other updates. The UI's response to a specific parameter would change depending on which UI is being used. What I'm struggling with is this: Which Actor should store the hardware's current parameters/settings? Should there be multiple copies of the hardware's current settings in each Actor? How should the parameters be passed around? Should there be an abstract Parameter class? If I used an abstract Parameter class, would dynamic dispatch be the best way to handle different UI reactions? I'm afraid of coupling Actors too tightly together. On the other hand, it's not clear to me where the Parameter data should be stored, because it seems like the Controller and UI would need to have access to it. Should it be stored in the Controller and passed up to UI as needed? If anyone has any thoughts/advice, I'd greatly appreciate it.

As my coworkers and I dip our toes into OOP, we're looking for best practices/guidelines to follow. We already took the basic OOP course from NI and watched a few intro presentations. What are some other guides, documents, or books people can recommend for solid OOP design practices? LabVIEW-specific guides are especially appreciated, as none of us have a strong CS background. But anything will help. Thanks.

Thanks for the review, Dhanasekaran! Let's hope the graders agree with you that my coding looks good. I took the exam today; I found it more challenging to finish all the functionality than the practice exams. I was close to getting all the functions going, but couldn't quite make it with the last one. I had a shell sub-VI and some code in a disable structure, along with some free labels explaining how the function would've worked. All the other functions worked, independently of the unfinished section of code. I documented as I went, but I wish I'd had more time to clean up and debug. Hopefully I get a good result in three weeks!

Actual attachments... CLD Exam 1 - ATM (for 2011).zip CLD Exam Practice - ATM Simulator (for 10.0).zip

Hey guys! I'm taking the CLD Exam on Wednesday (9/26) and I'm pretty nervous. I attached my SECOND attempt at the ATM for review; this one is functional unlike my first try. This time I finished the ATM in 3 hours exactly, with the benefit of being familiar with the application already. I finished the Car Wash in 3.5 hours and the Boiler in 3 hours (both on first attempt). Is there anything I should try to do this weekend before the exam? Anything I should review? Anything in my ATM solution that looks odd or problematic? Should I feel pretty prepared based on the practice exams, or is it pretty different from the real deal? I googled around for forum topics and most of them are a couple years old. Thanks guys, Mike

Not a direct comment about your project, but I've heard that the Traffic, Security, and Sprinkler sample exams aren't reflective of the current CLD exam. They're meant to be finished in 2 hours instead of 4. If I'm wrong, someone please step in and correct me.

Hi Mark, Yes, this code was completely done in 4 hours. I did not spend any time building the front panel, as the exam has recently changed to provide the front panel ahead of time. I actually coded in 2011, but back-converted to 8.0 so more people could review. I just discovered Quick Drop and am still getting used to it, but will definitely practice more before the test! I've already noticed an increase in speed and I think it'll get faster as I get more familiar with the shortcuts. I tossed the FP images in because I had a lot of spare time after finishing the code. It was the last thing I did, after correcting flags from VI Analyzer.

I'm experiencing the same "infinite instances" problem that Ravi observed. Does anyone know if there's a way to get both features (allowMultipleInstances and OS Open Document) to work together nicely? My application has had OS Open Document for several months. The addition of multipleInstances is a late request by the enduser... it would require serious re-architecting to get the desired behavior with a single instance. Thanks.