Jump to content

drjdpowell

Members
 View Profile  See their activity

  • Posts

    1,994

  • Joined

  • Last visited

  • Days Won

    183

 Content Type 

Everything posted by drjdpowell

  1. drjdpowell
    You can use SQLite entirely in memory by using “:memory:” as the filename. Also note that SQLite uses a caching mechanism that makes it effectively in-memory as far as reading goes, as long as the database is smaller than the cache size (2 MB by default).
  2. drjdpowell
    Property nodes are notoriously slow. There’s an advanced technique called “Defer Panel Updates” that can be used to speed things up.
  3. drjdpowell
    You could consider a hierarchal structure of nested LVOOP objects similar to the one we used in the JSON package. Another thought would be SQLite, though I have never done a hierarchal structure in it so it might be more complicated. But you would have the advantage of fast lookup on URLs and just about anything else you wanted fast lookup of.
  4. drjdpowell
    I assume you have no control over the format of the message? Objects are best flattened/unflattened upwards from child to parent, which means the child information should precede parent information in the message. Your messages are the opposite. I suspect you can still parse it without “downcasting”. You’d have to generate a “type” object to call a parse method, but rather than set the private data of the parent type, the parse method would call further parse methods on the remaining bytes to actually return the subclass. So the parse method called on the “type” object would actually return a different object of the final subclass. Does that make sense? It’s a bit like the onion skin of recursion; instead of calling methods one after the other, you call them one inside the other, going all the way down to the final subclass, and then rising back up through the inheritance hierarchy setting the private data of each level. — James
  5. drjdpowell
    I need to install the latest LabVIEW version to look at your code, but some of what you describe sounds very similar to what I’ve done. My Transports are called “Messengers”, and I have “Actor” objects that contain a Messenger that is the method to send messages to a process running in parallel. But other stuff mystifies me. It sounds like you have message classes as the children of your Process classes; but aren’t messages and processes entirely different things.
  6. drjdpowell
    Could you explain your use case? I’m having a hard time grasping what you are trying to do, so I can’t help.
  7. drjdpowell
    Didn’t really follow the description of the problem (you’re sending message classes over a CAN bus?) but the fact that you have a reference (the CAN bus) that is needed by multiple processes (the zones) suggested there should be one dedicated process to encapsulate that reference. It shouldn’t be the Zone Manager because that has a well-defined job (managing zones) that is independent of CAN bus. So you need a “CAN bus actor/active process/whatever” that is the gatekeeper of the CAN bus and forwards all the messages.
  8. drjdpowell
    By “easy” I meant dead easy. Google instructions, run two installers, run LabbitMQ examples. Now, configuring a cross-machine, robust-against-failure message broker would be a whole higher level of complexity, but then John’s N-client, M-server system with the requirement of robustness is going to be complex regardless. Can one do it the poor man’s way; have a reentrant subVI that waits on a Shard Variable and forwards message to a User Event? I wrote a TCP server the other way, using dynamically-launched processes, and it actually came together quite well, and seems scalable (though I have yet to had the use case to really test it). There is a “TCP Listener Actor” that waits for connections and launches a “TCP Connection Actor” to handle each one. The Connection Actors forward incoming messages to a local queue (or User Event). As each actor only has one thing to deal with, they are conceptually simple, and don’t need to poll anything (this is in my “Messenging” package in the CR if your interested). An advantage of making your own TCP server is that you can customize things; my server is designed to seamlessly support my messages, which carry reply addressed (callbacks) and have a publish-subscribe mechanism. Supporting both with Shared Variables would (I suspect) be just a complex in the end as going straight to TCP. — James
  9. drjdpowell
    Well, that idea didn’t last very long...
  10. drjdpowell
    I played around with RabbitMQ a bit yesterday. Getting a RabbitMQ broker installed and running was quite fast and easy. LabbitMQ needs polishing and is lacking in documentation, but seems pretty solid. RabbitMQ should do publish-subsribe very cleanly, especially with its “topic” exchange type where one can specify the messages one wants by pattern. And at least according to the documentation, one can cluster multiple computers into a single message broker, providing redundancy against single-point failure (though with the possibility on failure of some messages being delivered twice). — James
  11. drjdpowell
    Release the Notifier in your “stop” event case in the top loop; that will cause an error in the “wait on notification" in the bottom loop, causing it to shutdown (since the error is wired to the stop of the loop). That was the use case of the original post; to start and stop listening on FIFO for incoming data. I use secondary loops like this for things I have to wait on, such as a TCP connection. If instead you want a second loop to execute commands from the primary loop, then you are better off using a queue. But you can still use the destruction of the queue in the primary loop to trigger shutdown of the secondary.
  12. drjdpowell
    See this discussion, where I suggested the Actor Framework adopt mje’s mitigation of the issue (which he referred to above). Wait, sorry. You mean for using VI Server for messaging, rather than dynamic launching of VIs. I don’t know what to do about that.
  13. drjdpowell
    Well, currently they do let wiring to an indicator define the data type. Unfortunately it has to be directly wired, with no other structure in between, which limits its usefulness: And you still need the “Variant to Type” primitive. But where would type-conversion errors go otherwise? Also, the first thing I would do, if my idea was implemented, would be to make a “Variant to Numeric with Units” VI that would enforce matching units between the Variant and the supplied type. Your idea wouldn’t help with that.
  14. drjdpowell
    I’ve proposed it on the Idea Exchange.
  15. 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
  16. 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.
  17. drjdpowell
    Also see the NI examples “DataServerUsingStartAsynchronousCall” or “DataServerUsingReentrantRun”.
  18. 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.
  19. 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...
  20. drjdpowell
    Why are you using VI Server, rather than other communication methods (like TCP, Network Steams or Shared Variables)?
  21. 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.
  22. 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.
  23. drjdpowell
    Latest version, as a VIPM package, posted to the CR.
  24. drjdpowell
    More information about "Messenger Library"

    Version 2.1.7

    2,253 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)
  25. 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)  
×
×
  • Create New...

Important Information

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

  I accept