Understanding Client, Server & I/O Messaging for Ethernet Networks

Ethernet communications in the industrial sector is on the rise the advantages in speed and accessibility over serial communications are making it the new standard for industrial communication industrial automation protocols have several methods of communicating when devices from different automation suppliers need to communicate with each other specialty communication interface products are required selecting the ideal method depends on your specific application requirements if the best method is not used problems can develop later that could negatively affect your bottom line this video will discuss specific application examples that should help you understand how to select the best method for your application we'll be using our products in these examples but the principles apply to all Ethernet based automation communication solutions we'll begin by defining what the different methods are most industrial automation protocols have two methods of communication there's client-server data communications and input output message communications each of these methods has its own properties and characteristics that make them suitable for different applications both are used to read and write data between devices IO messaging is used when communication timing variations are not acceptable client-server data communications are used when some variation in communications is tolerable clients are devices that initiate communications and servers respond clients cannot talk directly to other clients and servers don't talk to other servers it's possible for a PLC to act as a client a server as well as an IO messaging master simultaneously on the same network communicating with various server devices and clients while controlling remote IO devices as applications demand IO message communications are given higher priority by the processor while client server data messaging are given lower priority IO messages are designed to run at regular time intervals meaning the communication speeds are consistent whereas regular data messaging speeds are dependent on the availability of unused processing power SCADA hosts or HMI terminals on the other hand are almost always configured as a client other devices such as drives can act as a server or as an IO message slave whereas remote i/o racks primarily act as i/o messaging slaves but can act as servers depending on the protocol to illustrate the dynamics of these different methods of Ethernet communication will run through some examples of devices configured in each of the different methods we've just discussed and examined the benefits and other considerations of using those methods we'll begin by taking a look at a PLC that stalks Ethernet IP that needs to communicate with an HMI that talks Modbus TCP for this example we'll use a Prosoft gateway to exchange data between the two different protocols the design goals for this example is to have data communication speeds of no slower than 500 milliseconds and access to the communication Diagnostics through the PLC the HMI is a client and so we'll have to configure our gateway as a Modbus tcp/ip server to communicate with it in this case we'll make the gateway a server on the Ethernet IP side as well this means we'll need to use message instructions in the PLC program to communicate with our gateway the client messages from the PLC will be sent with a lower priority only executing once all the i/o messages have been completed in addition to this it should be pointed out that PLC message timing is dependent on ladder code execution so regardless of having a lower priority the messages cannot be set faster than it takes the processor to cycle through the latter file as a result there is potential for this array to have some variation in communication speed this is acceptable for this application because HMI communications will not be outside our requirements of under 500 milliseconds by using message instructions in the PLC we also get Diagnostics on the gateways communication that can be monitored using your PLC programming software having access to this data can greatly reduce your time spent troubleshooting in the event of a communication problem having our Gateway acting as a server and the PLC as a client however requires that you make changes to the PLC program code for our next example we'll take a look at a PLC that talks Ethernet IP that needs to communicate with an OEM SPLC that talks siemens industrial ethernet in this example we do not want to edit the program on the OEM PLC we'll need fast data transfer of no slower than 50 milliseconds and be able to diagnose communication problems using the Ethernet IP PLC programming software or an HMI that's communicating with it editing the program in an OEM SPLC to initiate data transfers could void the warranty performance guarantees or you may not have access to the programming software therefore for this example we will use our gateway as a client on Siemens industrial Ethernet in order to communicate with the OEM PLC acting as a server when our gateways port is configured as a client it has a poll rate that sets your communication update interval and does not get sent at a lower priority like a PLC client message this gives you fast consistent communications like before we could use message instructions in our PLC acting as a client to communicate to the Gateway as a server but our Ethernet IP communication speeds will be dependent on the timing of the PLC's ladder code and any other Ethernet IP communications that may be going on getting data transfers in under 50 milliseconds could be difficult to avoid using message instructions we could configure our gateway as a client on the ethernet/ip side and the plc as a server this would eliminate the dependency on ladder logic timing and would also not require program changes however because the Gateway is initiating communications the PLC will not have any indication in case of a communication failure the Gateway would be invisible to the PLC so if anything goes wrong like someone accidentally powering down the Gateway your client device will simply stop communicating this could extend your downtime when trying to isolate the problem especially if the problem happens 5 years from now and the person who programmed it is long gone the solution that meets all the application requirements would be to set up IO messaging between the ethernet/ip PLC and our gateway when PLC's do i/o messaging sometimes called an IO connection they require a communication update interval to be set this will ensure the communications between the PLC and Gateway are fast and consistent as they will be given priority over other communications the PLC will also have access to communication diagnostic tags which allow you to use your PLC programming software's to troubleshoot problems instead of using our gateway are in chassis communication module could also be used to solve this application our and chassis modules use IO messaging across the backplane to the PLC the modules communication port would be set up as a client to talk to the OEM PLC and this would meet all the design goals for the application and give you a more integrated solution in this next example we'll examine a situation where we have two PLC's that need to do high-speed interlocking one PLC talks Ethernet IP and the other talks pro finet this application requires the communications to have extremely tight timing for this example the PLC's are able to make calculations and issue commands in real time based on data they share with each other in applications where every millisecond counts and when the protocol supported using the IO messaging method is the best way to go by configuring an IO message on each side of our gateway we can ensure communication speeds between the PLC's as low as 10 milliseconds we also need to be able to use the PLC programming software or HMI to view and troubleshoot communication issues the thing to know about this method of communication is that it is very deterministic and repeatable thus offering it very fast and precise timing the data transfer rate is locked in by the program in IO messages are given top priority by both PLC's using this communication method requires you to program both PLC's to set up the IO messaging this will also allow the PLC's to monitor the communication status of our Gateway and display the diagnostic tags to an HMI or the PLC programming software for our last example we have a PLC that needs to talk to five drives that use a different protocol than the PLC in this example the PLC talks Ethernet IP and the drives talk Modbus tcp/ip mod was tcp/ip doesn't use i/o message communication so we'll need to use client-server communications the PLC will have to be a client as the drives will be server devices our design goals here are high speed fault tolerance and communication Diagnostics in the PLC this PLC can use a message instruction and some ladder code to create Modbus TCP packets via their Ethernet communication module using this method has some shortcomings PLC data messages are sent at a lower priority than i/o messages and can be affected by other Ethernet messages like if a user performs a program upload so using this method the communications to the drives will likely slow down periodically for this application a dedicated communication module that has Modbus tcp/ip built-in is a better solution as it is not affected by these issues a single client has no problem communicating with several different servers on the same network but there are some considerations using such an arrangement the client will open communications with each Drive one by one sending a read or write command and waiting for a response once the client receives the response from the server it will close the connection and move on to the next drive the issue is if one Drive is taken offline unexpectedly it will slow down communications with the four other drives while the client waits for its requests from the missing drive to timeout some server devices also have limits on how quickly socket connections with the clients can be opened and closed meaning the client could have to wait until an individual server is ready to resume communications the ideal situation here would be to use a communication module that supports multiple clients one talking to each of the servers this will ensure faster communications by giving each Drive a dedicated connection to a Modbus tcp/ip client commands can be sent to all five drives by separate client connections instead of cycling through each Drive one at a time in the event of a drive going offline communication with the other four drives will remain unimpeded many devices such as Prosoft mvi 56cm netsy can support multiple client connections also because our module uses an i/o connection to the PLC the communications are fast in the plc has access to communication diagnostic tags to reduce your troubleshooting time in case of problems so in summation when deciding what communication method you want to use there are a few things you should consider you should be mindful of what devices you're using what protocols you're using and whether or not you have access to the PLC program the devices you have will determine what methods you can use remember some devices can only be configured as a client or as a server also not all Ethernet based protocols can support IO messaging they will need to use client-server communications finally if you want to configure are in chassis or gateway module as a server or utilize IO messaging you will have to make edits to the PLC code if you don't have access or don't want the hassle it will have to be configured as a client on the network Prosoft technology offers a wide range of Ethernet communication solutions for the industrial environment our enchanting modules and gateways give you the power and flexibility to handle whatever communication needs you might have to learn more visit our website at you

Channel: ProSoft Technology

Views: 37,875

Keywords: prosoft, technology

Id: ITB5MDFkRwI

Length: 14min 21sec (861 seconds)

Published: Tue Mar 03 2015