Improving performance with OPC tags

Question

I am working with a PC based automation software package called Think'n'Do created by Phoenix Contact It does real time processing, read inputs/ control logic / write outputs all done in a maximum of 50ms. We have an OPC server that is reading/writing tags from a PLC every 10ms. There is a long delay in writing a tag to the PLC and reading back the written value (Think'n'Do (50ms) > OPC Server (10ms) > PLC (10ms) > OPC Server (10ms) > Think'n'Do (50ms) ) that process takes up to 6 seconds to complete when it should by my math only take 130ms.

Any ideas of where to look or why it might be taking so much longer would be helpful.

Answer 1

It depends on how you have your OPC client configured to pull data. When you subscribe to a group in OPC, you get to specify a refresh rate. This might default to 1s or even 5s, depending on the OPC client. There's also a limit the OPC server might put on the frequency of updated data. This only applies if you have your OPC client subscribing to data change events.

The other way you can go is to do async or sync reads / writes to the OPC server. There are several reading modes as well. Since you are using OPC, you can use any OPC compatible client to test your server, this will tell you if the problem is with a setting in Think'n'Do or is it something with the PLC / server.

The best general purpose OPC client I've used is OPC Quick Client. You can get it with TOP Server here: http://www.toolboxopc.com/Features/Demo/demo.shtml. Just grab the TOP Server demo and install the OPC Quick Client. You can use it to connect to your OPC server and browse the tags and see what the data looks like. The second best OPC client I've used is from ICONICS (called OPC Data Spy) available here: http://www.iconics.com/support/free_tools.asp.

Use the OPC client to see how fast you can read the data. Make sure you set the group refresh rate correctly. I think the tools might provide some timing information for you as well (but you'll be able to figure out a 6 second delay pretty easily).

Answer 2

If the system does syncronous reads (blocking I/O call), then implements the logic of your application then syncronous writes (again blocking) then you need to consider that there are multiple round-trips to the PLC.

A syncronous read involves App(request)->OPCServer->PLC->OPCServer->App(result). That is just the read for one item (although you can ask for a group of items in one go).

Then a similar sync write also involves App(Write)->OPCServer->PLC->OPCServer->App(Done).

Asyncronous reads & writes and group reads & writes can help reduce blocking of the application, but be careful that your aplication can cope with this ansyncronous behavior

The other thing to look at is the PLC configuration, On Allen-Bradley PLC's there is an interscan delay setting that is used to service I/O requests over external networks. If that time is short and you have a high bandwidth of data then this will slow things down.

Answer 3

Here are a few places to look: OPC Client configuration, OPC Client itself, OPC Server, or the PLC itself.

Here are things you should check:

1. OPC Client configuration - The OPC Group you've added the OPC tags to should have a fast scan rate (ie. 100 ms to 1 sec depending on what you use it for). With the act of writing values, do you notice if the values come in faster? If not, then there might be a DCOM or network configuration issue.
2. OPC Client - Download a free OPC Client software(probably from the OPC Foundation website or major OPC Server software vendors) to see if you get the values back faster. If so, there might be a problem with your client.
3. OPC Server - Some OPC Server have diagnostic tools. Turn those on and see what is the time the writes actually occur and what time the reads actually take place. If you can answer those questions, you can probably identify whether the culprit of the delay is from the PLC or the OPC Server. Also observe the CPU usage of the OPC Server, if you notice it is using more CPU than normal, it probably means that the OPC Server is loaded down which might deteriorate performance.
4. Others - Finally check PLC, network are working properly.

Answer 4

It sounds as if you are not using the cache in the OPC server. Normally OPC servers have a cache, if your client connects and doesn't specify that it wants to use the cache you don't get the performance that you may need. The OPC server is responsible for refreshing the cache from the device although the criteria for refreshing may differ from OPC server to OPC server.