G
> But I have potential > customers/clients who have standardized on Wonderware, for > instance, and any control system that is proposed to part of > their systems has to work with that system. AFAIK, that means > OPC or DDE. > Ken This is very much to the point. The PuffinPLC project aims to produce a PLC. People who use PLCs often want to monitor and manage them using SCADA/HMI packages. And most of those SCADA/MMI packages run on Windows. I'm a big fan of and a minor contributor to Open Source and the Linux community, but I do not require that my clients be the same. And while I expect a capable, full-featured, Open Source, Linux-based SCADA package to suddenly appear any week now - no, really, I do - I do not expect the control and automation client base to embrace it anytime soon. If PuffinPLC is going to be a viable PLC option for people who aren't ready to use PuffinSCADA on Linux for their alarms and trends and history and user interfaces, then PuffinPLC is going to have to provide either: 1) communications facilities for which the HMI packages already have drivers (i.e. Modbus, CAN, DNP3, etc) 2) communications facilities that use IPC mechanisms the HMI packages support (i.e. an OPC wrapper for OIC, or whatever becomes PuffinPLC's native protocol, or a PuffinPLC NetDDE server, or an ODBC interface, etc) Personally, I think PuffinPLC's initial and primary protocol for communicating with an HMI should be an open implementation of the slave side of Modbus serial and Modbus/TCP (neither of which requires the proprietary Modbus+ SA-85 hardware). Every HMI on the planet can talk to a Modbus source. If PuffinPLC responds to a Modbus master, we integrator types can at least consider using it. Of course, that presumes that the goal of the PuffinPLC project is to produce a PLC that can compete with other PLCs for any job in which PLCs are a component. I had understood that the goal was to produce something that looked and acted like a PLC, possibly embedded on a PC-104 card in a DIN-rail-mounted enclosure, whose selling point was its robustness, performance, versatility and low cost, and whose underlying operating system was, to the user, completely irrelevant. On the other hand, that's just my opinion and, as Dennis Miller is wont to say, "I could be wrong." By the way, the preferred method for implementing Wonderware access to new I/O data sources is to write a driver with the Wonderware I/O toolkit. The toolkit lets you write a program which communicates with the data source in its native tongue, and serves the data to Windows programs via DDE, NetDDE, and/or SuiteLink (Wonderware's proprietary implementation of DDE over TCP/IP). Regards, Greg Goodman -- Chiron Consulting [email protected] _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc