Jump to content

drjdpowell

Members
 View Profile  See their activity

  • Posts

    1,981

  • Joined

  • Last visited

  • Days Won

    183

 Content Type 

Everything posted by drjdpowell

  1. drjdpowell
    I’ve proposed it on the Idea Exchange.
  2. drjdpowell
    One thing to possibly look into is LabbitMQ, a LabVIEW wrapper of RabbitMQ, a message broker system. An already developed message system might have addressed many of your issues. Haven’t tried it myself (has anyone used LabbitMQ?) so I can’t tell how much effort it would be to set up. — James
  3. drjdpowell
    I was going to go into that, but bailed with a “…" Maybe you should use a central message “broker”, with all servers and clients connecting via the broker. Then there is only one connection per process. I think Shaun’s Dispatcher works this way, if I recall right.
  4. drjdpowell
    Also see the NI examples “DataServerUsingStartAsynchronousCall” or “DataServerUsingReentrantRun”.
  5. drjdpowell
    There is only one listener. It listens for clients on a port and creates connections (one for each connected client). Those connections can be serviced either by polling through them or by dynamically spawning a connection handler for each. But there is only one listener.
  6. drjdpowell
    One can do a “Server” without polling, if one dynamically spawns new processes to handle each connection. Though dynamic spawning brings one right back to the root loop problem...
  7. drjdpowell
    Why are you using VI Server, rather than other communication methods (like TCP, Network Steams or Shared Variables)?
  8. drjdpowell
    I sure wish this worked with Variants. In fact, I may post that as an idea on the Idea Exchange; a “Preserve Run-Time Type” function for Variants.
  9. drjdpowell
    Illustration: A Child object on a Parent-type wire being cast into a "target" Grandchild object on a Parent-type wire will produce an error with PRTC (note that the “stock downcast” works on wire types, not the actual objects). The point of this is that the compiler can be certain that the object coming out of the PRTC is the same as the target object; this means it can trace through the input wire type to the output of the subVI at edit time. So if you write a subVI with Parent inputs and outputs, and connect a grandchild wire to the input, the output wire will take on grandchild type. See below an example subVI I made recently using PRTC; note that I can “pass through” wires of different object types (the actual subVI uses LVObject inputs and outputs). I should add that the PRTC is only needed if the compiler cannot already tell that the object out is the same as the object in. In my subVI above, I’m receiving an object in a message and using PRTC to “cast” it as an object of a specific type. Inside the subVI, the wires are LVObject, so the stock cast functions do nothing. It is confusing at first.
  10. drjdpowell
    Latest version, as a VIPM package, posted to the CR.
  11. drjdpowell
    More information about "Messenger Library"

    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)
  12. drjdpowell
    View File Messenger Library An extensive library for passing messages between parallel processes. Generalizes the communication method, allowing the message sender to use the method provided by the receiver. Supported communication methods include wrappings of 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. Communication 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. 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. Please note that this package has nothing directly to do with the NI Actor Framework (other than both packages are influenced by the Actor Model). ***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) ***NOTE: latest versions require VIPM 2017 or later to install.*** Submitter drjdpowell Submitted 11/27/2012 Category LabVIEW Tools Network Certified License Type BSD (Most common)  
  13. drjdpowell
    That’s because the second time around your are setting N=6, so the FOR loop needs to execute six times, but the queue only holds 5, so it gets stuck waiting.
  14. drjdpowell
    Actually, he needs that to throttle the producer loop to always provide “buffer” number of elements to the consumer loop. Instead, he has a bug in setting the number of iterations of the inner FOR loop (it should be “buffer”-1); removing that, the “buffer full” locals, and adding a Val(signal) property makes the code work. But this is all academic as... This is a very over-engineered way of doing what could be done with one simple loop with “Array Subset” in it. I recommend the OP start from scratch after resolving not to use any local variables, queues, or event structures. — James
  15. drjdpowell
    Should that meaningfully be called a “leak” then?
  16. drjdpowell
    LVOOP is by value, with the values on the wires, so if there are no terminals there is no object.
  17. drjdpowell
    The JSON package currently depends on four OpenG packages: Data, Array, String, and Error. The array stuff is only used in one place that I’d like to rewrite anyway, so it is only three packages that are required. And the variant-handling stuff is widely applicable; if I wrote Variant-based APIs to be “self contained”, I would quickly wind up in a situation where I have multiple non-identicle sets of variant-handling VIs installed on my machine. Not ideal. Switching to using the off-palette VariantDataType VIs installed with LabVIEW is one option, but then if NI hasn’t put it on the palette, don’t you need to gain approval for that?
  18. drjdpowell
    I’m pretty sure you’ve got some non-UI thread substitutes lying around. I think you posted one once.
  19. drjdpowell
    Changing it programmatically in the "Mouse Down?” event doesn’t work?
  20. drjdpowell
    Theoretically, the not-on-the-pallet VIs in vi.lib\Utility\VariantDataType should blow the OpenG stuff out of the water, as OpenG has to flatten the data to access it (expensive), but my only experience with the VariantDataType Vis is that they are glacially slow.
  21. drjdpowell
    OK, but to me it seems silly for anyone to avoid OpenG yet use this (far, far less tested through experience) third-party open-source software. I’d rather offer the whole package to OpenG. Now, do it with higher performance and you’ll get me interested.
  22. drjdpowell
    Shaun, I am looking at the VIPM package that Ton and I have put together. Shall we divide into two packages, one not dependent on OpenG and one that contains all the Variant stuff? So people who can’t use OpenG can still use the core functions or your extended API? I can do that just be replacing one OpenG function, Trim Whitespace, in the core (can we use your “Fast Trim” instead). Ton, You currently have the package installing under LAVA; don’t we need a LAVA tools approved package before doing that?
  23. drjdpowell
    Ah, I though your “variant arguments” were variant attributes and couldn’t understand how you were doing that.
  24. drjdpowell
    Hi Ton, I cannot, for the life of me, tell how you got this behavior before (where in the code were the attributes extracted?) but it seems like a good idea so I added it to “Variant to Cluster”. Though I made an empty variant with no attributes “null”, rather than an empty object. Note that a non-empty variant will ignore the attributes and convert the contained value instead.
  25. drjdpowell
    Was it really “half-valid”, or just invalid but non-zero?
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.

  I accept