Python in Process Control?
neil.benn at arcor.de
Sun Oct 3 23:43:45 CEST 2004
Comments beneath :
Peter L Hansen <peter at engcorp.com> wrote in message
news:<AcadnZxtQPvH9cDcRVn-sg at powergate.ca>...
> 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).
> 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
> > IMHO, I think that Python is not a suitable piece of software for
> > industrial control as it has poor support for bytes (a string
> > be used to store bytes!) and also bit twiddling is difficult
> > 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
> > that you can throw and as you know, when controlling equipment
> > 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!
> 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.
> 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.
This is my second attempt at a response - so if you get two mails back
then please forgive me!
More information about the Python-list