Hi,
I’m having issues with data duplication when I use the history option for an OPC tag (at both the UDT level and data instance level). I have only one data instance of that UDT and I’m recording the same value twice at two different time intervals as shown below. The scan rate is 40 Hz, Direct mode, OPC Data Mode: Subscribed.
This is a screenshot of the raw data from the sqlt_data_xxxx_xx table
Can someone let me know where is the bug?
TIA
Any chance you have another gateway you restored a backup on?
My gateway is on another device (HMI computer) in the same network but that’s the only gateway in the network. Would that be an issue? There is time difference between the duplicate records which makes me think that two processes or publishers are trying to insert the history of the data.
Try to check in your database who’s connected to it. Perhaps you can find two ignition instances where one is burried on a test server, or someone might have restored a backup on a personal computer for testing.
It will depend on the database how you can view the connected users/computers though.
The only times we’ve seen this behaviour was when restoring backups in the same network.
I double checked with the database and the Ignition instances, everything looks good, just one instance int he network. I tried experimenting with the history scan class to see if that might be an issue and found out an interesting info about this duplication. I was seeing duplicate values even at 8 Hz and it got worse beyond that.
The PLC is sending out data at 40 Hz freq though but I’m not able to capture it through an OPC tag. I also tried running a Tag Change script to avoid duplicates while inserting the history to the database but the closest I could get was 10 Hz regardless of how high the scan class freq was.
Are there any other places for bottlenecking?
So you mean you expect 40 changes per second, or a scan class/tag group of 25ms? I didn’t notice the “40 Hz” in the original post. It’s a quite odd unit to use in this context.
That’s likely just too fast for OPC. According to the OPC specification, the OPC client can ask for a refresh rate, but the OPC server (which is probably your PLC, unless you have an intermediate serer) can ignore that rate and return results at a slower pace. Most PLC’s only send OPC values when there’s time left during their cycle. Even with a slow refresh rate, it’s possible the results will arrive with a delay when the PLC is busy.
100ms (or 10 Hz as you call it) is already quite fast for OPC.
But I don’t get why you are seeing duplicated values. Did you force the historian to write every 25ms? It shouldn’t get an OPC update, so it shouldn’t write to the database normally. I also don’t get how it seems to log in two groups both at 100ms but 26ms apart from each other.
Can you show the tag configurations (tag group settings, historian settings)?
But anyway, it looks like you will have to use a different method for logging this data. Like keeping a buffer in the PLC and storing it to a local file or using some other protocol.
What kind of PLC is this? If you have leeway to adjust the PLC code to buffer multiple samples, and Ethernet/IP support to get low-latency UDP traffic, it can be done with my Ethernet/IP Module.
It’s a siemens ‘SIMATIC S7 1500’ model, the scan class at the PLC level is 40 Hz. I guess I’m being restricted by the OPC driver polling rate because I tried running a python script to read directly from the datablock of the PLC and I was able to collect data at 40 ish Hz for the most part (without any duplicates). Here is an extract:
The 1st column is pressure in kPa and 2nd column is the UNIX timestamp (it’s milliseconds after the decimal). I’ll see if we can work around without the module if not I’ll check it out, thanks.
I haven’t seen any reports of Siemens natively supporting Ethernet/IP I/O devices. That would be required for my module to be of any use.
