Python in Process Control?

[Cameron Laird]

In article <MJednUj3F8J40MDcRVn-sA at powergate.ca>,
Peter L Hansen  <peter at engcorp.com> wrote:
			.
		[constructive
		name-dropping]
			.
			.
>As one tiny example, I had to whip up a provisional driver for
>a Tecan (Cavro) robot for a customer who needed to talk to it
>with LabVIEW.  I spent the majority of two weeks learning
>ActiveX issues from scratch, and wasted a fair bit of time trying
>to do a COM server using the win32com stuff before switching
>to and successfully using ctypes.  I also used the excellent
>PySerial (thanks Chris!) module.
>
>In the end, the code that represents the robot-specific aspects
>of this, the protocol and command set and such, took only two
>days to write.  And it worked, first time (after my log messages
>allowed us to troubleshoot the customer's incorrectly wired
>cable) *without ever visiting the site for testing*.  This was
>for me an unprecedent occurrence in the history of my work in
>software.  (For those that don't do control: code that talks
>to robots *never* works the first time. :-) )
>
>Had I done this with any of the past languages I've used for
>the task, whether C, C++, Delphi, Java, I'm certain it would
>have taken several times longer, probably at least as long
>as two weeks.  (And I *have* done similar though simpler stuff
>in each of those languages which did take much longer,
>especially to debug.)
>
>I attribute the productivity to two things, roughly equally:
>Python, and test-driven development.
>
>Cameron: let's set up that list!  If nothing else it might
>encourage cowardly companies to start to share more things
>via open source, such as drivers for robots, which while they
>took time to develop are *not* part of a given company's core
>IP and which, if they contributed them to the community,
>would likely benefit from more improvements than the company's
>own programmers will ever be able to make...
>
>-Peter

It's possible to eliminate one of us; Peter and I just write
the same things.

Despite my usual abhorrence of redundancy, though, I'll relate
my part.  My industrial automation experience is quite shallow,
really, noteworthy only for my enthusiasm--and for the
consistency of my observations.  EVERY time I do process control,
there are days (sometimes--hold your hats; this is no
exaggeration--months (!)) of pleading, "No, I really want the
documentation where you say what it's supposed to do, and what it
really does", then the the getting-the-right-cables interval of
frustration, then we get a signal through, then various miracles
occur, and the conclusion is, "You mean it only takes thirteen
lines of code to do that?  Our software folks said it's not
possible."

The point is not any particular virtue in me; it's that the
advantages of high-level, test-driven development simply are not
known NEARLY as well as they might be.  It consistently blows 
process control vets away to see:
1.  efficient delivery and diagnosis through
    test-driven development; and
2.  compensation for undocumented product 
    defects on-site, in real-time, often
    while I or others are hundreds of miles
    away.

My conclusions for today:  Peter's right.  Moreover, I *know* I
can document huge swathes of the industrial automation world far
better than they're done now.  A lot of this stuff is easy, if
just explained sensibly.  There are huge efficiencies still to be
gained.

Peter et al.:  I'm crazy-busy the next week.  Stay in touch, 
though; there's got to be a better way to do this stuff, and I'm
thinking about it seriously.