Stobber

Huh? How? By wrapping them in subVIs? That still statically links to the NI-RIO xnodes. I need a way to dynamically load the code that calls NI-RIO at runtime. I ended up turning my IO API library into a class and abstracting it from the application with the Factory Pattern, but it took a lot of dumb boilerplate code, and now there's quite a bit of code duplicated between the Physical IO class and the Simulated IO class. I still hate it, but it works for now.

Lots of things about building plugin interfaces in LabVIEW are quite painful. So it's intuitive only to someone who started using LV before the static VI refnum was introduced...what percentage of total users do y'all constitute? As a LV 7.1+ power user, I had to post on LAVA to figure it out. I'd say that presents a case for reconsidering the UX on this feature.

I have an RT app. A pretty big one. It does a lot of stuff. I have a Windows app that talks to my RT app. In the interest of dividing labor, creating automatic unit/subsystem tests, allowing multiple devs to build on their own machines, etc. I need to be able to simulate the RT program on Windows. So I abstracted all the calls to NI-RIO using Conditional Disable Structures and added a "Simulator" VI that wraps the entire application while hooking into some custom messages so it can display information to the user. When I need to run on Windows, the RIO calls don't execute and the Simulator panel ties into the network connections. When I need to run on RT, the Simulator panel isn't called and the RIO calls execute. It works great....except on machines that don't have the LVFPGA module installed (because they only develop the Windows app). Even though the ConDis structures prevent code from being called, it still gets statically linked into the app. This prevents a Windows-only system from building the Windows app: it throws errors while looking for FPGA Module components. What's the best way to abstract the FPGA reference wire from the code to work around this? I hate the idea of creating a class hierarchy for my IO calls and dynamically loading the class at runtime because dynamically launched code is nearly impossible to debug on LVRT.

Completely unintuitive, but it works! Thank you gentlemen.

I want to use the ACBR nodes to launch and unload a VI, but they need a strict reference and I only know how to create one of those using a Static VI Reference. Statically linking to these VIs causes some build issues on other people's machines, though. Do I have to go oldschool and use the "Run" method with a non-static reference, or is there a way to get a strict reference without statically linking to the VI that I want to launch?

Yeah, too many people assume that's a rhetorical question, but it has an answer: The latest version breaks otherwise stable features. 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.

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

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.

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:

This attitude frustrates me endlessly.

I was mucking around in General Error Handler.vi today and noticed a weird subVI with a really intersting comment inside. Thought I'd share it with the crowd, since it applies to time-critical processes, thead swapping, and general compiler insights.

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?