A few years back, I wrote sort of a poor man's test automation and control panel framework - the beginnings of one, anyway - using Ruby and GTK+. More recently, specifically after Qt became available under LGPL, I started playing with substituting Qt for GTK+, since the GTK+ API for some features that I regard as indispensable was not at all stable, and besides Qt looks slicker.
Well, there were silly issues with background images not working right from stylesheets when widgets were created from Ruby, and then there's the minor detail that the Qt bindings for Ruby seem to be no longer maintained, so there's no support for Qt5, which has some nice features that I'd want to use, and....
Well, so maybe I'd use ECMAscript, which is supported as part of Qt5?
This whole things has been on behind-the-back-burner priority for quite a while now, though with the new mini-test-equipment program it seems like time to dust it off, no?
And then... someone mentioned node.js, in an entirely different context. I took another glance at it. And... maybe? Hm. Other people are already using it for lab automation: good!
So there may already be a suitable not-NI framework for the instrument-communication and test-sequencing side of things. As for the control panel?
Well, looking at what's routinely done with HTML5, a control panel with the usual features would seem to be a perfectly mundane browser app. And the new canvas feature appears to support the kind of cool stuff I'd started playing with in GTK+ back in the day, for fripperies like steam gauges and Nixie readouts.
This also provides handy separation of the test application and its GUI. GUI runs on the user's browser; test app runs on the lab machine (which could also be running the browser); they communicate over TCP or whatever.
And, since the software framework was supposed to end up open-source anyway (I want to sell hardware and consulting services, not software and tech support), piggybacking on something that's already happening seems like a good move.
This also leads to a thought about communication with gadgets....
SCPI, Standard Commands for Programmable Instruments, is kind of long in the tooth, innit? There are Issues, for example, related to its HP-IB origins; SCPI over TCP turns out to be rather troublesome for application programmers owing to the lack of the out-of-band signaling that the old bus provided. And it's not really for programmable instruments so much as merely connected instruments.
So... what about instruments that have built-in JavaScript interpreters, and can take immediate commands and scripts to be stored for later execution? And return data in JSON format?
I haven't looked yet to see if anyone's already playing with that, but it seems worth a ponder, next time I have some pondering bandwidth available. I haven't even looked at the size of JavaScript interpreters. (Or perhaps some sort of tinyJavaScript? Anyone remember the various flavors of tinyBASIC, etc.?)
Anyway: to the back burner with this! I have more urgent stuff to do the next couple of weeks.
Update: A bit of fiddling while my brain is fried this fine blustery afternoon.
I determined that the version of node.js included in Debian-Jessie is way outdated, and followed the instructions for installing from a node-oriented repository - on my workstation, which is still on Wheezy. Then I tried a little code sample that uses the serialport package (which appears to be nicely cross-platform):
eric@magrat:~/tinker/node.js$ node listserial.js
/dev/ttyACM0
/dev/ttyS0
/dev/ttyS1
/dev/ttyS2
/dev/ttyS3
/dev/ttyUSB0
eric@magrat:~/tinker/node.js$
Hmmm. Notice anything interesting here? Yes! It finds not only ttyS* (including the ones that don't actually exist, but this is a longstanding Linux Issue, and the application may need to do some filtering to eliminate ports that can't actually be opened) and ttyUSB*, but also ttyACM*, which some serial terminal programs don't seem to know about after all these years - USB modem? Wozzat then?
So... assuming that the rest of the library actually works and talks to the ports as it should, that's a good start on communicating with MCUs.
This may not sound like a big deal, but the absence of proper cross-platform serial-port support for Ruby has been a persistent annoyance.
Recent Comments