connectivity (OPC)

  • Thread starter Juan Carlos Orozco
  • Start date
D

David Nimmons

Wonderware and other MMI's do not use OPC to communicate with the hardware, but instead use Modbus, DH+, ControlNet, etc. OPC is used to allow external applications such as spreadsheets access to the process data, with Wonderware acting as the OPC server. For Wonderware to communicate with the LinuxPLC, all that is required is a driver for Wonderware that speaks the LinuxPLC protocol. Wonderware will then provide the OPC access. When we develop a Linux based MMI, then we have to decide whether or not to provide OPC functionality. Since so many 3rd party applications depend on OPC for access it would probably be desirable. At the plant where I work we use Aspen for our historical trending and Pavilion for advanced process control. These communicate with our Foxboro and ABB DCS's using OPC. These are both Unix based systems and if I am not mistaken the OPC server runs on the Unix machines, so it should be possible to implement OPC without requiring Windows. I, personally would prefer to come up with our own protocol and convince all the third party vendors to support it also since I hate using anything associated with Microsoft, but, reality being what it is....... Ken Irving wrote: >My hope is that those Linux MMIs will stand up to the competition on an equal (or more so ;) basis, when they're available and demonstrable. 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. < _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Juan There is another possibility that I like, replace all that expensive stuff with Linux stuff. I have to think that way, being a peripheral on a massive NT network doesn't do it for me. And I need to think that's possible and a major improvement. Otherwise what are we trying to do here? I am pragmatic enough to see your point and I'm not criticizing you, but we gotta have goals and it's my job to focus on them. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Jim Redman: > I'm all in favor of a good rant and strongly held positions but I think > that it emphasises a problem that I have with the LinuxPLC project. ... > Linux is, to my mind, a great platform for factory automation, and my > choice of OS on my notebook. However I think that I'd be just as > disappointed with a world only Linux as I would be with only Windows. Linux is not quite as monolithic as Windows, but that's neither here nor there, I guess... You're quite welcome to make a Windows port of PuffinPLC. [on Java] > For example an IEC editor that runs on anything (say Palm Pilot) would be > a great addition to the project You're quite welcome to write an IEC editor in Java. That's the real trick, I guess. In the OSS world as elsewhere, saying ``A, B and C should be done'' rarely carries anywhere near the weight of ``I've done A, B and C and here's the tarball''. Technical arguments can rage for weeks or months (see the archives); working code, preferably based on rough consensus, does wonders. Jiri -- Jiri Baum <[email protected]> Q: Why did the chicken cross the Moebius Strip? A: To get to the other... um... er... --r.h.f.r _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J

Juan Carlos Orozco

Hi Curt, First of all, I want to say that I am not trying to persuade to use OPC and specially not trying to persuade to use DCOM into this project. It may seem this way because what I am in favor is to achieve maximum interoperability for the LPLC project, I think this is the best way of achieving exactly what you intend, this is to replace the expensive stuff with Linux stuff. OPC is to LPLC what SAMBA is to Linux. And modbus is to LPLC what ftp is to Linux (in the file sharing sense). The second analogy needs some explanation, modbus and ftp are both very good things and desirable to have them, the problem is that for certain applications (windows file sharing in the case of ftp) it does not integrate so well to the environment. Specifically it would be a good thing to have an exposed catalog of the available IO points of the LPLC with human readable names to interconnect with an MMI. As a real life example, a customer with Wonderware for a plant supervision and about 10 machines with a mixture of Siemens S5, S7 and SLCs integrates a network using two separated local networks (RS485) each to communicate with Siemens and AB. The networks end on a windows machine and Wonderware communicates with all of their machines for plant supervision. As an exercise how could we migrate to Linux in this company. The first step would be probably to put in new machine automations an LPLC with modbus and integrate to the Wonderware machine via a separate modbus RS485 or modbus/tcp. The next step besides putting more machines with LPLC would be to try to change Wonderware (when LPLC has a competing software available). One option for this step is that our MMI can be used as OPC client and use the information available from the other non LPLC networks maybe as an intermediate step. Other probably better solution could be to use network cards and Linux drivers to integrate LPLC MMI to the Siemens and AB PLC networks. One possible scenario is that a customer such as this will be reluctant to switch to another MMI because a) The one they have work and they are afraid of trying something new, b) Even if the new MMI is free it is very expensive to program all their specific configurations for their plant. In a company that this last scenario is the case is where a complete integration via OPC of the machines that use LPLC become first class citizens and a compelling option against other brand PLCs. Conclusions: OPC is not the only solution to integrate LPLC to current PLC networks (Profibus, Devicenet, etc...) but it is one possible solution. For some private networks like siemens MPI it could be the only solution other than doing a special driver. A very desirable feature for a LPLC is to expose a catalog of available services, alarms, IO, History using human readable names. This could be achieved using OPC or inventing our own protocol. For LPLC to become a first class citizen on windows based supervisory systems such as Wonderware, Intellution, etc... it would be good to have an OPC bridge that takes into account the previous features. This is where the first analogies in this writing applies. It is a good idea to think of replacing the expensive stuff with Linux stuff but it is not realistic at least for some years to come. Juan Carlos Orozco ACElab Industrial Automation [email protected] www.ace-lab.com _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Juan Juan Carlos Orozco wrote: > > Hi Curt, > First of all, I want to say that I am not trying to persuade to use OPC and > specially not trying to persuade to use DCOM into this project. It may seem > this way because what I am in favor is to achieve maximum interoperability > for the LPLC project, I think this is the best way of achieving exactly what > you intend, this is to replace the expensive stuff with Linux stuff. > > OPC is to LPLC what SAMBA is to Linux. And modbus is to LPLC what ftp is to > Linux (in the file sharing sense). The second analogy needs some > explanation, modbus and ftp are both very good things and desirable to have > them, the problem is that for certain applications (windows file sharing in > the case of ftp) it does not integrate so well to the environment. > Specifically it would be a good thing to have an exposed catalog of the > available IO points of the LPLC with human readable names to interconnect > with an MMI. Yes, it would. We don't need Windows to do that. > > As a real life example, a customer with Wonderware for a plant supervision > and about 10 machines with a mixture of Siemens S5, S7 and SLCs integrates a > network using two separated local networks (RS485) each to communicate with > Siemens and AB. The networks end on a windows machine and Wonderware > communicates with all of their machines for plant supervision. As an > exercise how could we migrate to Linux in this company. The first step would > be probably to put in new machine automations an LPLC with modbus and > integrate to the Wonderware machine via a separate modbus RS485 or > modbus/tcp. The next step besides putting more machines with LPLC would be > to try to change Wonderware (when LPLC has a competing software available). > One option for this step is that our MMI can be used as OPC client and use > the information available from the other non LPLC networks maybe as an > intermediate step. Other probably better solution could be to use network > cards and Linux drivers to integrate LPLC MMI to the Siemens and AB PLC > networks. One possible scenario is that a customer such as this will be > reluctant to switch to another MMI because a) The one they have work and > they are afraid of trying something new, b) Even if the new MMI is free it > is very expensive to program all their specific configurations for their > plant. In a company that this last scenario is the case is where a complete > integration via OPC of the machines that use LPLC become first class > citizens and a compelling option against other brand PLCs. > > Conclusions: > > OPC is not the only solution to integrate LPLC to current PLC networks > (Profibus, Devicenet, etc...) but it is one possible solution. For some > private networks like siemens MPI it could be the only solution other than > doing a special driver. This one interests me. > A very desirable feature for a LPLC is to expose a catalog of available > services, alarms, IO, History using human readable names. This could be > achieved using OPC or inventing our own protocol. Or even with some existing cross platform products. > For LPLC to become a first class citizen on windows based supervisory > systems such as Wonderware, Intellution, etc... it would be good to have an > OPC bridge that takes into account the previous features. This is where the > first analogies in this writing applies. This one seems to interest other people a lot. But this is where we could do the most good with replacement. > It is a good idea to think of replacing the expensive stuff with Linux > stuff but it is not realistic at least for some years to come. I find that attitude very fatalistic. There is a great deal of application code that could be shared with the project if we can provide the basis and make it attractive. You are assuming that we will have to write all this with our tiny group of coders. That's like assuming that Linus wrote all of what we call Linux himself. At least 95% of Linux is contributed from outside the core kernel development group. This, not the genius of a few is what makes OSS work. Once we have a platform for add-ons we can expand the number of contributors exponentially. Consider this, everyone who has written their own software for automation, HMI, SCADA, etc. has done so for much the same reasons that we are doing LPLC. This maverick software is very difficult to market on it's own. If you can combine it as a whole package, it becomes much more viable. If you can shift your model to services and contribute the software to the cause you stand to gain immensely compared to letting it molder. It will happen, all we have to do is frame the movement and get it moving. It's much better to be a part of a strong OSS movement than to craft even the most elegant software that is used only once and no one else sees. Think about it, all the ingredients are there, we need to provide the catalyst. Regards cww _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
J
Andrew: Normally devices ignore transmissions they do not understand. If there are three, four or more devices hanging on a 485 port each with its own protocol, device 1 will not respond to the protocol used for device 2, 3 etc. This is based on a master slave setup. To have emergency signalling the slave device would have to initiate the transmission. "maximum length" is also not a problem since each protocol typically will have different transmission lengths. jeff _______________________________________________ LinuxPLC mailing list [email protected] http://linuxplc.org/mailman/listinfo/linuxplc
 
Top