Search the Community

Hello I need to create a json in the following structure: { "Value1": { "Build": { "1": { "t_inst": { "Type": "Gold", "Key": "15", "size": "big" }, "1_avg": { "Type": "Green", "Key": "11", "size": "big" }, "2_avg": { "Type": "Blue", "Key": "21", "size": "big" } }, "2": { "t_inst": { "Type": "Gold", "Key": "15", "size": "big" }, "1_avg": { "Type": "Green", "Key": "11", "size": "big" }, "2_avg": { "Type": "Blue", "Key": "21", "size": "big" } } } }, "Value2": { "Build": { "1": { "t_inst": { "Type": "Grey", "Key": "22", "size": "small" }, "1_avg": { "Type": "Yellow", "Key": "8", "size": "big" }, "2_avg": { "Type": "Blue", "Key": "21", "size": "big" } } } } } I've searched several forums, but none I've seen have as many layers as I need. Could someone help me?

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)  

This is a weekend project (ok, several weekends now) I've been meaning to share for a while. It's a proof of concept which I'd like to get some feedback on before I invest more time. The idea is to provide a toolkit that uses LabVIEW webservices to serve an interactive HTML5 representation of any application's front panel(s) as an easy way to monitor and control the application (over the internet) without the need for heavy applications or runtime engines. Just a browser. And because not everyone is a also web-developer, the work required to create that website should be done entirely by the toolkit. In my solution it's as easy as dropping a single vi on the block diagram, that registers the VI with the FrontPanelManager which takes care of all the data exchange between the website and the front panel. Here's a screenshot of an example front panel showing all supported elements and its HTML version on chrome: Obviously, there are some cosmetic differences that can be fixed later. Controls on both LabVIEW front panel and HTML site act as controls and are synchronised across the two. By default, the website queries the front panel every 250ms for new data. The refresh rate can be changed with the cog button in the bottom right corner. To run it open the project start the WebService Get the URL of Main.html and point your browser to it start "To Publish/Main.vi" and watch the data appear in the browser As I said this is a proof on concept and it's a long away from being a toolkit. I'm working on functions that appear in the Tools menu to automatically add and configure the webservice and dependencies and many other things. [2014]FPPublisher.zip

View File JSON LabVIEW JSON is a data interchange format (sometimes compared to XML, but simpler). There are multiple projects to create a JSON package for LabVIEW. This is yet another one motivated by this hijacked conversation originally about a different project to convert JSON into LabVIEW Variants. This project uses a set of LVOOP classes to match the recursive structure of JSON, rather than variants. It allows conversation to and from JSON. All functionality is available through two polymorphic VIs: Set and Get. In addition to Get and Set VIs for common data types, one can also convert directly to or from complex clusters via variant-JSON tools. Copyright 2012-2016 James David Powell, Shaun Rumbell, Ton Plomp and James McNally. [Note: if you are using LabVIEW 2017, please also see the JSONtext library as a an alternative.] Submitter drjdpowell Submitted 10/04/2012 Category General LabVIEW Version

Hi! I have to convert a dynamically generated array into a JSON string and back. Unfortunately I found that the un-flatten method loses the variant data. See the screenshot of FP and BD and the comments inside. JSON_Text_test.vi Is this a bug in JSON Text or is my data-construction not supported as expected? In case of the letter I have modify huge parts of my code. So I hope that it is a bug 😉 The 2nd thing I recognized is that the name "Value" of the cluster is not used during flatten. Instead the name of the connected constant / control / line is used. I found the green VI ("Set Data Name__ogtk.vi") at OpenG Toolkit that allows me to programmatically set the variant data name. As you can imagine I would prefer not to need the OpenG VI. Thanks in advance for your kind help 🙂

I recently stumbled upon this issue while debugging an application that didn't handle JSON payload as expected. As it turns out, Unflatten From JSON breaks on NUL characters, even though Flatten To JSON properly encodes them as ("\u0000"). I have confirmed the behavior in LabVIEW 2017, 2019, and 2020 (all with latest service packs and patches), currently waiting for confirmation by NI. Workaround: Use JSONtext

Hi, I'm receiving a JSON string from a web API, which I'm trying to convert into a cluster (of clusters) but I've run into some problems: 1) Sometimes the order of the elements in the JSON string changes, which causes my conversion to fail. 2) Sometimes the "object" returned via JSON is null, which causes my conversion to fail if I use clusters within clusters. It works with variants in clusters but then I need to convert the all the variants manually Is there any way to improve my code to fix those problems? The attached snippet is a simplified version. In my project, the first JSON string to data is done in a library. The second conversion from "result" variant to data is done in my application. This makes a direct conversion from JSON string more difficult.

I’m working on a new JSON library that I hope will be much faster for my use cases. It skips any intermediate representation (like the LVOOP objects in the LAVA JSON API, or the Variants in some other JSON toolkits) and works directly on JSON text strings. I’d like to avoid making a tool just for myself, so I’d like to know what other people are using JSON for. Is anyone using JSON for large(ish) data? Application Config files? Communication with remote non-LabVIEW programs? Databases?

Hi There I want to go from TestStand's output i.e. database to HTML5 SPC charts. Sorta like http://moderndata.plot.ly/using-plotly-from-labview-via-python/ Has anyone done this or used Bokeh or Enthough's data tool before? What about these tools with TDMS or HDF5? Thanks. I appreciate it. Best, Pavan By the way, https://www.enthought.com/services/consulting/case-studies/TAIPAN/ (like TestStand without TestStand)

SQLite has added the json1 extension module in the source tree. It implements eleven SQL functions and two table-valued functions that are useful for managing JSON content stored in an SQLite database. This is a huge feature feature improvement that effectively allows transparent queries of embedded JSON strings in the DB and will be of special interest to LabVIEW web enabled applications with SQLite back-ends for direct to DB insertions and remote queries. It achieves an impressive pars speed of over 300 MB/s (allegedly)

I am using JSON API 1.1.2 and recently discovered that JSON to Variant and Variant to JSON cannot handle paths. Any chance I can get a fix that adds another case for paths? I would have assumed that this would be handled by the default case in both VIs but the default cases seems to be handled in different ways. Variant to JSON uses Variant to Flattened String and JSON to Variant uses OpenG Scan From String. I think the default case would be able to handle paths if Variant to JSON used OpenG Format Variant Into String. Why was this not done? I can see that it was at one point in the code comments but there isn't enough of an explanation. If I can help modify the code please let me know. thanks, -Pat

This is my first post but I have been browsing LAVA for years! I couldn't figure out how to post this within the repository forums so I decided to throw it up here. I am using the JSON LabVIEW 1.1 API in a large project and just came across an issue. The attached VI shows the problem but what it boils down to is that doubles get truncated to 6 decimal places. It is being truncated because of the Format Into String function's "format string". Was this done on purpose? I know how to make the change that I am looking for but I would like to see it get worked into the package's source. Thanks, -Pat Build Basic JSON.vi

Very pleased to see the New JSON Encode and Decode in the palettes of LabVIEW 2013. I've looked at using them instead of the various libraries out there and I'm in two minds whether I will convert my current apps or use them in the future instead of those 3rd party libraries now I have had a chance to play.. Let's start off by saying they work great They are orders of magnitude faster than 3rd party ones and they adhere vehemently to the JSON standard. It's the last bit I'm in two minds about. JSON is subset of Javascript (EMACS). Javascript is dynamically typed, which means that any variable can hold any type and although a string may have quotes around it, it does not preclude inserting it into, or operating on as a numeric type. Whilst the JSON spec does specify that string types be encased in quotes, Javascript (and PHP, for that matter) programmers don't really care and it doesn't break their code if they are present or not. Therefore it is very common to see quotes around numerics and even quotes left off of strings and most parsers will cope with this. LabVIEW is strictly typed and when the JSON Decode encounters quotes, it will error if you have defined the field as, say, a double. and then will not process any further fields. This is a right, royal pain! It also misses a trick that would make our lives so much easier and our code much simpler. Take, for example, the following real JSON stream from MTGox. { "channel":"dbf1dee9-4f2e-4a08-8cb7-748919a71b21", "channel_name":"trade.BTC", "op":"private", "origin":"broadcast", "private":"trade", "trade":{ "type":"trade", "date":1376196221, "amount":0.3333, "price":102.95507, "tid":"1376196221462784" ,"amount_int":"33330000", "price_int":"10295507", "item":"BTC", "price_currency":"USD", "trade_type":"ask", "primary":"Y", "properties":"limit" }} The "price_int"," amount_int" are encased in quotes when quite clearly they are integers and, more importantly, we need to manipulate them as integers. This forces the use of cluster elements that are strings and then to convert those fields to the appropriate type. It is compounded further since the structure is nested which means we have to unbundle all of the elements and then re-bundle to our desired types as we cannot use a single cluster definition. Additionally, the "date" is a numeric of the correct type, but that is not very useful in this scenario since it will need to be converted to a string. So defining that field in the decoding cluster as a string would have been a bonus. . This is the conversion using the native JSON decode.vi. This is using the JSON API available in the CR. The JSON API in the CR is much more forgiving in that the cluster, alone, decides on the type. So type conversion can be done transparently by defining the cluster regardless if a value is quoted or not. This yields a much simple, easier to maintain VI and, should the server generating the JSON decide to strictly adhere to removing quotes from integers; it will not break our code as it would with the native VIs. The native JSON decode has a "strict validation" boolean that states It would be useful if this boolean also disabled type checking of quoted strings. It would also be useful if it didn't stop at the first field it couldn't interpret and tried harder to continue. I could live without the latter, but not sure I can without the former - hence my ambivalence. Did I mention how fast the native VIs are?