Leaderboard

FWIW: I now really understand the benefit of automated diagram cleanup - it works wonderfully on the hundred or so VIs that I just created using scripting. Thank you NI!

When you select a file to be "Always Include" which isn't a LabVIEW file, it doesn't put it in the EXE. Go to the Destinations category and you'll likely see two things, your EXE and the "Support Directory" this is the location where files that don't go into the EXE will be when the build is done. So if I include a JPG file as Always Include it will go in the folder specified by the Support Directory. This is usually something like <folder where EXE exists>Support or data in older versions of LabVIEW. So what this all means is you can call "Motor Monitor.exe" from your top level EXE, but you will need to know the path relative to the main EXE which is defined by that Support Directory settings. You can also click the Preview category and choose Generate Preview to get an idea of the file structure that will exist after the build is made and it should show you where the Motor Monitor EXE will be.

VERBOSE MODE OFF

Agree, wholeheartedly. I've pined for the past couple years to apply functional programming to all my application domains. A recent realization is functional programming simply just doesn't map to many problem domains. Key business logic such as actuation and user interaction often blows referential transparency (i'm finding that pure functions are better applicable in purely computational domains; personally, I just don't spend much time here). That said, the quest to eliminate mutable state in hopes of achieving pure functions has, at worst, led to more maintainable code. (Simply -- striving to minimize crossing code boundaries with data, and especially references to data or objects, for all levels of procedural abstractions, down to structures) I've found functional programming and object-oriented programming (see also "pants-oriented clothing") are just two roughly-orthogonal components to the bigger picture -- service- and actor-oriented programming. OMG, AQ, Scala; you're right. All this shit does converge to something useful. (A CLA Summit that focuses on practical LabVIEW implementations of programming paradigms; that's a CLA Summit I'd go to.)

(Replace the lowercase actor below with process or subsystem or service... it's more general than an Actor Framework Actor.) I had a brief offline conversation about this topic the other day about the semantic difference between a command and a request sent to an actor. An actor receiving requests is generally in charge of its health and destiny; an actor sent commands is subject to DoS attacks or other hazards from external sources, whether incidental or malicious. As Dak mentions, separating incoming messages from the job queue is a great implementation for receiving requests (I owe a lot of my understanding and respect for this concept to the JKI State Machine). The visual below represents an actor (the traffic intersection) and its response to individual messages from four distinct non-owning-but-using actors (the incoming lanes) defining their own concepts of priority (drivers with their own agenda). Were this intersection handling incoming requests rather than commands, it performs its job more effectively (by coordinating order, rate, and even batch-ness by aggregating requests to provide efficiency) and reduces undesirable interaction between the four independent actors. (Finally, I don't assert requests sent to actors are universally better than commands, since they each have merits in different problem domains; just acknowledging the existence of this concept, especially when chain-of-command and ownership does not naturally exist.) Originally from: http://chivethethrottle.files.wordpress.com/2013/01/random-t-01_18_13-920-55.jpg

I particularly second this. Actors should endeavor to read their mail promptly, and the message queue should not double as a job queue.