Jump to content
gb119

LabVIEW client for Jupyter Kernels

Recommended Posts

For a while I've been tinkering with the idea of building a LabVIEW client that could to talk to Jupyter kernels for interfacing with Python having been previously a user of RolfK's OpenG LabPython package. Although this, and now the native LabVIEW 2018 Python support have many uses (and indeed I use them in my 'production' code), there were a few things that a Jupyter kernel client can do:

  • Not be tied to particular versions of Python - LabPython got stuck for me around 2.7.10 and I think was fussy about which compiler have been used. The 2018 native support is restricted to 2.7 or 3.6 I believe (3.7 defintiely doesn't work)
  • Not being tied to the same 32/64 bits of LabVIEW
  • Being able to offload the Python to a remote server, or go cross platform

I haven't investigated the Enthought package (too much hassle to get a new vendor set up on my University's purchasing system and not really able to justify spending tax payer's money on playing!) which I suspect might be doing something similar.

Anyway, the attached zip file is a proof of concept - it includes a test vi that will try to find an ipython executable and fire it up and you can then interact with it. There's lots of things not properly tested and probably a slew of bugs as well. To run it you need several dependencies:

  1. OpenG Toolkit libraries, particularly the LabVIEW Data, string, error and array libraries
  2. The JKI JSON library - I had to pick a JSON serialiser and the JKI one seemed as good as any and better than some...
  3. The JSONText JSON serialiser library available via VIPM
  4. The Zero-MQ Labview bindings - libzmq is the underlying network transport used in Jupyter and there is an excellent LabVIEW bindings library for it.
  5. The attached SHA256 implementation so that the communications messages are properly HMAC signed.
  6. LabVIEW 2018 - sorry I'm only writing in 2018 now and this code uses malleable vi's with type specialization and asserts in use - so it may not be easy to backport

There's a few things that I'd still like to figure out - primarily the client protocol is very much focussed (reasonably enough) around the idea that the client is sending strings and is interested in string representations of data.I'd like to figure out an efficient way to transfer largish LabVIEW data structures backwards and forwards. I think this probably means developing a custom message handler and registering it with the kernel when the code starts and writing some Python 'flatten to string' and 'unflatten from string' code - but that's only this week's concept....

If you use it, please note that this probably only alpha quality at best -  it may or may not work for you, it may not be safe to use, If it causes any loss or damage or eats your cat then it's not my fault....

Edit 6th MArch 2019: I've switched the JSON parser to JSONText, found and fixed a few bugs, managed to build a VI package for it that should have the correct dependencies and installs the example client in the LabVIEW example finder.

 

university_of_leeds_lib_sha256-1.0.5.3.vip

university_of_leeds_lib_jupyter_client-1.0.1.5.vip

Edited by gb119
  • Like 2

Share this post


Link to post
Share on other sites

Why not just use JSON as your message format?  Python will have JSON libraries.

Both JKI JSON and the OpenG Variant Tools are very slow, BTW.  Try JSONtext, which I developed partly just to get reasonable performance.

Share this post


Link to post
Share on other sites

So for transferring largish chunks of floating point data (e.g. image data or similar) JSON is quite unwieldy (and I worry about losing precision when round tripping to/from ascii data). I haven't looked at it in enough detail, but it seemed to me that there was a good chance that the numpy representation of a double float and LabVIEW's might be sufficiently close that one could do a fairly efficient pack/unpack operation.

I take the point about the speed of the JSON serialisers - the choice was more influenced at this point by what I was used to workign with than speed. I'm looking at replacing it with yours and ijn the process keeping more of the message as raw JSON strings rather than storing in arbitary lusters in variants....

Share this post


Link to post
Share on other sites

You could consider a JSON header, followed by binary data.  I strongly suspect the float representation in both languages is identical: IEEE standard.  

Share this post


Link to post
Share on other sites

That was the direction I was thinking in - when I've finished unbreaking the effects of changing JSON parser 🙂

Share this post


Link to post
Share on other sites

The original article has been updated with a new version of the JuPyter Client build as a VI Package. This version has switched the parser to JSONText and removed the OpenG dependencies, and fixed up a bunch of bugs. The example client application gets installed into the example finder. It's still far from production ready code...

Share this post


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.


×
×
  • Create New...

Important Information

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