Process Control Help

[tylerca]

I'm attempting to start some process control using Python. I've have
quite a bit of literature on networking, and have made some tinkering
servers and clients for different protocols HTTP, FTP, etc... But now
it's time for the murky web of industrial protocol. I'm looking to
start with IO and servo controls via Ethernet.

Questions:

Is there an existing forum on this already?
What protocols are the most python friendly? i.e. are transparent
enough that i can create my own python driver. (or do these drivers
exist?)
What ethernet accesible servo and IO industrial devices have people
had success with?

[Hendrik van Rooyen]

<ty*****@jeld-wen.comwrote:

>

I'm attempting to start some process control using Python. I've have
quite a bit of literature on networking, and have made some tinkering
servers and clients for different protocols HTTP, FTP, etc... But now
it's time for the murky web of industrial protocol. I'm looking to
start with IO and servo controls via Ethernet.

Questions:

Is there an existing forum on this already?
What protocols are the most python friendly? i.e. are transparent
enough that i can create my own python driver. (or do these drivers
exist?)
What ethernet accesible servo and IO industrial devices have people
had success with?

What is it that you are trying to do?
Some of the commercial devices come with their own software, and
you may not need python or anything else.
A lot of the industrial connectivity is still RS-485 or RS-422 and not
Ethernet based - although some of the protocols, have, I think, been ported.

If you say more, then someone can maybe help you, as there are quite a few
people on this group who seem to dabble in process control.

- Hendrik

[Azazello]

On Jul 28, 1:40 am, "Hendrik van Rooyen" <[e-mail]:

<[e-mail]:

I'm attempting to start some process control using Python. I've have
quite a bit of literature on networking, and have made some tinkering
servers and clients for different protocols HTTP, FTP, etc... But now
it's time for the murky web of industrial protocol. I'm looking to
start with IO and servo controls via Ethernet.

Questions:

Is there an existing forum on this already?
What protocols are the most python friendly? i.e. are transparent
enough that i can create my own python driver. (or do these drivers
exist?)
What ethernet accesible servo and IO industrial devices have people
had success with?

What is it that you are trying to do?
Some of the commercial devices come with their own software, and
you may not need python or anything else.
A lot of the industrial connectivity is still RS-485 or RS-422 and not
Ethernet based - although some of the protocols, have, I think, been ported.

If you say more, then someone can maybe help you, as there are quite a few
people on this group who seem to dabble in process control.

- Hendrik- Hide quoted text -

- Show quoted text

We're looking to run some industrial machinery from a PC. Starting
with some basic servo controls and IO port reading for something like
an XYZ table (just X would be a good start!). Now there is some
existing software out there for PC control but this software is, to my
understanding, largely unnecessary and "black box". This "black box"
creates a problem when trying to e.g. control servos and IO with the
same program. And if we want to include an HMI like a touchscreen, or
export the machinery's production into a RSS feed, the web of software
becomes messy and slow. If we could consolidate this software into a
single, non "black-box" package, we could see significant improvements
in development time. Having to program 3 different devices with three
different languages to control your PLC, Servos, and module X is the
status quo we face, but it is quite frustrating and limited. Soo....
I need to find some ethernet friendly IO, serial would be fine but but
it's a leash in many instances. I know some protocols have been
ported to ethernet, but I am having extreme difficulty figuring out
what these protocols entail. ModBus/TCP is the one I'd like to
choose. I know that people have done this kind of software but it
seems that industrial python remains a bit taboo because of
proprietary issues...

Ty

[Paul Rubin]

Walt Leipold <le*****@ace-net.comwrites:

The first time you see twenty tons of machinery move
unexpectedly because you inadvertently changed one bit in memory, you
become very conservative about your software platform.

+1 QOTW

[Hendrik van Rooyen]

"Walt Leipold" <lei...e-net.comwrote:

8<--------------- summary of state of the art -------------

(Wow, that was a depressing post to write.)

Cheer up! - The end is nigh!

Warning:
The rest of this post is barely on topic for python,
and contains some shameless self advertising. Its
probably bad for your health too.

I have just spent considerable time developing some stuff.

I call it SDCL - simple distributed control language

Its a simple scripting language, that is interpreted.

The HMI bits are python, the "compiler" is python,
the simulator is python, the interpreter in the PC is
python. What is not python is the interpreter in the
PLC - that is a mix of Assembler and C, for speed.

You can run the code either in the PC, or in the PLC,
or as a mix of both - obviously fast stuff needs to run
in the real hardware, but a lot of the control, checking
and sequencing functions fall naturally into the PC.
With the PC logging, you get ISO 900x almost
automatically, as any change to a variable that lives in
the PC is logged.

The language is still a bit "brain dead" - it implements a
virtual Reverse Polish Notation stack machine and reads
like assembler, with less than 40 instructions to learn.

A real compiler is planned for some unspecified future time.

The first app is an injection moulding machine, and it has
been working for some months now, with crude animation
of the machine's motions on screen, and everything from
star-delta timing to thermocouple heating inputs and control,
as well as screw position and injection pressure sensing on
the PLC.

There are just over 3000 instructions in the sequence to
control this machine, and the "address space" is 64k of
instructions - so it is aimed at fairly serious control.

Unfortunately at this stage the "PLC" is Microcorp proprietary.

But the whole thing is aimed at simplifying the problem of
putting voltages on wires and reporting the results to a PC.

I intend to open the spec as soon as I am satisfied that there
are no fearsome dragons left lurking in the code or the design.

- Hendrik

[Cameron Laird]

In article <11*********************@e9g2000prf.googlegroups.c om>,
<ty*****@jeld-wen.comwrote:

>

I'm attempting to start some process control using Python. I've have

[Cameron Laird]

In article <11**********************@x40g2000prg.googlegroups .com>,
Azazello <ty*****@jeld-wen.comwrote:

>On Jul 31, 12:45 pm, Walt Leipold <[e-mail]:

[Cameron Laird]

In article <he************@lairds.us>, I mused:

>In article <11**********************@x40g2000prg.googlegroups .com>,
Azazello <ty*****@jeld-wen.comwrote:

>>On Jul 31, 12:45 pm, Walt Leipold <[e-mail]:

.
.
.

>>It has nothing to do with 'proprietary issues'. A lot of it has to do
with the perception of support -- who will support Python and custom
Python code if my plant shuts down? Who will train my developers and
operators? Who can I sue? The rest of it is because of the way the

.
.
.

>>Yes, it's a shame that you have to buy three packages to perform three
functions, and then buy other 3rd-party packages to tie them together.
Yes, it's a shame that industrial software is expensive, and
proprietary, and Windows-only, and generally has a brain-dead scripting
language (when it has any scriptability at all). Still, as much as it
galls me to say it, if your company's primary business isn't writing
industrial automation software, don't write industrial automation
software.

.
.
.

>>* Unless you're a hobbyist, if you want to do data acquisition or i/o,
purchase an i/o server for your particular bus/instrumentation from a
major manufacturer. You *can* write your own i/o server, especially for
simple protocols like Modbus, but the commercial versions have been
tested more exhaustively than you can manage. Also, the most common
protocol these days is OPC, which isn't a protocol at all in the
conventional sense -- it's a set of APIs to a Windows DLL, with the
wire-level details completely opaque -- so you'd have to buy a library
for that anyway.