Daklu

Jeff, I gave NI my test code and they confirmed it was an existing CAR. It is reportedly fixed in 2013 SP1, but I have not confirmed it yet.

The only way to guarantee Labview loads the correct version into memory is to close and reopen the project. Sometimes LV will notice the version on disk is different and ask if you want to revert (which in this context means 'load from disk,' not 'undo any changes you made') but I wouldn't bet on it noticing every time.

How long do we get to keep you?

Hey Jon... you coming back to Labview or just stopping by for a visit?

All this talk of television shows and not a single mention of House of Cards? Unacceptable! (I keep thinking I ought to try the British version.) I'm finding I'll be interested in a televised drama for a while then get bored--mostly because nothing substantial is happening. Revenge started out good but partway through the first season I realized the story wasn't going anywhere. Arrow has a back story I find a little bit interesting, but again there's no progression. I really enjoyed Weeds for a while--until it became too dark and I wearied of watching Nancy's self-destructive behavior. Tried both Mad Men and Breaking Bad. Neither struck a chord with me. I'm a little more forgiving of sitcoms. I enjoyed the early seasons of Big Bang, though I've never particularly liked Penny. Been watching 30 Rock, and that's okay. By far the best sitcom I've seen in the last 2 decades is Scrubs. (And Zach Braff nailed an awesome photobomb the other day.) There aren't that many "good" web series. I mostly enjoyed The Guild, probably because I was way into World of Warcraft for a while and could relate to the situations. But it pales in comparison to the best web show I've seen: Dr. Horrible's Sing Along Blog. If you're willing to include Machinma in the web series category, Arby 'n' the Chief was pretty funny. (If you're not familiar with it, start from the . BTW, it's not safe for work.)

For the money you might be better off purchasing a Labview RIO Eval kit.

Wait, are you saying that changing a class' library membership doesn't reset the mutation history in 2013?

Huh... I have the Raspberry Pi User Guide and didn't see any references to using the labeled pins as GPIO. Thanks for the link.

Okay, okay. Enough already... I ordered a Uno off of Ebay for <$13 including shipping. We'll see how it goes.

Shaun, Yeah, Danny mentioned the Pi earlier. Unfortunately, the Pi only has 8 GPIO pins. This board needs 10. Multiplexors or serial I/O options are possible, but this is a project for high school students in their second year of programming who will have limited help and supervision. The environment must be simple enough to set up for them to make progress quickly. Jordan, I see two different ways to approach using the Uno. The first is to program the microcontroller using c/c++ to control the lights on the circuit board directly. The second is to write firmware and have the student use the Uno as a usb digital I/O module, which is what Darin was suggesting. What kind of experience have you had using the Uno as a standard usb device? Have you had any troubles getting it to work well? (As an aside, since the Uno comes with a usb port it potentially sidesteps the problems others were having with the FTDI chips.)

I bought the OEM version... $75. Yeah, that's still a lot of Arduinos. I might pursue firmata on my own, but I'm very concerned there will be too many difficulties getting in the way of the student's success. In particular, it appears they'd have to use a USB serial port and there looks to be some issues with that. Not a big deal for an engineer--potentially a project killer for a high school CS student working independently. (What arduino would you recommend for a simple digital I/O module?)

Thanks for the leads. I ended up purchasing a LabJack U3. They don't have a Java API for that model, but it does support Python, and they are introduced to Python at the end of the first year. The firmata library looks very interesting. Unfortunately there are just too many unknowns for me to be confident I could give them something soon enough. (Namely I have no practical experience with Java, Arduino, or fermata.)

My daughter is taking a high school computer science class and learning Java. I met with her teacher last night as part of a "technical advisory board," and she asked for some projects her second year students could work on independently. (Second year CS students attend the same class as the first year students, but for the most part they choose their own projects and work on them independently.) Being a hardware guy, naturally I think programming is more fun when there are flashing lights and moving parts. A couple years ago I purchased a "traffic light kit" that is kind of neat and dirt cheap. However, writing a desktop app for it requires a digital I/O module with a Java API. Unfortunately there doesn't seem to be much Java support in the hardware community. Does anyone know of a low cost USB digital I/O module that comes with a Java API?

External actors shouldn't know anything about individual steps in the process. All they know is they send a StartProcess message to your SequenceController actor and get a message back when the process is done. Your question is more about API design that AOD. I can tell you one way to do it; I can't tell you what you should do. I usually implement configuration settings as ordinary classes, not as actors. A typical AppCfg object for me might have the following methods: -Create AppCfg (path Path); -Save (); -Get configItemA(); -Get configItemB(); -Set configItemB(string Key, string Value); -etc. During initialization the startup code creates an AppCfg object, which load the data from disk, and hands the object off to whoever is responsible for that data. If there is a need to reload the AppCfg data while the app is running, the actor responsible for that object can expose a ReloadCfgData message. When the message is received it would discard the existing object and create a new one from the file on disk. There's no reason for the initialization code to expose any steps in the process, because the initialization code is only run during startup. I try to write my component APIs so each method is independent, meaning there's no overlap in the methods' functionality. If the Initialize method calls LoadAppCfg, I wouldn't expose a separate LoadAppCfg method. I find the component is easier to use and the code is easier to understand when I don't have to keep referring back to the documentation to remind myself exactly what low level API methods are called by each high level API method. That said, there's nothing in AOD that prevents you from exposing low level and high level messages in the same actor. Examples don't help with figuring out when an actor should be used. An example can show how to implement them, but there are way too many variables for me to tell someone when they should use an actor. When do I use actors? Any time I have multiple processes that need to run concurrently. When should you use actors? When the business conditions are suitable to do so. (I am working on reimplementing the Evaporative Cooler example, but my motherboard gave up the ghost over the weekend so I have to postpone it for a while.)

No, I'm saying the MHL sends a message to the helper loop telling it what step to execute. MHL: Do step 1. Here are the data you need. HL: I finished step 1. Here are the results. MHL: <checks results and figures out the next step> Do step 2. Here are the data you need. HL: I finished step 2. Here are the results. MHL: <checks results and figures out the next step> Do step 8. Here are the data you need. etc. In the presentation I said any time I drop a MHL I consider it another actor. That's another simplification. I only call a MHL an actor if it has the characteristics I consider essential for agile actors--atomic messages (no sequential dependencies) and always waiting. The helper loop in this case could be a message handling loop, but it's not an agile actor because it directly executes lengthy processes. Really? I think it's a remarkably good example. Depends on the database. Some only process a single transaction at a time on each connection. That's why I asked which one you are using. There's nothing preventing the connection manager from monitoring the database and refusing to hand out connection objects if it is down. Anyway, I'm not trying to tell you how to design your app. I'm just trying to understand why you are favoring imposing synchronous access on an inherently asynchronous process. If the tradeoff for having a clean error log is worth it to you, I'm certainly not in a position to tell you it isn't. I'll grant you your solution is a viable alternative, and may even be the best solution in your situation. I'm not anywhere close to being convinced it is "the best solution" in general. I understand the sentiment, but there are no general rules for when they are and are not appropriate. It's appropriate if you can build it so it fits into your design and behaves how you need it to behave. It's like asking when it is appropriate and is not appropriate to use classes. There are no technical reasons not to use classes, and there are no technical reasons not to use actors.

Correct. I don't like having *loops* send messages to themselves. An actor may consist of multiple loops, so an actor can send messages to itself (helper loops) internally. Having a loop send messages to itself isn't inherently bad--it is possible to do it safely. I choose not to do it because it is very easy to overlook race conditions and very hard to verify they do not exist. What DB are you using? Databases support multiple connections. I don't understand why you are intent on limiting yourself to only one connection.

I agree with Shaun. I'll also suggest putting your code in a project. It helps keep your code organized, and you have to do it if you ever want to build an executable and/or installer.

The purpose of defining the differences between QSM, QMH, and MHL is to try and make them meaningful. As long as there is no agreement on definitions they have limited value in communicating ideas. In forum language the three terms are used interchangeably, causing ambiguity and confusion. I don't have strong objections to Shaun's definition of MHL: A message handling loop handles messages. That definition has value as an abstract idea. When a MHL is identified it tells me something useful about its role in the application. For the time being I'll refer to actor-style message handling loops as "Safe" MHLs (SMHL), meaning it can receive any message at any time without breaking the contract of its messages. Any MHL may be safe or it may be unsafe. The only way you can tell is by inspecting the code. Calling the subset of message handling loops that use a FIFO to buffer messages a QMH may be how the term is commonly used. If so, that's fine with me--I can adapt. However, I don't think it's a useful distinction in the same way identifying a LIFO MHL, or SEQ MHL, or Random Access MHL, or Notifier MHL isn't particularly useful. It gives me information about how the MHL is implemented, but from an actor-oriented viewpoint I don't care how it is implemented. All I care about is that it is safe. I'm not opposed to introducing new terminology, and I sometimes view sequences of messages as transactions. But since you introduced the terms you get to explain what they mean in the context of a MHL. I believe these terms have value as abstract concepts. The more difficult question is how does one identify critical sections in a MHL?

Oh, you mean like QMH/QSMs? Having a loop send messages to itself is a dangerous game. It's not well-understood exactly when it is safe to do so and when you are introducing race conditions. As far as I can tell, the only way you can guarantee race conditions don't exist is by not maintaining any loop data in a shift register. Once a loop becomes stateful race conditions have to be rooted out by inspection. That can be very difficult. You have to make sure the implied contract of each message will be fulfilled regardless of what other messages arrive before the sequence is complete. Example: There is a race condition in the QSM project template that ships with 2012. In the Initialize message handler, it is possible for a ChangeData message to be sent after InitializeData but before InitializePanel. If that occurs, then the Initialize message isn't honoring its implied contract, because the panel isn't in its initial condition when the sequence completes. You can't easily tell the race condition exists--you have to trace through each message and figure out what they do. Personally, I prefer to avoid that issue altogether by not self-sending messages. It makes it much easier to verify the app behaves correctly. I agree with James. It sounds like you're over-constraining your application. Why is it an advantage to only allow one actor to access the DB to the exclusion of all other actors? You're imposing synchronous behavior where it isn't required. It makes more sense to me to have a ConnectionPool actor that sends connection objects to individual actors that need DB access. The actor can use the connection to do its sequential operation. When it's done with the connection it can return the connection object to the ConnectionPool actor. No DVR needed. (This does expose you to the possibility of a connection leak if an actor does not return the connection when finished and asks for a new one the next time. You'd have to verify correct behavior via unit tests or inspection.) The point of having a waiting MHL is that it always has the most up-to-date information available to make decisions. Information is never stuck in the queue waiting to be read. Actually, "always waiting" is a simplification. What you want to avoid is having more than one message waiting to be read. Whenever a second message is pending, it is possible the message contains information that alters how the loop would have processed the first message. Always waiting does not mean the actor will be able to instantly do what the message requested. If the database API doesn't provide a way to abort a query in progress, then there's nothing you can do to change that. You have to wait for it to finish or timeout. It's just a matter of choosing the correct encapsulations and defining the desired behavior. Actors only expose messages which are guaranteed to fulfill their contract regardless of what other messages arrive in the meantime. Like I said earlier, if I had a sequence of steps that needed to be executed I'd wrap the sequence in an actor expose a few high level messages like StartSequence and AbortSequence. All the sequencing logic would be hidden inside the actor.

Actors don't maintain lists of other actors; they maintain lists of addresses. Each address is a list of zero or more actors (and zero or more other addresses) who will receive messages sent to that address. I agree an actor's internal list of addresses is localized; however, the address itself must be implemented as a reference or global for it to have any use in the AM. Reading back over this discussion, I think your use of the term "global addresses" is too vague. You may be referring to addresses in an unmanaged (meaning no actor is responsible for it) global data store. In that case I agree, since as near as I can tell the AM doesn't allow anything to exist that is not contained in an actor, address, or message. I'm referring to the address' behavior when implemented.

I see what you mean. The receiving actor has a single behavioral state, so all messages are always handled exactly the same way. Yes, you can do that for certain actors. I don't know if it is feasible to design all your actors that way. My gut feeling is eventually an actor somewhere in the app will need to handle a message differently depending on its internal state data. Here's my reasoning for why I think it is not. In the Actor Model (AM) actors don't send messages to other actors; they send them to addresses. An address is an abstraction of the list of all actors who will receive messages sent to that address--an alias of sorts. Nothing I've seen in the AM indicates the list of actors the address refers to must be static. Actors can be added to or removed from the list during run time, but it's not necessary to send messages to every actor that currently has the address to let them know the list has changed. The change is handled automatically, sometime behind the scenes (such as registering for user events) and sometimes in code (such as a subscription manager actor.) Saying named queues aren't allowed in the actor model oversimplifies things. I could use a named queue and pass around the name instead of the reference itself, and that wouldn't violate the AM. The important thing is the actor doesn't know about it before it's supposed to know about it. If your Planet Killer missile system is designed so every actor needs to always know the address of the Self-Destruct subsystem, then I don't see anything in the AM that says you can't use a global address implemented in whatever way you want. It's been a long time since I've done any programming with DBs, so my terminology might be wrong and certainly some of the details on how I think they work are wrong. For this response I'll use the term "DB connection" to mean a connection to the database that can only process one operation at a time. The general solution to reuse anything expensive to create is pooling. The initial approach I'd take with a DB is to create an actor that abstracts the database. The DbActor creates a private pool of connections it uses to service the requests it receives. Internally it keeps a look up table of the connections currently executing an operation and an address where the response should be sent. When a connection returns a response DbActor looks up the associated address, sends the response to it, and returns the connection to the pool. I would not distribute DbActor in a DVR for the reasons you mentioned. I also would not give connection objects to the other actors. One of the responsibilities of DbActor is to manage the connection pool, and if it is giving connections to others it can no longer do that. Helper loops are always exclusive to a single actor. Same for sub actors in hierarchical messaging. That exclusivity makes certain things much easier to reason about, but adds the overhead of having to write extra message routing logic. Regarding shutdown, when I have low level processes that might take some time to shut down, I write my shutdown logic so an actor doesn't shut down until all its sub actors have shut down. That's easy enough to do with hierarchical messaging. Aren't you using a variation of direct messaging? I've never tried doing a controlled shutdown with that, though I suppose you could as long as your actor topology has a clear hierarchy of responsibility. Yes, in my Agile Actor model the MHL is "always" waiting. If the MHL allows messages to remain on the queue for "too long," then in the AA model it is not an actor, because it requires priority messages or transport manipulation to get the behavior you want. (The AM makes no guarantees about the arrival order of messages, so priority messages can not exist.) I'm not familiar with NI's database palette. If the function for querying a DB blocks, then that function needs to be in a helper loop, not actor's MHL.

I'll respond to the rest as I get time, but this part jumped out at me. NO! This is the wrong approach to take! You must accept that you cannot--in general--prevent an actor from receiving a message it is not prepared to act on. Even if you only have two actors talking to each other. This is a fundamental truth of concurrent programming. Quit trying to break the laws of time; it's not likely to work out in your favor. (I've written about this subject before. Search for "sender side filtering" or "receiver side filtering" and you might find something.)

I've been poking around in the cooler example again. IMO, a big reason it is so complicated is because it illustrates so many different concepts and has a lot of abstract classes. I've started an AA implementation that strips away all the extra stuff and focuses on the basic AOD principles. I'll post it in a new thread when it's ready.

I can do the AA implementation, but I don't want any part of a QSMLH implementation. Maybe someone from NI would do it? (Don't forget the JKI-SM.) Yes, that task should be handed off to either a helper loop or a sub actor. Which one you choose depends on how much functionality that logical thread needs. If it’s just waiting for a response from the db, will forward it to your MHL, then exit, I’d say make it a helper loop. If instead it’s an abstraction of the database connection, I’d probably make it a full-blown actor. I create a helper loop or sub actor for every computation that is potentially slower than it needs to be to meet the project’s requirements. Is it a lot of loops? *shrug* I dunno… what do you consider a lot? I probably use more loops than most other developers. Taking a quick look through a smallish RT project I’m working on, the RT code has 17 while loops and the FPGA code has 13 loops. Is it hard to maintain? Not if you do a good job assigning responsibilities and designing the API for each loop. (Incidentally, helper loops can still be dynamically launched, so you don’t need to create 100 static loops on your block diagram just in case you’re waiting for 100 db connections.) You are correct—it’s turtles all the way down. That’s one of the reasons why I make a stink about the difference between a MHL and QMH. Eventually the actual waiting part will be delegated to a helper loop. How many layers of actors you need to go through to get to the helper loop depends on your design. Most of the time I design systems without having to use request-response messaging, but sometimes it is necessary. When I need a RR message I usually design them to be non-synchronous. Actor A sends the request to Actor B, optionally setting an internal flag indicating “I’m waiting for a specific response.” When a message arrives from Actor B, A checks the flag to see if it's the message he is waiting for and acts accordingly. I can't tell you what you should do--what behavior you want that actor to have? You could discard the message and tell the sender to try again later. You could store the message in an internal buffer and process it when the first DB call returns. You can open another database connection (dynamic launching FTW) and have both queries going in parallel. [Edit - If you don't know what you should do with the message then your system design is incomplete. Step away from the code and go back to your model. That's where you'll find the answer to your question.] You’re asking about a sequencer. Like implementing a flow chart with branching logic and whatnot, except you also want interrupts (which incidentally flow charts don’t allow) right? I’ll describe the basic approach I take to ensure there are no race conditions, but there could be alternative rule sets that are also thread safe. Let’s say you have designed your process using a flow chart and decided it is correct. Create a sub actor with a message handlers for each process block on your flow chart. Do not create message handlers for decision blocks. Do not have message handlers queue up other message handlers. The sub actor is simply a concurrent thread capable of executing the individual processes required by your flow chart. It knows about each step in the process, but it has no idea how the steps are connected. Every time a step is finished, the sub actor sends a StepCompleted message to the super actor along with any data that needs to be persisted or is required for branching logic. The super actor takes that information, figures out what the next step should be, and sends a message and data to the sub actor requesting it to do that step. Rinse and repeat until your process is complete. The super actor is responsible for knowing what the next step should be; the sub actor is responsible for knowing how to do that step. Because the super actor’s queue is not clogged up with lengthy flow chart steps, it is free to receive messages from external entities requesting to change the normal sequence of steps. That’s about as close as you can get to implementing interrupts in a data flow language. 1. I don't understand what you mean by "data dependencies between messages." Can you give me a use case to help me understand? 2. Any message handling code can be inlined as long as it finishes before the next message arrives. (Helpful, huh?) As a rule of thumb, I inline data accessors and decision logic (the brainy stuff) in the MHL. Lengthy computations, continuous processes, periodic processes, etc. (the brawny stuff) gets pushed into helper loops and sub actors. Deciding between a helper loop or sub actor comes down to how much functionality you want that logical thread to have. Complex functionality requires an actor, simple functionality gets by with a helper loop. 3. I assume you mean behavioral state machine, and not queued state machine, yes? I implement BSMs by nesting message handling loops inside a simple state machine. (If you really meant queued state machine, then my response is "I don't." They behave badly, why would I want to replicate that? )

The metronome and job processor examples were my attempt to show solutions to common challenges. Granted, they are LV code instead of abstract animations... (What can I say, it takes a long time to create complex animations in powerpoint.) As far as common programming challenges, integrating continuous processes, periodic processes, and/or sequencers into an application are the three things that come to my mind. What other kinds of challenges would you like to see implemented? (I don't think there's any point in showing how to implement different architectures. Once you understand how to integrate concurrent processes safely implementing an architecture isn't difficult.) I've been considering reimplementing the AF swamp cooler example using my style of AOP (which I self-righteously dub, "Agile Actors.") Would that be helpful? I've mentioned many times writing takes me a looooong time. If I write the code would someone else be willing to take the lead on doing a write up for it?