Python in Process Control?

[Peter L Hansen]

Neil Benn wrote:
> Peter L Hansen <peter at engcorp.com> wrote in message 
> news:<AcadnZxtQPvH9cDcRVn-sg at powergate.ca>...
> <snip>
>  > 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.
> 
> Oh, how long ago was that as far as I know that model was discontinued a 
> long time ago.  I skipped a few of them myself (there's nothing wrong 
> with the machine - it's just an old model and not up to today's standards).

The project was only a couple of months ago.  I have no idea how
old the robot itself was, but that wasn't my concern.  The customer
had a robot and needed software... maybe he got it on Ebay. :-)

> <snip>
>  > 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).
> 
> Hmm, not sure about that - you need to look at the process it is being 
> used in and the cost of downtime.  In addition you also have to consider 
> the end users  and the cost of a lost unit - this is why people talk 
> about industrial automation in a lab setting with no concept of what 
> they mean, in the field of laboratory automaiton industrial automation 
> is typically used as a marketing slogan!!
>  In life science unit cost is an awkward indicator as it is very 
> difficult to put a cost on a lost unit - it could be nothing, it could 
> be billions!!  If you are interested in this field then there is an 
> active mailing list on laboratory automation, you can access it trhough 
> the american link of www.lab-robotics.org or the European link 
> www.elrig.org.

No idea what you are talking about, really.  When I use the terms
I used above, I mean nothing either more or less than "using a
computer to control other equipment".  Even talking to a
spectrum analyzer while controlling a signal generator falls under
the rubrik "industrial control" as far as I'm concerned.  Unit
costs?  Downtime?  Orthogonal issues which don't affect the term.

Hey, if anyone has a nice catch-all title that covers what you
call laboratory automation and what you call process control
and what you'd call the example I just gave, but which isn't
"industrial control", please offer it here.  I'd much rather
use a term that covers the whole spectrum rather than have to
list each subcategory of an unnamed general category each time
I try to talk to someone about it...

>  > 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.
> 
> I've also got python running controlling a bunch of kit - as for byte 
> support, sorry but a byte array should not have the ability to be 
> changed into upper case unless it represents characters - which bytes 
> patently do not.  

I haven't encountered any of my byte arrays accidentally ending
up with the alphabetic characters upper-cased on me... maybe you
need to do more testing. <wink> :-)  Really, who cares if the
data type used happens to support some functionality that doesn't
apply to the area you use it for?  Nobody is forcing you to put
.upper() in your code...

> Although yep, if you ignore the fact that it 
> is a string, with the string stuff tagged onto the side then you can go 
> ahead and use it with gay abandon.

I guess that's exactly what I do.  Yippee-kay-yay!! ;-)

> Nope I'm a geek!!  I couldn't find it on your website though.

http://www.engcorp.com/main/projects/FrontPage  under the name
CavroCom...

> By client - I mean client calling my code; not a customer - a checked 
> exception is an excellent way of making the client calling code writer 
> think about these errors.  People who are unused to controlling machines 
> are often unaware of the lack of control you have over yuor environment. 
>  However, test driven development is a tool that is used in many 
> languages - not just python.  Certainly in the control of machines you 
> must test and test again - however test driven development is a tool 
> that can be used alongside a variety of other tools such as UML, checked 
> exceptions and stress testing (that's what I call playing Doom3 while 
> controlling the robot with your code).  TDD is not a magic wand, it's 
> just common sense (to me anyway).

No real disagreement there...

> Cheers, I wrote a wrapper around PySerial to implement 
> listeners/observers (that's what the polling loop does, Twisted probably 
> does the same) - although if there is a published and supported 
> implementation then I'll use that.

As I commented (I believe) in an offline reply to your earlier email,
I don't think the way Twisted does this is likely to be a close
enough fit to the architecture of your app to bother, but feel
free to investigate.  I haven't yet attempted to convert the
stuff that I wrote on PySerial to use Twisted, but I plan an
experiment soon.

>  This is my second attempt at a response - so if you get two mails back 
> then please forgive me!

No problem.  I believe I got and replied to an offline query(*) with
some of the same content, but in any case I'm much happier carrying
on such discussions "in public" where others can contribute, flame
us as the idiots we are for not knowing about project X on Sourceforge
(which they just started last week) which will do exactly what
we want, and so on. ;-)

-Peter

(*) But it's equally possible either your or my spam-filter dropped
a message and we never saw it. ;-)