Jump to content

Recommended Posts

Examples?  I looked through the "detailed help".  The "JSONtest API example.vi" did a great job at building a json structure and looks like to deconstruct it, you have to already know what the components are.  Are there other examples that I missed?

Thanks

Link to post
  • Replies 159
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

View File JSONtext Package for working with JSON.  Uses high-speed text parsing, rather than building an intermediate representation as with prior LabVIEW JSON librari

working on it

Help Is there a way to parse this JSON string into this cluster in the following way: - The order of elements inside the "Parameters" cluster does not matter. No error - I can use enums

Posted Images

I have been using the From JSON text to write a 2-dimentional array containing an array of cluster as show on the block diagram below.

image.png.e2dcda075c3412db9ef4a88f97bf0cf3.png

I have been getting error d91 (Hex 0x5B) The data type of the variant is not compatible with the data type wired to the type input on the From JSON.vi.

Although this error is only flagged when using version 1.4.5.91. When downgrading to 1.4.4.89 the error is not flagged and the conversion to the input happens without an issue.

I'll return to use the older version for now but it would be good to know why is this occuring on the newer version

Link to post
Posted (edited)
2 hours ago, Filipe Barbosa said:

I have been getting error d91 (Hex 0x5B) The data type of the variant is not compatible with the data type wired to the type input on the From JSON.vi.

https://bitbucket.org/drjdpowell/jsontext/issues/80/2d-array-of-variants-not-converting

Will be fixed in 1.5.2

Edited by drjdpowell
Link to post
  • 3 weeks later...

I am trying to convert some JSON, but the datatype changes based on the UUT response.

Since I am using the stock "From JSONText" vi, I was using a type def cluster, of a string, and two doubles (as seen in rxample 2).   But if the device has not been configured yet, it responds with 3 strings (example 1), which causes an error in the conversion process since the data types dont match.

Example (pressure and temperature are strings):

{"attributes": {
"flow": "<unset>",
"pressure": "<unset>",
"temperature": "<unset>"
}

 

Example 2 (pressure and temp are doubles):

{"attributes": {
"flow": "100",
"pressure": 5.235,
"temperature": 25.5
}

 

I can use two type def clusters, and if I get an error with one, try the other.   But I figured there might be a more elegant way to handle it.

Link to post

You could ignore the error, with NaN as default pressure and temperature.  Or you could read flow first, and only get pressure/temperature if flow isn't "<unset>".

Link to post
  • 2 months later...

Would it be a lot to ask, for this library to support C++ style comments? Basically any text after // would simply be ignored until the EOL.

I know that JSON strictly speaking doesn't support comments but JSON5 for instance does support those C++ style comments. 

Edited by Rolf Kalbermatter
Link to post
  • 2 weeks later...
2 hours ago, Aristos Queue said:

The subVIs that "Merge Cluster into Object.vim" calls support pretty printing

The various Insert functions, like the subVI on the Right, don't support Pretty Print.  I suggest you try Reformat, which can Pretty Print the resulting JSON.  Or in the latest 1.6.5 version, just released, try the new "Pretty Print" function, which is faster and supports Comments.

Link to post
  • 2 weeks later...

Block diagram of "From JSON Text.vim" is shown below.

  1. What is going on in the error case of the case structure? Why do you need to call the same node but bypassing the error cluster? Why not just wire the default value through the case frame and leave out the call to Variant to Data entirely?
  2. The error cluster tunnel going into the case structure can be changed into the ? terminal, thus avoiding forking the error cluster wire and making it just slightly clearer what's going on in this diagram.

image.png.d99768541157c0cf8dc6b49c33aa99d7.pngimage.png.ea62fa208114cc2687d7617ccd643099.png

Link to post

Next question:
Why does "Get String" have two different inputs, one for the LV Type and one for the default value? The default value terminal does not appear to be wired anywhere in the toolkit, and all callers have to do their own selection after the call to pick the default value.

image.png

Link to post
Posted (edited)
18 hours ago, Aristos Queue said:

Why does "Get String" have two different inputs, one for the LV Type and one for the default value? The default value terminal does not appear to be wired anywhere in the toolkit, and all callers have to do their own selection after the call to pick the default value.

This was originally a method in the early prototype API of JSONtext (pre public release), which is why it has a "default" input.   However, I used this (now private) method internally whenever a LabVIEW type is stored as a JSON string (should really have made a separate method).  In such use, I found a problem of needing a better description of the error if conversion failed, and for that I needed the actual LVtype.  This is not really how I would design it from scratch, but it happened incrementally.

Edited by drjdpowell
Link to post
3 hours ago, Aristos Queue said:

What is going on in the error case of the case structure? Why do you need to call the same node but bypassing the error cluster? Why not just wire the default value through the case frame and leave out the call to Variant to Data entirely?

Ah, this can be illustrated with this image:

1630603382_2021-07-1220_32_49-Window.png.8db7128f64e2d2d260ef61f544aa16ff.png

JSONtext does not follow the common error rule of returning default value on any error.  Instead, it returns best-efforts, with only sub-elements that produce errors being returned as the supplied default.  Here it is only the "B" element, requested as a Float but a String in the JSON, that is returned as default (as explained in the error message).

Thus we are doing the Variant-to-Data even on error, in order to get this partial conversion of JSON to Data. 

 

 

  • Thanks 1
Link to post
Posted (edited)
On 6/17/2021 at 10:19 AM, Rolf Kalbermatter said:

Would it be a lot to ask, for this library to support C++ style comments? Basically any text after // would simply be ignored until the EOL

Note: latest version supports comments.

https://forums.ni.com/t5/JDP-Science-Tools/BETA-version-of-JSONtext-1-6/m-p/4146235#M39

Edited by drjdpowell
  • Like 1
Link to post

I am getting this error when going to JSON. This seems like an error that should only occur when going from JSON. The error comes out of image.png.2ddca2301d657ad1720be16cfe7abf9d.png whenever the "$Path or Item Name" terminal is an empty string.

Now, for one thing, I'm not convinced empty string should be an error at all... using empty string as a field name is legit JSON so far as I know. But even if it is illegal, I would prefer a different error here, something that says "the field name cannot be empty string." Is that reasonable?

Note that I did try passing "$." instead of empty string... that gave me the same error.

Is there a way to add a field that has a name of ""?

image.png.f7af90ef79e39360f4cf76ef5954480f.png

 

Link to post
Posted (edited)

That is a case that needs (at least) a better error.

Try the path $.""

By using the quotes, the name is any JSON string, and can thus handle any name.  The unquoted form is for convenience and can't handle all edge cases.  

BTW, what JSON are you feeding in to that node.  It has to be an Object if you want to insert at $.""

Edited by drjdpowell
Link to post
33 minutes ago, drjdpowell said:

BTW, what JSON are you feeding in to that node.  It has to be an Object if you want to insert at $.""

I'm feeding it legit object JSON. As long as the field name wasn't empty, everything worked. 🙂

Link to post

image.png.6ad79d6c41646ba39b9f73c1d7149da1.png

This subVI violates the "never copy all or part of the input JSON string" rule. There's no such thing in LabVIEW as an array of substrings. I would suggest that the next version of the JSONText toolkit should include a VI named something like "Get all Object Item offsets.vi". It would return two arrays of clusters of two integers: start offset and length. The first would be the names and the second would be the object data. (After looking at the JSON spec again, I note that the name string can contain escaped characters, so maybe go ahead and return the names as you are doing now because otherwise people are going to forget that step and just get substrings and think they have valid names and the copies out of the main JSON will have to happen anyway.)

Link to post

The handling of variant attributes is asymmetric. I can serialize the variant and its attributes are recorded as fields of an object. But on deserialize, the attributes are not recovered. I suspect this is because there isn't any type information to tell us what type each attribute should be, but I'm not sure. Why isn't the deserialize handled? Can it be handled?

image.png.590740a6d11bbd8f250e342da0b476ad.png

Link to post
15 hours ago, Aristos Queue said:

The handling of variant attributes is asymmetric.

The To-JSON behaviour was copied from the previous LAVA-JSON library.  That library had the reverse operation, but it only worked if one provided same-named attributes in the default value.  As you point out, this is because we need to know what type to convert the JSON to.  Personally, I found this kind of useless, as the whole point of attributes is to have unknown items of unknown type.  I had also developed "subJSON"  for exactly this use case, and never use Variant Attributes at all.  So it kind of got stuck in limbo.   

I note that the newer Set and Map support doesn't run into this issue, as Sets and Maps have Type.

Options:

  1. Leave as is, not really supporting Variant Attributes
  2. Deprecate the current To-JSON support and fully not support Attributes at all
  3. Save Type in the JSON somehow (I don't like this)
  4. Use limited JSON types when converting from JSON: String, Float, Boolean
  5. As in LAVA-JSON, but using (4) as a fall back if type not supplied

Added later: see https://bitbucket.org/drjdpowell/jsontext/issues/39/support-json-to-variant-when-no-datatype where it was proposed to do (4), I think.

Edited by drjdpowell
Link to post

I generally prefer #4 straight up. If you add #5, anyone not supplying the types will be slowed down by the code checking the input variant for "Did you provide a type for this attribute? How about this attribute?" and getting a "no" answer each time. It's not slow, but it is an unnecessary hiccup. Anyone who knows the types can get them from the generated variant.

The one difficulty that makes me lean toward #5 is objects. If we parse "a":5 then we know to add attribute "a" as an integer. But if we hit "a":{ ... } then that can be a cluster of those elements, another variant attribute table, or an class. In those cases, I'd like to leave it to the Serializer to decide how to parse what is between the braces. If it can detect that the stuff between the braces is an object or a known cluster and deserialize it, great. And if it cannot, it yields to its parent implementation which pulls it in as a variant attribute table.

Does that make sense?

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Similar Content

    • By LogMAN
      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
    • By drjdpowell
      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
    • By drjdpowell
      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  
    • By ThomasGutzler
      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.

    • By drjdpowell
      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.]



×
×
  • Create New...

Important Information

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