Jump to content


  • Content Count

  • Joined

  • Last visited

Community Reputation


About nickster

  • Rank
    LAVA groupie

LabVIEW Information

  • Version
    LabVIEW 2017
  • Since
  1. Ah, that's a cool trick. Thanks. Food for thought. Reconsidering my position...
  2. Thanks. I'll take any speed-ups I can get. But when I sit down to wire this up, I realize I'm not understanding the instructions. Could you show an example diagram? Early on in development I had tried out both the built-in LV JSON tools and JSONtext, as well as one or two other JSON toolkits on the market. My focus then was just on getting a solution up and running, not on performance benchmarking. I went with JKI purely on this basis. I recall that there was something smoother about retaining some subset of data within a cluster in variant form for later typecasting. LV JSON, I think, was an absolute no-go from this standpoint, and JSONtext was a maybe-go if I had allowed myself to play around with it more. I will come back to JSONtext and try to implement it - would be nice if I can get a performance boost. As for dealing with the JSON string itself, yes, I can go there, but code reuse will go in the toilet. Regarding the original problem of programmatically renaming an element in a (variant of a) cluster, I found a workaround for my application by instead building up a new cluster from scratch using OpenG. I'm not sure whether anyone would describe it as "elegant."
  3. I have a project that's making heavy use of JKI JSON in conjunction with OpenG Variant toolkit. For a bit of context, I'm communicating with an instrument server via JSON-RPC over websocket. I can access properties of the server by sending a "Query" command, with an empty JSON object corresponding to the desired property in the "params" field. In Labview, it looks something like this: which ends up sending a JSON-RPC message like this to the server: { "jsonrpc":"2.0", "method":"Query", "params":{ "filter":{ "SomeNumericValue":{ } } }, "id":"bar" } From time to time, I need to query data that's returned in the form of a dictionary. For example, the server maintains a database of user-defined instrument settings, with each settings object labeled by a guid string. I can retrieve all dictionary elements in one go with an empty object labeled "{}". Then I can restructure them into a more LV-amenable array using OpenG Variant tricks. So far so good. The Labview looks like this: Just for total clarity, the JSON-RPC message sent from my client looks like this: { "jsonrpc":"2.0", "method":"Query", "params":{ "filter":{ "SomeDictionary":{ "{}":{ } } } }, "id":"bar" } Unfortunately, the full database can be really big and unwieldy. Each item in the dictionary is itself a pretty bulky object. (Side note: I sadly think I've discovered that it can break the JKI JSON parser. I'm not sure how this happens - maybe a memory issue when recursion gets really, really deep. Don't shoot me if I'm wrong about that. JKI JSON is saving my life right now, so I don't want to speak ill of it!) I would really like to query just one dictionary element at a time. In terms of how my code currently works, that would require changing the wildcard "{}" label within the filter object structure to the actual name of of the item I want to grab. (Knowing the item names is no problem. I can retrieve a list of names from a separate query.) So far I haven't figured out how to do this. Maybe it's not even possible. (Just wiring a variant to Set Data Name.vi and then using Bundle's to build up a cluster doesn't work. The element in the cluster will be named "Renamed Data" - i.e., the output name of Set Data Name.vi.) For the record, no, I do not like the fact that the server spits out dictionaries, as these naturally map onto a cluster of clusters (object of other named objects), and Labview desperately wants all objects to already be named at runtime. But this is just how the device works, and I can't change it.
  • Create New...

Important Information

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