From: P....
Sent: Wednesday, April 16, 2014 9:32 PM
To: Zbynek Zahradnik
Subject: RE: QuickOPC Download Form - p....

Hello Zbynek, while looking at the option of the Kepware OPC Server I found that on the Device Properties there is a Scan Mode Tab where you can adjust the scan mode to: Do not scan, demand poll only which is what I am looking for. Thanks for your help.

We have quoted a couple of projects and if we are successful we will be using QuickOPC-COM to connect to the OPCServer selected for the application.

Thanks again,

P.

No, the purpose of the parameters is to control the behavior between QuickOPC and the OPC Server - in this case, to make sure that we do not issue any additional requests beyond what you explicitly call in your code. Both parameters you mentioned should be -1 (Infinite).

Assuming that this is taken care of, OPC servers will usually only do what they are told - i.e. they will read only when a Read call comes in from an OPC client, etc. The OPC specifications, however, do not prescribe this behavior, so it would be perfectly OPC compliant if the server chose - for whatever reason - to make some Reads even when not asked to. For OPC servers that are basically PLC protocol drivers, I am not aware of any server that does such thing, but the only way to find out with certainty is to contact the server vendor.

Best regards

From: P....
Sent: Wednesday, April 16, 2014 2:15 AM
To: Zbynek Zahradnik
Subject: RE: QuickOPC Download Form - p....

Hello Zbynek, thanks for your answer on the forum. Looks like the default value of UpdateRates.WriteAutomatic is -1, is that mean that the OPCServer will write only once when QuickOPC will write to the server ? And if I set the property UpdateRates.ReadAutomatic to -1 (default is 10000) will the OPCServer read the PLC only when QuickOPC is reading the OPCServer ? This would be the behavior that I am looking for (reading and writing only once after a request from QuickOPC).

Regards,

P.

I understand now.

"Normally", OPC subscriptions are preferred over periodic Reads. This is because with subscriptions, the communication between the OPC Server and the client can be change-based, and because it gives the server a chance to optimize the subscription requests that may be possible be coming from multiple clients. I understand that you do not want to do PID loop calculations whenever any of the input values change. Still, you could use subscriptions, by storing the values that are coming from in the item change notifications. Then, you may have a periodic task that will just take these current values (no call to OPC server at that moment), make the calculations and write the outputs. The disadvantage here is that even if you set all your inputs to be in a subscription with 10 seconds update rate, the server will do this scanning independently, on his own, and unless there is a change, on the client you will not be notified that this interval has elapsed. So without some extra hacking, you would end up with two periodic tasks on each side - not nice.


In the end, the periodic Read (although not generally recommended) may be the solution here (also considering that the period is quite slow). It will similarly to what you have described with a dedicated driver (.OCX). You will simply write a task that executes every 10 seconds, call a method (ReadMultipleItems) on the EasyDAClient object, process the values, and then call WriteMultipleItems.

There are just some things to be aware of and tweak as necessary:

1. QuickOPC manages the connections to the server automatically, connecting as needed, and disconnecting after some period if there are no requests coming from your app. Make sure that the so-called "hold period" in the component's settings is significantly higher than you reading period. This way, QuickOPC will stay connected to the OPC server, which is better performance-wise.
2. QuickOPC attempts to automatically set up an internal subscription when it detects the Reads, and then sometimes - when appropriate - provide the values from "memory" instead of making the Read. This will probably not be desirable in your case, so you need to set the parameter "Automatic update rate - Read" to "infinite" (-1).

I can point you towards the precise place where to set these parameters, it's in the doc - just let me know if you don't find them.

From: P....
Sent: Tuesday, April 15, 2014 6:15 PM
To: Zbynek Zahradnik
Subject: RE: QuickOPC Download Form - p....

Hello Zbynek, thanks for your time. Here is the same question but asked differently: we need to control the temperature of a process by reading the temperature detectors (RTDs), making calculation (PID loops) and writing back the valves opening. Since we a controlling a slow process we need to do that every 10 seconds. With a dedicated driver (like an .OCX) for a PLC we would start a loop that at every 10 seconds that will read the temperatures, make the calculations and write back the valves openings and wait another 10 seconds. This looks to me very efficient communication wise. We would like to do the same thing with QuickOPC communicating with an OPC server. Is it possible ?

Subscribing to the temperature detectors to trigger the calculations is not good because there is quite many and they are changing of values all the time so the subscription will give new values all the time while what we need is only their values at an interval of 10 seconds (I know there is the deadband but still the OPCServer will poll the values from the PLC at an interval to verify if the new value is within the deadband). We don’t want to have an increase in the traffic between the OPCServer and the PLC compare to using a dedicated driver (like .OCX).

Thanks again,

P.

Dear Sir,
I am glad that you made it work in principle.

I will need some more explanation to your question. What is not clear to me is, are the two activities you are describing (reading and writing) somehow quite separated physically – such as that they reside in different processes that cannot easily communicate?

Because otherwise, the “usual” approach would be to use QuickOPC to subscribe to changes of the inputs. You can then perform the calculations based on the input values –depending on the needs, either a) directly in the item changed event handler – if any change requires immediate recalculation, or 2) periodically, using the values stored from notifications (or, in this case, you can replace the subscriptions by periodic reads, but that’s less efficient). Once the calculation is complete and if the results are different from the last ones, you can call the write, with all the new values – immediately following the calculations.

Or maybe I have totally misunderstood the question. Anyway, I need some info.

From: P.
Sent: Tuesday, April 15, 2014 2:51 PM
To: Zbynek Zahradnik
Subject: RE: QuickOPC Download Form - p....

Good morning, we have been able to connect to an OPC server with your program while using Dyalog APL ! Currently we are rewriting our application from APL2000 (www.apl2000.com) to Dyalog APL and are revising our communication strategy. Currently we are contemplating at using CimQuest OPC servers with your QuickOPC-COM client.

Question: Is it possible to have an OPC server that will be idle all the time and it will be a command from QuickOPC that will ‘force’ to READ all the inputs of the PLC and have another command from QuickOPC that will ‘force’ to WRITE all the outputs ? What we need to do is first read all the temperature detectors of the PLC (‘Inputs’), make some calculation (PID loops) and write back to the OPC server the value of the opening of all the valves and then force all those values to be written at the same time to the PLC. What we don’t want is to have the OPC server write continuously to the PLC for nothing (at every 2 sec for example) when the application needs to refresh the values at only each 10 seconds. If we set the OPC server to be refresh at every 10 seconds and our application writes at every 10 seconds I don’t see how to synchronize the 2 programs so it does not take up to 20 seconds in some cases when badly synchronize.

Thanks for your time in advance,

P.

[a download form entry mentioning Dyalog APL in Note]

From: Zbynek ZahradnikSent: April-13-14 10:35 AM
To: p....
Subject: RE: QuickOPC Download Form - p....

...
I have briefly looked at Dyalog APL, and my understanding is that it has the ability to instantiate COM (“OLE”) classes and call their methods. It should therefore be possible to use with QuickOPC-COM in principle. We have not verified it, though. I would be quite interested myself to see if that works, and willing to help if you need.

Best regards,