Jump to content

Recommended Posts

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

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

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 comment

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 comment

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 comment

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

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 comment

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.

×
×
  • Create New...

Important Information

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