In the manuals i did not found a description of how the subsciption and reading rate from a device is calculated. It would be good to have a bit more information to tune the scan class rates.
A little background:
I use a protocol converter to connect old Siemens S5 PLC’s to Ignition using the S7 driver. Since the connection between the converter and the PLC is a 9k6 serial line, i have to keep an eye on the update rates.
In Ignition i have two different Scan Classes (2s and 15s) that read 2 different memory blocks. The 2 second ScanClass is behaving as expected and results in a read request every 2 seconds.
For the 15s Scan Class i see in the Server Diagnostics a subscription rate of 5s. The i switched the read request to trace and found that the two reads are combined to a single request executed at 2s.
I don’t think that there is an easy way to change this behaviour, so i will have to change the plc program to combine all tags in one memory block and put everything in a single ScanClass.
Can you please give me some more information about the internal workings of the OPC drivers:
When is the subscription increased compared to the scan class rate
Under which conditions are memory block reads combined in the S7 driver.
Scan class rates translate directly to UA Subscription rates, with a max of 5 seconds. (As of 7.5.5 and later, I think. There used to be no cap, which was problematic.)
Scan class rates translate directly to UA MonitoredItem sampling rates, which is the rate the Driver is told to poll at.
Any duplicate items in a driver (items with the same address) will be aggregated and read at the fastest of all requested rates for that item.
[quote]Scan class rates translate directly to UA Subscription rates, with a max of 5 seconds. (As of 7.5.5 and later, I think. There used to be no cap, which was problematic.)
[/quote]
Ah, ok. That means for rates slower than 5 seconds i can only use read mode.
But why is my tag with address QD48 (in the 15s ScanClass) combined with reads from a data block (DBn,) in the 2s ScanClass? Is it possible that the S7 driver reads everything with the fastest rate?
You can continue to use rates slower than 5 seconds - the subscription rate and the sampling rate are decoupled. In cases where the scan class rate is slower than 5 seconds the subscription will evaluate every 5 seconds on the server still but just send back a keep-alive. The sampling rate at the driver level should still be whatever your scan class rate actually is.
This might be a bug unless your 2-second scan class also has a QD48 tag in it.
I just checked the subscriptions, and the tag is only in the 15s Class. I also checked another device where i have a single item in a 1s ScanClass and there everything is polled with 1s rate. It seems this is really a bug.
One other question: I just changed the 2s Class to 10s (and chekd there is no subscription with 2s left), but the driver still reads every 2 seconds. I’m still running 7.5.5, so is this one of things that changed in 7.5.6?
Please try 7.5.6 and see if this still happens. I’m pretty sure I did fix a bug related to items getting stuck at a faster sampling rate after being switched to a slower one…
Ok, i just updated to 7.5.6 and rate changes are no correctly applied to the subscriptions.
The problem with the Siemens driver putting every tag in a single request with the fastest rate is still there.
I did a few checks and there seems to be something wrong with the read optimizations also. When i request IW0 and IW100, the driver requests the complete block with 100bytes. This happens even when the two tags are in different Scan Classes.
[quote=“chi”]Ok, i just updated to 7.5.6 and rate changes are no correctly applied to the subscriptions.
The problem with the Siemens driver putting every tag in a single request with the fastest rate is still there.
I did a few checks and there seems to be something wrong with the read optimizations also. When i request IW0 and IW100, the driver requests the complete block with 100bytes. This happens even when the two tags are in different Scan Classes.[/quote]
Ok, thanks. I’ll see if I can get to the bottom of this.
The optimizer doesn’t care what rate an item is at. I think the logic was that it’s not harmful if items that are being asked for at a slower rate get to piggyback their way into requests that are being sent at a faster rate, provided that there’s room in that request.
The over-arching goal of the optimizer is to get all the data being asked for in as few requests as possible, never slower than asked for, but sometimes faster than asked for.
I dont’t have an acute problem with this behaviour after rearranging the memory areas in the plc’s. But i think it would be good to mention this in the manual at least. I just imagine reading a data block at adress 0 and adress 1000. With a large enough pdu this would result in a block of 1000bytes with each request, wouldnt it?
Maybe an optional setting for the maximal spanned gap size would be a good idea.
I dont’t have an acute problem with this behaviour after rearranging the memory areas in the plc’s. But i think it would be good to mention this in the manual at least. I just imagine reading a data block at adress 0 and adress 1000. With a large enough pdu this would result in a block of 1000bytes with each request, wouldnt it?
Maybe an optional setting for the maximal spanned gap size would be a good idea.[/quote]
The max request/response size isn’t very big, only 240 bytes or so I think, so it would never grow that large. But yes, it may be useful to have a gap size or even an option to turn gap spanning off, like the Modbus driver has.