Thank you for your thoughts.
I’m sure you could engineer a solution with a hardened, solid-state PC and FSQL, but the issue with this approach is one of cost – each installation will cost several thousand dollars. A recent job we looked at required local datalogging in each of 26 wind turbines, so cost of each installation was very important.
Having a situation where the PLC and computer are both up but the network is down is in fact very common in some industries, for example where you have remote outstations without a permanent connection to a central control room. In this situation the control room will connect to each outstation maybe once a day using a dialup modem (for example) to download information that has been collected.
The reason I was interested in Nathan’s approach was that it was very generic. It also had the advantage of being a single box solution, instead of having to install a separate PLC and datalogger. If the datalogger and PLC are not linked via some kind of network, this approach can become complicated, with a requirement to feed inputs to both the PLC and datalogger.
I have looked at a number of dataloggers but the problem comes in trying to get the data out of them and into a relational database. This would need code to read the data as a file, then code to step through the file, extract its contents and put them into the database. I much prefer the approach of using standard FSQL where possible.
I still think a PLC with easy access to non-volatile storage such as CompactFlash would be the best solution.
As an aside, a variation on Nathan’s approach would be to have 2 pointers tracking through a circular buffer. One pointer would track where the PLC was in the buffer, the other would track where the PC was. If the PC was ‘behind’ the PLC, it would read data until it caught up – some mechanism would be required to cope with wrapping round from the end of the buffer back to the beginning. If the PLC ever caught up to the PC, the PC’s pointer would be pushed ahead of the PLC’s, losing data. The advantage of this approach would be to avoid having to move lots of data on each read if the buffers were large and lots of data had backed up. Maybe this is an unnecessary complication.
Regarding the time tag in the PLC: would it be possible to record something like the number of seconds since the start of the year, then translate this back to a time and date in FSQL before saving it to the database? This could be held in a 32-bit integer rather than a 38 byte string, greatly saving on PLC memory.
Al