ShaunR

Just append the SENDER (as received by the handler) as part of the ACK message

That's what the Just inspect the SENDER part of the message

The controls have different names from one picture to the other. They are the same controls, right?

Well. It looks like images aren't in the supported datatypes for that package

Well. It's fairly easy to eliminate if that is a suspected problem. Just put a check path exists and log the path before the dialogue is invoked. Then, if you see the dialogue again, you will be able to see whatf the path was and whether the app thinks it exists. You can them paste it into a browse window and see if explorer complains.

What is the default path or current path? Is it pointing to a networked drive? Are all drives actually available that are mapped? I've seen in windows (not specifically LabVIEW) that file dialogues can be "flakey" when network locations are invoked on drives that are unavailable or NAS locations that are asleep. Basically any network access failure will bring windows to it's knees and is usually facilitated by a file action (browse or open/save). When a file dialogue is invoked, it will try to enumerate drives and you only need one to not respond. If you look carefully, you will see that all the indicators are there, they are just not populated (they appear as "discolourations")-classic symptom of struggling to enumerate the drive list. You may find something in the windows event log.

Not from Europe (not sure about NK; cannot find any relevant EU sanctions) . Sanctions to Iran basically cover finance, transport and energy although if you had a "nuclear processing plant.vi", they might group that under "energy". LabVIEW is, apparently, also available in Iran, so I wouldn't be too quick to jump to conclusions about the OPs country of origin. Maybe it just cannot be bought online from wherever he resides. Congratulations! Lavag.org made it on the spooks radar. Three more keywords and they break your door down

Elimination of the case structure isn't that important. The encapsulation of the state-machine is the important bit which is what you have achieved but It is only the equivalent of "create Sub VI" on the case. From your description, you are still "driving" the machine with external, module specific messages which causes you to require the application state-machine (execution engine or sequencer) to know what module specific messages to send and in which order. That's a dependency that I don't like. So. Keep the class and keep the case structure and hard-code the "Message X" and "Message Y" in a couple of frames (probably multiple hard-coded messages in one frame) and we are back to the API. The execution engine only has to worry about application stuff and not what language the state-machines speaks (I just feel that if the messages are hard-coded, then there isn't any point to them). At that point, you can rationalise the interfaces to the modules (same messages) and swap entire modules in and out with the same execution engine (same as switching out the actor, I suppose) OR swap the execution engine with another. The end result of breaking message interdependence is is that you get swappable modules, swappable execution engines and swappable user interfaces and whole sections of a project become reusable (which is why I'd love to see the project manager cope with nested projects).

No. And I think this is where we view things fundamentally differently perhaps. In my world, messages have nothing to do with states. Well. That's not strictly true since there may be one or two out of 100 that you could identify as having a particular state. Perhaps it's better to say there is no inherent link between them. Messages are just commands and the handler is just the API interface to the state-machine - the contoller. There is no different messaging strategy "just" for state-machines where messages map to discrete states. States are handled by a separate process (the state-machine). In this world, the rest of the software doesn't care about all the internal states of the module let alone be responsible for driving them. Many of the messages I send to a state-machine are things like INIT, START, STOP, PAUSE, CONTINUE etc But if you change your terminology and say...... "Ahh... so if a message is handled the same way across multiple messages, you combine several messages into a single frame. Then yes. That was what I was stating in comparison to events.

You can already. It's called C++, C#, VB, Python or any other text language. Choose your poison.

Really? Hmmm. So as an example, you would use my #5 argument to suggest that requiring to be in a certain state to be able to dequeue a message at all, means that messaging and state have been separated and are not dependent?#2 is just adding multiple strings to a frame so it behaves similarly to adding multiple control events to a single event structure frame (same code, different messages).

You only really need to onion route when you traverse a boundary (like forwarding across TCPIP) so message depth is usually limited to 2 (arguably it could be considered chaining at that point). Everything else you send directly. If you were to onion route (i.e. concatenate) to twenty levels, then I can see that may be an issue.I just don't see the point if I can send directly. What's your use case?

Well. In context of my comments on the other thread. The message handler would always be the first example and all the state info and logic would be pushed down in the hierarchy.into subvis/classes (in your examples just "create subvifrom selection" and add the while loop memory for the state to it). A few of the arguments for #1 that I would put forward (not any particular order) 1. it is cleaner and easier to read.(subjective I know, but the frame represents messages only rather than a message and a state) 2. You can group messages in the frames (like you can with events) independently of state. 3. You can guarantee that a "dequeue" happens for every message regardless of state. 4. Less code replication. 5. Separation of responsibilities (bugs in the statemachine are separate from bugs in the message handler).

You need to call an initialising function first and it will return the reference that you can then pass to your other functions. Using the VISA example again, there is a viOpen function C Syntax ViStatus viOpen(ViSession sesn, ViRsrc rsrcName, ViAccessMode accessMode, ViUInt32 openTimeout, ViPSession vi) Visual Basic Syntax viOpen&(ByVal sesn&, ByVal rsrcName$, ByVal accessMode&,ByVal openTimeout&, vi&) It takes as an argument a string which is the resource name - rsrcName$ - (e.g. "Com1"). and returns the session value which is the vi&. It is the vi& that is passed to the other functions. Your DLL should have a similar function that takes a resource name string and passes back a LVRefNum which you can then pass into your other function calls.

Could be. Could also be a class, or action engine-depends on your level of abstraction. The goal is to have one VI per frame that is not dependent on the message order and is atomic. For a trivial example. You could have a JKI style statemachine set of messages for opening, reading and closing a file and have to pass the reference from frame-to-frame. I'm suggesting this is a bad idea and you should have a one read message and it invokes a READ vi which opens reads and closes the file.

Don't get me wrong. you can have stateful FUNCTIONS. I'm saying that the HANDLER should not be stateful. Sending a message should execute a function every time rather than conditionally executing if a message was received earlier....... there be monsters Nothing to stop you having a class in a frame that maintains its state but it should be encapsulated within the scope of the function, not the handler or, even better, just don't send a message at all (it depends what state we are talking about- file open, read,close........bury it in the function. Move slide if position is greater than 3mm, thats a sequencers job and it shouldn't send "move"). The TCPIP code I placed was just a quick and dirty way of sending commands. From experience it is quite adequate for the local loop at medium rates (10s of ms) or for an internal GB network of hundreds of ms, but forget it for internet or high speed comms. It is also useful if you are talking to many destinations with short packets infrequently (e.g. 50 cRIOs with "RESTART"). It is up to the developer to define the functions and features, the handler just provides a messaging interface. I think I said earlier that in the real world I use a comms handler and can send via a number of methods. That module actually maintains connections (whatever the interface) but I have made it function so that they die if not used for a couple of minutes so if they are used often they persist, but I don't have to explicitly close them. You can do whatever you like in the handlers, just KISS 1. Actually. The generic symantics are TARGET->SENDER->CMD->PAYLOAD. So no. It's not loose. Target and sender are purely for routing. It could have been Destination IP address and Source IP address but for this implementation I chose VI names and relieved the burden on the user of typing in the sender on every message. Additionally, you don't have to use queues. It's just convenient that queues can be isolated by names so the target is consumed for that purpose. Queues also break the need for wires running all over the place, or shared storage (which is required for events). You could have used TCPIP primitives in the Send instead of Queues and it would have worked much the same way directly over a network (which is pretty much how dispatcher in the CR works). In this respect it is a messaging strategy realised with queues and handlers. But the messaging itself would be identical with TCPIP listeners and opens. This is what makes it easy to traverse boundaries both in hardware and in software languages since it could be a webserver written in python at the other end (not easy to do with labview coded messages). 2. Well. You can't beat discipline into programmers. Only the army can do that But you have perhaps missed the "reuse" aspect. Once you have a TCPIP handler, for example, then why do you need to rename it? It's like renaming Lapdog. Besides renaming is just a search and replace string on all VIs. Not as if you have to go and rename a shedload of VIs,and have to re-link all over the place is it? 3. I don't understand the question. There is no TCPIP display loop. There is a TCPIP handler which happens to be showing its panel. And there is an IMG handler. The listener just forwards the message using Send.

I'm no expert in VB but looking at the VISA programming manual, references are usually passed as Byval Value& (notice the ampersand) e.g. C Syntax: ViStatus viGpibSendIFC(ViSession vi) Visual Basic Syntax: viGpibSendIFC&(ByVal vi&) The C pointer (asterisk) makes me tentative, however, since it could be a ByRef. But it is unusual. Hopefully Rolf will be along to answer definitely (he's the guru on this kind of stuff, I tend to work the other way around - Labview->C)

The non-labview thing I found interesting was that cats operate time-shares on their territory if they live closely packed together so they don't have to meet each other. If only I could get my neighbour to co-operate like that!

Not exactly what you are asking for but it may be suitable even if not perfect (case select-it uses the JKI plugin framework). Alternatively, it would be a very good starting point for your own framework plugin.

The vision toolkit is for, well, vision (images, OCR, camera feature detection.etc) I would take a look instead at the Robotics toolkit which has path planning, obstacle avoidance, directed graphs etc.

The IMAQ Spoke might be worth looking at

Indeed. In fact, if you can put a file write in the send (i.e. save the message with a timestamp) you can load it back up and playback a recording. If you match the timestamp with an error log, you can replay everything the operator did to replicate an error I'm not sure what you mean by "infer" the message type. You "know" what the type is for each message payload (it's planned) so you "know" what to unflatten with.if it's non-stringy. It's no different from "knowing" what get message to place in each frame in the lapdog example but without having to have VIs for every labview type you are going to support. It's just data seralisation.

I think it just looks like the JKI because it uses delimited strings and string cases. There is no state, the strings are hierarchic and atomic so it is much simpler. That is not to say you could not build a QSM style handler, but I highly recommend not to and instead think in terms of atomic functions associated with strings. I think it is more akin to SCPI in that it is hierarchical messages. If a single string is unintuitive, just add another [payload/data/DaklusStuff] terminal and concatenate inside the send. The advantage of a single string is that it's easier to document (scan diagrams and list messages) and create scripts. Although the former goes out the window when you start dynamically generating the messages. No. It's part of the messaging strategy and key to the routing. It allows you to modularise the code to effectively create an API messaging interface whose "address" (or target as I call it) is defined simply by naming the VI handler (it can be extended for clones too, but this is an example). It helps, of course, if the "target" describes the modules' capabilities (like DVM, FILE, DB etc) and that would be a "convention" I practice since it allows conversations such as: FILE->LOAD->c:tempcfg.cfg DVM->SET->VOLT->3.9 DB->QUERY->SELECT * FROM test;

Maybe. But you should note that in the presentation, his FGV singleton is a singleton (because all VIs are singletons-unless re-entrant) but he is incorrect that this is enough to fix the race condition in his anti-pattern (i.e. he hasn't fixed it and it isn't atomic). The FGV must contain the read->write for it to be protected by the VI boundary