I think your idea is good. James I downloaded and looked at the file you created, and I would encourage Hugh to do so.
I actually agree with you if a person wants to keep the data so it is not overwritten and do whatever with it. But I do not agree with not storing it in the PLC. It does not tax the PLC a bit to keep it there, not at all waist-full and it is the most efficient way to make it available to the HMI for display and for use by the PLC if it is needed for any type of process control.
Everything he said he wants can be done with a few instructions and displayed on the HMI. If he wants to keep it indefinitely then I agree with you to store it in a DB but still keep the data file in the PLC for all new data for whatever time period he wants to display on the HMI. There is no need to take it from the PLC and put it in a DB and put it back in the HMI.
Also, any part of the data file can be averaged, you don't have to average the whole file, you can start and stop anywhere in the file you want. You can also get the min/max from any part of the file you want and with many PLCs it only takes one instruction each to do that.
We have 6 months of data for two furnaces stored in the PLC
Run Time, Total Fuel Used, Total Cost to operate per furnace and for a dryer and water heater. Computations for fuel used is based on BTU of appliance. Everything is calculated in the PLC. (We will be adding CTs to electrical equipment as we go forward with our Total Energy Monitoring Plan to monitor costs and plan expenditures. )
We take only parts of those 6 months long files to display Average fuel used per day last 30 Days and last 7 Days, and real time per day for each of the two furnaces. For now, we only get a running total for the other appliances because they don't use much. Cost per day real time is also displayed.
We also take total fuel usage of all equipment and project when we will need a re-fill updated every time an appliance cycles. All the data is displayed on the HMI Updated every scan less then a second, Now that's six months of data and we have enough memory in the PLC we could do it longer but we don't need it any longer than that so why put it in a DB? We don't know what more we would do with it unless we wanted to keep it year to year.
If the HMI is not running- you get no data, That is the week link in using a SQL solution to store the new data. In an Industrial setting where the PLC is controlling the equipment you are monitoring, If there is data to be had, it will be in the PLC, if the PLC is not running, there is no production data to be acquired anyway until it is back in run mode, nothing lost.
Another advantage is if you connect a different HMI, the data is still in the PLC, all you have to do is load the config file into the HMI. And it is not HMI type dependent, You can put it on whatever HMI that is compatible with the PLC. Can't do that if the data is stored in the HMI -
I think you have probably done PLC work long enough to know the PLC is far more efficient at directly displaying the information on the HMI without putting a PC in the middle, /processing and putting the processed info on the HMI. There is no way a PC based solution for that is more efficient or even close to the speed the plc does it on it's own.
Where I agree with you is keeping the data long term but for everything else he wants, he does not need an external db for it. As long as the PLC has enough memory to store what he wants.
I am grateful for your presenting this alternative and I may use it myself if I want to keep the data to compare from year to year but I will still store the new data in the PLC which I back up daily to a network drive.
On a side note, I am amused at the windows people that hated Novell Netware for the command-line interface - no GUI and yet rave about SQL. ( I like NetWare)
I would say the best of both worlds here is both solutions together, not one or the other. So thanks for that Idea.
(They only keep me alive because I know DOS)