LinkedIn Profile

Facebook Page

Location

Interests

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
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

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

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.]

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?

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

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?