Leaderboard
Popular Content
Showing content with the highest reputation on 10/30/2019 in all areas
-
Version 2.1.7
2,245 downloads
Advanced messaging made simple! Messenger Library is a library for message passing using a variety of powerful Messaging Patterns, and a set of Templates for easily creating parallel modules to interact with those Patterns. Together, these comprise a powerful and deep framework for rapid application development. Communication patterns supported and other features include: -- Request-and-wait-for-Reply -- Asynchronous Request-Reply, where the reply is sent to a "reply address" attached to the request -- Scatter-Gather: Requests sent to multiple addresses, with all Replies gathered together in order -- Register-Notify, where one process sends a registration message to another in order to subscribe to published messages. -- Future Token, a reference to a future Reply not yet made -- Asynchronous Dialog: query the User without blocking (User's response sent as a message) -- Delayed Request: message sent with a set asynchronous delay -- Metronome, a source of precisely-timed periodic messages -- Timeout Watchdog: trigger an action if something expected doesn't happen Freely intermix communication by Queues, User Events or Notifiers. First-class support for TCP communication, allowing easy interaction of multiple executables using any of the Messaging Patterns. Also supports UDP, including multicast. Module Templates are simple, consisting of a single VI and a single loop, and are robust against race conditions (unlike the more complex "Producer Consumer" NI templates) Includes two utilities under the menu "Tools>>Messenger Library": -- a utility to create a new parallel modules from a set of well-tested templates -- a Manager utility to see all running Modules Multiple Examples are included. Of particular interest are: -- An example developed over a series of YouTube videos (linked below) -- A redo of the standard "Continuous Measurement and Logging" Example using Messenger Library -- TCP Reconnecting Example, showing easy network communication with handling of temporary disconnects Note: Messenger Library is intended to promote actor-oriented design, but is not related to the Actor Framework. ***Introductory Videos are on a YouTube channel.*** ***A great summary of many Messenger Library sources, provided by Bob W Edwards*** JDP Science Tools group on NI.com. Original conversation on this work is here. Now hosted on the LabVIEW Tools Network (but note that the latest version will often be on LAVA)1 point -
It's called bindings to non native libraries and functionality. It's a standard problem in every programming environment. The perceived difficulty has always a direct relation with the distance of the programming paradigme of the calling environment to the callee. In C it is almost non existent, since you have to bother about memory management, thread management, etc, etc. no matter what you try to call. In higher level languages with a managed environmen like LabVIEW or .Net, it seems a lot more complicated. It isn't really but the difference between what you normally have to do in the calling environment is much bigger when calling such non native entities. And each environment has of course a few special subtleties. The one currently causing me a lot of extra work for the OpenG ZIP library is the fact that LabVIEW always has and still does assume that STRING==BYTEARRAY and that encoding does not exist in a LabVIEW platform. A ZIP file can contain encoding in the stored file names and nowadays regularly does. So the strings that are returned as filenames in an archive need to be treated with care. Except when I then try to turn it into a LabVIEW path to create the file, the whole care falls into the water as the filepath either will alter the name to something else or even possibly attempt to create a file with invalid characters. So the solution is to replace the Open File, Create File and Create Directory among with some others functions (like Delete File) with my own version that can handle the paths properly. Great idea except that LabVIEW does not document and hence not guarantee how the underlaying file system object is mapped into a file refnum. So in order to be safe here I also have to create the Read File, Write File, Close File, File Size and such functions.All doable but serious work to do. I'm basically rewriting the LabVIEW File Manager and Path Manager functionality for a considerable amount.1 point