03-22-2016 03:30 PM
This is the modified “Continuous Measurement and Logging" code I showed at the end of my talk on March 22. It makes three modifications to the LabVIEW 2015 original:
1) use of a private stack for executing sub-actions.
2) "error chaining" of sub-actions
3) synchronous request-reply communication from the main loop to stop the subloops, simplifying the application state diagram.
-- James
03-22-2016 03:36 PM
Thanks Matey,
I'll hold of publishing the video until after the CLA summit, if you like
Steve
Opportunity to learn from experienced developers / entrepeneurs (Fab,Joerg and Brian amongst them):
DSH Pragmatic Software Development Workshop
03-22-2016 04:39 PM
No need, publish it now.
PS> apparently MY posts don't need moderation.
04-07-2016 04:57 PM
Here are my slides from the talk.
04-20-2016 04:49 AM - edited 03-29-2018 11:21 AM
04-22-2016 05:14 AM
Note on the code:
This was the result of an hour or so of me modifying the NI template. It's for illustration of the principles I talked about; do NOT use this as a template for actual projects.
Personally, I use the "DEV template", which you can see by installing "Messenger Library" and selecting the Menu option "Tools>>Messenger Library>>Create Actor from Template" (a video). This has the same features (private subAction stack, error chaining, and synchronous request-reply) but is something I have actually used in multiple real-world projects.
10-03-2017 05:01 PM
Hi drjdpowell,
I like your idea of the action stack to prevent anyone from inserting states into a stack of grouped options. Do we need an extra queue (or in the case of your DEV template, a multi-line string)? Or would it be sufficient to make sure when we enqueue multiple states that we lock up the queue reference? (through a DVR or action engine, for example)
03-29-2018 04:58 AM
@Gregory wrote:
Hi drjdpowell,
I like your idea of the action stack to prevent anyone from inserting states into a stack of grouped options. Do we need an extra queue (or in the case of your DEV template, a multi-line string)? Or would it be sufficient to make sure when we enqueue multiple states that we lock up the queue reference? (through a DVR or action engine, for example)
Sorry for not responding, I somehow missed this.
Locking the queue would block anyone trying to send us a message, so that isn't good. You could get away from needing an extra thing to serve as your action stack by enqueuing on front of your queue. You would want to make sure no external process can enqueue in front, only the message-handling loop itself. Then your single queue is serving both as a queue of external messages and a stack of internal actions.
03-29-2018 10:41 AM
I see, so you would reverse the order of your messages and then enqueue to the front of the queue? Now that I look at it this way, I think having a separate action stack is easier to follow.