This topic says that prior to 7.8 it was not advisable to set the Max Records higher than 50k. Is that fixed? And what is the new practical upper limit for Max Records? (ignoring disk-space)
Is there a practical upper limit for Forward Write Size?
Is there an optimal ratio that should be maintained between Store Max Records and Forward Write Size?
If I increase the Write Size significantly, then is it best practice to also increase the Write Time?
Last things, I noticed that the units of time for the “Write Time” setting in Store and Forward is called out in the inductive university videos, but I didn’t see it in the manual. Not sure if this is the place for this kind of suggestion, but I think adding the units to Write Time in the text manual is a great idea. Also the description for Forward Write Size and Write Time in the manual, (“Same as disk cache setting above”), is not completely accurate, I’m sure. Forward Write Size and Write Time are at best “Similar to disk cache setting above”, or else they wouldn’t be separate fields with different values (and I’m not recommending that you simply rewrite it to say “similar”. It should say exactly what it does.). I don’t mean to nit-pick, but I’m sure you understand why I wouldn’t like to guess at “you know what I mean” type descriptions when I’m designing an industrial system.
Also agreed, we did a fairly large hub and spoke design…and the manual provided little guidance for tuning the settings. In the end it was trial and error to determine exactly how the setting worked which is not ideal.
Any update on this? I’ve got a similar hub/spoke setup with several remote gateways going over wireless links back to the main gateway - I’d like to use the store and forward system to be able to handle com loss for up to ~6-8 hours and still be able to back fill when comms are re-established. What size of Max records/write size and memory buffer would allow me to achieve this? What are the limits?
Yeah, you know, I just looked at the man page for this and I don’t see much change from back when I first posted this question. I wouldn’t be totally surprised if they didn’t know the answer as it pertains to the existing system, or if they were holding off on updating the man page until some upcoming major rework of their historian is released. After all, Ignition’s Achilles heel has been its historian for some time now; their query structure isn’t well optimized to handle very large systems with high density data. At least that’s a common objection from their competitors (namely Wonderware).
For the record, though, we did manage to resolve the issue by trial and error; changing values here and there and watching what happened to the historian. Unfortunately, I no longer have access to that particular system, so I don’t remember what the precise solution was. Good luck!
Funny this came up in the forum this week. I spent several hours earlier this week trying to understand why my historian was only recording data about 45 seconds out of every minute, leaving me with 13-14 second data gaps. I worked with tech support on that, and it came down to my cache holding over 1,200,000 “records”. This was on a remote history provider, and once I restored the remote gateway and the cache started emptying, the data gap started shrinking. I didn’t monitor it the whole time, but somewhere close to 100K records, the data gap was finally gone. This is on a 7.9.8 version gateway.
For the record, I had set the retention to 10,000,000 records. Needless to say, I’ve dropped it down since.