Process Control Help

[Walt Leipold]

Azazello wrote:
 > 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.

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

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 
industry evolved, and the kinds of programmers and development teams 
that write industrial control packages.

 > If we could consolidate this software into a single, non
 > "black-box" package, we could see significant improvements
 > in development time.

You *might* save on development time (although I wouldn't bet on it), 
but you'll lose on testing time.  Heck, you'll even lose because you 
have to document your stuff and train people to use it -- what happens 
to your custom system if you get hit by a bus?

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

I share your frustration with the status quo in industrial automation. 
On the other hand, I've been brought in to customer sites a number of 
time to fix their re-invented wheels, and my advice is not to re-invent 
the wheel.

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.

For reasons of quality, long-term supportability, manageability, 
insurability, and several other -ilities, the sad facts are:

* Unless you're a hobbyist, if you want to do machine/motion control, do 
it from a PLC.  Windows is not reliable, stable, or real-time enough to 
be trusted to control moving pieces of hardware, and custom software, 
possibly with hand-crafted multithreading, is not as reliable or 
predicatable as ladder logic on a PLC.  (Look up "Therac 25" for some 
reasons why.)  Python is a great language, but it depends on the 
underlying OS for threading, and has a GIL that can bite you too.  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.

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

* Unless you're a hobbyist, if you want an HMI, purchase LabView or 
InTouch or RSView or whatever, and use their tools to draw and 
'configure' your screens.  (Where 'configure' generally means 'program 
in Visual Basic or some other brain-dead language', but we try not to 
say "program" -- customers and underwriters *hate* "custom" software.)

I personally think it's a tragedy that every manufacturer bases its HMI 
on Visual Basic for Applications rather than a better (and free and Open 
Source!) language like Python.  It's also a tragedy that the dominant 
i/o 'protocol' for industrial automation isn't really a protocol, and is 
Windows-only to boot.  It's horrifying that the primary means of 
communication between process control and data acquisition applications 
is via DDE or ActiveX.  And I find it incredible that people and 
companies will pay large sums of money for some of the industrial 
automation products on the market.  But that's the way the industry 
works, and, as frustrating as the commercial offerings are, using them 
will probably be better for you and your company in the long run.

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

-- Walt

"Eddies in the space-time continuum!"
"And this is his sofa, is it?"