Al,
Thanks for jogging my memory - wind turbines or anything on a “part time” (satellite, dialup, or leased line) are really good examples of that specific case. You also bring up a good point about the economy of being able to use a single central FactorySQL setup instead of requiring something additional at every site.
A mechanism to wrap/overwrite data makes sense as you overflow past your memory bounds - this would be set up in the PLC. Having 2 pointers to track where the PC is versus PLC is seems functionally equivalent to what I described - in both of our examples FactorySQL should only read each value exactly once. You could easily implement your idea by triggering the group based on “pointer1 != pointer2”. Neither example is doing a block data read from the PLC, which would be a more efficient in terms of data transfer and time (although you could read value+timestamp together). Your example adds the unnecessary benefit of storing cached history in the PLC even after FSQL has read it, while mine performs more operations in the PLC to conceptually simplify the situation by dumping the value from the PLC after a read. As far as I can tell we’re both doing pretty much the same thing.
You could set FactorySQL up to work with the PLC and store dates in a more efficient manner. If you use a 32 bit unsigned integer and only need precision down to the seconds, you can choose a starting date - it gets you 136 years worth of seconds. If you need to be tight with memory, I’d use a 24 bit unsigned number as seconds for a total of 194 days since FSQL’s last read. The rolling reference also can introduce potential pitfalls.
A few things to consider:
- Keep in mind that the PLC and PC are using separate clocks. FactorySQL can synch time with a group that writes it’s HHMMSS to PLC registers periodically.
- In the rolling reference example you would want to buffer up your data to a certain size before performing the read operations and time synch reset.
To accomplish this:
- Create a queue or circular buffer as described, storing the “date” as number of seconds since some date, say Jan 1, 2007.
- Create OPC Item(s) that read your historical value(s) and seconds. You could do some ridiculous bit banging here if necessary.
- Create action items as necessary as expressions if you need to de-couple the OPC values. The simplest case has no action item here and two OPC items: value and seconds.
- Create an action item that is an SQL INSERT query like in my example. The only difference is that it should include a date addition function that writes the date_time + seconds to the t_stamp column.
Your suggestion is really a minor modification and a clever idea. You can save memory by being clever with your bits, but I wouldn’t go there unless it makes a big difference - your time is worth something and it makes it obscure for the next guy.