Python in Process Control?

[Wolfgang Keller]

Hello,

is it that my know-how to use Google is insufficient or...

....does really noone use Python for industrial control applications?

At least I didn't manage to find any publicly available modules for such
things as OPC/fieldbus communication etc...

TIA,

best regards,

Wolfgang Keller

[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

[David Fraser]

Peter L Hansen wrote:

Wolfgang Keller wrote:

There seem to be some Python bits out there, for example MatPLC and
Lintouch use Python and some commercial products as well (PyDACHS), but
unfortunately there doesn't seem to be a more or less consistent library
for industrial automation or a coordinated effort to build up one.

What, in your opinion, would it take to start one? I'm able to
offer the use of a server to host a web site, and would be happy
to register a domain name or something, but those are the easy
bits. Some kind of core group to get it off the group is likely
more important than a name, though sometimes threads in this
group might lead one to suspect otherwise. ;-)

No need to do servers/websites/domains, just use sourceforge...

David

[Grant Edwards]

On 2004-10-01, Neil Benn <be**@cenix-bioscience.com> wrote:

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!)
It's incovenient, but it works. I often end up converting the
string representation to/from a list of integers.
and also bit twiddling is difficult (people who ask about his
on the Python newsgroup are usually shouted at).

Bit twiddling didn't used to be difficult, but it's getting
more so. :( Programs that used to be fine are now throwing
warnings about shift operations, hex constants, and things like
that.

A while back, somebody wrote a pure-python fixed-length integer
class that looked like it would be handy. A C implimentation of
byte arrays would be very handy, since then you wouldn't have
to convert back and forth between strings and lists of
integers.

The combination of a C-language byte-array and C-language
fixed-length integer operations would kill.

--
Grant Edwards grante Yow! I feel partially
at hydrogenated!
visi.com

[Peter L Hansen]

David Fraser wrote:

Peter L Hansen wrote:

I'm able to offer the use of a server to host a web site, ...

No need to do servers/websites/domains, just use sourceforge...

SourceForge is, from my perspective, an incredibly unreliable
and awkward beast, and I'd be loathe to host anything on it
at this point. I _might_ host an actual project on it, but
I certainly wouldn't consider it for what I'm actually picturing
in this discussion, which is some sort of "Python in Automation"
"portal" or whatever they're called these days... something
along the lines of a combination of a wiki, maybe an RSS feed
(if someone will explain what the benefit is), a mailing
list, and maybe some sort of Vaults-style way for people to
provide links to their own projects (some of which, doubtless
would be SourceForge-hosted).

The simplest thing that could possibly work (tm) of course,
is a wiki and a mailing list, and I can have that up in
a few minutes if desired...

-Peter

[Cameron Laird]

In article <MJ************ ********@powerg ate.ca>,
Peter L Hansen <pe***@engcorp. com> wrote:

[Cameron Laird]

In article <ma************ *************** ***********@pyt hon.org>,
Neil Benn <be**@cenix-bioscience.com> wrote:

[Richard Brodie]

"Neil Benn" <be**@cenix-bioscience.com> wrote in message
news:ma******** *************** *************** @python.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!)

That's largely a matter of attitude I think; many would argue that byte
strings shouldn't be used to store text.

[Cameron Laird]

In article <ma************ *************** ***********@pyt hon.org>,
Neil Benn <be**@cenix-bioscience.com> wrote:

[Dennis Lee Bieber]

On Fri, 01 Oct 2004 15:08:11 GMT, cl****@lairds.u s (Cameron Laird)
declaimed the following in comp.lang.pytho n:

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
Not process control, but my current assignment fits this
roadblock quite well.

I'm stuck with writing a requirements document, software design
document, and then the software, to read a binary stream from device-X.
The only documentation I have for device-X is that I have a 2400baud
RS-232 connection. There is no documentation as to parity, word-length,
stop bits, or handshaking. I'm guessing 8N1 as it is binary data, but
will have to determine handshaking by trial&error.

Furthermore, I don't know how many bytes are in the data stream
per data item. The people who would know if it is fixed or variable
length, or if it even has a delimiter between data items, stonewall with
a "you have no need to know that information".

Scarier thought, device-X is loaded from device-Y which appears
to be using 5-level (+parity?) paper tape! (I'm sure it isn't a 9-pin
tape -- looked like 4pin, sprocket, 2pin). Maybe I'm expected to receive
5-bit data and convert to 8-bit to write as hex...

Just typical government imposed SNAFU... (and people wonder why
so many projects go over budget?)

-- =============== =============== =============== =============== == <
wl*****@ix.netc om.com | Wulfraed Dennis Lee Bieber KD6MOG <
wu******@dm.net | Bestiaria Support Staff <
=============== =============== =============== =============== == <
Home Page: <http://www.dm.net/~wulfraed/> <
Overflow Page: <http://wlfraed.home.ne tcom.com/> <

[erik.wilsher]

I work with process automation myself, and I belive that writing an OPC
server is *not* a trivial task, even in python. There are some good
books available on this subject, the OPC-foundations home page contains
some good references.

If you want to get started with client code quickly, you could try the
QuickOPC ($) library from OPC-labs (www.opclabs.com). Setting up a
client in python with that library is three lines of code (really!):
------
import win32com.client
import time
s = win32com.client .Dispatch('OPCL abs.EasyDA')

def test(times=1000 0):
v = s.ReadItem('',' Matrikon.OPC.Si mulation', 'Saw-toothed
Waves.Real8','' ,0)
t0 = time.clock()
for i in range(times):
v = s.ReadItem('',' Matrikon.OPC.Si mulation', 'Saw-toothed
Waves.Real8','' ,0)
print time.clock()-t0

test(1000)