Python in Process Control?

[Neil Benn]

Hello,

      Comments beneath :

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).

<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.
 >
 > >    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.

  Yep, that's why I put IMHO - don't get me wrong, I have used python 
for control and it has good sides and bad sides - like everything in 
life!  I j

 >
 > 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 know it works in python but it's an incorrect 
metaphor.  In the same way that a string is not a bunch of 8 bit chars 
(encoding.decoding etc).  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.

 >
 > 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...

If I can't twiddle bits correctly - I'm a bit stuck if I need to make a 
check sum from the bits in a byte array.  The RSP9000 doesn't require 
that sort of thing (or so I thought but I controlled the RSP9000 using 
the Turbo Pascal interface supplied with the machine rather than direct 
RS232 commands) but other kit does.  Also in my experience (~1 decade 
controlling and managing lab autoamtion) bit twiddling is something I've 
had to do a few times - it just depends on the interface supplied by the 
manufacturer.  Java's not much better at this either - I ended up 
writing a bit twiddling class to handle this - it's just that most 
business apps don't need bit twiddling so it's fallen out of popularity.
 >
 > 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.

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

 >
 > > 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.
 >
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).
 >
 > > 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...

Exactly, because python has a GIL and can only run in one processor a 
variable will never need to be marked as volatile.  In other systems 
this is something I would need to be concerned about - not in python!
<snip>
 > 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).

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.

<snip>
 > Actually, we *did* use ActiveX, unfortunately, because that's what
 > the customer wanted to use to interface LabVIEW to the driver <snip>
LabView isn't a bad tool, the use of wiring metaphors appeals greatly to 
engineers (as you'v probably expereicend) - also it is (again IMO) one 
of the best graphical programming tools out there.  I don;t use it 
because I can program and flow control in LabView is a pain but that 
doesn;t stop me having an a look in every now and then.
 >
 > -Peter

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

Cheers,

Neil