From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Actor Framework Discussions
Losing the ease of dataflow programming
@auspex wrote:
Is there a tool already available or in the works which addresses my concerns?
Have you tried using the Desktop Execution Trace Toolkit? There used to be a stickied post describing it for AF, but the new forums seem to have made that disappear and I don't remember enough details to search for it.
Essentially, it runs in parallel with LabVIEW and if you track 'User Defined Trace Events' in DETT, whilst setting the symbol 'AF_Debug_Trace' = TRUE in Project Properties > Conditional Disable Symbols, it will give you little highlighted notifications when messages are sent and received, when actors are started or end, and so on. It's very helpful when things all break around you and you don't know why your small change lead to an application that hung until force closed.
You can double click on the entries to open the relevant VIs, but it can be a little trickier to find the right places sometimes - in particular, clicking on the highlighted lines will open the VIs responsible for generating the trace, not the VI that was run because of the action. Using 'VI Execution' as another 'Capture Setting' (dropdown box, same as the 'User Defined Trace Events') will show which VIs run. Errors can also be tracked, and double clicking those is usually helpful at highlighting problems.
Your other option can be to enable VI scripting, then on the VI you want to debug, place a VI Server Reference, and two Invoke Nodes, and call 'Pause VI', and 'FrontPanel.Open' or similar - then when the VI runs it will pause (wire the error out to something at the beginning of the VI) and open the front panel, despite it being a clone VI.
If it isn't Actor Core or a similar framework VI you're trying to debug, you might also be able to just make it either non-reentrant, or non-shared (in which case you can open the specific clone and enable debugging there). I think doing this with the shared-reentrant VIs that are in the framework will break stuff though, so maybe don't do that (especially don't do that, click yes, you want to change all VIs in the inheritance hierarchy, then forget which VI you changed... I've never done that... Honest)
@auspex wrote:
I work at a synchrotron, where I see different LabVIEW "styles" at different beamlines.
...
I fear my AF code is seeing the second-system effect.
...
LabVIEW is our choice because, as I like to put it, it's something a physics grad student can pick up over a weekend. But I've made an application to be used, and hopefully extended by, novices, and whoever maintains it should probably be someone with Erlang, Lisp, and Forth experience.
You must be a true AF enthusiast (or a very adventurous person) to develop a non-trivial AF application and hope it could be supported by casual coders with little prior knowledge of LabVIEW ...
Actor Programming (with AF or something else) is inherently complex. A quote from Edsger Dijkstra : " ... My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. "
Actor Programming is message-driven (processes evolving in time), while Structured Data Flow is based on static relations between nodes connected with wires. No wonder we prefer the latter 
I had been doing Actor Programming (in different forms) for the last 12 years and trying to comprehend and troubleshoot a message-driven system had always been a very challenging and slow thing to do ... so I would say you have zero chances of success for a casual coder supporting your application.
Couple years ago I got so frustrated that I had to go with the only option left - to start thinking outside the box. Result - I can now describe an actor-based system workflow with a good old datflow block diagram. No more need to sift though message logs as now I can use native LabVIEW execution highlighting ...
The trick is using blocking Actor Calls (i.e. synchronous request-reply messages, not sure how they are called in AF these days). Blocking calls had been demonized to an extent most people avoid using them in any context. But they are safe in some very important use cases (such as describing a top-level system workflow) when following certain simple rules. A nice bonus - I can now lay out and wire a block diagram that visually matches a Sequence Diagram for the same workflow. Easy to design. Easy to understand.
I do not use AF for a variety of reasons. Instead I use a custom implementation of Event Aggregator Pattern (a Message Broker providing a scalable message transport layer) with simple QMH-based implementations of actors on top. One can use different actor implementation (mix & match) as long as they call into the same Message Broker. You can read about it here: "Actor Programming without an Actor Framework"
I think you may be able to pull the same 'blocking actor calls' trick in AF, but I never tried. It would require following some rules, with one requesting to use a separate interruptable Worker Loop for running a Workflow inside the actor.
I would like to thank you for your post - it gave me an opportunity to recapitulate on the pain I went through while learning Actor Programming - leading to a presentation idea for the next CLA-A Summit with a tentative title "The Joys of Actor Programming".
@Dmitry2002 wrote:
@auspex wrote:
I work at a synchrotron, where I see different LabVIEW "styles" at different beamlines.
...
I fear my AF code is seeing the second-system effect.
...
LabVIEW is our choice because, as I like to put it, it's something a physics grad student can pick up over a weekend. But I've made an application to be used, and hopefully extended by, novices, and whoever maintains it should probably be someone with Erlang, Lisp, and Forth experience.
You must be a true AF enthusiast (or a very adventurous person) to develop a non-trivial AF application and hope it could be supported by casual coders with little prior knowledge of LabVIEW ...
I see using the AF as one less thing for the next developer to maintain, because without it I would have to make my own solution. I read recently a rebuff of the Lisper's pride in being able to easily make an object system: the result is a proliferation of incompatible and poorly tested object systems, such that you must make your own if you need one.
My only hope for the novices is that they will be able to extend it in simple ways. I'm not too worried about them, because whoever comes after me must be able to at least handle that simple extension. I do worry that my replacement will not be someone who understands the program and the science it supports; they may need to hire two people, and they'd better get along well.
Actor Programming (with AF or something else) is inherently complex. A quote from Edsger Dijkstra : " ... My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. "
I know this quote and the phenomenon all too well. Whether explaining physics, the X window system, economics, the conjugation of Latin verbs, or the difficulties of translating Attic Greek, I know it all too well.
Actor Programming is message-driven (processes evolving in time), while Structured Data Flow is based on static relations between nodes connected with wires. No wonder we prefer the latter
I had been doing Actor Programming (in different forms) for the last 12 years and trying to comprehend and troubleshoot a message-driven system had always been a very challenging and slow thing to do ... so I would say you have zero chances of success for a casual coder supporting your application.
Couple years ago I got so frustrated that I had to go with the only option left - to start thinking outside the box. Result - I can now describe an actor-based system workflow with a good old datflow block diagram. No more need to sift though message logs as now I can use native LabVIEW execution highlighting ...
The trick is using blocking Actor Calls (i.e. synchronous request-reply messages, not sure how they are called in AF these days). Blocking calls had been demonized to an extent most people avoid using them in any context. But they are safe in some very important use cases (such as describing a top-level system workflow) when following certain simple rules. A nice bonus - I can now lay out and wire a block diagram that visually matches a Sequence Diagram for the same workflow. Easy to design. Easy to understand.
I do not use AF for a variety of reasons. Instead I use a custom implementation of Event Aggregator Pattern (a Message Broker providing a scalable message transport layer) with simple QMH-based implementations of actors on top. One can use different actor implementation (mix & match) as long as they call into the same Message Broker. You can read about it here: "Actor Programming without an Actor Framework"
I think you may be able to pull the same 'blocking actor calls' trick in AF, but I never tried. It would require following some rules, with one requesting to use a separate interruptable Worker Loop for running a Workflow inside the actor.
I would like to thank you for your post - it gave me an opportunity to recapitulate on the pain I went through while learning Actor Programming - leading to a presentation idea for the next CLA-A Summit with a tentative title "The Joys of Actor Programming".
Alas, blocking was a major problem of the program I've replaced.
OK. I need to do more reading and thinking, so I'll end this reply abruptly.
@Ben wrote:
Judging by cbutcher reaching for the DETT and scripting....
No.
To be clear, in the face of what seems to be quite some opposition to AF in an AF forum, you don't need to do any scripting... Just enable the VI Scripting functions (Tools, Options, VI Server) then use one in an Invoke Node...
Now, so long as debugging is enabled, you can trace your wires to your heart's content (regardless of the shared-clone nature of the Actor Framework). Be aware other actors and VIs will keep running.
If you have the OpenG libraries (or just reimplement their function based on the call chain) you might also be able to get the VI reference for the VI calling a subVI (i.e., the parent VI) and then put the entire thing inside a subVI on a nice palette slot for click and drop use...
