Jump to content

gb119

Members
  • Content Count

    302
  • Joined

  • Last visited

  • Days Won

    5

Everything posted by gb119

  1. 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...
  2. That was the direction I was thinking in - when I've finished unbreaking the effects of changing JSON parser 🙂
  3. 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....
  4. 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: OpenG Toolkit libraries, particularly the LabVIEW Data, string, error and array libraries The JKI JSON library - I had to pick a JSON serialiser and the JKI one seemed as good as any and better than some... The JSONText JSON serialiser library available via VIPM The Zero-MQ Labview bindings - libzmq is the underlying network transport used in Jupyter and there is an excellent LabVIEW bindings library for it. The attached SHA256 implementation so that the communications messages are properly HMAC signed. 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
  5. I would use a lockin amplifier with some sort of comms interface:-) Failing that you could simply implement the same algorithm - multiply your signal by sine and cosine waveforms at the refetence frequency, low pass filter, calculate the mean and feed into x,y to polar co-ordinate convertor. Altetnatively, up-sample the signal, feed into an FFT, index out the right (complex) element and covert to r,theta.
  6. Having to use the accessor vi rather than a property node tripped me up - I can see how the compilation issues mean not accessing the private data directly, but not the difference between calling an accessor vi directly or inside the property node.....
  7. I've seen variants of 'Vi Failed to Compile' with projects involving complicated class hierarchies and class instances as data members of other classes etc. Nothing particularly new - I've seen this in versions of LabVIEW from 8.6 onwards - usually simply opening the offending Vi 'standalone' is enough to get it to compile then everything is ok until the next time that LabVIEW decides it needs to compile all my code. Now in 2018 64bit I've got a slightly odd one where when I open my top level Vi, LabVIEW decides that the Actor Framework isn't compiling, but if you open that first and then load the top level Vi everything is fine... I find it incredibly hard to debug the issuse as it only happens when one has a sufficiently large project. Keeping compiled code separate seems to make it more likely, as does having very large class hierarchies or classes with private data containing classes. Actor Framework also seems to be a contributing factor. The error message is almost as helpful as the old MacOS installer error "There was a problem with the hard disc, please use a different one....."
  8. Assuming that "crap" is not a vialbe option, I like "brittle" too. "fragile" to me would imply code that is susceptible to runtime errors as opposed to one that is easily broken by subtle changes in editing. Perhaps "chaotic"in the maths sense might suit?
  9. Well, the screenshot you showed implies that Python threw a Syntax Error exception - although I can't immediately see why. There are a couple of issues that I can see in your code though: 1) You've got several Windows style paths quoted in strings there, but \ in Python is an escape character - to include \ in a string you need to either do "C:\\Python27\\Lib" or else use a raw string r"C:\Python27\Lib" 2) There is a major limitation to do with thread safety between Python and LabVIEW - LabVIEW is intrinsically multi-threaded and some Python libraries - such as numpy - are not. This can lead to seemingly random crashes in LabVIEW - so not your current problem, but likely to become one... There's been quite a bit of discussion in various threads here on this problem by folk who know more than me about the internals of both LabVIEW and Python.... (and I've just spotted, does np.loadtxt close files when passed an open filehandle - if not then you'll be leaving files left open by your script.)
  10. As well as having 32 bit LabVIEW, is your Python 32bit as well? What distribution of python are you using (or vanilla python 2.7?) I've failed to get recent versions of anaconda Python to play nicely with LabPython whereas vanilla 2.7.10 from python.org was ok. Sometimes I find that running VI Package Manager via 'Run as Administrator...' is necessary even though my user account is a member of the Administrators Group. The error looks like it's a file permissions problem, so probably the latter is the first place to try...
  11. Indeed - this is what I had in mind as 'keeping state in the sub-vi'. The OpenG library polymorphic vi is a nice little wrapper for this.
  12. In the specific example I had in mind, keeping the input at the same value would cause the instrument to reset, whilst not changing the input doesn't - so 'No Change' is different from 'the same again'. You can then either expose the "No Change" option to the end user - but that might be more confusing. The alternative (which is what I normnally end up doing) is to have separate enums/rings for the UI and the underyling driver - but then you have to keep them consistent otherwise it gets very confusing(!). (there's other alternative strategies like maintaining state either in the caller or subvi - or possibly hardware - of course). In the subvi, I'd argue that code that detects sentinel values e.g. by looking for NaN in floats or default values for rings would be less transparent than each control having a property node IsWired? that is only true if that control was wired when that subvi was called. Bounds testing on control values is then just about making sure its a valid value and doesn't get overloaded with a "value was supplied" meaning as well.
  13. I'd quite like this feature for cases where the natural type for an input is a ring or enum, but you also want a "don;t change" as the default option. Yes, you can have "don't change" as one of the enum/ring values, but that then gives an ugly API. There's certain instrument driver type subvi's I have where the instrument has a mode e.g. a waveform shape, and some common parameters - amplitude, offset, duty cycle. One could have separate subvis for each of these parameters, but it's also nice to have just the one vi that would change only the parameters that were wired up and would leave alone those that weren't.
  14. HDF5 is used quite widely in big facilities based research (synchrotrons, neutron sources and such like). It's a format that supports a virtual directory structure that contains meta-data attributes, and multi-dimensional array data sets). Although it's possible to browse and discover the names and locations of all of the data in the file, it's generally easier if you have some idea of where in the virtual file-system the data thatr you are interested in is being kept. There;s a couple of LabVIEW packages out there that provide an interface to HDF files and read and write native LabVIEW data types - they work well enough in my experience, although I haven't personally used HDF5 files in anything other thn proof of concept code with LabVIEW.
  15. One of the things I wanted to be able to do was to read from both ends of the buffer - so to have a way to get to the most recent n items for n less than or equal to the size of the buffer. So I tweaked the read buffer XNode template to handle a negative offset meaning to read from the current buffer position backwards (i.e. Python style). This, of course breaks LabVIEW array indexing semantics, but for this particular situation it makes some degree of intuitive sense to me. The attached is my hacked template. XNode Template.vi
  16. I really liked this, so I couldn't resist a minor hack - I added a search method that lets you specify a regular expression (also made the method selector a type def to make it easier to add even more methods. The only downside wasn't that I can't inline the Search Filter 1D Array of strings because I've added an XNode in there in the form of the PCRE search vi - so it'll have killed performance a little. Find References XNode 1.0.2.1.zip
  17. Hmmm, that's odd because I'm running Python 2.7.10 and 2.7.11 with LabPython VIPM packages just fine when I installed Python from Python.org, installing the same versions from Ananconda tended to cause LabVIEW to crash, but I had been assuming that was something to do with which version of Visual Studio had been used to build the two sets of binaries. Do the changes you've made in the LabPython codebase potentially allow Python 3.x to be used, or is goign to continue to be just a Python 2.x thing ? In the ideal world, I guess one might replace LabPython with something that looked more like an ipython/juypter client that could talk to juypter kernels to allow multithreaded LabVIEW to play with non-threadsafe Python modules. But in the ideal world, I'd have the time to look at trying to do that...
  18. LabPython only supports python modules that are threadsafe (this is because LabVIEW is multi-threaded, but Python has places where it isn't (related to the global interpreter lock). Unfortunately numpy and scipy are not thread safe, so it's easy to trip over this and crash LbaVIEW. Newer versions of Anaconda also seem to have problems with LabPython (Anaconda 2.3 onwards I think), but vanilla Python from www.python.org seems ok.
  19. Python 2.7 works with LabPython on LabVIEW up to (at least) 2014, 32bit only, BUT there is something about the anaconda builds that causes LabVIEW to crash on recent 2.7 releases. Running plain vanilla python as downloaded from python.org works fine. One gets the feeling that LabPython in its current form is not goign to be viable for very much longer as both languages continue to develop (Python 3.x and 64 bit code are not supported for example, the scripting node interfaces are not well supported with public documentation) - probably a better solution would be to build an interface between LabVIEW and a Juypter (ipython) kerenel process - but I know I don't have time to work on anything this complicated :-( Any python module that is not thread safe will also cause problems - unfortunately that includes numpy - but sometimes one can avoid tripping over the non thread-safe bits if one is cautious in which bits of numpy one tries to call).
  20. 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
  21. 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 :-( !
  22. It's on my list to overhaul the update state ability and ensure the version numbers are sanitized for a future release - but, whilst I happy that folk are using the code, the XNode versions tarted up as a 'proof of concept' to show that it could be done.... Unfortunately the update will be delayed by small things like teaching undergraduates :-)
  23. Hmmm, not sure what has happened there. I'd have to go back over those versions, but I don't recall that I made a change to the state type of the control which is where I'd expect to have to use the UpdateState ability. Unless that was the point where I jumped from LabVIEW 8.6.1 to LabVIEW 2012, in which case the version jump might be causing the problem.
  24. I guess as the proponent of the "other" method of using templates in XNodes, I'd say it's a trade-off between work done in preparing the template and work done in the XNode ability - but mainly when I started playing with XNodes we didn't have inline subvi's (I think, or they were very new and I didn't trust them inside an XNode). Working out which thing to copy from the template can be just a convention that there is one node object on the top-level of the template - tagging the tunels just made it easier to keep track of what got wired where.... I've been toying with the idea of setting up an LVClass that implements all of the XNode abilities as dynamic dispatch methods of the class. An XNode with an instance of a child of this class as it's state control and whose abilities just wrapped calls to the relevant methods would be a sort of "Universal" XNode whose behavious was controlled by the class. Setting up a new XNode would then just involve making a new copy of the Universal XNode, setting the default value of the state to be an instance of a new child class and then filling in the child class methods. The advantage is that you can edit a class with regular LV tools - so it makes it all a bit easier.... One could even write an intermediate generic templating XNode class, perhaps that got information about which controls needed to be adapted to type from the control captions - implementing a new templated XNode would then just mean creating a new child class, adding the template and going...
  25. YEs, that would mean implementing LZW compression in native LabVIEW which seemed like a lot of work....:-)
×
×
  • Create New...

Important Information

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