drjdpowell

Added a new version 1.8.4.85 to the Code Repository. Tested that this works between 2011 and 2017 using the TCP Client/Server example that comes with the library (with either side being the Server or Client). The TCP Connection and TCP Client actors now send an initial message to each other containing a flattened variant, and they each determine if the other is running an older LabVIEW version (if so, they use bean’s fix from above). Note that this only affects the VariantMessage class. If you flatten Objects containing Variants then this won’t work, and I don’t know what happens if your VariantMessage contains a cluster that contains nested Variants. Please report any such problems, and we can look into a solution. Personally, I don’t tend to use Variants internally to other data structures, but I know others do. Also note that both sides of the connection will need to be running this latest Messenger-Library version, otherwise the initial exchange of version messages will fail.

Hooovahh, Doesn’t VIMs in 2015 require the VIMs to be saved in User.lib?

But is JSON a serialization format for IEEE floating-point binary numbers? Or is it a decimal notation format for data that can be used as interchange between programs (or humans) that are not necessarily using IEEE numbers? My humans are going to be annoyed that the number 0.6 they intended is saved as 0.59999999999999998.

Although strict-typing is a valid reason to argue for separate User Events for each “message”, the freedom to Register selectively for messages is something that can be achieved in other ways. The “ObserverRegister” in “Messenger Library” allows selective registration. Also the flip side of the advantages of strict-typing are the advantages of being able to write generic code.

There must be something, otherwise why up-rev the format with each version? Anyway, I’m thinking of having the the two TCP communication actors exchange two initial messages to tell the LabVIEW versions they are each running in, then have each use the lowest version for flattening. Then they will use the highest version available to both sides. If that is too much work I could just set the version used to 2011.

In 2015, the “VIMs” just worked as regular Variant-typed VIs. You would have to use Variant-to-Data primitives to convert to desired type. As in the wiki, beyond 15 digits not every decimal number has a IEEE 754 representation.

I'm thinking of modifying the TCP Messengers to optionally accept a LabVIEW version for use in flattening. Then you can set whatever version you need.

Hi guys, I'm on holiday this week, sans LabVIEW, so I can't help. But question: is there a way to flatten to an older version of LabVIEW? So tell 2016 to flatten to 2014 format? I vaguely recall reading this. If so, we should be able to make usingly an older format an options, allowing communication with an older version of LabVIEW.

Note that there are two schools-of-thought on how to use User Events. One is to have a separate custom Event for every different message (about 40 in your case). For examples of this see the DQMH or JKI’s “State Machine Objects”. These rely on scripting tools to manage all the custom subVis that need to be generated. The other school is to use a single User Event to carry all messages, using something generic like a string “message label” and a Variant “data” payload. “Messenger Library”, if you look under the LVOOP hood, is basically this. At its simplest, you can do this later method with only a single “Send Message” subVI (with “label” and “data” inputs) that you place everywhere you were previously setting a control. So this is not a lot of work, or at least, not more than any other possible method.

Here's an interesting UI trick, as an example of what one can do with "filter" events: Problem: I like right-click menus to add lots of options to graphs, but the Users seldom discover the right-click options. I would like an obvious menu button for the User to see, but have any click on the button open the graph menu. Solution: put the button on the graph. On "Mouse Down?", hide the button and make the mouse click a right click. The Mouse Down then falls on the graph and triggers "Shortcut Menu Activation?", where I make the button visible again (the User never notices it being hidden). Example Chart Menu Button.vi LabVIEW 2015; controls from Flatline

I think sktthemes is a bot advertising something about photography promotion, as it just copied what I posted earlier.

Any comments on the new JSONtext library? Bugs? Unclear or confusing parts? Missing functionality?

Eventually I want to expand the use of VIM features, but getting rid of the variant-to-data boilerplate is a good start.

Actually, you can just back save the entire package and use the VIMs unchanged as regular Variant-output VIs. The only issue that forced me to use 2017 to build the package was that the VIMs wouldn’t appear on the pallets if I built in 2015.

Sorry for the jump to 2017, but the new VIM functionality was just too tempting. I need to repeat a performance comparison, but here was my earlier tests. Depends on the use case, but roughly an order of magnitude for the typical cluster to/from JSON use.

Might be something to do with the new VIMs. I couldn’t build the package without excluding examples that used VIMs. Did you use VIPM 2017? And, does anyone else have this problem?

I've just added the (almost-out-of-beta) 0.8 version of JSONtext to the CR. I have used it in real-world projects but not exercised every feature.

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. On the LabVIEW Tools Network. JDP Science Tools group on NI.com. Copyright 2017 JDP Science Limited Submitter drjdpowell Submitted 08/02/2017 Category General LabVIEW Version 2017 License Type BSD (Most common)  

That's never been true, as far as I know. The reason to use shift registers is that a local variable will involve a data copy, while a shift register does not.

I didn’t try ODBC, as I was using pq, a dll that takes to Postgres more directly. I would think that ODBC to Postgres would work, though.

That queueing behavior is a know issue with XControls, which are running even when the VI is stopped, so it may have nothing to do with the picture per se.

I asked a similar question a year ago. I decided on PostgreSQL, though my project that needs it was put on hold.

I’m using JSON for test record storage. That can be stored locally, but can also be easily loaded into a JSON-aware database (including SQLite, Postgres and MySQL). Then one can query against particular items in the JSON. I’ve done this with the JSON_tree function of SQLite and it worked quite well.

I had a brief look at Orleans last night. Very interesting, but it brings up a warning. Most “actor” programming out there has been developed to handle distributed software-only applications on large numbers of interchangeable servers. Think 20,000 Halo5 players and 2 or 3 Microsoft server farms. We, in LabVIEW, are more likely to be dealing with a small number of not-at-all-interchangeable pieces of physical hardware. We don’t have the option of handling an error by restarting to finish the job on a different server. So the features of Orleans “virtual actors” sounds very interesting, but not necessarily that applicable to hardware-controlling applications. I would still look at Akka if I were not doing LabVIEW.