[CR] JSON LabVIEW

[ShaunR]

Not sure if this is the best thread...

 

I'm looking to use the JSON implementation to manipulate STIL files (IEEE 1450).

 

Is an extension of the JSON.lvlib a good use case for this implementation?

 

The format looks like this for SPI (serial peripheral interface bus):

 

Signals {

                //My SPI Signal - Direction is Relative to Slave

                CLK      In;

                MOSI     In;

                MISO     Out;

                CS       In;

} // end

 

DCLevels SPI_Levels {

                CLK        {VIH '3.3V'; VIL '0V'; }

                MOSI      {VIH '3.3V'; VIL '0V'; }

                MISO      {VIH '0V'; VIL '0V'; VOH '2.0V'; VOL '1.8V'; }

                CS          {VIH '3.3V'; VIL '0V';}

}

 

 

Any suggestions on the best way to do this? Not using STIL is not an option.

 

Thanks!

If manipulating, rather than creating; I would take a look at the new SQLite features.to see if that would be a solution. You could import a STIL files' JSON representation directly.

 

You can then query (or update) it's parameters as if they were part of the database. This would link in extremely well with the rest of a test system so you could pull out test results and the STIL parameters for a particular configuration or date/time with transparent SQL queries.

Edited January 20, 2016 by ShaunR

[Shaun Hayward]

Not sure if this is the best thread...

 

I'm looking to use the JSON implementation to manipulate STIL files (IEEE 1450).

 

Is an extension of the JSON.lvlib a good use case for this implementation?

 

The format looks like this for SPI (serial peripheral interface bus):

 

Signals {

                //My SPI Signal - Direction is Relative to Slave

                CLK      In;

                MOSI     In;

                MISO     Out;

                CS       In;

} // end

 

DCLevels SPI_Levels {

                CLK        {VIH '3.3V'; VIL '0V'; }

                MOSI      {VIH '3.3V'; VIL '0V'; }

                MISO      {VIH '0V'; VIL '0V'; VOH '2.0V'; VOL '1.8V'; }

                CS          {VIH '3.3V'; VIL '0V';}

}

 

 

Any suggestions on the best way to do this? Not using STIL is not an option.

 

Thanks!

 

I think you'll definitely need to write your own parser / serializer as STIL is definitely not JSON.

[ShaunR]

I think you'll definitely need to write your own parser / serializer as STIL is definitely not JSON.

You are right. I've just noticed the semi-colons. I thought it was a JSON export format of STIL that was posted.

[smuellener]

Hello

 

We connect from LabView to an ASP.NET API and deserialize the data using this toolkit. For the received DateTime strings of the form 2016-02-04T16:02:36.4537156+01:00, the VI "Scan Timestamp.vi" does not recognize the server's timestamps (using the template %^<%Y-%m-%dT%H:%M:%S%u>T)

 

we had to explicitly add the following to the top of the string templates:

 

%^<%Y-%m-%dT%H:%M:%S%7u>T

%^<%Y-%m-%dT%H:%M:%S%6u>T

 

in order for the fractional seconds part to be recognized. As our string is a standard and used in all ASP.NET we would be greatful if you could include it in the next release. Should we update the vi and upload it here?

 

Thank you

Steven

[Stobber]

in order for the fractional seconds part to be recognized. As our string is a standard and used in all ASP.NET we would be greatful if you could include it in the next release.

 

That seems like the kind of thing that should be added to a wrapper or extension to the library's classes, not to the library itself. As someone who never uses ASP.NET (or any of hundreds of other frameworks, services, and tools I can choose from for a new project), I don't want to lug that VI around in my code base.

[drjdpowell]

Steven is referring to the array of supported time formats in "JSON Scaler.lvclass:Scan Timestampâ€.   His timestamps are valid ISO-8601 format so we should support them.

 

Note for Steven:   That format is local time, plus an offset.   LabVIEW Timestamps are in UTC, so I will have to apply the correction.   

 

PS> seems one can just use the format: %^<%Y-%m-%dT%H:%M:%S%12u>T and it will work for any smaller number of digits

[Stobber]

Ah, that makes more sense!

[drjdpowell]

Anybody ever done a full ISO8601-timestamp parser in LabVIEW?  There are lots of options in ISO8601, and our trial-and-error format method is a poor fit if we really want to support ISO8601.

[smuellener]

I agree with you that framework specific functionality should definitely not be included in the library itself. In this case though we are not talking about asp.net or any framework what so ever. 

 

If anyone is using microseconds resolution (which is totally possible for many labview specific applications), he can not directly use this very useful library to work with the timestamps from json (it will not be recognised at all and the decimal part cut entirely to 0). A solution to this is also not easily added as a warapper or extension.

 

ISO 8601 states that there is "no limit on the number of decimal places for the decimal fraction". I would therefore suggest to support 6 and 7 decimal places as well or even go up to nanoseconds resolution (although I personally do not use it but someone else might use timestamps down to nanoseconds in the future):

 

%^<%Y-%m-%dT%H:%M:%S%9u>T

%^<%Y-%m-%dT%H:%M:%S%8u>T

%^<%Y-%m-%dT%H:%M:%S%7u>T

%^<%Y-%m-%dT%H:%M:%S%6u>T

[ShaunR]

If anyone is using microseconds resolution (which is totally possible for many labview specific applications), he can not directly use this very useful library to work with the timestamps from json (it will not be recognised at all and the decimal part cut entirely to 0). A solution to this is also not easily added as a warapper or extension.

 

Sure it is. Save and load it as a string and you can have any format you like. There is no date/time "type" in JSON!.

 

Serializing dates to and from LabVIEW in a cross boundary way is, at best, a kludge and you always have edge cases (different separators, different offsets, different epochs.- the list goes on). If you view the date/time JSON object as a "helper" that tries the common types but specific ones you should just convert manually then there will be less bloat of the function as it trial and errors umpteen different formats and takes 10 hours to do so.

 

You could even save the time and the format string along side it so you know how to re-interpret it. This cat has many skins.

I never offer a date/time conversion in any toolkit for these reasons, but if I did, it would be a default conversion format with a string input to override with a custom one.

 

That's my view, anyway.

Edited February 8, 2016 by ShaunR

[drjdpowell]

I’m happy to standardize on ISO8601, it being a standard, but I need time to write it.  

[JKSH]

Hi,

 

I found out that Set from JSON Value.lvclass:SON String.vi doesn't seem to notice if strings are incomplete. (Currently using version 1.4.1.34)

 

If I input an incomplete object, e.g. 

{"Hello": "Wor

...the VI reports a Parse error (error code 1). This is expected.

 

However, if I input an incomplete string, e.g.

"Wor

...the VI doesn't report an error. What's more, the resulting JSON Value object can be passed into JSON Scalar.lvclass:Get as Text.vi which then produces a valid LabVIEW string with no complaints ("Wor").

 

Is it worth making the scalar parser more robust?

Edited March 9, 2016 by JKSH

[drjdpowell]

Is it worth making the scalar parser more robust?

Possibly.  If one was sending a stream of JSON (including some scalar strings) then this would cause a failure.  However, if some of those scalars were number, like 123.456, then there would be no way to be sure you had the full value as 12 or 123.4, etc. are valid JSON.  So to guard against partial JSON one might have to require streams to use either an Object or Array.

[JKSH]

Possibly.  If one was sending a stream of JSON (including some scalar strings) then this would cause a failure.  However, if some of those scalars were number, like 123.456, then there would be no way to be sure you had the full value as 12 or 123.4, etc. are valid JSON.  So to guard against partial JSON one might have to require streams to use either an Object or Array.

 

Agreed, there's no sensible way to figure out if a raw number is complete or not, so we shouldn't even try.

 

I did indeed stumble upon this while experimenting with the library's ability to handle JSON streams over TCP, but I'm not planning to send raw standalone scalars.

[JamesMc86]

Hey Guys,

Had a play today and hit a parsing error.

It would be really useful if the errors generated included a preview of the string it failed to parse. I did a quick mod so that it includes the first 10 chars of the string it is trying to parse.

I'd be happy to look at adding this in a fork but wanted to check there is no reason this hasn't been done before.

Cheers,

James

[drjdpowell]

Sorry, James, I missed your post till today.  

The primary concern I have is whether error code has a performance cost on all the cases where their is no error.  I haven’t looked, but I don’t think this is the case.  I modified the parsing code a while back to never break up the JSON string, but rather just index along it.  This was for performance reasons, but it should mean that you have full access to the whole string at point of error.   So I’d recommend reporting back more than just 10 characters, possibly including part of the string before the actual section that failed to parse.

[3esmit]

Hello, I am using your awesome library. I'm in need of organizing the document JSON to String by the order I want, so I can present with a user friendly output.

If 'Names Order' String Array is not empty, JSON Object.Flatten will interate over it with get variant attribute, getting only the avaliable attributes with those names in array.

 

Known bugs:
- that this change still not affect nested documents, this could be easly implemented by accepting at Names Order with dot separed for accecing sub documents. This feature is planned to be added in future, if you feel challegned to do so, please contribute.
- JSON Value class, and in other childs should do something with this input.

I'm looking for a repository to pull request, but seems like there is none (https://bitbucket.org/tcplomp/json-api-labview is 404), so I created one https://github.com/3esmit/JSON-LabVIEW/

It would be cool if LAVA had all repos in github, just like JKI is already doing.

 

[drjdpowell]

19 hours ago, 3esmit said:

I'm looking for a repository to pull request, but seems like there is none (https://bitbucket.org/tcplomp/json-api-labview is 404),

It’s at https://bitbucket.org/lavag/json-api-labview now.

[smuellener]

Hi

When we try to deserialize a Json Array but (wrongly) provide an empty string as an argument, the VI JSON Value.lvclass:Read Array.vi crashes yielding the error: "<ERR> Not a JSON Array". I suggest returning an empty/default element of the type to deserialize in instead. This would be the same behaviour for arrays as for single objects.

Thank you

Steven

[drjdpowell]

Can you go into why you want this behavior?  An empty string is not a JSON value of any kind, so the error seems appropriate.   I can see some possible value in accepting null as being equivalent to an empty array or empty object, but why is entering nothing not an error?

[smuellener]

When receiving a http response from a http api (fi to a POST request), the response should be 200 (ok) and may contain a body (to deserialize). When something goes wrong, that body may not contain any elements (empty string). We have two options:

1. Add validy check every time before calling deserialization VIs for them not to crash (and possibly catching errors if it does crash)

2. The deserialization VIs could simply not crash in the first place returning an empty array

Which way do you prefer?

[ShaunR]

2 hours ago, smuellener said:

When receiving a http response from a http api (fi to a POST request), the response should be 200 (ok) and may contain a body (to deserialize). When something goes wrong, that body may not contain any elements (empty string). We have two options:

1. Add validy check every time before calling deserialization VIs for them not to crash (and possibly catching errors if it does crash)

2. The deserialization VIs could simply not crash in the first place returning an empty array

Which way do you prefer?

Can you clarify what you mean by "crash". Generally it means LabVIEW disappears completely or a "General Protection Fault" of some kind ("Insane Object" or "Virtual Function" failures are nasty). If that happens you usually don't get to see any  error cluster type errors at all and have to restart LabVIEW.

Edited July 22, 2016 by ShaunR

[drjdpowell]

Can I see some code?   I’m having a hard time understanding because an Error is “something goes wrong” which then needs to be handled.  If something has gone wrong with your POST response then you should already have an error, and either you pass that through Read Array.vi or you just leave the Error out of Read Array.vi unwired (since it will return an empty array).

[Dan B]

I am having an issue with the JSON using LabVIEW 2014 64 bit version.

The 32 bit version of LabVIEW does not generate this error and works fine.

The ZLIB CRC32__ogtk.vi will not execute. The Call Library Node is pointing to an invalid library, and when I browse to the Library in the 64 Bit NI folder (C:\Program Files\National Instruments\LabVIEW 2014\user.lib\_OpenG.lib\lvzip\lvzlib.dll)  I get the error "The Library is not valid for the current platform. For example, you are running 64-bit LabVIEW and the library might be a 32-bit library.

I installed this via VI Package Manager for the 64 bit operating system.

Any idea how to fix this?

 

[Gribo]

You need the 64 bit version of the library.