Where Kepware is at its best is when there are device drivers from various manufacturers thus establishing centralized communications.
What Kepware does is connect the device to the client. In answer to your question regarding other software, you would need the other software in that Kepware doesn't address the device side for programming or the client side for interface. This version does not always allow for certain drivers or plug-ins that are available through the non-OEM version. This is the OEM / Enterprise version of Kepware's OPC server. If you have any questions, feel free to post, pm or email.Īs has been mentioned, in some cases it is included with the client software. The diagram through our synergy page link will provide you with a visual idea of what KepserverEX can do.
This link includes a list of all products, manuals and data sheets where available. A current version of KepserverEX is available for download at our web site: These links will provide you with additional information regarding KepserverEX: We have extensive information on our web site as an authorized Kepware distributor. There may be additional restrictions relating to options that are available through a non-RA version. Regarding KepserverEX incorporated into RA software, it is limited in relation to the non-OEM product.
Its interface allows you to communicate between many different device driver protocols. KepserverEX is their flagship product and offers device drivers for many of today's control manufacturers. Kepware is an OPC Server product that acts as the bridge between devices (PLCs / DCS / CNC / Database, etc.) and clients (HMI software, Scada software, etc.) In the next release of the software, RSI disabled the feature that had allowed me to use that (unsupported, unadvertised) feature in the first place. That's when we discovered that RSView ME would happily make one connection to an external OPC server, but had no mechanism for reconnecting if that connection was broken. They wouldn't reconnect until we cycled power. Until somebody tripped over the Ethernet switch and my test PanelViews got disconnected.
It was pretty neat, and I was ready to buy all the rest of the terminals and install it at the customer. The performance benefit was that multiple PanelView Plus terminals (we had ten) could poll data from the OPC Server without adding additional traffic to the very heavily loaded DH+ network. The PanelViews actually went out over the Ethernet network and used the RSLinx Classic OPC server as their data server, rather than using the onboard RSLinx Enterprise or a physical DH+ module. The PC ran a 1784-PKTX module on the DH+ network, with RSLinx Classic as the driver and OPC Server. Another anecdote: ten years ago when PanelView Plus was very new, I tested a system where we installed a PC to act as an OPC middleman between the network and the PanelView Plus terminals.