> 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

 

Hi Greg. Greg Goodman wrote: > > > 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. Unfortunate, but true. > 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) If ODBC would do it we are in pretty good shape. Lots of free ODBC gateway stuff around. > 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. Code is in development. I will be persuing some sort of agreement with Groupe Schnieder if possible. I can't see why they would object too strenuously. > 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." No that's a limited but fairly good summary. For my part Linux will never be irrelevent and I expand the scope to include whatever else the customer needs for a complete free and open solution. And all of it with source code so that you can really know how it works and provide excellent service for your customers without pulling out your credit card or spending hours listening to bad muzak and sales hype on hold. Another goal is to be able to use the right IO hardware for the job regardless of manufacturer. And to provide a community of peers for support that really understand what you are trying to do and want to help. And of course to let you provide that last 10% that you can't seem to get using any one manufacturers line. And the option of simply putting the application on a larger system if it grows, the only cost being of the hardware. More "seats" simply means more hardware. And no forced upgrades or dll hell or version churn or instability or the other things that balloon support costs and really have nothing to do with your solution. The goal is to make the economics so compelling that you'ld be crazy not to use it. The Linux based products I sell are already this way, simple as they are. How about what you are currently using? If your platform cost approaches zero and your total solution price changes only enough to make sure you get all the jobs you want, doesn't OSS begin to make a lot of sense? We'll have a much better business case if you can get past the "gotta be Windows thing". We'll try to help you out either way. > 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). But, I'll wager that code then belongs to WW. I'm certain someone will see fit to do this but it probably won't be us and they probably won't be able to share it. It'll probably have to be done over and over. We have a better idea on how to treat integrators and users. Don't get the idea that I'm criticizing you. What I'm saying is that we have a lot more going on here that is good for the industry than simply a PLC replacement, it's a whole new way of providing solutions with tremendous advantages when fully realized. Looking at the PLC in isolation you don't gain anywhere near as much. A better PLC doesn't solve all the other problems with the status quo. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc