I'm new to indusoft and I have a trending question: when do you use the propietary format, and when do you use a database? We tried logging our trend sheets to a database, but everything was logged in the same file. Because we have quite a lot of data, we would like to have a file every day. Therefore, we changed to the propietary format because then automatically a file is created every day and per trend sheet. Is this possible for database too? Perhaps the database solution is more interesting for us concerning search options.
I've always thought that one of the advantages of logging to a database is that you don't end up with a new 'file' every day? Using a database allows for very flexible reporting by making use of timestamps to analyse or present arbitrary periods of operation.
That is, presentation from the database can be for any time period ... so a 'file' per day shouldn't really be a requirement. I have only used the proprietary format for trending, but save other production information in remote SQL databases using the DB functions.
In general, I would advise using the proprietary format for trend logging unless you need to do the kind of analysis on your data that is provided through SQL.
We use the SQL Express 2008 R2 database from Microsoft for all data including trending and alarm/history. This allows other programs such as MS Excel to access the database which you cannot do in the proprietary format. This also allows us to use the redundant database function to save data to other computers which have the SQL Express install. Nice thing is you can use the SQL functions from Indusoft to do things like create backups of the database and it is a free download from MS. One thing we did find is that if we create a seperate Database in the SQL Express (One called IndusoftMain and one called IndusoftTrends) for the trend data, then acces to the data is faster since the SQL server is multi-threaded and can handle multiple requests at the same time. This sped it up on computers that were lacking in resources like CPU speed or RAM.
Mike, You mention two databases here: IndusoftMain and IndusoftTrends. Did you create these in the same instance or create two different instances. (I'm assuming two databases within the same instance).
This sounds like a great idea. In the water filtration industry, we need to log a serious amount of data, but only report on min,max,avg for 15 minute intervals. It sounds like the Main database could be used for the results of those queries.
Lastly, the proprietary method allows capping the number of files (ex.366 days). Did you end up with a maintenance screen for purging old data from the SQL databases?
Ideally you should automate the purging of data from SQL databases using some simple scripting which is scheduled at intervals.
One thing you may need to be careful of is trying to delete a huge number of records if you are collecting a large amount of data daily. That is, the database may slow dramatically while the deletion of old records takes place.
We are required to keep the water records for 10 years so what I have done is wrote a program in Visual Studio that allows the operators to create a SQL backup on the fly, then it purges out all the records except for the last 30 days. This allows the operators to get fast graph times but maintains the record keeping requirement.
In respect to the IndusoftMain and IndusoftTrend these are seperate databases. By doing this we don't have to worry about the size of the main database. We also use the redundant database feature to keep a second redundant copy on the same machine of IndusoftMain and IndusoftTrend called IndusoftMain2 and IndusoftTrend2 so if something happens to the structure of the primary database or the secondary database we don't loose any records.
To cap that off we have redundant server machines running 1 TB Raid 5 data arrays and 500 GB Mirrored drives (which contain the operating system). Then we run Lockstep Backup for Workgroups for automatic backup of the systems with the primary backup being stored on one machine and the mirrored backup being stored on the other machine.
So as you can see, we take the record keeping requirement very seriously.
I forgot to mention, we are required to sample every point on one minute intervals for over 300 points per site, so we are taking over 430,000 samples per day per site into MS SQL 2012 Express Servers (which is free). It never ceases to surprise me how well the whole system runs considering the amount of data being handled.
Mike, Thanks to both you and Greg for some great advice. (Although belated). Over the past month or so I have been tweaking the trend sheets by changing deadbands and moving less active data to their own sheets. My final question, I think, has to do with the same tag on multiple sheets, which apparently can't be done, even though the table in the DB is different. Am I missing something? I was about to create buffer tags, updated in scripting, so I have the same value used on different sheets. Any thoughts? Thanks again, Jack
It looks like you're right about a tag only being allowed on one Trend sheet. I just tried it in one of my applications. I was allowed to include a tag in a second sheet ok, but after verifying the application it had been removed from the original sheet.
I think I had found this before, and it seems unnecessary .... although I'm sure there is probably some good reason.
