Leaderboard

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

Exactly! So when a customer calls they can provide useful information about the problem!

For our re-usable code we like to have a separate project for the "library" where maintainance is performed. These are put in source code control and we never link directly to the VIs in the project area. When use VI Package Manager (VIPM) to build VI packages to place the VI's in a custom location in the user.lib folder. This has worked well for us with multiple developers through two LabVIEW upgrades. We are still working with the community version of VIPM since I can convince the boss man to spring for the pay version(s) that would let us manage distribution easier.

I just discussed this with my teammate and we noted some rules we follow. 1) (Really a must): Each class should be in its own directory. (This means LabVIEW will go automatically to the correct directory when you want to save a method for the class.) 2) We use virtual folders in a class to distinguish between scope (Public, Private, Protected; we don't use Community) and purpose (AccessorMethods) but locate all methods directly under the class directory on disk. I don't see any reason to have subfolders under a class on disk. 3) We group closely related items (often these correspond to a UML package) in a virtual folder in a LabVIEW project and a folder on disk. This is especially true if we add the classes to a project library (.lvlib). 4) We do not, however, make the disk folder hierarchy match the class inheritance hierarchy. There is no reason to do this. Moreover, if we change the inheritance structure (e.g., insert a layer, or just remap the inheritance relationships) we do not want to have to move directories on disk (which is a bit more annoying if we have already checked files into source code control). 5) We find project libraries useful (for instance) when we want to copy a set of code and reuse it, but just with a new namespace. There are differing opinions in LAVA threads on putting classes in project libraries, though. 6) We use a template for our components now. We put code we need to customize or add to in the project and in a template directory. Common code is generally in the dependencies and in folders in the user.lib. (It took me a while to learn to realize the advantages of locating items in the user.lib.) 7) Something we have found useful is to put different applications (or other pieces) within a component (for control components, for instance the view may or may not run when the controller is running; having separate applications for the view and controller is, of course, necessary for cRIO applications) into separate projects. This helps us to concentrate on one piece at a time, and means that we can build the different pieces separately. For each component we have a top-level project that includes the subprojects, just for convenience. 8) On that note, I advocate using interfaces appropriately to separate source code dependencies effectively. This is especially true since different projects may use sections of the code in different ways. Nonetheless, our disk locations generally do match the hierarchies in the project on the macro level, and we have found that to be a really good idea. Generally the level on which we apply groupings matches a package (think diagram) in UML. (On that note, I will put in a plug for modeling. I think modeling is essential to end up with an optimal design.)

You didn't use the correct secret code word...

Important Point of Clarification: uploading code to LAVA does not automatically limit its use to the BSD protection/limitations. Code posted to threads are, by default, covered by Creative Commons, and uploaders of submissions to the Code Respository are given a choice on what license to apply to their Code Repository submission - we put the control in the hands of the creator by allowing them to select from a list of pre-defined licenses (the most common ones), but we also allow the upload to be covered by any other license - just include it with your submission. We offer this flexibility to allow the creator to choose how they want their code to be used - rather than us taking control of it (which is completely the opposite of what lavag.org was founded on, and continues to strive for today). I'm struggling to see how any of this issue can be at the feet of LAVA, as we have an as open system as I can imagine. So here's a constructive suggestion: rather than pushing LAVA members to upload their code to ni.com so NI can do whatever they choose with it (include selling it for profit without passing any of those profits on to the creator), maybe NI should suggest an appropriate license that people should use on lavag.org (or anywhere else) that NI can work with. Even if it's one that's not currently in the list, members could include it with their submission. We could even add it to the standard list, if that's what our members want. We could even make it the default selection, if that makes sense. We're here for our members - we're not resisting changes - if you want us to change, and it makes sense to Mike, we'll do it. It's really as simple as that. More information on how the LAVA Code Repository works is here: http://lavag.org/top...repository-work