In article <[EMAIL PROTECTED]>, I mused: >In article <[EMAIL PROTECTED]>, >Azazello <[EMAIL PROTECTED]> wrote: >>On Jul 31, 12:45 pm, Walt Leipold <[EMAIL PROTECTED]> 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. -- http://mail.python.org/mailman/listinfo/python-list