Process Control Help

[Cameron Laird]

In article <heq5p4-29v.ln1 at lairds.us>, I mused:
>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
>			.
>			.
>			.
>>> 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.
			.
			.
			.
>>> 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.
			.
			.
			.
'Just occurred to me that a GREAT thing to do might be for a young
engineer to catch the SD Best Practices 2007 East in Boston in
September <URL: http://www.sdexpo.com/2007/sdbp/overview.htm >,
which is running concurrently with Embedded Systems <URL: 
http://www.embedded.com/esc/boston/ > (as well as RFID World <URL:
http://www.rfid-world.com/boston/ >).  They sell inspiration by the
half-hour.