Daklu

I agree that our economy is disproportionally sensitive to world oil supply and I'd like to see that dependence reduced. At the same time, it doesn't make economic sense to replace oil with more expensive energy while the oil is available. I really don't think there is an easy solution to this. Mostly I just want there to be honest discussion about the impacts of various alternatives. Even if it is harming the environment, it's still the (pure) capitalist thing to do as long as people are willing to buy it. Capitalism only cares about the environment when customers do. It was a tongue-in-cheek commentary on common perception and the influence CO2 has had in public discourse. We created an entire industry and added hundreds of dollars to the cost of cars to cure the smog problem and what did we get? Global warming. What crisis is going to grow out of alternative energy sources?

Kurt, I think I'll finally get some time to implement some of my own active objects based on your example, but I wanted to toss out some questions to make sure I'm understanding it correctly and only change what I need to. All the vis/controls in the private folder should remain untouched, except DataRef, which I customize with my own data, and Process, in which I delete all the cases (except "shutdown") and add cases to handle my object's commands. Create and Destroy are the only public methods that are part of the framework; the others are unique to the example. Correct? There is both a command queue and a message queue. I couldn't find the message queue used anywhere. Is this an artifact of the development process or is there an intended use for it? I'm a little confused about the occurrence you use in LaunchProcess and CloseProcess. Both vis have a "Wait on Occurrence" before exiting with a 1 sec timeout, but there's no action based on whether or not the occurrence was set. Is this just a placeholder to show where to put code that does need the occurrence? I see you've set up the methods and controls with dynamic dispatching and protected scope. Have you tried creating a generalized ActiveObject for the core functionality and deriving child objects for specific implementations?

I agree with you with respect to errors. Wouldn't reentrancy really be a big benefit if you're logging a lot of events to debug your application? Especially in an RT environment, where you want to have as little impact on the timing as possible? (I haven't done Labview RT, so I'm speculating here.)

I agree that it's not very discoverable, especially in cases where we have, say, 8 instances and 2 of them have matching inputs. The boolean/error vis I referred to earlier all have the same conpane, so there's no way to select a different one other than the context menu (or the selector.) If the developer is familiar with the api of that particular poly vi it shouldn't present a problem. Still, this technique is probably best suited for private internal code rather than public consumption.

I understood what he was saying, but before reading his post I hadn't realized it was possible. I had just assumed that poly VIs had to have different inputs. It never occurred to me that it wasn't a requirement. There's always the option to draw the instance icon instead of the poly icon. If the icons are good enough to distinguish between the different instances then there's no problem, even if they have the same type inputs.

Uhh... well the thread was started specifically to address climate change data, so it is relevant to this thread. Regarding the other issue you raised, I happen to agree with you in principle. I'd like to see more alternative energy solutions. At the same time we have to remember there's no free lunch. Alternative energy advocates usually present these ideas as ideal solutions that lead to energy nirvana. I never see any discussion of potentially negative side effects. Remember catalytic converters? They were supposed to solve our smog problem by changing toxic chemicals into "harmless" water and carbon dioxide. Oops... it turns out CO2 is destroying the planet. Nobody saw that one coming... Every solution is going to have some sort of side effect. Biofuel crops displace food crops and drive up food prices. Opening new farms specifcally for biofuel crops puts more stress on the water supply and increases the cost and use of fertilizers and insecticides. Nuclear plants have that annoying radioactive waste to deal with. Geothermal is very localized and loses efficiency over time. Wind and solar both take energy that exists in a natural environment and convert it to electricity. On a small scale it's impact is undetectable. What happens when there are enough of them to supply the world's growing energy needs? How will all those windmill farms affect weather patterns? During the day, solar energy heats the ground like a thermal battery. Put down solar panels and those batteries no longer get charged. What impact will that have? Oil is used because it is convenient, relatively cheap, and has a high energy content. (Since 2003 only ~18% of US oil has been imported from the Persian Gulf. Link) Suppose we do develop alternative energy sources and we no longer need oil? Big oil companies get broken and the world is free? Not likely. Big oil may be done but they'll be replaced by big wind, big sun, or big nuclear. What happens to those countries that depend on oil exports? Will they sit by passively while the world slowly strangles their economic livelyhood? Will they switch over to farming and exporting opium? Will they invade neighboring countries for their resources? Do you expect them to happily return to being nomadic desert tribesmen? The promises made by renewable energy are, IMO, largely pipe dreams. Extracting useful energy from nature for our own use will always have some impact on the system as a whole. There's no such thing as a "environmentally neutral." There are some forms of sustainable energy (hydropower comes to mind) but they cannot produce infinite power. Reducing energy use is the only route to long term survival, and frankly I doubt humanity will ever willingly go down that path.

Very nice. Is this going to be included as a shipped example in 2010? (I'm curious, is that implementation something you've been sitting on for a while waiting to see if the community would 'discover' it or did you actually have to sit down and think about it for a while?)

Pfft... I can get a pc any old place. I might want to borrow your brain though--mine appears to be wearing out.

So I've been playing around with implementing a Memento interface, figuring it could be a fairly useful feature to have in many different kinds of objects. Sure you could use the Flatten to String prim, but what if your class uses run-time resources like queues or DVRs? Wouldn't it be cool to be able to have it automatically generate those runtime resources if needed when you restored a previous state? So I spend a couple days designing and experimenting with it until I have something I'm happy with. As I'm wrapping up some documentation I think, "Hey, I wonder what does happen if I try to unflatten an object that uses run-time resources?" What do I discover? Flatten and Unflatten have absolutely no trouble at all handling run-time resources in classes. Silly me. "Hey everyone, look at the cool little wagon I built. It's a little rickety and you have to kind of hold the wheel on with your foot if you start going too fast, but it's really useful if you have to go someplace! Pay no attention to that shiney sports car AQ is giving away... this is way better!"

That's what did it. I thought I had installed the update on this computer already... *shrug*

I must be a friggin idiot. For the life of me I cannot get the clipboard to grab a copy of the template. I've tried following exactly what you do in the video but it always pastes an empty canvas. Did you secretly put a copy of the banner on your clipboard before you started recording?

Incidentally, the singleton example that ships with Labview is a good example of a distributor that manages n vanilla byref objects for clients. The examples I posted are ways to build singleton behavior into a class itself. In general following the distributor pattern provides more flexibility; you can always make a byref object into a singleton but you can't make a singleton into a byref object.

I know... apparently their mommas never taught them it's not polite to point. Yep, you're right. One potential downside of using a distributor class is that it's relies on cooperative clients that send the object back to the distributor when they are done with it. If a client hangs or forgets to return it you end up losing at least one, and potentially more, of your process objects. If you have a large application with many clients requesting process objects, forgetting to return one of them would show up as slowly decreasing performance over time as the application runs. I've been wondering if there's a good way to prevent that from happening. I can't think of any way for the distributor object to forcefully recall an object without relying on client-side implementation. If the process objects are active objects you could implement a self-destruct mechanism that operates either from an internal watchdog timer or on a message from the distributor. Once the object has been destroyed the distributor could create a new process object and put it on the internal queue. I haven't prototyped this so I don't know how messy it would get or if it's even feasible. I'm not sure how well a self-destruct message would work with vanilla objects. In principle you wouldn't want to create a replacement process object until you've confirmed that the old process object was destroyed, but the client controls the object's execution and it's possible that object will never execute again. My point was that whereas a singleton is something that is built into the class itself, a fewton that is implemented using a distributor is an artifact of the way the objects are being managed. It could be a useful term to describe the programmer's intent, but I believe it is incorrect to describe a class as a fewton. (Unless, of course, the class itself limited the number of objects that could be created. I have no idea what that would look like in Labview though.)

All right... here's an object I created (LV 2009) to help test out my Interface Framework and make sure it can handle various ways data can be stored. It implements the following techniques to achieve different kinds of data persistence: ByVal Data - Plain old vanilla Labview ByRef Data - Data Value Reference ByRef Data - Unnamed Queue Static Data - Global Variable Static Data - Named Queue Static Data - Functional Global You can look to see how I implemented them. Beware: I didn't bother to include any locking behavior as I don't need it for what I'm doing. Race conditions will likely pop up all over the place if you use these exact implementations. I'll happily answer any questions, but if you shoot yourself in the foot you can't say you weren't warned. Did I mention I really like vanilla? I can see why you'd want a limited number of certain kinds of objects. Is this limitation something they try to build directly into the class? If so, that seems like an overly-complex way to go about it. Much easier to just create a regular old by-val object to manage a single process and then create a distributor object that has an array of n process objects and sends them off to clients that request them. Numeric Test Object.zip

I read his description as an internal implementation of a singleton object. As long as any class wire accesses the same chunk 'o data it is essentially a singleton regardless of the internal implementation. The two copies on the queue just provide a convenient way for him to cancel a lock without having to requeue the data, as you would have to do with a single element queue. I searched... no joy. Sleep? More like a medieval torture device.

Great idea! I have a bunch of "Error (and/or/not) Bool" utility VIs that would be perfect for this.

Pure fiction. No such thing as a $100 bill. (I've never seen one anyways... )

Way to go Ben! We'll get this kool-aid down your throat one way or another.

My take on it: Geeks are social misfits because they like technology. Nerds are social misfits because... they're social misfits. Geeks become your boss. Nerds become your waiter. Geeks expect to give technology tips to those they interact with. Nerds expect to receive monetary tips from those they interact with. Geeks are comfortable with who they are. Nerds are comfortable imagining they are someone else. Nerd/Geek status crosses gender boundaries, though in general I think it's easier for a boy to be considered a nerd than a girl. Once you reach adulthood the nerd label usually isn't applied any more. Then you're just "weird."

For your viewing amusement, here's the diagram I came up with after the parallelism problem was fixed. (Zoomed out to obscure the details.) Note this is only the part of the program that runs when the "Start Test" button is pressed. I haven't bothered with the rest of it. Yeah, there's definitely room to condense the number of states used. The pre-test validation process can be compressed into a single state with multiple VIs. Odd design decisions early on make the execution loop harder to refactor. In truth I probably won't do either unless someone specifically asks me to. I'm ready to get off this merry-go-round. (Either that or given ownership of it.) As long as I'm complaining... has anyone ever noticed that it's way easier to develop software for someone who doesn't know Labview than it is to develop software for someone who does know Labview but doesn't understand application development?

Woo Hoo! I Win!

I introduced my (then) 11-yo daughter to the Holy Grail at the beginning of her spring break last April. She loved it--watching it about a dozen times before the week was out. Recently she's started identifying herself as a gamer. I can't complain about that... games are what steered me into technology. And it's way better than the Goth route she started down a couple months ago.

Right-click -> Edit Icon. (Sorry, couldn't resist. )

So a Moore SM always proceeds sequentially from one state to the next with no decision branching? Are you sure that's right? That definition seems to trivialize Moore SMs to the point of being useless. I've know I've seen state diagram examples claiming to be Moore SMs that do have branching... This is a good point. The queue isn't part of the data used to make decisions on what the next state should be; it's just part of the framework that allows the QSM to work. On the other hand, one could argue that the queue is the ultimate decider on the next state. I guess it depends on what you consider state inputs and outputs. Is the state output only the data and the state(s) it put on the queue? Or can the queue itself be considered an input/output. If you're simply adding states to the end of the queue I can see the states themselves being the output. If you're flushing the queue or adding states to the front of the queue I would lean towards calling the queue itself an input/output. Still puzzled. I'll have to ponder it for a while.

Actually you are one of the people I was specifically hoping to get some feedback from. 30 years of state machines is way more experience than I have. Yeah, I've come to the conclusion they don't scale well at all--though I wonder if it is more a matter of ill-defined states rather than an inherent problem with QSMs. I did try modelling it by abandoning the 'each state only appears once on the diagram' restriction. I'm guessing this is what you mean by a "flow diagram." I discovered a case of 'QSM parallism.' What I mean by this is that a state queues up more states with the expectation that they will be executed immediately, but the queue still had states on it that it needed to execute to complete a previous process. That essentially (unintentionally) splits the execution into two separate paths that are interleaved on the queue, which of course leads to unpredictable behavior. The odd thing is the software seems to be working okay. I suspect dark magic is at work but I loaned out my copy of "Software Exorcism for Dummies" and haven't got it back yet. Yes! This is exactly what I was trying to describe with the term "process machine." You know how when you're watching a scary movie you can tell when something bad is going to happen? That's kind of how I felt, but I couldn't identify what the consequences were going to be or why it was going to happen. Just a nagging sense that it wasn't right. I'm still struggling with Mealy vs Moore as they apply to Labview state machines. From what I can find online the main difference between the two is that in a Moore SM the output depends only on the operations performed in that state while in a Mealy SM the output depends on the operations performed in that state and on the inputs themselves. If that's the case, I believe a non-queued SM in Labview would be a Moore SM. Does it stand to reason that a QSM in Labview is a Mealy SM since the output (next state) depends not only on the operations in the state, but on whether or not there are any states remaining on the queue? Oooo... a "Function Machine." I like that better than "Process Machine." You did an excellent job of concisely articulating what's been rattling around in my head. Clarity is a wonderful thing. Ahh... I neither have the influence nor the position to enforce this.