Jump to content
News about the LabVIEW Wiki! Read more... ×


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by drjdpowell

  1. I also use 2013 as my base for most reuse packages. It has the new tunnel options including the valuable "conditional" (fixed over 2012 to have good performance) and Variant Type VIs that are about 100 times faster (than in 2011 at least). The next really useful feature is VIMs in 2017.
  2. drjdpowell

    Rebar/Rust and G Community

    A note on the discussion about LabVIEW refunms, such as Queues and the like. These are "owned" by the Top-level VI that created them, and are cleaned up when that Top-level VI goes idles. This could be the whole App, but async-called VIs are all their own "Top Level", so if your app is made up of many async called VIs ("modules", "actors" or whatever) then refnums have a quite reasonable defined lifetime, the lifetime of the creating module/actor/async-thing. This behaviour is reliable; I know because I routinely rely on it to trigger automatic shutdown of async running things when their callers stop for any reason.
  3. drjdpowell

    Rebar/Rust and G Community

    You should kudo this then: Means to register a DVR-cleanup callback for use when DVR released when VI goes idle. This would allow DVRs to wrap all dll pointers, with proper cleanup regardless of how the VI stops.
  4. drjdpowell

    [LVTN] Messenger Library

    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.*** 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 LabVIEW Version  
  5. drjdpowell

    [LVTN] Messenger Library

    I've never looked at rti-dds, but could you implement a "reply address" with it? Instead of a blocking command-reply, you could do an async command-reply-continuation. I talk about this messaging pattern in this GDevCon talk: https://youtu.be/HIuzY_Bs7BI (staring at 7:38). Regarding Event support, you can always write a reusable forwarding loop, which listens to an rti-dds whatever-they-call-it and posts the messages to a User Event. I'm a believer in not cobling together different communication methods, and if I had your use case I would try and use only one package to implement it, adding capability if needed (though in my case that package would be Messenger Library, of course).
  6. drjdpowell

    [LVTN] Messenger Library

    You're certainly using the TCPMessengers in an unanticipated way. Why are you not just using your RTI-DDS stuff for everything? Mixing multiple different communication systems can be problematic.
  7. drjdpowell

    [LVTN] Messenger Library

    What's wrong with 52 clones? That's not a large number.
  8. drjdpowell

    Register a notifier as a user event

    This is very useful behavior, as it simplifies initialization code quite a lot, and eliminates almost all worries about "who starts first" among communicating modules. I have a similar feature in Messenger Library; I call it a "State Notification" as distinct from an "Event Notification", as the type of data where one needs the most recent value is state data.
  9. View File Cyclic Table Probes A package for creating custom probes with "history"; showing the last N values rather than just the latest. Values are displayed in a cyclic table, which wraps around automatically when it reaches the bottom of the display window. Developed to support messaging systems, where messages can be handled too quickly for the eye to see with a last-value probe. Included are some standard probes, for strings, variants, objects, and some numerics. Also included is a "Text Variant" probe, for messaging using a cluster of such, and a "JKI State Queue" probe for use in designs using the JKI "state machine" template (see image). But the expected use case is for very easily creating custom probes for whatever messages one is using (just modify one of the included probes). Also includes "Quick Timer" probes to rapidly time execution of portions of code to accuracies of as low as 10 microseconds. Now hosted on the LabVIEW Tools Network. Requires VIPM 2017 or later for install. Submitter drjdpowell Submitted 11/16/2013 Category Custom Probes LabVIEW Version 2013 License Type BSD (Most common)  
  10. drjdpowell

    [CR] Cyclic Table Probes

    I've never even tried them on an debugged executable. But it is likely the same issue that causes crashes on RT: use of a pane resize event to detect when the User resizes the probe. I now conditionally disable that on RT. I'll investigate when I get a chance.
  11. drjdpowell

    [LVTN] Messenger Library

    I'm afraid I have no answer as how to test actual UI code, other than an actual set of tests done by a person. That is quite a big problem. However, I commonly do have business logic in some kind of subVI or class method, and that can be unit tested. So for example, I can test if the "Save Data" and "Load Data" methods properly write/read the data, but I can't test if the "Save" and "Load" Menu items actually call those method correctly. One can, though, test the message-interaction of an actor in a Unit Test. And one can use Queries to help do this quite easily, even if the actor, in actual use, is interacting much more asynchronously. Below is a part of such a test of a ModbusTCP Server. I included a diagram of the actor interactions at top (a secondary value of unit tests is that they allow one to demonstrate the use of a component in a simplified setup). Note that I quickly made a simple message loop to stand in for the "Device", needed to handle some of the commands sent over Modbus (the actual actor that is the Device in the application is much more complicated). Not shown, off the bottom of the screen, I use the Plasmionique Modbus Library as a test Modbus client to run a series of communication tests with the server. Note, though that this is an example of an Actor that involves no UI at all. If it had UI elements, I could not test that automatically.
  12. drjdpowell

    SQLite for OpenG

    Hello, I’ve been working with SQLite for a logging application and I thought I might offer my SQLite LabVIEW wrapper for possible inclusion in OpenG. There are at least two other implementations out there, both with licensing restrictions, but it would be nice to have this in OpenG as I think SQLite is a major addition to the capabilities of LabVIEW. Below is a zip file; it includes a couple of examples. SQLite LabVIEW.zip LabVIEW 2011. SQLite dll for Windows (32-bit) included. NOTE: more recent version now in the Code Repository. An (incomplete) menu: Here is the block diagram of Example2: There are basically two use modes: (1) calling “Execute SQL” on a Connection to run SQL scripts (and optionally return 2D arrays of strings or variants from an SQL statement that returns results); and (2) “Preparing" a single SQL statement and executing it step-by-step explicitly. The advantage of the later is the ability to “Bind” parameters to the statement, and get the column data back in the desired datatype. The “Bind” and “Get Column” VIs are set as properties of the “SQL Statement” object, for convenience in working with large numbers of them. This package closely follows the SQLite C/C++ interface and is intended to facilitate the execution of SQL scripts, rather than provide VIs that substitute for SQL statements. Thus there are no VIs for creating tables, triggers, etc. The SQLite website provides extensive documentation of SQL and the C/C++ interface. The only differences from the C/C++ interface are: 1) “Reset” and “Finalize” do not return the error code from the previous “Step” (as this would be both unnecessary an confusing in LabVIEW) 2) The default busy timeout for waiting for a database file that is temporarily “busy” due to another connection is set at 5000 ms, rather than 0 ms. 3) I created a “First Step” VI that wraps “Step”, intended to be the first call on Step that actually execute the statement (further calls to Step increment through return result rows). I did this to allow future potential retry logic in “First Step”, and to have a clearer set of VI icons showing the difference between executing a statement and stepping through result rows. As I said, it would be really nice to have an SQLite interface in OpenG. I’ve only just scratched the surface of what can be done with SQLite (see, for example, the “Full Text Search” and “R*tree” extensions). — James
  13. drjdpowell

    LabView Memory Full Error

    Do you have the Desktop Execution Trace utility? The first thing I would do if I had an out-of-memory would be to use this to look for "leaked" references. I once had a failure after 4 weeks of running that was caused by an unclosed .NET reference in a once-a-second loop.
  14. drjdpowell

    [CR] JSONtext

    View File JSONtext Package for working with JSON. Uses high-speed text parsing, rather than building an intermediate representation as with prior LabVIEW JSON libraries (this is much faster). Allows easy working with "subitems" in JSON format, or one can convert to/from LabVIEW types. Uses the new "malleable VIs" of LabVIEW 2017 to convert to any LabVIEW type directly. JSON text makes use of a form a JSON Path notation, allowing easy and rapid access to the subitems of interest. Requires LabVIEW 2017 and install by VIPM 2017 or later. Original conversation about JSONtext. Now on the LabVIEW Tools Network. Copyright 2017 JDP Science Limited Submitter drjdpowell Submitted 08/02/2017 Category General LabVIEW Version 2017 License Type BSD (Most common)  
  15. drjdpowell

    [CR] JSONtext

    Thanks Elmar. Issue 27.
  16. drjdpowell

    LabVIEW Not Responding

    Just several seconds, but with fewer actors. I will try and investigate when I next see it.
  17. drjdpowell

    LabVIEW Not Responding

    I have noticed that, though not enough to bother me much. I've assumed it was a LabVIEW bug in the edit environment. I haven't investigated it because it can't affect executables (they only run once). BTW, is that 60 actor types, or 60 running instances?
  18. drjdpowell

    [CR] JSONtext

    Can you explain your use case, and why the public API is inadequate for it?
  19. I’m hoping to add some sample projects to my “Messenging” package, and I thought it would be easy and instructive to rework one of NI’s templates, “Continuous Measurement and Logging”, as it is already somewhat actor-like with three communicating modules. Attached is a (back-saved for 2011) copy of the NI project, with my version included (run “Main.vi” for the original, “Main.lvclass:Actor.vi” for my version). I kept the basic functionality the same, but couldn’t resist changing some of the UI (in the old code, “Main” controls the UI; in the new code, published state messages from the Acquisition and Logging Actors set the UI). Continuous Measurment and Logging with Messenging.zip Any comments appreciated. Is this example less clear than the NI original? Why? How could I improve it? In particular, is code like this (the most complicated interaction, I think) understandable without heavy documentation? It’s a “Start Logger, then Start Acquisition, then Unset the Busy Cursor” three-actor chain message: I’m thinking of making a “Send Chain Message” subVI (that accepts arrays of addresses and message labels) to replace the above code. — James
  20. Hi Osamu, This is not an Actor Framework thing. "Actor" is a computer-science term that is used by dozens of frameworks it multiple languages. This example uses "Messenger Library", available on the LabVIEW Tools Network or here on LAVA.
  21. Here's a minirant to NI I made in May: Rounded corners on icons could be useful, if it indicates something, but rounding every single graphic element is silly.
  22. That was my impression; changing everything for no good reason rather than retaining continuity with the past but changing a few keys things where there is real benefit.
  23. They need a killer feature, some great thing not in regular LabVIEW. So far I haven't identified such a feature.
  24. drjdpowell

    How do you model this?

    You're a bit late for this conversation, though the topic is still very relevant today.
  25. View File SQLite Library Introductory video now available on YouTube: Intro to SQLite in LabVIEW SQLite3 is a very light-weight, server-less, database-in-a-file library. See www.SQLite.org. This package is a wrapper of the SQLite3 C library and follows it closely. There are basically two use modes: (1) calling "Execute SQL" on a Connection to run SQL scripts (and optionally return 2D arrays of strings from an SQL statement that returns results); and (2) "Preparing" a single SQL statement and executing it step-by-step explicitly. The advantage of the later is the ability to "Bind" parameters to the statement, and get the column data back in the desired datatype. The "Bind" and "Get Column" VIs are set as properties of the "SQL Statement" object, for convenience in working with large numbers of them. See the original conversation on this here. Now hosted on the NI LabVIEW Tools Network. ***Requires VIPM 2017 or later for install.*** Submitter drjdpowell Submitted 06/19/2012 Category Database & File IO LabVIEW Version 2011 License Type BSD (Most common)  

Important Information

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