In college and highschool, we (really, the ubiquitous We, since i'd have this conversation with anyone who cared), spent a lot of time discussing the merits of different programming languages, about which model worked best and which was fastest for a given application. I spent a lot of time at work and home tinkering with different languages. Fortran, C, shell script (tcsh & pdksh), javascript/html, VB, perl, Igor, and labview.
However, I'm a career chemist, not a computer scientist. My goals are very much focused on cranking publications and not fine tuning code. I've come to realize the best tool for a lot of problem is the one you have to effectively solve the problem. One example: at work, one of our visualization products is written in
Delphi. I doubt that would be the tool of choice for many people, but the scientist who is the PI knew pascal really well (back in the 1980s!) and it has stuck over time.
Of course, the tool you have works great, until you reach its limits. I use Labview for instrument automation. It has a easy to use GUI toolkit, and knows a lot about hardware and signals, right out of the box. Yesterday, I found something it doesn't know much about: drawing arbitrary graphics on screen.
I'm building a control package for a vacuum manifold that preconcentrates gases before injecting them into a gas chromatograph. I thought it would be nice to give a visual representation of the flow paths that were open by drawing the manifold on screen. It turns out, labview doesn't give you many tools to do easily do that:
What this image is showing is that Labview's 2D drawing stack is entirely procedural, with no facilities for storing, moving, or transforming images after they've been created. Anytime your program wants to update an image screen, the code you write needs to explicitly redraw the entire image. It's not possible to algorithmically create a sprite library, then scoot the sprites around, or rotate or otherwise transform them. You have to build a bunch of routines that describe objects and then push those around.
Pain.
This means that it's going require writing quite a bit of code to make a panel that easily represent the open flowpaths to the user. Achieving that kind of functionality is not a high priority for the project, so for the time being, it will fall back on using more generic, less descriptive indicators.
If you're standing in front of the hardware, it's possible to guess what this means, but I think that's going to be beyond the grasp of inexperienced users, so I consider the solution to be suboptimal. Experience has shown that analytical error rates scale with the steps the analyst must complete and the clarity of state and hardware protection that software can provide. This panel doesn't clearly show linked flow paths, or if the instrument really knows if gases are moving or pressure tolerances are being exceeded.
Things could be a lot better.
I suspect there is a better way to do this. Some years back I had a coworker that was quite good at getting labview to have process flow diagrams; essentially the same thing you want to do.
ReplyDeleteSadly, I do not know how he did it, and I no longer have access to that codebase. One guess is that he found a a way to use a outside images.
I had thought about making an external library of images to load en masse. The problem I had with that was I think that translates into ~128 individual cases (in this scenario, it's probably best to handle the edge conditions, as almost any valve combination is plausible).
ReplyDeleteI'd really like to declare objects and then change their colors (kind of like in SVG).
Actually, if there was a labview SVG library.... but there's not.