Log template impact on PLC performance...
I wonder if the log template min and max time for logging can have impact on the PLC performance?
My guess is that it will impact the connectivity server performance but not the PLC as it already have real time update to the connectivity server.
Thank you in advance.
Best Regards // Mattias
Min Time decide the update rate requested at the OPC server.
Max Time decide if Basic History should extrapolate last known value + quality if no data has arrived after Min Time. Max Time should therefore *never* be equal to Min Time, there is probably not one OPC server able to deliver data on the exact same microsecond offset, sample after sample over time. Basic History will insert an extrapolated value *immediately* when Max Time expires (if set) even if a raw value is received from the OPC server one microsecond later. Min Time = Max Time will deliver a trend curve, but log period may shrink by up to 50% and a "report", et.c trying to read values off the log will often see two very adjacent values (an extrapolated value then followed by a raw value).
The subscription's effect on the PLC depends on a number of factors:
- Is OPC server able to multiplex subscriptions to same item and cycletime (most do)?
- Is this item already subscribed by another client?
- If "NO" is the answer to both the above, the OPC server need to create a new subscription with the PLC at the cost of more or faster telegrams, etc.
- If "YES" is the answer, no additional telegrams will be required to feed the log, maybe faster telegrams if update rate of log is faster than the already existing client.
Most OPC servers I've come across run very low on CPU; they only exchange network telegrams and there is often ample processor power available. Hence, the number of items and their update rates will have a larger impact on the PLC's performance than the connectivity server.
E.g. MB300 and AC800 OPC Server are capable of multiplexing subscriptions; they will also attempt to minimize the number of telegrams required to be exchanged with the PLC. E.g. if a faster subscription is started on an item which already have a slower subscription running (e.g. when opening a faceplate at 1000 ms when there is already a slower subscription made by process graphics or a history log) the slower subscription will be cancelled and a faster be started. The slower client will receive its data, at requested interval, but taken from the faster client's feed from the PLC.
There are (a few) OPC servers that can not multiplex; each client (faceplate, display element, history log, 3rd party client, etc) will be fed using a dedicated telegram exchange with the PLC.
Then there are OPC servers that are better at certain update rates than other. E.g. the MB300 OPC will spend less resources in the system when feeding an item at 9 second update rate than it will at the seemingly leaner 1 minute update rate. The Advant/Master PLCs on MB300 can autonomously feed data on 1, 3 and 9 seconds, but slower rates need to be manually clocked & pulled from the OPC server with dedicated telegrams at a *much much* larger cost.
Some OPC servers, e.g. AC 800M have features built-in for analysing the subscription load on the PLC. Check the "Tools->Display Variable Communication Statistics" menu item in the OPC server panel. The CPU load in an AC 800M is "linear" to the number of MMS transactions it is exposed to. More MMS = higher CPU. A fast PM891 can sustain a lot more communication than a slower PM861. However, a lot is also dependant on how well the task tuning is made in AC 800M. You can easily have a PM891 "choking" on a single large application with long execution time. Small (=short) tasks and lots of Task Offset is what you want to have have in AC 800M if MMS communication is important.