> Despite what all the hype will say, do not expect it to be "Easy" or > "Quick" (whatever programming language you use, and I include LabView in > that respect too!) Programming, and doing it well, in any language, for > whatever reason, takes time and thought to get "Just Right", so that all > circumstances are covered. Something that many programmers seem not to > appreciate. What I mean, is expect errors from the instrument, and the > users input (often you!) and make the program robust enough to catch and > handle them safely. > > IF a condition is met (or not) > THEN do something you want > ELSE take care of any unexpected conditions
Great summary, Dave. This is one of the only pieces of advice I'd add a caveat to -- specifically, that user-friendly error recovery in the GPIB world can bloat your code at a geometric rate. What does it mean, for instance, if a write timeout happens on the 12th command in the 4th iteration of a 20-command loop? Did the timeout happen after the instrument accepted the command, or before? What *is* the instrument's state at this point, anyway? Should your program try to recover gracefully and offer the user a chance to retry the operation... or is it better to terminate the whole measurement and let the user recover from whatever unexpected situation occurred in the outside world? My own software sometimes fails on the side of recklessness, when a GPIB error brings up an unhelpful error message and aborts the whole program. That reveals its origin as a collection of quick and dirty hacks that were never meant to be seen by the outside world. Still, the code base would be much larger and harder to maintain if I actually tried to implement good SW engineering practices when talking to "stateful" hardware. In newer applications I've at least broken myself of the habit of terminating the whole .exe when something goes wrong, but I still don't believe in taking extraordinary steps to handle errors. Kill the current measurement and let the user do the troubleshooting, IMHO. Make a distinction between robust, general-purpose code written for end users and random hacks written to make your own life easier in the here-and-now. They both have legitimate places in your lab's ecosystem. > As my old college tutor kept trying to drum into us, the programs > purpose and function should be easily read in the comments. The "code" > is the translation from your comments, to get the machine to do your > bidding. > > Document what you do, in the source comments, line by line at times! > You'll save a lot of time when you come back to something later, even > only a few days time! Better, however, to write the *code* for human consumption in the first place. Comments age like dead fish. If you find yourself writing a long comment to explain something, chances are you should go back and find a simpler way to express it in the code itself. -- john, KE5FX _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
