Python in Process Control?

[Peter L Hansen]

Neil Benn wrote:
>          Just out of interest - which tecan robot were you interfacing 
> to - every Tecan robot that I've ever programmed comes with a high level 
> API (Toolbox, Gemini, Logic, WinWash, Magellen).  

I meant to mention, but only barely implied, that the source is
actually available, on Engenuity's project page.  It was a
Cavro RSP9000 robot.

> I would think however 
> that controlling a tecan robot in the environment that it is typically 
> being used in (life sciences R+D) is not industrial control (its my job 
> BTW!).  It's not like making milk....

I use the terms "industrial control" and "automation" rather
interchangeably, along with "laboratory robotics" and other
terms.  It's all the same thing, regardless of the end user,
except when regulatory issues get involved (aeronautics, FDA
approvals, etc).

>    IMHO, I think that Python is not a suitable piece of software for 
> industrial control as it has poor support for bytes (a string shouldn't 
> be used to store bytes!) and also bit twiddling is difficult (people who 
> ask about his on the Python newsgroup are usually shouted at).  

Well, let me see how to answer this politely. :-)  What you *think*
and what is reality are not necessarily the same thing. ;-)  No,
the more polite answer is really that this is an area where perhaps
it's more a matter of opinion than anything else, and mine differs
from yours.

Python certainly has *excellent* ("perfect"?) support for manipulating
bytes, and if you consider that a string is not a string, but is
actually a sequence of bytes, then other than being misnamed for
this application area, a string provides great support for bytes...
certainly *in practice* it works wonderfully, and I guess as someone
who has used Python very successfully for industrial control I'm
somewhat qualified to say so.

As for bit-twiddling, it's rarer than you might think to have to
do more than the odd shift, OR, and AND masking, and maybe an
exclusive-OR or two for spice, and Python is well enough suited that
this isn't really an issue.  Performance-wise, if you have to do
such things to a very high-bandwidth stream of data, it might run
into troubles, but (a) there are options, and (b) it hasn't bothered
me yet...

I was going to show an example from the Cavro code mentioned above,
but all it took was a few | and & operations and it's too boring
to show.

> The 
> other thing that is a problem for python in this is that it is very 
> difficult in python to make your your client is aware of all the errors 
> that you can throw and as you know, when controlling equipment there is 
> a lot of things that are out of your control (an exception that is 
> rarely thrown will often not be caught if the programmer never sees it 
> running and gets lazy).    

Absolutely!  Uncaught exceptions would be a real pain to a customer.

So would untested code.

Not using good testing procedures would be a real sign of carelessness
or sheer incompetence.  I hope no one would subcontract for industrial
control software with anyone who would actually produce software of
the sort you describe above.  Of course, I recommend and use test-driven
development for my code, and don't suffer from the problems you
describe.  And did I mention that the software worked flawlessly the
first time it ran, and has had no bug reports in the month or two
of use it has seen since then? ;-)

Note also that these problems have nothing to do with Python,
and everything to do with poor programming practices.

> apps a little easier to write - although I still spent about 2 days 
> trying to work out how to make a variable volatile (culminating in 
> understanding the threading module!).  

All variables are "volatile" in Python, at least in most senses of
the word.  I don't understand what you were doing...

> The serial module is good but I 
> think that a model of input and output streams with listeners/observers 
> would make far more sense, currently I have to make a polling loop to 
> receive the data, 

You might want to investigate the use of Twisted's serial module,
which wraps around PySerial and effectively provides this, instead
of doing the polling loop approach (which, by the way, I also used
in the Cavro code but might change to Twisted in a later version).

>    Good to see that you didn't use ActiveX (if one more company _boasts_ 
> that their equipment comes with 'industry standard' ActiveX I think I'm 
> going to cry)!!  Believe it or not I still have to interact with some 
> equipment using DDE!!!!

Actually, we *did* use ActiveX, unfortunately, because that's what
the customer wanted to use to interface LabVIEW to the driver.  It
does work, and works reliably, but in the end it's the use of
LabVIEW for this stuff to which I object more strongly than I
object to the use of ActiveX.  (Without LabVIEW in the picture,
however, ActiveX would also have been unnecessary, as we would
have gone pure-Python.)

-Peter