SYSTEM:

TIA Portal V19 Update 2

WinCC Unified SP2

Windows 10

CPU 1517F-3 PN/DP (Main Line PLC)

Hello all,

A client recently asked why they weren't able to access tag data that we are supposed to be logging for them. I looked into the issue and it turns out that the reason we can't access that data is that it no longer exists! The logging tags we have set up are configured to write to a SQLite database whose size is capped at 1000 MB. We very quickly overrun that mark due to a mixture of bad log configuration and amount of data coming in due to the size of the plant. We are now attempting to find ways to cut down the log size significantly. For context, we are hoping to give the client three months historical data and they currently hit the 1000 MB mark in about a day and a half of runtime.

We are looking into how much we can expand the data allocation for the DBs, as that is the most obvious solution, and we are also going to switch from logging tags OnChange to logging them Cyclically every second or so, depending on what the client wants, etc. The last thing we are looking to do to help solve this is to cut down on the log entry size. We realized that our log entries (Motor Amps) are being stored as LReals, even though in the PLC the data type is Real. Somewhere between the PLC and the DB, the value is being converted. I am particularly confused because the extra bits are not just zeroes, so they look like they are conveying a level of accuracy we definitely don't provide (Or need... Why would you need fifteen decimal place accuracy every 100ns on a motor's amperage...). My hypothesis is that these are just random bits in memory that are being given to the LReal when the Real is changed to an LReal.

So the question is what is going on? Why are these Reals changing type? Is this a logging thing? I saw that if you select certain compression modes for logging tags that a Real can change to an LReal, but we have no compression selected, and that still doesn't really explain why extra data would be appended to the values.

The followup question I have is whether changing these back to Reals will change the size of the log entry. The obvious answer seems to be yes, but I'm less sure because Siemens' documentation says that every log entry will be Approximately 50 Bytes. It seems like a small change to go from 16 Bits to 8, but 8% of hundreds of thousands adds up to a lot of extra space. Is that how it works, or does the size not really change much?

Finally, any other suggestions on space saving measures for data logging would be appreciated. I saw something about using a script to back up to a separate location and empty the working log, but that seems like a bit of a hack. Not one I'm opposed to using if necessary, but saving space in place is priority one for me.

Thanks for taking the time! Let me know if there are any other Questions.

Stefan, you are a mad genius. I don't know how you and Murof and the other guys come up with such consistently good answers! I tip my hat to you.

I did not even consider the effect of binary, but that makes perfect sense. Interesting that they don't allow 32-bit reals, but I'm going to assume the higher powers who wrote SQLite knew what they were doing with that one.

I have already created a duplicate set of logging tags to test out cyclic acquisition instead of on-change. I will also play with the compression and smoothing settings to see if we can fix this overloading issue.

Thanks so much for the help!