I'm trying to get a fleet of cRIOs to run in concert with AWS' IoT "framework", for lack of a better word. Being a framework of sorts, it brings a bunch of tooling for running a fleet of IoT devices according to best practices (security, etc.) and is practically infinitely scalable.
I've examined the LabVIEW Cloud Toolkit for AWS by NI ( https://sine.ni.com/nips/cds/view/p/lang/en/nid/215508 ), and while the toolkit works for communicating with certain AWS interfaces in general (S3, SQS, and a couple others over HTTP), it does not work with the IoT framework.
The main reason is that devices are meant to communicate over MQTT. What's more, the TLS session is mutually authenticated by both the client and the server. TLS is barely available on some platforms in LabVIEW, so no MQTT library has this even close to implemented (I've checked). Luckily, these sorts of security-related items and more are already implemented for us in AWS' collection of C libraries:
As simple as build and install? Almost! But alas, no.
The one dependency I can't satisfy is OpenSSL, which needs to be 1.1.0 or greater. Everything else works (I've tried it) NI Linux RT only has 1.0.2 in the repos. Thus my questions:
I suppose my alternative is to construct the entire application in Python. There's the NI libraries for FPGA (DAQmx doesn't work on RT), and there's the AWS libraries in Python. As a side note there, the Python base that NI provides is nearly deprecated and I'm hoping there's an upgrade path before too long there too.
Don't know much about the AWS IOT framework, but you mentioned it has a python library. You can call python from LabVIEW, so maybe just do that? You could also just have a seperate python app that communicates to the AWS MQTT server and relays those messages over localhost to your LabVIEW program.
Thanks for the reply, Sam.
This is on a real-time cRIO. I know there's at least two great ways to call python on Windows (Enthought library and now the built-in nodes). But if there's a way to do it on RT, please let me know. I could only find suggestions in the idea forum for it. The built-in nodes break if you move them under an RT target, too.
I could probably call multiple scripts to pass info to python, but that gets ugly fast since I'm hoping to pass a lot of data and each sysexec call spins up a new bash shell session. The other way is to start a python script and pass everything over local networking (or unix pipes). That path is clunky in its own way, because now I have my application split across two very different toolchains and long-term maintenance and debugging gets to be ugly.
I'm a bit disappointed that RT doesn't have a way to call directly from LabVIEW to python. Being built on Linux it should be almost painfully easy. (I say "should" - but of course that's expectation compared to everything else on Linux rather than technical lift to get LabVIEW there).
Please correct me if I'm wrong - I would LOVE to be right now!
I don't have a secret on how to call Python in LabVIEW RT. I thought there was some trickery involving ssh or something. Part of the problem is that LabVIEW RT runs in a chroot. I think the solution is to run sshd outside the jail and ssh into the main linux instance and then run your python commands. Some googling might reveal a post or two on the forums about that. I remember seeing it somewhere.
I don't know enough about pipes to know if pipes work across a chroot, but I imagine localhost would.
I agree that adds an extra layer, I guess you could spin it as a feature. It's more modular or an abstraction layer or something.
Good point about the chroot. I knew it LV code ran as lvuser, but didn't realize it was a chroot. I guess that may make it harder to run the main python script from there. It's easy enough to run it with a startup script and connect over local TCP, but still a bit of a hurdle.
However, I'm beginning to think that it might be easier to run without LabVIEW at all. If we can't get the C AWS libraries working, I'm beginning to think the total effort would be far less if we were to simply use python. Python to call the AWS libraries, and to call the FPGA API (since DAQmx doesn't work on cRIO, but the FPGA VI does). 90% of what we want to do is encompassed in acquiring a waveform and sending it in a (properly authenticated) MQTT message.
My worry with python on cRIOs these days is that the version in the repos is nearly deprecated. I don't have it in front of me, but I think it was python 3.5.5, from around 2018. When I ran pip update, it gave me a deprecation warning. With the way AWS keeps up to date, that may not have a very long runway unless NI updates the package repos soon.
Hmm.. As far as python versions, I know Ubuntu is very far behind, but there is deadsnake? PPA you can add and pull the latest version from there. I know the ni linux rt stuff uses opkg, maybe there is an opkg repository you can pull the latest version from?
If not, I guess you would have to build the latest version? That sounds like a pain. I would ask around and see if someone else has already put in the leg work.