LabVIEW Wiki - User contributions [en]

https://labviewwiki.org/w/api.php?action=feedcontributions&feedformat=atom&user=Drjdpowell LabVIEW Wiki - User contributions [en] 2026-04-20T18:53:35Z User contributions MediaWiki 1.43.0 https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=31911 Messenger Library 2023-01-26T17:12:48Z

<p>Drjdpowell: </p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a free package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TPvM6u-IaeE Register Notify]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> [https://youtube.com/playlist?list=PL5AulxutFbdjFzxb-Lr6HItKR_2sG2aFA Full Playlist on YouTube]<br /> <br /> A [https://lavag.org/topic/16360-lvtn-messenger-library/?do=findComment&comment=127088 great summary of many Messenger Library sources], provided by Bob W Edwards.<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library], [https://forums.ni.com/t5/JDP-Science-Tools/bd-p/5397 JDP Science Tools] and [https://bitbucket.org/drjdpowell/messenger-library/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=31532 Messenger Library 2022-01-07T11:39:00Z

<p>Drjdpowell: Added link to missing video, plus full playlist</p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a free package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TPvM6u-IaeE Register Notify]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> [https://youtube.com/playlist?list=PL5AulxutFbdjFzxb-Lr6HItKR_2sG2aFA Full Playlist on YouTube]<br /> <br /> A [https://lavag.org/topic/16360-lvtn-messenger-library/?do=findComment&comment=127088 great summary of many Messenger Library sources], provided by Bob W Edwards.<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library], [https://forums.ni.com/t5/JDP-Science-Tools/bd-p/5397 JDP Science Tools] and [https://bitbucket.org/drjdpowell/messenger-library/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=31531 Messenger Library 2021-12-20T16:52:38Z

<p>Drjdpowell: Add link to JDP Science Tools group</p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a free package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> A [https://lavag.org/topic/16360-lvtn-messenger-library/?do=findComment&comment=127088 great summary of many Messenger Library sources], provided by Bob W Edwards.<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library], [https://forums.ni.com/t5/JDP-Science-Tools/bd-p/5397 JDP Science Tools] and [https://bitbucket.org/drjdpowell/messenger-library/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=GLA_Summit_2020/Future_Promises:_Borrowing_ideas_from_async_languages&diff=30893 GLA Summit 2020/Future Promises: Borrowing ideas from async languages 2021-01-13T17:57:18Z

<p>Drjdpowell: Fix Youtube links (were going to wrong presentations)</p> <hr /> <div>'''Future Promises: Borrowing Ideas From Async Languages''' by James McNally<br /> <br /> <br /> ''Futures and Promises are a concept that is core to asynchronous programming in many languages (JavaScript, Rust, C#).<br /> <br /> With asynchronous QMH models everywhere in LabVIEW, can't we leverage the concept too?<br /> <br /> This talk will introduce the terminology and demonstrate how they can work with existing constructs, and perhaps a dedicated API.''<br /> <br /> <br /> <div style="text-align:center;"><youtube width="800" height="600">MFO5VokFq-I</youtube></div><br /> <br /> ==Presentation Links==<br /> * [https://youtu.be/MFO5VokFq-I YouTube Video Link]<br /> <br /> ==See Also==<br /> {{ambox|text=Add links to internal wiki pages that would also help.}}<br /> <br /> ==External Links==<br /> {{ambox|text=Add links to external resources that would also help.}}<br /> <br /> [[Category:GLA Summit 2020]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=30171 Messenger Library 2020-07-15T15:17:35Z

<p>Drjdpowell: </p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a free package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> A [https://lavag.org/topic/16360-lvtn-messenger-library/?do=findComment&comment=127088 great summary of many Messenger Library sources], provided by Bob W Edwards.<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenger-library/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Talk:Messenger_Library&diff=29991 Talk:Messenger Library 2020-07-06T09:12:46Z

<p>Drjdpowell: </p> <hr /> <div>The link to the following resource is not valid: A great summary of many Messenger Library sources, provided by Bob W Edwards. --> Fixed, JDP<br /> <br /> [[Category:Pages with broken file links]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=29990 Messenger Library 2020-07-06T09:10:17Z

<p>Drjdpowell: Changed (broken) direct link to Bob Edwards summary with a link to his post (hopefully this won't break)</p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a free package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> A [https://lavag.org/topic/16360-lvtn-messenger-library/?do=findComment&comment=127088 great summary of many Messenger Library sources], provided by Bob W Edwards.<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=List_of_LabVIEW_Champions&diff=8142 List of LabVIEW Champions 2019-06-25T15:39:59Z

<p>Drjdpowell: </p> <hr /> <div>{{see also|LabVIEW Champion|LabVIEW Champions program FAQ}} <br /> Complete List at NI.com: [https://forums.ni.com/t5/LabVIEW-Champions-Directory/tkb-p/3012 LabVIEW Champions]<br /> <br /> {| class="wikitable sortable"<br /> |-<br /> ! Name<br /> ! Tenure<br /> ! Home<br /> |-<br /> | [[Albert Geven (LabVIEW Champion)|Albert Geven]]<br /> | 2005-Present<br /> | Netherlands<br /> |-<br /> | [[Alessandro Ricco (LabVIEW Champion)|Alessandro Ricco]]<br /> | 2005-Present<br /> | Italy<br /> |-<br /> | [[André Manzolli (LabVIEW Champion)|André Manzolli]]<br /> | 2005-Present<br /> | Brazil<br /> |-<br /> | [[Ben Rayner (LabVIEW Champion)|Ben Rayner]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Bill Meier (LabVIEW Champion)|Bill Meier]]<br /> | 2010-Present<br /> | United States<br /> |-<br /> | [[Bogdan Iwinski (LabVIEW Champion)|Bogdan Iwinski]]<br /> | 2010-Present<br /> | Poland<br /> |-<br /> | [[Brett Percy (LabVIEW Champion)|Brett Percy]]<br /> | 2005-Present<br /> | Australia<br /> |-<br /> | [[Bruce Ammons (LabVIEW Champion)|Bruce Ammons]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Buddy Haun (LabVIEW Champion)|Buddy Haun]]<br /> | 2008-Present<br /> | United States<br /> |-<br /> | [[Charles Ghommidh (LabVIEW Champion)|Charles Ghommidh]]<br /> | 2005-Present<br /> | France<br /> |-<br /> | [[Chris Cilino (LabVIEW Champion)|Chris Cilino]]<br /> | 2017-Present<br /> | United States<br /> |-<br /> | [[Chris Roebuck (LabVIEW Champion)|Chris Roebuck]]<br /> | 2013-Present<br /> | United Kingdom<br /> |-<br /> <br /> | [[Christian Altenbach (LabVIEW Champion)|Christian Altenbach]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Christophe Salzmann (LabVIEW Champion)|Christophe Salzmann]]<br /> | 2010-Present<br /> | United States<br /> |-<br /> | [[Christopher G. Relf (LabVIEW Champion)|Christopher G. Relf]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Dany Allard (LabVIEW Champion)|Dany Allard]]<br /> | 2013-Present<br /> | Canada<br /> |-<br /> | [[Darin Kinion (LabVIEW Champion)|Darin Kinion]]<br /> | 2012-Present<br /> | United States<br /> |-<br /> | [[David Thomson (LabVIEW Champion)|David Thomson]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Dennis Knutson (LabVIEW Champion)|Dennis Knutson]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Ed Dickens (LabVIEW Champion)|Ed Dickens]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Fabiola De la Cueva (LabVIEW Champion)|Fabiola De la Cueva]]<br /> | 2012-Present<br /> | United States<br /> |-<br /> | [[Gaurav Kulkarni (LabVIEW Champion)|Gaurav Kulkarni]]<br /> | 2013-Present<br /> | India<br /> |-<br /> | [[Jack Dunaway (LabVIEW Champion)|Jack Dunaway]]<br /> | 2010-Present<br /> | United States<br /> |-<br /> | [[Jeff Bohrer (LabVIEW Champion)|Jeff Bohrer]]<br /> | 2012-Present<br /> | United States<br /> |-<br /> | [[Jim Kring (LabVIEW Champion)|Jim Kring]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Joe Hoskins (LabVIEW Champion)|Joe Hoskins]]<br /> | 2010-Present<br /> | United States<br /> |-<br /> | [[Joerg Hampel (LabVIEW Champion)|Joerg Hampel]]<br /> | 2018-Present<br /> | Austria<br /> |-<br /> | [[Jonathon Green (LabVIEW Champion)|Jonathon Green]]<br /> | 2012-Present<br /> | Australia<br /> |-<br /> | [[Justin Goeres (LabVIEW Champion)|Justin Goeres]]<br /> | 2012-Present<br /> | United States<br /> |-<br /> | [[Leigh Christian (LabVIEW Champion)|Leigh Christian]]<br /> | 2010-Present<br /> | United States<br /> |-<br /> | [[Marcus Johnson (LabVIEW Champion)|Marcus Johnson]]<br /> | 2013-Present<br /> | Sweden<br /> |-<br /> | [[Mark Balla (LabVIEW Champion)|Mark Balla]]<br /> | 2010-Present<br /> | United States<br /> |-<br /> | [[Mark Ridgley (LabVIEW Champion)|Mark Ridgley]]<br /> | 2013-Present<br /> | United States<br /> |-<br /> | [[Mark Yedinak (LabVIEW Champion)|Mark Yedinak]]<br /> | 2010-Present<br /> | United States<br /> |-<br /> | [[Michael Aivaliotis (LabVIEW Champion)|Michael Aivaliotis]]<br /> | 2005-Present<br /> | Canada<br /> |-<br /> | [[Mike Porter (LabVIEW Champion)|Mike Porter]]<br /> | 2008-Present<br /> | United States<br /> |-<br /> | [[Muthuraman Sudalaimuthu (LabVIEW Champion)|Muthuraman Sudalaimuthu]]<br /> | 2013-Present<br /> | India<br /> |-<br /> | [[Nancy Hollenback (LabVIEW Champion)|Nancy Hollenback]]<br /> | 2008-2010<ref>In 2010, Nancy joined NI.</ref><br /> | United States<br /> |-<br /> | [[Norm Kirchner (LabVIEW Champion)|Norm Kirchner]]<br /> | 2008-2008<ref>Months after becoming a Champion, Norm joined NI.</ref><br /> | United States<br /> |-<br /> | [[Quentin "Q" Alldredge (LabVIEW Champion)|Quentin "Q" Alldredge]]<br /> | 2018-Present<br /> | United States<br /> |-<br /> | [[Parag Deshpande (LabVIEW Champion)|Parag Deshpande]]<br /> | 2012-Present<br /> | India<br /> |-<br /> | [[Pavan Bathla (LabVIEW Champion)|Pavan Bathla]]<br /> | 2007-Present<br /> | United States<br /> |-<br /> | [[Piotr Maj (LabVIEW Champion)|Piotr Maj]]<br /> | 2012-Present<br /> | Poland<br /> |-<br /> | [[Putnam W. Monroe Jr. (LabVIEW Champion)|Putnam W. Monroe Jr.]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Ray Robichaud (LabVIEW Champion)|Ray Robichaud]]<br /> | 2005-Present<br /> | Canada<br /> |-<br /> | [[Richard Sorrells (LabVIEW Champion)|Richard Sorrells]]<br /> | 2013-Present<br /> | United States<br /> |-<br /> | [[Rick Beauchaine (LabVIEW Champion)|Rick Beauchaine]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Richard Thomas (LabVIEW Champion)|Richard Thomas]]<br /> | 2012-Present<br /> | England<br /> |-<br /> | [[Roger Isaksson (LabVIEW Champion)|Roger Isaksson]]<br /> | 2013-Present<br /> | Sweden<br /> |-<br /> | [[Rolf Kalbermatter (LabVIEW Champion)|Rolf Kalbermatter]]<br /> | 2010-Present<br /> | Netherlands<br /> |-<br /> | [[Samuel James (LabVIEW Champion)|Samuel James]]<br /> | 2012-Present<br /> | India<br /> |-<br /> | [[Samuel Taggart (LabVIEW Champion)|Samuel Taggart]]<br /> | 2018-Present<br /> | United States<br /> |-<br /> | [[Saverio Mercurio (LabVIEW Champion)|Saverio Mercurio]]<br /> | 2010-Present<br /> | United States<br /> |-<br /> | [[Scott Hannahs (LabVIEW Champion)|Scott Hannahs]]<br /> | 2005-Present<br /> | United States<br /> |-<br /> | [[Shane O'Neill (LabVIEW Champion)|Shane O'Neill]]<br /> | 2010-Present<br /> | Switzerland<br /> |-<br /> | [[Steve Watts (LabVIEW Champion)|Steve Watts]]<br /> | 2013-Present<br /> | United Kingdom<br /> |-<br /> | [[Tim Robinson (LabVIEW Champion)|Tim Robinson]]<br /> | 2013-Present<br /> | United States<br /> |-<br /> | [[Tomi Maila (LabVIEW Champion)|Tomi Maila]]<br /> | 2007-Present<br /> | Finland<br /> |-<br /> | [[Urs Lauterburg (LabVIEW Champion)|Urs Lauterburg]]<br /> | 2005-Present<br /> | Switzerland<br /> |-<br /> | [[Yair Neeman (LabVIEW Champion)|Yair Neeman]]<br /> | 2007-Present<br /> | Israel<br /> |-<br /> | [[Zbigniew Sobków (LabVIEW Champion)|Zbigniew Sobków]]<br /> | 2005-Present<br /> | Poland<br /> |}<br /> <br /> <br /> <references /><br /> <br /> [[Category:LabVIEW Champions]]<br /> [[Category:Lists]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Talk:Source_Code_Control_Tools&diff=8129 Talk:Source Code Control Tools 2019-06-20T21:13:18Z

<p>Drjdpowell: </p> <hr /> <div>Good catch, James. I looked at the website of SourceTree and as it doesn't mention HG anywhere I assumed they dropped support for Mercurial? In the documentation, it still mentions it though.<br /> --[[User:Joerg.hampel|Joerg.hampel]] ([[User talk:Joerg.hampel|talk]]) 18:57, 20 June 2019 (UTC)<br /> <br /> I set up Sourcetree a week ago and had no trouble adding both HG and Git repos. So I thought I'd add it. --James</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Talk:Source_Code_Control_Tools&diff=8128 Talk:Source Code Control Tools 2019-06-20T21:12:29Z

<p>Drjdpowell: </p> <hr /> <div>Good catch, James. I looked at the website of SourceTree and as it doesn't mention HG anywhere I assumed they dropped support for Mercurial? In the documentation, it still mentions it though.<br /> --[[User:Joerg.hampel|Joerg.hampel]] ([[User talk:Joerg.hampel|talk]]) 18:57, 20 June 2019 (UTC)<br /> <br /> I set up Sourcetree a week ago and had no trouble adding both HG and Git repos. So I thought I'd add it.</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Source_Code_Control_Tools&diff=8125 Source Code Control Tools 2019-06-20T18:53:05Z

<p>Drjdpowell: </p> <hr /> <div>Source Code Control Tools are used to interact with [[Version Control Systems]]. <br /> <br /> ==Direct LabVIEW interfaces==<br /> The LabVIEW 8.6 help includes a list of SCC tools that integrate with LabVIEW's source code control interface:<br /> [http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/using_source_code/]<br /> <br /> [[Agent SVN]]<br /><br /> [[Perforce]]<br /><br /> [[Microsoft Visual SourceSafe]]<br /><br /> [[Microsoft Team System]]<br /><br /> [[MKS Source Integrity]]<br /><br /> [[IBM Rational ClearCase]]<br /><br /> [[Serena Version Manager (PVCS)]]<br /><br /> [[Seapine Surrond SCM]]<br /><br /> [[Borland StarTeam]]<br /><br /> [[Telelogic Synergy]]<br /><br /> [[PushOK (CVS and SVN plugins)]]<br /><br /> [[ionForge Evolution]]<br /><br /> <br /> This page offers a comparison of different tools:<br> [[SCC Tool Comparison]]<br /> <br /> ==Stand-Alone Tools==<br /> <br /> Depending on the Version Control System used, there are usually various third-party tools that offer additional features or platform-specific UX. Popular examples are<br /> <br /> * [https://tortoisesvn.net TortoiseSvn] for use with [[Subversion]]<br /> * [https://www.sourcetreeapp.com SourceTree] for use with [[Git]] and [[HG]]<br /> <br /> [[Category:SCC]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=LabVIEW_Wiki:Featured_content&diff=6853 LabVIEW Wiki:Featured content 2019-03-16T15:53:13Z

<p>Drjdpowell: </p> <hr /> <div>[[Getting Started]]<br /> <br /> [[GDevCon]] - the new Independent LabVIEW Conference (see [http://youtube.com/gdevcon GDevCon's YouTube channel])<br /> <br /> [[Actor_Framework_is_not_as_hard_as_you_think_and_here_is_why…]]<br /> <br /> [[Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=LabVIEW_Wiki:Featured_content&diff=6852 LabVIEW Wiki:Featured content 2019-03-16T15:48:56Z

<p>Drjdpowell: Adding some recent work to Featured Content</p> <hr /> <div>[[GDevCon]] - the new Independent LabVIEW Conference (see [http://youtube.com/gdevcon GDevCon's YouTube channel])<br /> <br /> [[Actor_Framework_is_not_as_hard_as_you_think_and_here_is_why…]]<br /> <br /> [[Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=LabVIEW_Wiki:Featured_content&diff=6851 LabVIEW Wiki:Featured content 2019-03-16T08:59:44Z

<p>Drjdpowell: </p> <hr /> <div>[[GDevCon]] - the new Independent LabVIEW Conference (see [http://youtube.com/gdevcon GDevCon's YouTube channel])</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=LabVIEW_Wiki_talk:Quick_index&diff=6850 LabVIEW Wiki talk:Quick index 2019-03-16T08:54:08Z

<p>Drjdpowell: Created page with "This index seems a bit useless. Consider removing, or reducing the number of entries to one per letter."</p> <hr /> <div>This index seems a bit useless. Consider removing, or reducing the number of entries to one per letter.</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Talk:List_of_LabVIEW_Champions&diff=6059 Talk:List of LabVIEW Champions 2019-03-04T20:05:12Z

<p>Drjdpowell: </p> <hr /> <div><br /> Shouldn't this page just point to the complete list at NI.com?</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Talk:List_of_LabVIEW_Champions&diff=6058 Talk:List of LabVIEW Champions 2019-03-04T20:04:52Z

<p>Drjdpowell: </p> <hr /> <div><gallery><br /> 7<br /> </gallery><br /> Shouldn't this page just point to the complete list at NI.com?</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Talk:List_of_LabVIEW_Champions&diff=6057 Talk:List of LabVIEW Champions 2019-03-04T20:04:13Z

<p>Drjdpowell: Created page with "Shouldn't this page just point to the complete list at no.com?"</p> <hr /> <div>Shouldn't this page just point to the complete list at no.com?</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=6055 Messenger Library 2019-03-04T10:54:10Z

<p>Drjdpowell: </p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a free package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> A [https://lavag.org/applications/core/interface/file/attachment.php?id=13899 great summary of many Messenger Library sources], provided by Bob W Edwards.<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=6047 Messenger Library 2019-02-28T21:12:08Z

<p>Drjdpowell: Added link to Bob Edwards' sumary</p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a free package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> A [https://lavag.org/applications/core/interface/file/attachment.php?id=13891 great summary of many Messenger Library sources], provided by Bob W Edwards.<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Mercurial&diff=6045 Mercurial 2019-02-28T20:40:54Z

<p>Drjdpowell: </p> <hr /> <div>= Introduction =<br /> <br /> {{TOCright}}[[Image:Logo.Mercurial.png|right]]<br /> <br /> Mercurial is a [[Source Code Control|Source Code Control]] system by Selenic, it's key feature is the distributed nature of the system. This means that changes (commits) are stored in a local repository, which can be sent (pushed) to a central repository and which can be downloaded (pulled) by others.<br /> <br /> = Getting started =<br /> <br /> Joel Spolsky has written a How-To and Why-To page called [http://Www.hginit.com HG init] (hg is the chemical symbol for Mercury).<br /> <br /> = Configuration =<br /> <br /> Mercurial stores it's setting in a file called 'hgrc' inside a hidden folder '.hg'<br /> <br /> == Setting up LVMerge ==<br /> <br /> [http://zone.ni.com/reference/en-XX/help/371361F-01/lvhowto/configmerge_thirdparty/ LVMerge] can be used by Mercurial as a Merge tool. Add the following text to the hgrc file:<br /> <pre>[merge-tools]<br /> LVMerge.args = $base $other $local $output<br /> LVMerge.executable = C:\Program Files\National Instruments\Shared\LabVIEW Merge\LVMerge.exe<br /> LVMerge.gui = True<br /> LVMerge.binary = True<br /> [merge-patterns]<br /> **.vi = LVMerge<br /> **.ctl = LVMerge<br /> **.lvclass = LVMerge<br /> **.xctl = LVMerge<br /> **.lvlib =LVMerge<br /> </pre><br /> <br /> You can now use TortoiseHG to perfrom a merge ([[Merge with TortoiseHG|How-To]])<br /> <br /> <br /> <br /> == Setting up LVDiff ==<br /> <br /> [http://meta-diff.sourceforge.net/ LVDiff] is a software package that uses the built in diff-functionality from LabVIEW to do command line based LVDiffs.<br /> <br /> === Download ===<br /> <br /> First thing is to [http://meta-diff.sourceforge.net/ download] LVDiff, copy the contents of the zip-file to a location where you have writing priviliges (lvdiff uses a local ini file).<br /><br /> Alternative: Installer from [http://decibel.ni.com/content/groups/mercurial NI Community Mercurial User Group]<br /> <br /> === Adjust ===<br /> <br /> Then you need to open up the lvdiff.vi and implement these changes.<br /> <br /> [[Image:Lvdiffcopy.png]]<br /> <br /> This snippet (the actual code inside lvdiff copy is shown) tests if the filenames are the same and if that's the case it calls a VI called lvdiffcopy, which creates a copy of the file2.<br /> For LabVIEW 2011 (and up) a patch file is available, use this to replace lvdiff.vi in the lvdiff installer folder[[File:Lvdiff_2011_patch.vi|lvdiff 2011 patch]].<br /> <br /> === Configure ===<br /> <br /> To be able to select lvdiff as the diff tool you need to add the following settings to the [merge-tools] section of the hgrc configuration file:<br /> <pre>lvdiff.diffargs = $child $parent<br /> lvdiff.executable =C:\Program Files\lvdiff\lvdiff.exe<br /> lvdiff.gui = True<br /> lvdiff.binary = True<br /> </pre><br /> <br /> If you are using TortoiseHg 1.0 or later, you can add a [diff-patterns] section to your hgrc file, analogous to the merge-patterns section mentioned above. This will enable automatic selection of the visual diff tool (see [http://tortoisehg.bitbucket.org/manual/1.0/common.html#word-diffs]):<br /> <pre><br /> [diff-patterns]<br /> **.vi = lvdiff<br /> **.ctl = lvdiff<br /> **.lvclass = lvdiff<br /> **.xctl = lvdiff<br /> **.lvlib = lvdiff<br /> </pre><br /> <br /> === Start LVDiff ===<br /> <br /> You can start lvdiff in TorsoiseHg in the 'commit' dialog with right-click and 'Visual Diff':<br /> <br /> [[Image:StartVisualDiff.png]]<br /> <br /> In the following dialog, select 'LVDiff' and double click on the VI to diff:<br /> <br /> [[Image:HG_LVDIffStart.png]]<br /> <br /> After this LVdiff will launch LabVIEW and both VI (current and committed) will be compared.<br /> <br /> == Ignoring files ==<br /> <br /> Mercurial stores general ignore patterns in a file called '.hgignore' in the repository root, so you can add the patterns to the repository. I use the following patterns<br /> <pre>.ogp$<br /> /built*$<br /> /build*$<br /> .lvlps$<br /> .aliases$<br /> </pre><br /> <br /> === Globally ignoring files ===<br /> If you're using TortoiseHG you can use a global ignore file, by adding the following in your %profile%\mercurial.ini file:<br /> <pre><br /> [ui]<br /> ...<br /> ignore = %userprofile%\.hgignore<br /> ...<br /> </pre><br /> Next to the mercurial.ini file you create the reference .hgignore file with the contents of your choice ([http://programmer.brettveenstra.com/2010/02/27/mercurial-on-windows-tip-global-ignore-file/ source]).<br /> <br /> = Performing a merge =<br /> <br /> The following conditions needs to be true to be able to perform a merge:<br /> <br /> *All local changes needs to be commited (hg st should only show&nbsp;?)<br /> *A changeset is pushed by another user to the central repository<br /> *The other changeset is not yet pulled<br /> <br /> The merge will try to detect the differences and call LVMerge if necesarry, LVmerge will show four VIs:<br /> <br /> *Base, the base VI which was present in the changeset that is the same on both repositories<br /> *Mine, local commited VI<br /> *Their, remote VI with edits from the other user<br /> <br /> These are not editable.<br /> <br /> *Resulting, this is the VI that will be stored to disc after the merge finalizes. This file can be edited by the user<br /> <br /> For each diff LVMerge will give options to use either, 'base', 'mine' or 'their' code.<br /> <br /> <br /> <br /> After the merge the code should be committed and pushed.<br /> <br /> Most Mercurial Clients will show a graph with the following layout:<br /> <br /> [[Image:MergeTrackHG.png|border]]<br /> <br /> Here's the same graph from the 'other' user, which actually performed the merge:<br /> <br /> [[Image:MergeTrackHG_Other.png|border]]<br /> <br /> Here you see the opposite actions, two changesets in the local repo and one in the remote. Only difference is the moment of branching.<br /> <br /> = Mercurial clients =<br /> <br /> On Windows[[Image:Logo.Windows.png]], Mac[[Image:Logo.Mac.png]] and&nbsp; Linux [[Image:Logo.Linux.png]], there is a command line client called 'hg'. On windows there is a context menu tool called [http://tortoisehg.bitbucket.io TortoiseHG] based on the popular TortoiseSVN and TortoiseCVS tools<br /> <br /> = External Links =<br /> <br /> *[http://mercurial.selenic.com Official website]<br /> *[http://www.hginit.com HG Init]<br /> *[http://hgbook.red-bean.com/ Mercurial: The Definitive Guide]<br /> *[http://redline6561.livejournal.com/362393.html Setting Up Mercurial with Apache]<br /> *[http://kiln.stackexchange.com Kiln / Mercurial Knowledge site]<br /> *[http://decibel.ni.com/content/groups/mercurial NI Community Mercurial User Group]<br /> <br /> [[Category:SCC]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=6035 Messenger Library 2019-02-21T20:02:08Z

<p>Drjdpowell: </p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a free package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Addresses&diff=6034 Messenger Library Addresses 2019-02-21T20:01:06Z

<p>Drjdpowell: </p> <hr /> <div>'''Addresses''' in [[Messenger Library]]<br /> <br /> At its simplest, an "address" in [[Messenger_Library]] is just something to which one can send a message. But it is also Messenger Library's primary feature, as there are many types of addresses that allow important functionality and high flexibility. They are implemented as a set of LVOOP classes, but detailed knowledge of LVOOP is not needed to use them.<br /> <br /> Here is a listing of the different types of addresses.<br /> <br /> '''Send''' is the most generic class ("parent" class); any other address can be carried on a "Send"-class wire. "Send" defines the key method (subVI) of an address: "Send.vi", to send a message. There are a large number of extensions of this core method, designed to support the use of various [[Messenger Library Messaging Patterns|messaging patterns]]. For example, to send a message and wait for a reply. <br /> <br /> A secondary method of the "Send" class (and thus of all addresses) is "Valid.vi", which indicates if a message sent to an address will actually go somewhere. An address of the "Send" class itself serves as a "null" address, and thus messages sent to it do not go anywhere and so it is not "Valid". Note that being not "valid" is not the same as there being an error on trying to send to an address. Though most subtypes of addresses will thow an error if they are not valid (since that indicates a failure of the underlying communication), sending to the "null" address is not an error condition (see also: "Observers").<br /> <br /> '''Messengers''' are [[Messenger_Mibrary_Addresses|addresses]] that actually specify an underlying communication means. A QueueMessenger carries messages on a LabVIEW Queue, an Event Messenger uses a User Event, and a NotifierMessgenger wraps a Notifier. All these types impliment ("override") "Send.vi" of the parent "Send" class.<br /> <br /> Messengers have the additional methods of "Create" and "Destroy", which create and release the underlying communication reference.<br /> <br /> Note that from the point-of-view of the sender, all Messengers are interchangable, as they all impliment "Send" and "Valid". Only on the receiving end is their use different. QueueMessengers call "Receive.vi" to dequeue messages; EventMessengers are registered to an Event Structure, etc. This was the key initial motivation of Messenger Library: to make the sender of a message be able to use any communication method, as specified by the receiver.<br /> <br /> '''TCP Messengers:''' Basic Messengers only communicate locally inside a LabVIEW application or instance; TCP Messengers extend communiction between instances and/or computers, via TCP/IP. The implimentation pattern is Client-Server. There are TCP extensions of both Queue- and EventMessengers. In both cases, creating the Messenger starts up a TCP Server process, which accepts remote connections and forwards all received messages into the Queue or User Event. The receiving process uses the same API as it would with a local Queue- or EventMessenger. Note that this means conversion of a local-only component to a network-capable one is very easy and quick.<br /> <br /> The client side is provided by "RemoteTCPMessenger", which creates a client connection to a remote server (identified by a "service name" and ip address). Messages sent to this Messenger are sent to the remote process.<br /> <br /> The TCP Messengers are designed to work with the messaging patterns of Messenger Library. They automatically route replies and notification messages back through the same TCP connection as the initial request and registration messages. Note that this means that one must keep a RemoteTCPMessenger open in order to receive replies or notifications.<br /> <br /> '''Future Tokens''' are a special type of temporary single-use address. They are somewhat similar to "[https://en.m.wikipedia.org/wiki/Futures_and_promises futures]" of other languages, and generally serve to refer to the yet-to-be-received replies to a messages in the "Scatter-Gather" messaging pattern. A Future Token is an address that can only ever accept one message (sending to a Token twice results in an error), and receiving that message, via a "Redeem Token" method, destroys the Token. <br /> <br /> '''Observers:''' Observers are the "force multipliers" of addresses. They do not represent the actual means of sending messages themselves; instead, they "wrap" other addresses with extended functionality. Each Observer can contain multiple other addresses (copies of messages sent to the Observer are sent to each contained address) and, crucially, a "Translator", an object that alters messages. Via translators, an Observer can do things like relabel a message, or substitute a different message, or place the message inside an "Outer Envelope" (a message that contains another message). <br /> <br /> Observers have the key methods of "Create Observer", which allows the combination of multiple addreses into one Observer, and "Translate", a polymorphic VI that allows the specification of what mesage translation to do.<br /> <br /> The motivation behind "Observers" is to support "observation" of one process by another. This is to be contrasted with the more ususal "command" of one process of another. The difference is illustrated by thinking of process S sending a message to process R. If this message represents a "command" from S to R, then S must "know" R. R defines what commands it can handle, and S must know the command to send. Also, a failure to execute the command is a failure of S, since it has failed to get its command done. If, instead, the message represents the observation of S by R, then the "active" party is R. S is providing information that R chooses what to do with. It is S's job to provide the information, but it is not "commanding" R to do anything, and shouldn't need to know what "command" R should execute on receiving the message. R should define the command, and thus should control the command-element of the message (S supplies the data). "Observer" addresses support this kind of idea, as they allow the receiving process to pre-configure an address that defines aspects of the messages that it will receive.<br /> <br /> The most basic (and common) use of an Observer address is to configure the relabeling of a message. For example, a sender might send messages labelled "Temperature", but the observing process may provide an Observer address configured to relabel the message "Record Main Furnace Temperature", representing a command to itself of what to do with the data.<br /> <br /> Error-handling note: Observer address never produce an error when calling Send on them. As the sender is not instigating the observation, it should not be a failure to it if the observation has failed. An Observer Address will (silently) drop any contained address that produces an error on a Send call. This simplifies programming in situations where temporary processes observe a longer-running process, as "dead" addresses are automatically dropped. Note that this means that an Observer can change on calling "Send". Observer addresses are by-value collections containing by-reference Messengers, and should be treated as by-value objects.<br /> <br /> An Observer will read as "Valid" if any contained address is valid. <br /> <br /> '''Actor Address:''' The [https://en.m.wikipedia.org/wiki/Actor_model Actor Model] describes a way of programming that uses independant processes that interact via passing messages. Actors can also be created ("launched") by other actors. LabVIEW comes with an existing implimentation of this idea, the "Actor Framework", but this is an alternate design based on Messeger-Library. Please note that there are very significamt differences between the two. <br /> <br /> An "actor" address class in Messenger Library identifies a VI (called "Actor.vi") that will be asynchronously run when the actor is "launched" (Launch method called on the actor address). After launch, the actor address contains a Messenger that will communicate with the new actor. Sending to the actor address sends the message to the message-handling loop withing the actor VI.<br /> <br /> Creating a new type of "actor" involves copying a template class. Several templates can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). The recomended templet is called "DEV". Note, however, that any message-handling loop design can be substituted, based on either a Queue- or EventMessenger.<br /> <br /> An "Actor Manager" debug tool is also installed under the Tools menu. This allows one to see what actor/VI launch what, and gives the ability to open all front panels or block diagrams.<br /> <br /> [[Category:Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Addresses&diff=6033 Messenger Library Addresses 2019-02-21T19:58:49Z

<p>Drjdpowell: Wikipedia Future/Promise link</p> <hr /> <div>'''Addresses''' in [[Messenger Library]]<br /> <br /> At its simplest, an "address" in [[Messenger_Library]] is just something to which one can send a message. But it is also Messenger Library's primary feature, as there are many types of addresses that allow important functionality and high flexibility. They are implemented as a set of LVOOP classes, but detailed knowledge of LVOOP is not needed to use them.<br /> <br /> Here is a listing of the different types of addresses.<br /> <br /> '''Send''' is the most generic class ("parent" class); any other address can be carried on a "Send"-class wire. "Send" defines the key method (subVI) of an address: "Send.vi", to send a message. There are a large number of extensions of this core method, designed to support the use of various [[Messenger Library Messaging Patterns|messaging patterns]]. For example, to send a message and wait for a reply. <br /> <br /> A secondary method of the "Send" class (and thus of all addresses) is "Valid.vi", which indicates if a message sent to an address will actually go somewhere. An address of the "Send" class itself serves as a "null" address, and thus messages sent to it do not go anywhere and so it is not "Valid". Note that being not "valid" is not the same as there being an error on trying to send to an address. Though most subtypes of addresses will thow an error if they are not valid (since that indicates a failure of the underlying communication), sending to the "null" address is not an error condition (see also: "Observers").<br /> <br /> '''Messengers''' are [[Messenger_Mibrary_Addresses|addresses]] that actually specify an underlying communication means. A QueueMessenger carries messages on a LabVIEW Queue, an Event Messenger uses a User Event, and a NotifierMessgenger wraps a Notifier. All these types impliment ("override") "Send.vi" of the parent "Send" class.<br /> <br /> Messengers have the additional methods of "Create" and "Destroy", which create and release the underlying communication reference.<br /> <br /> Note that from the point-of-view of the sender, all Messengers are interchangable, as they all impliment "Send" and "Valid". Only on the receiving end is their use different. QueueMessengers call "Receive.vi" to dequeue messages; EventMessengers are registered to an Event Structure, etc. This was the key initial motivation of Messenger Library: to make the sender of a message be able to use any communication method, as specified by the receiver.<br /> <br /> '''TCP Messengers:''' Basic Messengers only communicate locally inside a LabVIEW application or instance; TCP Messengers extend communiction between instances and/or computers, via TCP/IP. The implimentation pattern is Client-Server. There are TCP extensions of both Queue- and EventMessengers. In both cases, creating the Messenger starts up a TCP Server process, which accepts remote connections and forwards all received messages into the Queue or User Event. The receiving process uses the same API as it would with a local Queue- or EventMessenger. Note that this means conversion of a local-only component to a network-capable one is very easy and quick.<br /> <br /> The client side is provided by "RemoteTCPMessenger", which creates a client connection to a remote server (identified by a "service name" and ip address). Messages sent to this Messenger are sent to the remote process.<br /> <br /> The TCP Messengers are designed to work with the messaging patterns of Messenger Library. They automatically route replies and notification messages back through the same TCP connection as the initial request and registration messages. Note that this means that one must keep a RemoteTCPMessenger open in order to receive replies or notifications.<br /> <br /> '''Future Tokens''' are a special type of temporary single-use address. They are somewhat similar to "[https://en.m.wikipedia.org/wiki/Futures_and_promises futures]" of other languages, and generally serve to refer to the yet-to-be-received replies to a messages in the "Scatter-Gather" messaging pattern. A Future Token is an address that can only ever accept one message (sending to a Token twice results in an error), and receiving that message, via a "Redeem Token" method, destroys the Token. <br /> <br /> '''Observers:''' Observers are the "force multipliers" of addresses. They do not represent the actual means of sending messages themselves; instead, they "wrap" other addresses with extended functionality. Each Observer can contain multiple other addresses (copies of messages sent to the Observer are sent to each contained address) and, crucially, a "Translator", an object that alters messages. Via translators, an Observer can do things like relabel a message, or substitute a different message, or place the message inside an "Outer Envelope" (a message that contains another message). <br /> <br /> Observers have the key methods of "Create Observer", which allows the combination of multiple addreses into one Observer, and "Translate", a polymorphic VI that allows the specification of what mesage translation to do.<br /> <br /> The motivation behind "Observers" is to support "observation" of one process by another. This is to be contrasted with the more ususal "command" of one process of another. The difference is illustrated by thinking of process S sending a message to process R. If this message represents a "command" from S to R, then S must "know" R. R defines what commands it can handle, and S must know the command to send. Also, a failure to execute the command is a failure of S, since it has failed to get its command done. If, instead, the message represents the observation of S by R, then the "active" party is R. S is providing information that R chooses what to do with. It is S's job to provide the information, but it is not "commanding" R to do anything, and shouldn't need to know what "command" R should execute on receiving the message. R should define the command, and thus should control the command-element of the message (S supplies the data). "Observer" addresses support this kind of idea, as they allow the receiving process to pre-configure an address that defines aspects of the messages that it will receive.<br /> <br /> The most basic (and common) use of an Observer address is to configure the relabeling of a message. For example, a sender might send messages labelled "Temperature", but the observing process may provide an Observer address configured to relabel the message "Record Main Furnace Temperature", representing a command to itself of what to do with the data.<br /> <br /> Error-handling note: Observer address never produce an error when calling Send on them. As the sender is not instigating the observation, it should not be a failure to it if the observation has failed. An Observer Address will (silently) drop any contained address that produces an error on a Send call. This simplifies programming in situations where temporary processes observe a longer-running process, as "dead" addresses are automatically dropped. Note that this means that an Observer can change on calling "Send". Observer addresses are by-value collections containing by-reference Messengers, and should be treated as by-value objects.<br /> <br /> An Observer will read as "Valid" if any contained address is valid. <br /> <br /> '''Actor Address:''' The Actor Model describes a way of programming that uses independant processes that interact via passing messages. Actors can also be created ("launched") by other actors. LabVIEW comes with an existing implimentation of this idea, the "Actor Framework", but this is an alternate design based on Messeger-Library. Please note that there are very significamt differences between the two. <br /> <br /> An "actor" address class in Messenger Library identifies a VI (called "Actor.vi") that will be asynchronously run when the actor is "launched" (Launch method called on the actor address). After launch, the actor address contains a Messenger that will communicate with the new actor. Sending to the actor address sends the message to the message-handling loop withing the actor VI.<br /> <br /> Creating a new type of "actor" involves copying a template class. Several templates can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). The recomended templet is called "DEV". Note, however, that any message-handling loop design can be substituted, based on either a Queue- or EventMessenger.<br /> <br /> An "Actor Manager" debug tool is also installed under the Tools menu. This allows one to see what actor/VI launch what, and gives the ability to open all front panels or block diagrams.<br /> <br /> [[Category:Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=6030 Messenger Library 2019-02-20T16:13:18Z

<p>Drjdpowell: Added YouTube Instructional Videos</p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> '''Youtube Instructional Videos on an example project'''<br /> <br /> * [https://youtu.be/boRwtOlfOk4 Messenger Library: Quick Introduction] ([https://youtu.be/d0PX-k4-aXQ and Added Comments])<br /> * [https://youtu.be/2jMujwVonS8 Actor to Actor Communication]<br /> * [https://youtu.be/i774UXu6RAg The Controller-Model-View principle]<br /> * [https://youtu.be/CbtHLQeftK8 Recurring Event Methods]<br /> * [https://youtu.be/TCzFg6DBqZc DEV Template Event and Message Handling]<br /> * [https://youtu.be/P1NXUYIldkE Asynchronous Dialogs]<br /> * [https://youtu.be/TIFY2KgXlzA Notification “Hookup” of a dynamic actor (and generic messages)]<br /> * [https://youtu.be/rKANBR1d65g Messenger Library and TCP]<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Actor_Oriented_Design_Patterns&diff=6029 Actor Oriented Design Patterns 2019-02-20T15:47:37Z

<p>Drjdpowell: /* Other Actor Implementation Designs */</p> <hr /> <div>'''Actor Oriented Design Patterns''' are software patterns that utilize the Actor Model (for example [[Actor Framework]]). Actors are a powerful tool when creating large, highly parallelized, scalable systems in LabVIEW. <br /> <br /> == Actor Framework Designs==<br /> The [[Actor Framework]] is a powerful tool there are many aspects to how it can be implemented. Below are three Actor Oriented Design Patterns implemented with the [[Actor Framework]]. These resemble their non Object-Oriented counterparts, see [[Design Patterns Overview|Design Patterns]], where these are an implementation of a single actor. There real power lies in multiple Actors working together. These patterns are:<br /> # State Machine Actor<br /> # Queued State Machine Actor<br /> # Queued Message Handler Actor<br /> === State Machine Actor ===<br /> The State Machine Actor (SMA) is completely implemented in Messages, it does not override the Actor Core. It sends the first Message on Pre Launch Init Method. Each subsequent Message sends the next Message in the state. <br /> <br /> Because it doesn't override the Actor Core the pattern does not have a UI of its own. It could be paired with another Actor that implements the UI and sends Messages to it to update UI elements. The paired Actor would follow one of the other patterns. See more about the [[State Machine Actor|State Machine Actor (SMA) Design Pattern]].<br /> <br /> === Queued State Machine Actor ===<br /> More to come.<br /> <br /> === Queued Message Handler Actor ===<br /> More to come<br /> <br /> == Other Actor Implementation Designs ==<br /> <br /> ==== LabVIEW Tools Network Addons: ====<br /> <br /> * [[Messenger Library]]<br /> * [[DQMH]]<br /> <br /> ==== Some Actor implementations in other languages: ====<br /> <br /> * [https://doc.akka.io/docs/akka/2.5/guide/introduction.html Akka]<br /> * [https://www.erlang.org/ Erlang]<br /> * [https://actor-framework.org/ C++ Actor Framework]<br /> * [https://www.pykka.org/en/latest/api/# Pykka (Python)]<br /> <br /> == Articles ==<br /> "[[Actor Framework is not as hard as you think and here is why…]]" - by Quentin "Q" Alldredge, Q Software Innovations, LLC<br /> <br /> ''If you are familiar with the Queued Message Handler (QMH) Design Pattern and Object-Oriented Programming (OOP) then you already know everything you need to start with Actor Framework. The purpose of this article is to show the parts of the Actor Framework that are comparable to the QMH Design Pattern and provide a step-by-step procedure for converting a QMH project to an Actor Framework project.''<br /> <br /> == References ==<br /> [https://en.wikipedia.org/wiki/Actor_model Wikipedia: Actor_model]<br /> <br /> [[Category:Design patterns]]<br /> [[Category:Actor Framework]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Actor_Oriented_Design_Patterns&diff=6028 Actor Oriented Design Patterns 2019-02-20T15:40:12Z

<p>Drjdpowell: /* References */</p> <hr /> <div>'''Actor Oriented Design Patterns''' are software patterns that utilize the Actor Model (for example [[Actor Framework]]). Actors are a powerful tool when creating large, highly parallelized, scalable systems in LabVIEW. <br /> <br /> == Actor Framework Designs==<br /> The [[Actor Framework]] is a powerful tool there are many aspects to how it can be implemented. Below are three Actor Oriented Design Patterns implemented with the [[Actor Framework]]. These resemble their non Object-Oriented counterparts, see [[Design Patterns Overview|Design Patterns]], where these are an implementation of a single actor. There real power lies in multiple Actors working together. These patterns are:<br /> # State Machine Actor<br /> # Queued State Machine Actor<br /> # Queued Message Handler Actor<br /> === State Machine Actor ===<br /> The State Machine Actor (SMA) is completely implemented in Messages, it does not override the Actor Core. It sends the first Message on Pre Launch Init Method. Each subsequent Message sends the next Message in the state. <br /> <br /> Because it doesn't override the Actor Core the pattern does not have a UI of its own. It could be paired with another Actor that implements the UI and sends Messages to it to update UI elements. The paired Actor would follow one of the other patterns. See more about the [[State Machine Actor|State Machine Actor (SMA) Design Pattern]].<br /> <br /> === Queued State Machine Actor ===<br /> More to come.<br /> <br /> === Queued Message Handler Actor ===<br /> More to come<br /> <br /> == Other Actor Implementation Designs ==<br /> [[Messenger Library]]<br /> <br /> [[DQMH]]<br /> <br /> More to Come<br /> <br /> == Articles ==<br /> "[[Actor Framework is not as hard as you think and here is why…]]" - by Quentin "Q" Alldredge, Q Software Innovations, LLC<br /> <br /> ''If you are familiar with the Queued Message Handler (QMH) Design Pattern and Object-Oriented Programming (OOP) then you already know everything you need to start with Actor Framework. The purpose of this article is to show the parts of the Actor Framework that are comparable to the QMH Design Pattern and provide a step-by-step procedure for converting a QMH project to an Actor Framework project.''<br /> <br /> == References ==<br /> [https://en.wikipedia.org/wiki/Actor_model Wikipedia: Actor_model]<br /> <br /> [[Category:Design patterns]]<br /> [[Category:Actor Framework]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Actor_Oriented_Design_Patterns&diff=6027 Actor Oriented Design Patterns 2019-02-20T15:37:23Z

<p>Drjdpowell: /* Other Actor Implementation Designs */</p> <hr /> <div>'''Actor Oriented Design Patterns''' are software patterns that utilize the Actor Model (for example [[Actor Framework]]). Actors are a powerful tool when creating large, highly parallelized, scalable systems in LabVIEW. <br /> <br /> == Actor Framework Designs==<br /> The [[Actor Framework]] is a powerful tool there are many aspects to how it can be implemented. Below are three Actor Oriented Design Patterns implemented with the [[Actor Framework]]. These resemble their non Object-Oriented counterparts, see [[Design Patterns Overview|Design Patterns]], where these are an implementation of a single actor. There real power lies in multiple Actors working together. These patterns are:<br /> # State Machine Actor<br /> # Queued State Machine Actor<br /> # Queued Message Handler Actor<br /> === State Machine Actor ===<br /> The State Machine Actor (SMA) is completely implemented in Messages, it does not override the Actor Core. It sends the first Message on Pre Launch Init Method. Each subsequent Message sends the next Message in the state. <br /> <br /> Because it doesn't override the Actor Core the pattern does not have a UI of its own. It could be paired with another Actor that implements the UI and sends Messages to it to update UI elements. The paired Actor would follow one of the other patterns. See more about the [[State Machine Actor|State Machine Actor (SMA) Design Pattern]].<br /> <br /> === Queued State Machine Actor ===<br /> More to come.<br /> <br /> === Queued Message Handler Actor ===<br /> More to come<br /> <br /> == Other Actor Implementation Designs ==<br /> [[Messenger Library]]<br /> <br /> [[DQMH]]<br /> <br /> More to Come<br /> <br /> == Articles ==<br /> "[[Actor Framework is not as hard as you think and here is why…]]" - by Quentin "Q" Alldredge, Q Software Innovations, LLC<br /> <br /> ''If you are familiar with the Queued Message Handler (QMH) Design Pattern and Object-Oriented Programming (OOP) then you already know everything you need to start with Actor Framework. The purpose of this article is to show the parts of the Actor Framework that are comparable to the QMH Design Pattern and provide a step-by-step procedure for converting a QMH project to an Actor Framework project.''<br /> <br /> == References ==<br /> <br /> [[Category:Design patterns]]<br /> [[Category:Actor Framework]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Actor_Oriented_Design_Patterns&diff=6026 Actor Oriented Design Patterns 2019-02-20T15:37:07Z

<p>Drjdpowell: /* Other Actor Implementation Designs */</p> <hr /> <div>'''Actor Oriented Design Patterns''' are software patterns that utilize the Actor Model (for example [[Actor Framework]]). Actors are a powerful tool when creating large, highly parallelized, scalable systems in LabVIEW. <br /> <br /> == Actor Framework Designs==<br /> The [[Actor Framework]] is a powerful tool there are many aspects to how it can be implemented. Below are three Actor Oriented Design Patterns implemented with the [[Actor Framework]]. These resemble their non Object-Oriented counterparts, see [[Design Patterns Overview|Design Patterns]], where these are an implementation of a single actor. There real power lies in multiple Actors working together. These patterns are:<br /> # State Machine Actor<br /> # Queued State Machine Actor<br /> # Queued Message Handler Actor<br /> === State Machine Actor ===<br /> The State Machine Actor (SMA) is completely implemented in Messages, it does not override the Actor Core. It sends the first Message on Pre Launch Init Method. Each subsequent Message sends the next Message in the state. <br /> <br /> Because it doesn't override the Actor Core the pattern does not have a UI of its own. It could be paired with another Actor that implements the UI and sends Messages to it to update UI elements. The paired Actor would follow one of the other patterns. See more about the [[State Machine Actor|State Machine Actor (SMA) Design Pattern]].<br /> <br /> === Queued State Machine Actor ===<br /> More to come.<br /> <br /> === Queued Message Handler Actor ===<br /> More to come<br /> <br /> == Other Actor Implementation Designs ==<br /> [[Messenger_Library]]<br /> <br /> [[DQMH]]<br /> <br /> More to Come<br /> <br /> == Articles ==<br /> "[[Actor Framework is not as hard as you think and here is why…]]" - by Quentin "Q" Alldredge, Q Software Innovations, LLC<br /> <br /> ''If you are familiar with the Queued Message Handler (QMH) Design Pattern and Object-Oriented Programming (OOP) then you already know everything you need to start with Actor Framework. The purpose of this article is to show the parts of the Actor Framework that are comparable to the QMH Design Pattern and provide a step-by-step procedure for converting a QMH project to an Actor Framework project.''<br /> <br /> == References ==<br /> <br /> [[Category:Design patterns]]<br /> [[Category:Actor Framework]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Actor_Oriented_Design_Patterns&diff=6025 Actor Oriented Design Patterns 2019-02-20T15:36:58Z

<p>Drjdpowell: /* Other Actor Implementation Designs */</p> <hr /> <div>'''Actor Oriented Design Patterns''' are software patterns that utilize the Actor Model (for example [[Actor Framework]]). Actors are a powerful tool when creating large, highly parallelized, scalable systems in LabVIEW. <br /> <br /> == Actor Framework Designs==<br /> The [[Actor Framework]] is a powerful tool there are many aspects to how it can be implemented. Below are three Actor Oriented Design Patterns implemented with the [[Actor Framework]]. These resemble their non Object-Oriented counterparts, see [[Design Patterns Overview|Design Patterns]], where these are an implementation of a single actor. There real power lies in multiple Actors working together. These patterns are:<br /> # State Machine Actor<br /> # Queued State Machine Actor<br /> # Queued Message Handler Actor<br /> === State Machine Actor ===<br /> The State Machine Actor (SMA) is completely implemented in Messages, it does not override the Actor Core. It sends the first Message on Pre Launch Init Method. Each subsequent Message sends the next Message in the state. <br /> <br /> Because it doesn't override the Actor Core the pattern does not have a UI of its own. It could be paired with another Actor that implements the UI and sends Messages to it to update UI elements. The paired Actor would follow one of the other patterns. See more about the [[State Machine Actor|State Machine Actor (SMA) Design Pattern]].<br /> <br /> === Queued State Machine Actor ===<br /> More to come.<br /> <br /> === Queued Message Handler Actor ===<br /> More to come<br /> <br /> == Other Actor Implementation Designs ==<br /> [[Messenger_Library]]<br /> [[DQMH]]<br /> More to Come<br /> <br /> == Articles ==<br /> "[[Actor Framework is not as hard as you think and here is why…]]" - by Quentin "Q" Alldredge, Q Software Innovations, LLC<br /> <br /> ''If you are familiar with the Queued Message Handler (QMH) Design Pattern and Object-Oriented Programming (OOP) then you already know everything you need to start with Actor Framework. The purpose of this article is to show the parts of the Actor Framework that are comparable to the QMH Design Pattern and provide a step-by-step procedure for converting a QMH project to an Actor Framework project.''<br /> <br /> == References ==<br /> <br /> [[Category:Design patterns]]<br /> [[Category:Actor Framework]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Messaging_Patterns&diff=6022 Messenger Library Messaging Patterns 2019-02-19T20:08:59Z

<p>Drjdpowell: Added GDevCon1 talk link</p> <hr /> <div>== Messaging Patterns ==<br /> <br /> [[Messenger Library]] is intended to support the following patterns:<br /> * Command: simply sending a command [[Messenger Library Messages|message]] to an [[Messenger Library Addresses|Address]].<br /> * Request-Reply (blocking): sending a command and then waiting for a specific replay to come back. Also called a "Query".<br /> * Request-Reply Asynchronous: Sending a request with reply address attached to the message, then carrying on with other work before the reply is sent back to us. This is analogous to email.<br /> * Scatter Gather (Blocking or Async): multi-actor versions of Request-Reply. Makes use of Future Tokens.<br /> * Register-Notify: Registration messages request future update "Notifications". See the Observer Registry helper object.<br /> <br /> Useful Links:<br /> * [https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html Enterprise Integration Patterns]<br /> * [https://youtu.be/HIuzY_Bs7BI GDevCon1 talk that includes messaging patterns]<br /> <br /> [[Category:Messenger Library]]<br /> [[Category:Design patterns]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Messaging_Patterns&diff=6021 Messenger Library Messaging Patterns 2019-02-19T14:40:16Z

<p>Drjdpowell: </p> <hr /> <div>== Messaging Patterns ==<br /> <br /> [[Messenger Library]] is intended to support the following patterns:<br /> * Command: simply sending a command [[Messenger Library Messages|message]] to an [[Messenger Library Addresses|Address]].<br /> * Request-Reply (blocking): sending a command and then waiting for a specific replay to come back. Also called a "Query".<br /> * Request-Reply Asynchronous: Sending a request with reply address attached to the message, then carrying on with other work before the reply is sent back to us. This is analogous to email.<br /> * Scatter Gather (Blocking or Async): multi-actor versions of Request-Reply. Makes use of Future Tokens.<br /> * Register-Notify: Registration messages request future update "Notifications". See the Observer Registry helper object.<br /> <br /> Useful Links:<br /> * [https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html Enterprise Integration Patterns]<br /> <br /> [[Category:Messenger Library]]<br /> [[Category:Design patterns]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Architectures_and_Frameworks&diff=6020 Architectures and Frameworks 2019-02-19T14:37:04Z

<p>Drjdpowell: Added Messenger Library link</p> <hr /> <div>*[[Occurrence]]<br /> *[[Reentrant VI]]<br /> *[[Functional global variable]]<br /> *[[State machine]]<br /> *[[Daemon]]<br /> <br /> ==Frameworks==<br /> *[[Actor Framework]]<br /> *[[Delacor Queued Message Handler (DQMH)]]<br /> *[[Messenger Library]]<br /> *[[JKI State Machine]]<br /> *[[DCAF|Distributed Control And Automation Framework (DCAF)]]<br /> <br /> [[Category:Portals|Application design and architecture]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=6019 Messenger Library 2019-02-18T22:53:12Z

<p>Drjdpowell: </p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> [[Category:Third party LabVIEW tools]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Messaging_Patterns&diff=6018 Messenger Library Messaging Patterns 2019-02-18T17:59:01Z

<p>Drjdpowell: </p> <hr /> <div>== Messaging Patterns ==<br /> <br /> [[Messenger Library]] is intended to support the following patterns:<br /> * Command: simply sending a command [[Messenger Library Messages|message]] to an [[Messenger Library Addresses|Address]].<br /> * Request-Reply (blocking): sending a command and then waiting for a specific replay to come back. Also called a "Query".<br /> * Request-Reply Asynchronous: Sending a request with reply address attached to the message, then carrying on with other work before the reply is sent back to us. This is analogous to email.<br /> * Scatter Gather (Blocking or Async): multi-actor versions of Request-Reply. Makes use of Future Tokens.<br /> * Register-Notify: Registration messages request future update "Notifications". See the Observer Registry helper object.<br /> <br /> Useful Links:<br /> * [https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html Enterprise Integration Patterns]<br /> <br /> [[Category:Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Messaging_Patterns&diff=6017 Messenger Library Messaging Patterns 2019-02-18T17:58:25Z

<p>Drjdpowell: </p> <hr /> <div>== Messaging Patterns ==<br /> <br /> [[Messenger Library]] is intended to support the following patterns:<br /> * Command: simply sending a command [[Messenger Library Messages|message]] to an [[Messenger Library Address|Address]].<br /> * Request-Reply (blocking): sending a command and then waiting for a specific replay to come back. Also called a "Query".<br /> * Request-Reply Asynchronous: Sending a request with reply address attached to the message, then carrying on with other work before the reply is sent back to us. This is analogous to email.<br /> * Scatter Gather (Blocking or Async): multi-actor versions of Request-Reply. Makes use of Future Tokens.<br /> * Register-Notify: Registration messages request future update "Notifications". See the Observer Registry helper object.<br /> <br /> Useful Links:<br /> * [https://www.enterpriseintegrationpatterns.com/patterns/messaging/index.html Enterprise Integration Patterns]<br /> <br /> [[Category:Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Messaging_Patterns&diff=6016 Messenger Library Messaging Patterns 2019-02-18T17:55:00Z

<p>Drjdpowell: Messenger Library Messaging Patterns</p> <hr /> <div>== Messaging Patterns ==<br /> <br /> [[Messenger Library]] is intended to support the following patterns:<br /> * Command: simply sending a command [[Messenger Library Messages|message]] to an [[Messenger Library Address|Address]].<br /> * Request-Reply (blocking): sending a command and then waiting for a specific replay to come back. Also called a "Query".<br /> * Request-Reply Asynchronous: Sending a request with reply address attached to the message, then carrying on with other work before the reply is sent back to us. This is analogous to email.<br /> * Scatter Gather (Blocking or Async): multi-actor versions of Request-Reply. Makes use of Future Tokens.<br /> * Register-Notify: Registration messages request future update "Notifications". See the Observer Registry helper object.<br /> <br /> [[Category:Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=6015 Messenger Library 2019-02-18T17:51:57Z

<p>Drjdpowell: </p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|Messaging Patterns]]<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=6014 Messenger Library 2019-02-18T17:51:39Z

<p>Drjdpowell: </p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> * [[Messenger_Library_Addresses|Addresses]]<br /> * [[Messenger_Library_Messages|Messages]]<br /> * [[Messenger Library Messaging Patterns|messaging patterns]]<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Addresses&diff=6013 Messenger Library Addresses 2019-02-18T17:51:08Z

<p>Drjdpowell: </p> <hr /> <div>'''Addresses''' in [[Messenger Library]]<br /> <br /> At its simplest, an "address" in [[Messenger_Library]] is just something to which one can send a message. But it is also Messenger Library's primary feature, as there are many types of addresses that allow important functionality and high flexibility. They are implemented as a set of LVOOP classes, but detailed knowledge of LVOOP is not needed to use them.<br /> <br /> Here is a listing of the different types of addresses.<br /> <br /> '''Send''' is the most generic class ("parent" class); any other address can be carried on a "Send"-class wire. "Send" defines the key method (subVI) of an address: "Send.vi", to send a message. There are a large number of extensions of this core method, designed to support the use of various [[Messenger Library Messaging Patterns|messaging patterns]]. For example, to send a message and wait for a reply. <br /> <br /> A secondary method of the "Send" class (and thus of all addresses) is "Valid.vi", which indicates if a message sent to an address will actually go somewhere. An address of the "Send" class itself serves as a "null" address, and thus messages sent to it do not go anywhere and so it is not "Valid". Note that being not "valid" is not the same as there being an error on trying to send to an address. Though most subtypes of addresses will thow an error if they are not valid (since that indicates a failure of the underlying communication), sending to the "null" address is not an error condition (see also: "Observers").<br /> <br /> '''Messengers''' are [[Messenger_Mibrary_Addresses|addresses]] that actually specify an underlying communication means. A QueueMessenger carries messages on a LabVIEW Queue, an Event Messenger uses a User Event, and a NotifierMessgenger wraps a Notifier. All these types impliment ("override") "Send.vi" of the parent "Send" class.<br /> <br /> Messengers have the additional methods of "Create" and "Destroy", which create and release the underlying communication reference.<br /> <br /> Note that from the point-of-view of the sender, all Messengers are interchangable, as they all impliment "Send" and "Valid". Only on the receiving end is their use different. QueueMessengers call "Receive.vi" to dequeue messages; EventMessengers are registered to an Event Structure, etc. This was the key initial motivation of Messenger Library: to make the sender of a message be able to use any communication method, as specified by the receiver.<br /> <br /> '''TCP Messengers:''' Basic Messengers only communicate locally inside a LabVIEW application or instance; TCP Messengers extend communiction between instances and/or computers, via TCP/IP. The implimentation pattern is Client-Server. There are TCP extensions of both Queue- and EventMessengers. In both cases, creating the Messenger starts up a TCP Server process, which accepts remote connections and forwards all received messages into the Queue or User Event. The receiving process uses the same API as it would with a local Queue- or EventMessenger. Note that this means conversion of a local-only component to a network-capable one is very easy and quick.<br /> <br /> The client side is provided by "RemoteTCPMessenger", which creates a client connection to a remote server (identified by a "service name" and ip address). Messages sent to this Messenger are sent to the remote process.<br /> <br /> The TCP Messengers are designed to work with the messaging patterns of Messenger Library. They automatically route replies and notification messages back through the same TCP connection as the initial request and registration messages. Note that this means that one must keep a RemoteTCPMessenger open in order to receive replies or notifications.<br /> <br /> '''Future Tokens''' are a special type of temporary single-use address. They are somewhat similar to "futures" of other languages, and generally serve to refer to the yet-to-be-received replies to a messages in the "Scatter-Gather" messaging pattern. A Future Token is an address that can only ever accept one message (sending to a Token twice results in an error), and receiving that message, via a "Redeem Token" method, destroys the Token. <br /> <br /> '''Observers:''' Observers are the "force multipliers" of addresses. They do not represent the actual means of sending messages themselves; instead, they "wrap" other addresses with extended functionality. Each Observer can contain multiple other addresses (copies of messages sent to the Observer are sent to each contained address) and, crucially, a "Translator", an object that alters messages. Via translators, an Observer can do things like relabel a message, or substitute a different message, or place the message inside an "Outer Envelope" (a message that contains another message). <br /> <br /> Observers have the key methods of "Create Observer", which allows the combination of multiple addreses into one Observer, and "Translate", a polymorphic VI that allows the specification of what mesage translation to do.<br /> <br /> The motivation behind "Observers" is to support "observation" of one process by another. This is to be contrasted with the more ususal "command" of one process of another. The difference is illustrated by thinking of process S sending a message to process R. If this message represents a "command" from S to R, then S must "know" R. R defines what commands it can handle, and S must know the command to send. Also, a failure to execute the command is a failure of S, since it has failed to get its command done. If, instead, the message represents the observation of S by R, then the "active" party is R. S is providing information that R chooses what to do with. It is S's job to provide the information, but it is not "commanding" R to do anything, and shouldn't need to know what "command" R should execute on receiving the message. R should define the command, and thus should control the command-element of the message (S supplies the data). "Observer" addresses support this kind of idea, as they allow the receiving process to pre-configure an address that defines aspects of the messages that it will receive.<br /> <br /> The most basic (and common) use of an Observer address is to configure the relabeling of a message. For example, a sender might send messages labelled "Temperature", but the observing process may provide an Observer address configured to relabel the message "Record Main Furnace Temperature", representing a command to itself of what to do with the data.<br /> <br /> Error-handling note: Observer address never produce an error when calling Send on them. As the sender is not instigating the observation, it should not be a failure to it if the observation has failed. An Observer Address will (silently) drop any contained address that produces an error on a Send call. This simplifies programming in situations where temporary processes observe a longer-running process, as "dead" addresses are automatically dropped. Note that this means that an Observer can change on calling "Send". Observer addresses are by-value collections containing by-reference Messengers, and should be treated as by-value objects.<br /> <br /> An Observer will read as "Valid" if any contained address is valid. <br /> <br /> '''Actor Address:''' The Actor Model describes a way of programming that uses independant processes that interact via passing messages. Actors can also be created ("launched") by other actors. LabVIEW comes with an existing implimentation of this idea, the "Actor Framework", but this is an alternate design based on Messeger-Library. Please note that there are very significamt differences between the two. <br /> <br /> An "actor" address class in Messenger Library identifies a VI (called "Actor.vi") that will be asynchronously run when the actor is "launched" (Launch method called on the actor address). After launch, the actor address contains a Messenger that will communicate with the new actor. Sending to the actor address sends the message to the message-handling loop withing the actor VI.<br /> <br /> Creating a new type of "actor" involves copying a template class. Several templates can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). The recomended templet is called "DEV". Note, however, that any message-handling loop design can be substituted, based on either a Queue- or EventMessenger.<br /> <br /> An "Actor Manager" debug tool is also installed under the Tools menu. This allows one to see what actor/VI launch what, and gives the ability to open all front panels or block diagrams.<br /> <br /> [[Category:Messenger Library]]<br /> <br /> [[Category:Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Messages&diff=6012 Messenger Library Messages 2019-02-18T17:49:16Z

<p>Drjdpowell: Messenger Library Messages</p> <hr /> <div>Messages in [[Messenger Library]] generally contain up to three things:<br /> <br /> * A "Label" that is a short text string that identifies the message. Examples: "Latest Temperature", "Start Measurement", "Shutdown".<br /> * Data of some type. There is more that one type of data message, but most messages hold data in a Variant.<br /> * (Optional) A "Reply Address", which is the [[Messenger Library Addresses|address]] where a reply to this message should be sent.<br /> <br /> Messages have Write and "Read" (aka Extract) methods to add and access Label and Data. There is also a Reply method for the message handler to send a reply to the Reply Address. <br /> <br /> '''Note on Error Messages:''' an "Error Message" is a special subtype of Message who's Data is an Error Cluster. On any "Read" of an Error Message, the contained Error Cluster will be output on the Error out terminal of the Read method. This connects Error Messages to the stadard LabVIEW error-handling design of the passed Error Cluster. Similarly, as responsibility for directing a reply belongs to the sender of the original message, if there is an error input on the "error in" terminal of any "Reply" method, then an error message will be sent (instead of the regular reply). This design effectively allows simple error handling Request-Reply messaging interactions, with the Requestor receiving the error cluster.<br /> <br /> See also [[Messenger Library]] and [[Messenger Library Addresses|Addresses]].<br /> <br /> [[Category:Messenger Library]]<br /> <br /> [[Category:Messenger Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library_Addresses&diff=6011 Messenger Library Addresses 2019-02-18T17:45:18Z

<p>Drjdpowell: Messenger Library Addresses</p> <hr /> <div>'''Addresses''' in [[Messenger Library]]<br /> <br /> At its simplest, an "address" in [[Messenger_Library]] is just something to which one can send a message. But it is also Messenger Library's primary feature, as there are many types of addresses that allow important functionality and high flexibility. They are implemented as a set of LVOOP classes, but detailed knowledge of LVOOP is not needed to use them.<br /> <br /> Here is a listing of the different types of addresses.<br /> <br /> '''Send''' is the most generic class ("parent" class); any other address can be carried on a "Send"-class wire. "Send" defines the key method (subVI) of an address: "Send.vi", to send a message. There are a large number of extensions of this core method, designed to support the use of various messaging patterns. For example, to send a message and wait for a reply. <br /> <br /> A secondary method of the "Send" class (and thus of all addresses) is "Valid.vi", which indicates if a message sent to an address will actually go somewhere. An address of the "Send" class itself serves as a "null" address, and thus messages sent to it do not go anywhere and so it is not "Valid". Note that being not "valid" is not the same as there being an error on trying to send to an address. Though most subtypes of addresses will thow an error if they are not valid (since that indicates a failure of the underlying communication), sending to the "null" address is not an error condition (see also: "Observers").<br /> <br /> '''Messengers''' are [[Messenger_Mibrary_Addresses|addresses]] that actually specify an underlying communication means. A QueueMessenger carries messages on a LabVIEW Queue, an Event Messenger uses a User Event, and a NotifierMessgenger wraps a Notifier. All these types impliment ("override") "Send.vi" of the parent "Send" class.<br /> <br /> Messengers have the additional methods of "Create" and "Destroy", which create and release the underlying communication reference.<br /> <br /> Note that from the point-of-view of the sender, all Messengers are interchangable, as they all impliment "Send" and "Valid". Only on the receiving end is their use different. QueueMessengers call "Receive.vi" to dequeue messages; EventMessengers are registered to an Event Structure, etc. This was the key initial motivation of Messenger Library: to make the sender of a message be able to use any communication method, as specified by the receiver.<br /> <br /> '''TCP Messengers:''' Basic Messengers only communicate locally inside a LabVIEW application or instance; TCP Messengers extend communiction between instances and/or computers, via TCP/IP. The implimentation pattern is Client-Server. There are TCP extensions of both Queue- and EventMessengers. In both cases, creating the Messenger starts up a TCP Server process, which accepts remote connections and forwards all received messages into the Queue or User Event. The receiving process uses the same API as it would with a local Queue- or EventMessenger. Note that this means conversion of a local-only component to a network-capable one is very easy and quick.<br /> <br /> The client side is provided by "RemoteTCPMessenger", which creates a client connection to a remote server (identified by a "service name" and ip address). Messages sent to this Messenger are sent to the remote process.<br /> <br /> The TCP Messengers are designed to work with the messaging patterns of Messenger Library. They automatically route replies and notification messages back through the same TCP connection as the initial request and registration messages. Note that this means that one must keep a RemoteTCPMessenger open in order to receive replies or notifications.<br /> <br /> '''Future Tokens''' are a special type of temporary single-use address. They are somewhat similar to "futures" of other languages, and generally serve to refer to the yet-to-be-received replies to a messages in the "Scatter-Gather" messaging pattern. A Future Token is an address that can only ever accept one message (sending to a Token twice results in an error), and receiving that message, via a "Redeem Token" method, destroys the Token. <br /> <br /> '''Observers:''' Observers are the "force multipliers" of addresses. They do not represent the actual means of sending messages themselves; instead, they "wrap" other addresses with extended functionality. Each Observer can contain multiple other addresses (copies of messages sent to the Observer are sent to each contained address) and, crucially, a "Translator", an object that alters messages. Via translators, an Observer can do things like relabel a message, or substitute a different message, or place the message inside an "Outer Envelope" (a message that contains another message). <br /> <br /> Observers have the key methods of "Create Observer", which allows the combination of multiple addreses into one Observer, and "Translate", a polymorphic VI that allows the specification of what mesage translation to do.<br /> <br /> The motivation behind "Observers" is to support "observation" of one process by another. This is to be contrasted with the more ususal "command" of one process of another. The difference is illustrated by thinking of process S sending a message to process R. If this message represents a "command" from S to R, then S must "know" R. R defines what commands it can handle, and S must know the command to send. Also, a failure to execute the command is a failure of S, since it has failed to get its command done. If, instead, the message represents the observation of S by R, then the "active" party is R. S is providing information that R chooses what to do with. It is S's job to provide the information, but it is not "commanding" R to do anything, and shouldn't need to know what "command" R should execute on receiving the message. R should define the command, and thus should control the command-element of the message (S supplies the data). "Observer" addresses support this kind of idea, as they allow the receiving process to pre-configure an address that defines aspects of the messages that it will receive.<br /> <br /> The most basic (and common) use of an Observer address is to configure the relabeling of a message. For example, a sender might send messages labelled "Temperature", but the observing process may provide an Observer address configured to relabel the message "Record Main Furnace Temperature", representing a command to itself of what to do with the data.<br /> <br /> Error-handling note: Observer address never produce an error when calling Send on them. As the sender is not instigating the observation, it should not be a failure to it if the observation has failed. An Observer Address will (silently) drop any contained address that produces an error on a Send call. This simplifies programming in situations where temporary processes observe a longer-running process, as "dead" addresses are automatically dropped. Note that this means that an Observer can change on calling "Send". Observer addresses are by-value collections containing by-reference Messengers, and should be treated as by-value objects.<br /> <br /> An Observer will read as "Valid" if any contained address is valid. <br /> <br /> '''Actor Address:''' The Actor Model describes a way of programming that uses independant processes that interact via passing messages. Actors can also be created ("launched") by other actors. LabVIEW comes with an existing implimentation of this idea, the "Actor Framework", but this is an alternate design based on Messeger-Library. Please note that there are very significamt differences between the two. <br /> <br /> An "actor" address class in Messenger Library identifies a VI (called "Actor.vi") that will be asynchronously run when the actor is "launched" (Launch method called on the actor address). After launch, the actor address contains a Messenger that will communicate with the new actor. Sending to the actor address sends the message to the message-handling loop withing the actor VI.<br /> <br /> Creating a new type of "actor" involves copying a template class. Several templates can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). The recomended templet is called "DEV". Note, however, that any message-handling loop design can be substituted, based on either a Queue- or EventMessenger.<br /> <br /> An "Actor Manager" debug tool is also installed under the Tools menu. This allows one to see what actor/VI launch what, and gives the ability to open all front panels or block diagrams.<br /> <br /> [[Category:Messenger_Library]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Messenger_Library&diff=6010 Messenger Library 2019-02-18T17:40:12Z

<p>Drjdpowell: Create page for Messenger Library</p> <hr /> <div>'''Messenger Library''', [http://sine.ni.com/nips/cds/view/p/lang/en/nid/213091 a package on the LabVIEW Tools Network], is an extensive library for passing messages between parallel processes. Simplifies communication, by allowing the message sender to use any method provided by the receiver. Supported communication methods include simple queues, user events, and notifiers, as well a more complex channels such as a TCP server and client. In addition, one can configure simple forwarding addresses (“Observers"), which can send messages to multiple destinations, optionally with modifications such as adding a prefix to the message label, relabelling, or substituting a different message.<br /> <br /> Messaging patterns supported include request-reply (asynchronous or synchronous), where the reply is sent to a "reply address" attached to the request, and register-notify, where one process sends a registration message to another in order to subscribe to a series of updates. Also supports scatter-gather, the gathering of replies from multiple senders into an array of messages.<br /> <br /> An option framework for dynamically-launched VI "actors" is also provided, including example templates, which can be accessed via the Tools menu (from an open Project, select Tools>>Messenger Library>>Create Actor from Template..). An "Actor Manager" debug tool is also installed under the Tools menu.<br /> <br /> Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the [https://en.wikipedia.org/wiki/Actor_model Actor Model]).<br /> <br /> '''Info'''<br /> <br /> •[[Messenger_Library_Addresses|Addresses]]<br /> <br /> •[[Messenger_Library_Messages|Messages]]<br /> <br /> For support please see [https://lavag.org/topic/16360-lvtn-messenger-library/ CR Messenger Library] and [https://bitbucket.org/drjdpowell/messenging/issues?status=new&status=open Bitbucket Issue Tracker].<br /> <br /> Compatible LabVIEW Versions: >= 2013.<br /> <br /> This Package depends on this other package: JDP Science Common Utilities, Cyclic Table Probes, JKI Statemachine, OpenG Zip Tools<br /> <br /> [[Category:Add-on Tools]]<br /> [[Category:Frameworks]]</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=GDevCon&diff=6009 GDevCon 2019-02-18T17:18:37Z

<p>Drjdpowell: Added GDevCon1 Youtube video link.</p> <hr /> <div>[[File:Gdevconsmalllogo.jpg|frameless|right]]<br /> GDevCon is an independent organisation dedicated to creating a series of events that is all about world-class graphical programming, organised by the community for the community.<br /> <br /> Established in 2017, GDevCon held their first conference in Cambridge, UK, on 4-5th September 2018 at Murray Edwards College. The event was attended by over 140 developers, and actually had to be moved from their first venue, Girton College, to accommodate the higher than expected demand for tickets.<br /> <br /> The event does not mandate any level of certification, unlike the CLA Summits, enabling access to developers who don't choose to attain any formal accreditation.<br /> <br /> Based on the success of GDevCon#1, GDevCon intend to build on the format and organise additional conferences.<br /> <br /> Visit the [http://www.gdevcon.com GDevCon] website to learn more about GDevCon and their future conferences.<br /> <br /> A full set of presentation videos (of very high AV quality) are [https://www.youtube.com/channel/UCJ0jhJNGk9kjc12npjy6b4g/videos available on YouTube].</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Talk:Actor_Oriented_Design_Patterns&diff=5952 Talk:Actor Oriented Design Patterns 2019-01-09T21:10:35Z

<p>Drjdpowell: </p> <hr /> <div>This seems to be "NI Actor Framework" Design Patterns, rather more-general ones that work with any actor-oriented coding style or framework. -- drjdpowell</div>

Drjdpowell https://labviewwiki.org/w/index.php?title=Talk:Actor_Oriented_Design_Patterns&diff=5951 Talk:Actor Oriented Design Patterns 2019-01-09T21:10:13Z

<p>Drjdpowell: Created page with "This seems to be "NI Actor Framework" Design Patterns, rather more-general ones that work with any actor-oriented coding style or framework."</p> <hr /> <div>This seems to be "NI Actor Framework" Design Patterns, rather more-general ones that work with any actor-oriented coding style or framework.</div>

Drjdpowell