Process Control Help

[Cameron Laird]

In article <1185923367.122846.117750 at x40g2000prg.googlegroups.com>,
Azazello  <tylerca at jeld-wen.com> wrote:
>On Jul 31, 12:45 pm, Walt Leipold <leip... at ace-net.com> wrote:
			.
			.
			.
>> 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
			.
			.
			.
>> 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?
			.
			.
			.
>> 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.
>>
>> * 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.
			.
			.
			.
>I really appreciate your post Walt. I started this thread last week
>and I have to admit that in the subsequent days the 'option' of using
>Python for our control solutions is simply not feasible.  Although the
>project I wanted to implement was fairly small scale, no 20 ton pieces
>or x-ray machinery, the principle of the matter remains the same,
>especially as a large corporation.  As an intern returning to school
>in the fall, the underlying responsibility for a Python system was my
>original concern and discouragement to my employer for persuing this
>path.  It became readily apparent that using the crumby software
>packaged with our control devices is surely faster in the long run, as
>we are not involved in software development.  (The majority of my
>coworkers' formal programming experience is in FORTRAN) It has been a
>very discouraging few days.  There's so much room for improvement and
>yet...  My 4-day conclusion is unless you're already involved in
>controls software you must be crazy to join.  Are many young engineers
>entering this field?
>

At an anecdotal level, I'd guess that, no, there are few
young engineers entering this field.

Mr. Leipold's descriptions of the difficulties involved 
in use of Python are accurate, and I particularly support
his advice to use whatever commercial I/O you can find.
I've had success, though, introducing high-level language
programming, and even Linux, as an alternative to vendors'
APIs, Labview, and so on.  I'm not sure how to summarize
what went into this; perhaps the best is to emphasize how
flawed is the software that's typical with vendor APIs.

While there's more to tell about the errors in commercial
networking implementations, the horror of ActiveX, and so
on, right now isn't the time for me to detail it all.