Stobber

VIPM is free for the community and why would you not want to use the latest?

Yeah, too many people assume that's a rhetorical question, but it has an answer: The latest version breaks otherwise stable features.

And that's where edge cases like you (and me) come in.

If using the VIPM API in automated build tools makes me an edge case, the LV community is in a bad way.

Yes, I can (and already did) manually install it. But if there's no reason to upgrade the package spec version, and upgrading leaves some users behind, then why not downgrade to accommodate me everyone?

I can't upgrade to VIPM 2014 because JKI broke the VIPM API with that version and hasn't fixed it yet. I use the API in my build tools, so it's a critical feature.

Is there any reason the package couldn't be built using VIPM 2013 to ensure compatibility with more versions of VIPM?

This package won't install using VIPM 2013 Pro and LV 2013.

"Compatible LabVIEW Versions" is 0.0.

The "spec" file in the VIP says Exclusive_LabVIEW_Version="LabVIEW>=10.0" though, so I'm not sure what's wrong.

I'm working in LV 2013. What tool does everybody use to find VIs that are still running in the background. Yes, this is an AF app.

It uses the 'other' SQLite toolkit

As long as we're counting, there are several SQLite APIs for LabVIEW, and multiple free ones among them.

It's in <vi.lib>/NI/Class Retrieval/

Not on my installation. That's the folder NI uses for their VIPM packages...maybe you installed a package that's not on the public server?

What's the path to the Class Retrieval library? I'd like to poke around and see what it can do!

No, I'm not trying to create a new project with the code. (I did try to get to the Bitbucket repo, but the link from the forum thread is broken. Is it still a public repo?)

I opened VIPM and realized that it doesn't think the pacakge is installed, even though there's obviously code in my <addons> folder. I reinstalled v1.2.1.23 and the palettes are still messed up.

[update]

Uninstalled the package, deleted the <vi.lib>/addons/JSON API folder, and then reinstalled. Palettes still look like my screenshot.

What palettes are you looking at?  My JSON API palette only has two items (the Get and Set polymorphic VIs).  

I see pretty much everything. Are you using auto-generated palettes?

Bug?

"JSON.lvlib:Get Item As String.vi" can't find its library on disk, and neither can I.

I found this function on the JSON Array palette.

Will anybody mind if I "clean" up the API and palettes a little? I want to:

- Give short names to palette items

- Create icons for all the palettes

- Rename some palettes

- Rearrange some palette items to group them better, maybe nest things deeper for more organization

- Expand the VI documentation for all public VIs

- Remove the probe VIs from the palettes

- Remove polymorphic instances from the palettes

- Remove test VIs from the palettes

I'd also like to do some things that would break backward compatibility:

- Rename several methods and functions to enforce "verb phrase" naming convention

- Standardize the names of many similar methods

- Remove test VIs from the package; I believe those belong in the source repo, not the distribution

Finally, I'd like to put out a "call for examples" and include any that are submitted. This is a big API, and it's hard to pick up without straightforward examples of both parsing and generating JSON. I'm still not even sure whether this is a DOM/XPath parser or a stream parser, or both!

Oh, I see. It only appears on the RT palette. Thanks!

I can't figure out where the VI to write to the console is. They deprecated the old RT Utilities API and Sys Config doesn't seem to have this function. I know I can watch a virtual console using the web admin interface, though. How do I write to the console from my application?

Hah, so I just go straight to the project XML for it. Thanks.

I'm trying to write a post-build step for my RT EXE that modifies ni-rt.ini on the target to enable the SNTP client. (I actually want this to be a post-deployment step, but LV doesn't give me that capability.) Does anyone know how to get the configured IP address of the target from the Project API? Here's where I'm stuck:

@Stobber. Direct modifications of the tags is not recommended and not supported. There is no documentation for those tags.

This attitude frustrates me endlessly.

http://forums.ni.com/t5/LabVIEW/Variant-to-Flattened-String-prim-crashes-LVRT-2013-on-a-cRIO/m-p/2726419#M807156

The Variant to Flattened String prim crashes an RT application in LV13. Does anybody know another way to get the type descriptor of a cluster?

Got it using VIs from vi.libUtilityVariantDataTypeVariantType.lvlib

GetClusterInfo followed by a FOR loop with GetTypeInfo.

*taps microphone* This thing still on? Or did LV13's JSON primitives supplant it?

gmart, is there any documentation explaining each of the tags returned by "BuildSpec:GetTagNames"? Figuring each of these out on my own will be a real PITA.

John, any update? What you posted 2 years ago is still pretty cool.

Son, I can't teach you all of programming. You need to step back and read some tutorials (and probably entire books). Here's a start: http://sql.learncodethehardway.org/

My supervisor told me not to use the SQL server. Make somthing easy concerning labview itself.

1. SQLite is a serverless DBMS. You just work with a file directly. It's ridiculously easy.
   
2. "LabVIEW itself", by which I assume your supervisor means the native APIs, doesn't have a good solution for this. "LabVIEW itself" will in fact make this harder. Your supervisor needs to let you use an appropriate tool for the job.
   

This is true, and I would also recommend an actual database, but that doesn't mean you can't do it with TDMS.

Let's not pollute the labor pool and the community by helping people shoot themselves in the foot.