Al,
Thanks for the compliment. Keeping time synchronized between PLCs can be done easily. I’m not speaking to very specialized cases where you’re using timing for GPS, deterministic, or tightly bounded timed applications - those could certainly call for an engineered solution with appropriate hardware.
It’s pretty easy to set up a FactorySQL group that sets the PLCs time (and date) based on the SQL database’s time. A similar group can be set up for each PLC that FSQL can talk to. It doesn’t matter if they’re different brands, represent “time” differently, etc.
Suppose you wanted to update all the PLCs clocks on the hour. Create a group for each PLC that “writes” the correct time. In most cases this will be a separate integer register for year, month, day, hour, minute, second. You might have to get the format to ms since something, a big dateTime string, etc. Each OPC item should be “read only” - you’re introducing them as a reference, not storing their values in the database. You would then create an “action item” that is an SQL query that gets that “piece” of the time - second, for example. That action item would then “write back” it’s value to the PLC register. You then create an action item to use as the trigger. I would use the same one for each PLC clock. I’d recommend using the HOUR as determined by the database and trigger on a value change. The group update rate tells how often to inspect. Once a minute makes sense in that example.
The beauty of keeping all PLCs synch’d to the SQL database is that you have a common timing source, even if you scale to multiple computers with FSQL, PLCs, etc. Better yet, most historical data “logs” using now() or CURRENT_DATETIME, which is totally with respect to the SQL database.
You are correct that changing the PLC time will change the logged time of cached data. However, our described implementation never takes PLC/DB time discrepancy into account. Therefore a time delta, error, is introduced regardless of whether our queue was piled high, empty, or somewhere in between. We have no way of tracking when this occurred and for which points it’s relevant. Net result - changing the synch’ing of clocks based on queue size won’t make a difference.
You could introduce logic that: waits for the queue to get to a certain size, checks the delta, and logs accordingly. This might be a little more accurate but still depends on when timing went off and the rate. Heck, it could introduce error. Bottom line - way too much complexity for questionable gain. Synchronizing the PLCs periodically based on the DB clock with FSQL should keep “very” close timing compared to our logging rates - you’ll want to verify this on your own system, of course. As you alluded to, if you truly need to keep times really close - engineer an appropriate hardware solution instead of attempting ridiculous hacks with FSQL.