Leaderboard

I don't think it takes too long after deciding to do an actor based project to run into the case where you have an actor spun off without a way to kill it. You'll figure that out and get your solution working so you can pass it off to someone else and forget about it. Soon after, that someone else will come to you and say something like "yeah, those actors are cool and all, but they're really hard to debug" I ran into some of these problems a while ago, so I decided to write a little tool to help with it. I decided to call it a monitored actor. Here were my design criteria: I want a visual representation of when a monitored actor is spun up, and when it is shut down. From the visual representation, I want to be able to: stop actor, open their actor cores, and see if they're answering messages The visual representation should give you an idea of nested actor relationships. Implementing a monitored actor should be identical to implementing a regular actor. (meaning no must overrides or special knowledge) Monitored actors behave identically to Actors in the runtime environment. It turns out that you can pretty much accomplish this by creating a child actor class, which I've called Monitored Actor. A monitored actor's Pre-launch Init will try to make sure that the actor monitor window is made aware of the spawned actor, and Stop core will notify it that the actor is now dead. The actor monitor window contains ways to message the actors and pop up their cores and such. I think it's fairly obvious what each button does except pinging. Pinging will send a message to the actor and time how long it takes to get a response. This can be used to see if your actor is locked up. The time it takes to respond will be shown in the ping status column. if you want to periodically ping all the actors, set the "poll Frequency" to something greater than 10ms. This will spawn a process that just sends ping messages every X ms. Where I didn't quite meet my criteria: If you were to spawn a new actor and Immediately (in pre-launch init) spam it with High priority messages, the Actor monitor window will not know about the spawned actor until it's worked through all the High priority messages that got their first. You probably shouldn't be doing this anyways, so don't. Download it. Drop the LVLIB into your project. Change your actor's inheritance hierarchy to inherit from monitored actor instead of actor. You shouldn't have to change any of your actor's code. The monitored window will pop up when an actor is launched, and kill it's self when all actors are dead. Final note: This was something I put together for my teams use. It's been working well and fairly bug free for the past few months. It wasn't something I planned on widely distributing. A co-worker went to NI week though and he said that in every presentation where actors were mentioned, someone brought up something about they being hard to debug or hard to get into the actual running actor core instance. So I decided to post this tool here to get some feedback. Maybe find some bugs, and get a nice tool to help spread the actor gospel. Let me know what you think. Monitored Actor.zip

NOTE: THIS TOOL WILL CURRENTLY CRASH LABVIEW Checkout this pseudo code: Class Vehicle{ Public Methods: Go(), Stop() } Class Car inherits Vehicle{ Public Methods: FloorIt(), ReFuel() } In school, I programmed java with Eclipse. In Eclipse, when you have a variable named myCar with a type "Car" you could type: myCar. (notice the period). When you typed the period, eclipse would pop up a little dropdown with the following in it: Go(), Stop(), FloorIt(), ReFuel(). These are all the methods that i'm allowed to call on the myCar variable. It's a car type, so I cal call all the Car methods, but a car IS A vehicle, so I can also call all the vehicle methods on it. Eclipse would figure this all out for me, and just show me everything. I wanted something like this in labview. I always found it a pain to look at the class I'm working on, then have to find it's parent in the project and find all the methods of it that i'm allowed to call, then go up another layer perhaps. Additionally, I need to remember access scope. So if I have class A that's calling a method on class B, what is it allowed to call? It depends on if the classes are parent/children, or if they're friends. I made a tool that does all of this for you. All you have to do is click on a class wire in a VI, and the tool creates a list of all VIs that you're allowed to call on that wire. It looks at access scope and it traverses the class hierarchy. And it does all this fast. (notice the car wire has been selected, and the Class method browser shows all the methods that it can call) Double clicking on a method name in the method browser will place the VI on your mouse so that you can drop it on the block diagram wherever. Shift double clicking on the method name will insert it on the currently selected wire (using a very bad insert algorithm). Hovering over a class name will show the method's description in the context help. HOW THIS TOOL WILL CRASH LABVIEW I wanted this to be fast. I didn't want there to be a wait every time you selected a new thing on the block diagram. Unfortunately, all of what I'm doing involve VI server calls, which are not super fast. The main culprit is when figuring out what the parent of the class is. So to avoid these slow VI server calls, I cache everything I will need. I make the slow calls once when you boot up the tool, and then every other time I need the info, i just have to look it up in a variant database. Perfect, and blazing fast. Well somewhere along the lines LabVIEW complains. Basically, if open the tool, then change a classes private data, LabVIEW will crash. I've submitted this to NI, but all I've heard back is "This is in CAR....." I wish this didn't happen. If it didn't then I would've spent some more time polishing this up, and then proudly released the tool (with lot of money, fame, cars and houses to follow). But it was not meant to be. So i post it here. In hopes that someone gives me an idea of how to avoid the crash. Or maybe you'll just tell me it's a dumb idea. mgi_lib_class_method_browser-0.1.0.2.vip

When designing block diagrams, I tend to spend way too much time making sure things are aligned perfectly, down to the pixels. It's really annoying. This is most noticeable with bends in wires. I don't like having "uneven" bends, or bends where they aren't necessarily needed, or wires that cross unnecessarily. For instance: Now you might wonder why I have bends there if I can just move the wires so they look straight. Well then they won't be perfectly aligned with the node's terminal. For instance: Of course, when there are bends, I want them to be even. For instance, these are the steps I might take to "fix" this sequence of property nodes (that I wouldn't likely put together in practice to my knowledge): Does anyone else have issues with trivial things like this? I find myself using the arrow keys a LOT on the block diagram to fix these kinds of things. Am I alone in that?

I like this tool, I'll definitely give it a go once the bugs are worked out. I've also wished that this functionality were built into the Project Explorer. When a new class is generated and the inheritance assigned, we would see the static parent class method VIs already populated in the child. The VIs could be grayed or italicized to visually indicate that they are inherited methods. These wouldn't need to be actual VIs stored on disk, just visual pointers back to the parent methods. We could also have dynamic dispatch VIs come in as italicized and red font or something to indicate they can be overwritten...

If you search ni.com/downloads and narrow by 2013 and NI Developer Suite you should be able to see the downloads for the three Platform DVD if you have SSP on the account you are searching with. The search URL I used is here - http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/en/pg/1/sn/n1:2013,n8:142,ssnav:pdl/ Hopefully that works for you! - credit to Altenbach for the quick search path

For inserting an object's UI into a subpanel, I have used the reverse approach successfully - I have a DD VI that accepts a reference to a subpanel called something like "Insert UI", then its up to the individual class to decide what VI gets inserted and give the opportunity for the class to do any housekeeping before actually displaying its UI to a user. Here's a pic: