Most "Open" Vendor


Thread Starter

Curt Wuollet

Hi all As part of a review process to find the vendor and product line that best suits our needs, I am calling on the vast and broad knowledge of the listers to save hours of research and put together a short list of vendors who give more than lip service to the "O" word. We have been evaluating product lines but, this is extremely difficult as you normally have to dig quite deep before you discover the "gotchas" and hooks that loom large once you have bought into a PLC line. The criteria are somewhat subjective as we do a lot of integrating existing equipment and have been dismayed at how little interoperability and commonality exists. We do not see many of the advertised advantages of OTS PLC's as we are dealing with comms and data interchange and other areas where the current proprietary model is weakest by design. Who does the best job in the following areas: Interoperability: Supporting the most "foreign" protocols and providing tools to support the oddballs or create your own. This is for fieldbus and data connections. Who publishes their protocols? Third party support: Who works the best with independent I/O and components, for example Wago, Beckhoff Bus Terminal, etc.? Tools: We use Linux for comm. service, vision, bulk computation, and data conversion/processing. We currently use DOS based tools only because the alternative is Windows based tools with the particular vendor we are now using. As documented often on this list, Windows can be problematic in the areas of stability, communications and handling legacy environments. One positive trend we have noted is support for browser based interfacess. Has anyone advanced this to the point that you can use their products without the need for Windows? Is anyone hinting at Linux tools? SCADA: We currently run Cimplicity IU. It is reliable, robust, and no longer supported. The proposed replacements are not. What are the non-Windows alternatives? We are pressured by the non-support of the SCADA and the move towards "Windows only" programming tools. The Linux PLC will probably be the long term answer, but we need to find the most open environment in the meantime and there will always be needs that are best met by a PLC. I'm hoping that the list collectively knows just about everything available and can help navigate through the proprietary minefield. Thanks Curt Wuollet, Linux Systems Engineer Heartland Engineering Co.
This posting is a gentle tooting of ones own horn. We are bucking the Windows trend and committing to the continued support of Vsystem on multiple platforms, including Windows NT/2000. We believe that we are open in the important sense, that is we give our users the APIs and help they need to interface their own code, including process models and IO that we do not support. As this is a news group, I will be an engineer and not a sales person and admit that our weak spot is that we do not have a long list of IO that is supported at the product level. After all we support 8-9 computer platforms (VMS (2) ELN(obsolete) tru-64 UNIX, VxWorks, Linux, Solaris, Concurrent PowerUX and NT/2000) and multiply that by the types of IO and you can see the problem. Frankly, we fit best with those who understand computers, protocols and programming. Our GUI has a new Java/Web display option (as well as MS Windows and X-windows). All the platforms intercommunicate on the network seamlessly (engineer speaking again) We are as open as we can be and still keep beans on the table! I hope that this helps. Peter Clout Peter Clout Vista Control Systems, Inc. 176 Central Park Square Los Alamos, NM 87544-4031 (505) 662-2484 FAX (505) 662-3956 [email protected]
My 2C: Siemens are terrible. Not only does it cost $3000 to buy the spec to their native PLC protocol (for one for the PLC's they actually sell in large volumes, not the expensive ones;-) ), but you need to sign an NDA so you cannot share code snippets etc. The low cost PLC's have secret mechanisms for programming, lest anyone should thing of making a better product than their own StepWin which is (IMHO) deliberatly nobbled to make it unsuitable for larger/complex projects (for which the hardware is quite capable). Modicon (Telemechanique) and OMRON are good, they make their native PLC protocol available freely so you can do what you like. OPC are dastardly. The keep flogging the DCOM business like it is leading edge whilst the new MS platforms and Visual Studio 7 beta make it quite clear that this is technology on the way out. I cannot blame OPC for being led up a gum tree, but now they are hastily looking into how automation can be done in the .net framework and keeping it all behind closed doors. The discussion is limited almost entirely to vendors as end users generally do not have budgets for participating in organisations that require some comittee attendance. Bring it out in the open chaps! Let end users talk about what they would like to do!

Frank Iwanitz

Hi, you are wrong in some cases. First, I never heard the word dastardly. But this is my problem. The other problems are more serious. Why should OPC move to .NET? It has taken a lot of investment to build opc solutions based on dcom. DCOM will be supported in the next ms os (as DDE will be). .NET provides a new way to write apps. I do not know anything about .NET ambitions of OPC. Why do you think that the discussion is limited to vendors? why do you believe that vendors (like Softing) do have more money as end users like GM? Both are opc foundation members. The foundation and especially the working groups managed to came up with suitable solutions which are used in about 600 products. They can not be totally wrong. You are right in some degree, requesting a more open approach to opc specification definition. There are a lot of things that are not very good in opc. But I can not see any REAL alternative. You mention that end users should be more involved. You are right. But asking five you will get 6 answers. We always include end user feedback in our products. But end users do have different views as vendors have. Regards, Frank