Leaderboard

What? Been there since pre-8.2? Who's been laughing at us flailing around with locked-down multi-VI XNodes (or multi-multi-VI polymorphics) for years? This seems to answer 99% of my (and everyone elses) requests for a simple type-adapting VI. Looks like a very simple XNode without any type-checking (e.g. wire a Boolean to the Delay input and it generates the code but breaks the calling VI). But if the programmer can be trusted, it looks incredibly useful. I would presume it has the same caveats as using an XNode, but if it's now "released" (thanks jkodosky, who I imagine has some mandate to do so) it would be good to know anything to be aware of. BTW, this is certainly not the same as the buggy, non-supported Generic VI that was dangled in front of us some time ago.

I've created 30-40 XNodes, and while I haven't done so, I think almost all of them could be replaced by VIMs. But most of mine are pretty simple, roughly equivalent to the OpenG Array XNodes, which I think could also probably all work well as VIMs. Knowing that VIMs are just generic XNodes is kindof reassuring - while they have a few issues, they seem to me to be a lot more stable and usable than say XControls. I've got pretty high hopes for VIMs, just no time to do anything with them at the moment. Yes, this makes sense, as most of my existing XNodes are essentially polymorphic replacements, which is why they seem to be good candidates for VIMs. However, what does blow my mind, even more than VIMs existing, is that AQ had no knowledge of them! All my preconceptions are demolished! Hopefully this is like feeding a mouse to a tiger - it only makes him hungrier...

So I'm still (slowly) looking at what it would take to connect LabVIEW to an IPython kernel. As well as the 0MQ binding (which I'd seen but never played with), and JSON serialisation support, it looked like being able to sign things with HMAC-SHA256 might be useful. So I've created a little SHA-256 library (pure G to make it OS and bitness agnostic). I might put it in the code repository if it seems generally useful. university_of_leeds_lib_sha_256_library-1.0.0.2.vip

I have nothing constructive to add other than... Wow.

I was wondering what that "GenericLabVIEW" XNode was for. Interestingly it seems like you're supposed to also be able to select a background texture for the node when "show icon" is turned off (i.e. "express VI"-like display mode.) But the image files are missing, so it doesn't work. But I don't think .vim stands for VI Macro. I think it just means it's an improved VI. /s Interestingly, the code for generic VI's is actually still in LabVIEW, even 2015. Even the hidden option that I assume Aristos used to create the example one he posted. (Add "GenericsAreGo=True" to the ini, right-click a control/indicator and there's a new "Generic" toggle in the menu--don't use it in anything you care if it breaks of course!)

Just twice? So your LabVIEW stability went up? Just kidding.

Crosspost

I have the impression that Juypter is very much focussed around textual languages - I think most of the existing clients expect to send text to their kernels and get back a mixture of text and graphics. LabVIEW doesn't really lend itself to this paradigm. You could, of course, write an interpreter in LabVIEW that took textual input and did stuff with it, but frankly there are probably easier things to do. Where it did occur to me that Juypter might be interesting for LabVIEW developers would be in something along the lines of LabPython - which although it works great, does have issues with both 64bt platforms and using non-thread safe Python modules (notably numpy!). I have a feeling that Python 3.x is not supported either. A LabVIEW based client for Juypter kernels might be a way around this by decoupling the scripting language from the LabVIEW executable - allowing mix and match 32bit/64bit, newer versions of Python, alternative language bindings etc.... Just needs someone who understands the LabVIEW scriptnode interface, C bindings to 0MQ, and how to do the Juypter protocol - which rules me out on erm, 3 counts :-( !