Jump to content

Recommended Posts

On ‎7‎/‎30‎/‎2016 at 7:36 PM, Gribo said:

You need the 64 bit version of the library.

 

Well, that's sort of my point. I was pointing to the dll in the 64 bit version of LabVIEW. I was working directly off of the VI's downloaded through VI package manager, installed into the 64 bit version of LabVIEW.

It's as though the dll included in this instance is NOT the 64 bit version of the library.

Maybe the issue is the OpenG library.

If it's just the dll that I need for the 64 bit library, does anyone have a copy they can attach?

Link to post
Share on other sites
  • Replies 240
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

The easiest way by far is to use the [un]Flatten to XML primitives, which can take objects and variants as arguments, and convert the XML to/from JSON. with simple regex/search/replace. Why they didn'

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

I tried to use this tool. And it looks great, however the function 'Variant to JSON' fails with a variant inside an object. I made the following changes: -Added support for Variant. By using 'Unwrap

Posted Images

1 hour ago, Dan B said:

Well, that's sort of my point. I was pointing to the dll in the 64 bit version of LabVIEW. I was working directly off of the VI's downloaded through VI package manager, installed into the 64 bit version of LabVIEW.

It's as though the dll included in this instance is NOT the 64 bit version of the library.

Maybe the issue is the OpenG library.

If it's just the dll that I need for the 64 bit library, does anyone have a copy they can attach?

Zlib isn't a dependency of the JSON library, is it? You need to be over here, I think.

Link to post
Share on other sites
2 hours ago, ShaunR said:

Zlib isn't a dependency of the JSON library, is it? You need to be over here, I think.

Ah, your right. I was using it with conjunction with JSON, I thought it was embedded inside one. My mistake.

I'll go pester the right people :)

Link to post
Share on other sites
  • 2 weeks later...
1 hour ago, drjdpowell said:

The current LabVIEW version for this JSON package is 2011, but I am considering switching to either 2013 or maybe even 2015.  What versions do people need?

Why? 2011 works in all versions up to and including 2016

Link to post
Share on other sites

I have stuff developed for a client in 2015, that I'd like to incorporate into this package, but I'm using the conditional and concatenating options on loop output tunnels (that came in after 2011).  So supporting 2011 requires a rewrite (and a more complex and lower performance solution).

Link to post
Share on other sites
31 minutes ago, drjdpowell said:

I have stuff developed for a client in 2015, that I'd like to incorporate into this package, but I'm using the conditional and concatenating options on loop output tunnels (that came in after 2011).  So supporting 2011 requires a rewrite (and a more complex and lower performance solution).

I don't know if the concatenating tunnel is more efficient. I thought it was just syntactic sugar.

Anyway. You could back-save to 2011 and avoid everyone else from asking for it in an older version ;) . You don't have to develop in the old version. The caveat would be if you wanted to use native primitives (like the parser in 2013).

  • Like 1
Link to post
Share on other sites

I'm using it in 2014.1. I would wait for a major upgrade to break compatibility. Shaun's suggestion of back-saving makes sense to me. I've done that with concat tunnels, and the code generator replaced them with old constructs appropriately as I recall. If you don't wait for an upgrade, then I'd bump the revision by a major number anyway. You even might consider setting the major rev to the version of LV it's developed in.

Link to post
Share on other sites

My work that uses JSON is in 2012. I just started shifting my core software to 2015 (though there are a couple things in 2016 that have caught my attention). I'm not running afoul of any bugs in the current revision, so I don't see an issue for me.

Link to post
Share on other sites

I am currently wondering about the encoding of strings in JSON, since havine something like this:

 

{ 
	"serverConfig": {  
		"read": {   
			"address": "164.3.157.40",
			   "port": 5010,
			   "bytesToRead": 130,
			   "connectionMode": "Server",
			   "connectionTimeout": 5000,
			   "readTimeout": 2000
		}
	}
}

throws error 1 (Parser error)

and when I remove the quotation marks on the values like so:

{ 
	"serverConfig": {  
		"read": {   
			"address": 164.3.157.40,
			   "port": 5010,
			   "bytesToRead": 130,
			   "connectionMode": Server,
			   "connectionTimeout": 5000,
			   "readTimeout": 2000
		}
	}
}

everything seems to work just fine.

The problem is that the JSON Editor that I use automatically sets quotation marks for non-numeric values. also the first variant passes validation, whereas the second doesn't.

am I missing something?

Edited by kull3rk3ks
Link to post
Share on other sites

Are you able to post this as a text file?

I always have quotes around strings using this tool without issues so they are supported and as you point out it isn't valid JSON without it. I am wondering if there are some extra characters or the types of characters that are used that cause the problem.

Link to post
Share on other sites
2 hours ago, kull3rk3ks said:

 


{ 
	"serverConfig": {  
		"read": {   
			"address": "164.3.157.40",
			   "port": 5010,
			   "bytesToRead": 130,
			   "connectionMode": "Server",
			   "connectionTimeout": 5000,
			   "readTimeout": 2000
		}
	}
}

throws error 1 (Parser error)

I quickly tried this string and I didn’t get any error.

Link to post
Share on other sites
11 minutes ago, JamesMc86 said:

Are you able to post this as a text file?

I always have quotes around strings using this tool without issues so they are supported and as you point out it isn't valid JSON without it. I am wondering if there are some extra characters or the types of characters that are used that cause the problem.

I just checked the JSON file again, found no error in it and decided to upload it to che cRIO again for testing. Lo and behold it works... I have no idea why.

Link to post
Share on other sites
On 8/15/2016 at 7:03 PM, drjdpowell said:

The current LabVIEW version for this JSON package is 2011, but I am considering switching to either 2013 or maybe even 2015.  What versions do people need?

I'm using JSON LabVIEW with a 2013 project, but I don't need the latest and greatest library :)

 

There is one feature I would love to see added though: Support for non-explicit variant conversion. JKI's recently-open-sourced library handles this very nicely:

json-comparison.png

The black frame represents a subVI boundary.

Several months ago I implemented a JSON-RPC comms library for my project, based on JSON LabVIEW. Because the "data" member can be of any (JSON-compatible) type, I had to expose the JSON Value.lvclass to the caller, who then also had to call Variant JSON.lvlib:Get as Variant.vi manually to extract the data. This creates an undesirable coupling between the caller and the JSON library.

It would be awesome if Variant JSON.lvlib:Get as Variant.vi could use the structure within the JSON data itself to build up arbitrary variants.

Edited by JKSH
Add variant comparison
Link to post
Share on other sites
8 hours ago, JKSH said:

This creates an undesirable coupling between the caller and the JSON library.

JSON is an interchange format.  Reducing coupling between components is what it’s meant for, so it’s sad that we worry about unwanted dependancies.  The “variants that contain only strings and numerics as basic datatypes” that you are asking for are a much less flexible substitute to JSON text.  I would not be happy if I had to do lots of manual type conversion on everything that isn’t a simple string; that’s an undesirable dependency to me.

Really, the best solution would be for NI to realize the value of a JSON-like datatype and build that into LabVIEW, replacing this library entirely with a much faster solution that can be widely used in interfaces between modules without worrying about unwanted dependancies.

As an alternative, have you considered using the JSON text itself as the thing to pass on, rather than a variant?  Try this: replace your “data” Variant with a string labeled “<JSON>data”.  That tag indicates to the library that you want your “data” subitem as JSON text.  Pass that string across your subVI boundary.  If you are just using strings and numerics, then your Caller can use the inbuilt JSON primitives to convert very quickly into data, so it isn’t dependent on this JSON library.

Personally, I solved this issue by deciding to make this JSON Library a standard component always used in all cases where complex structured data is passed between modules.  But then I did write the library.

Link to post
Share on other sites
  • 2 weeks later...

I made the Adapt to Type method public in JKI JSON allowing separation of the parsing from a JSON string and adapting to a LabVIEW type. It's not yet documented but if you look into JKI JSON Deserializer class the behavior should be relatively obvious. First deserialize from JSON string and then call adapt to type when you know what type you need. Thanks drjdpowell for the suggestion!

  • Like 1
Link to post
Share on other sites
  • 3 weeks later...

I’m doing a lot of work at the moment on a “JSON 2.0” version, particularly intended to improve performance in common use cases that I’ve encountered. For example, I have a new VI that flattens a Variant directly to JSON text (skipping the Objects entirely) that works on large arrays of numerics about 30 times faster.   

I’d like to claim R&D tax credits on the work I do on this (which is otherwise unpaid), and to do that the result of the work needs to be owned by my limited company, so I’d like to release the new version under “JDP Science Limited”, rather than “LAVA”.   I would put a BSD license on the new version, and properly comply with the BSD license of the current LAVA version.  I hope none of the contributors of "JSON LabVIEW” object?   The R&D credit would work out to about 30% of charged rate (if I do the tax math right, which is far from obvious).  30% is a lot better than zero.

 

Link to post
Share on other sites
59 minutes ago, drjdpowell said:

I’m doing a lot of work at the moment on a “JSON 2.0” version, particularly intended to improve performance in common use cases that I’ve encountered. For example, I have a new VI that flattens a Variant directly to JSON text (skipping the Objects entirely) that works on large arrays of numerics about 30 times faster.   

I’d like to claim R&D tax credits on the work I do on this (which is otherwise unpaid), and to do that the result of the work needs to be owned by my limited company, so I’d like to release the new version under “JDP Science Limited”, rather than “LAVA”.   I would put a BSD license on the new version, and properly comply with the BSD license of the current LAVA version.  I hope none of the contributors of "JSON LabVIEW” object?   The R&D credit would work out to about 30% of charged rate (if I do the tax math right, which is far from obvious).  30% is a lot better than zero.

 

I've no idea what you are talking about (R&D Tax credits?) so it's difficult to make a judgement but you appear to want to take sole ownership rather than be the caretaker of a community project. So I object on that basis. Am I able to claim these credits too?

There is nothing in the BSD licence that says you cannot take the current software and create a derivative as long as the licence is followed.I would prefer you create a new product derived from the current.to mark a distinct change rather than an attempt a seamless absorption. In time, people will probably move to your new product in preference  but I think a distinction should be made and the current project control handed over to LavaG admins.

I'm not suggesting that you don;t deserve most of the credit for the library. only that a distinction is made that it is no longer the same community software in order for you to benefit..

Link to post
Share on other sites
1 hour ago, ShaunR said:

I've no idea what you are talking about (R&D Tax credits?)

https://www.gov.uk/guidance/corporation-tax-research-and-development-tax-relief-for-small-and-medium-sized-enterprises

1 hour ago, ShaunR said:

I would prefer you create a new product derived from the current.to mark a distinct change rather than an attempt a seamless absorption. In time, people will probably move to your new product in preference  but I think a distinction should be made and the current project control handed over to LavaG admins.

I was thinking of that as an option.   The LAVA community one would be version 1.4.1.  I’m afraid I’ve checked in some things starting with a switch to 2013; you should ignore those and branch from the last 2011 checkin.   I’ll set up a new repo and a new project name.  

Link to post
Share on other sites

I thought the concept is that you would still own the copyright on your contributions anyway, if you happen to license it under open source (as you are obliged to if you have derived from most open source license) that doesn't have ownership implications so I wouldn't expect that to be necessary (although I'm not familiar with the in's and out's of R&D credits as I haven't found a project for them yet).

Either way I am happy for you to do this but I do think it would be a shame to split to 2 projects as it tends to cause more confusion (jenkins vs hudson for example!)

Link to post
Share on other sites

JSON LabVIEW is BSD licensed.  It’s not “Copy Left”, so one doesn’t have to open-source any derivative work.  

BTW, what I’m working on is a major change, that gets rid of the intermediate representation as LVOOP objects entirely.   The only representation is text.  So I may be able make it an independent package that can be used in parallel with the LAVA JSON library.

 

Link to post
Share on other sites
30 minutes ago, drjdpowell said:

JSON LabVIEW is BSD licensed.  It’s not “Copy Left”, so one doesn’t have to open-source any derivative work.  

BTW, what I’m working on is a major change, that gets rid of the intermediate representation as LVOOP objects entirely.   The only representation is text.  So I may be able make it an independent package that can be used in parallel with the LAVA JSON library.

What is the criteria for the Tax exemption that requires this move? What makes this toolkit a good choice over, say, you messaging library which has little or no collaborative contributions  so far?

Edited by ShaunR
Link to post
Share on other sites
1 hour ago, ShaunR said:

What is the criteria for the Tax exemption that requires this move? What makes this toolkit a good choice over, say, you messaging library which has little or no collaborative contributions  so far?

I’m recording my work on Messenger Library and all other reuse libraries, and hope to claim at least some of them also.   JSON just happens to be what I am working on right now.  

Link to post
Share on other sites

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



×
×
  • Create New...

Important Information

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