HMI changes do not require restarting the system. Just publish the HMI configuration and either restart the real-time viewer or click on the refresh button to get the latest HMI changes
Automation logic changes can be published module by module from the module top menu options or right-click menu options.
Downloading a module replaces the module and continues the execution of the module while all other modules are running.
Automation also allows you to republish the entire Automaton logic to the server and will go through an automation restart after publishing the automation logic.
Some of the database configuration changes can be done from the real-time tabular views while online with a running system. Some of the changes take effect immediately, and some require a restart of the system. For example, user password, protocol polling intervals, scaling, simulation, object descriptions, units, and alarm properties can be changed during runtime without any need to restart the system.
Other properties such as Historian logging properties can be changed during the runtime but will not take effect until restarting the Historian task or the entire system.
You cannot create or remove objects during the runtime.
An exception to the above are:
You can use Automation API to create, update and remove runtime alarm objects without restarting the system.
How do I backup my entire configuration?
From the Database Builder “File” pulldown menu, sect Archive to store the entire copy of the project (both offline and online folders) onto a single file.
How do I make sure all my automation data and report templates are saved in the Archived file?
Sinolta stores all configuration files in their correct space.
Some sensitive datasets that are required to be used as part of the project operation such as excel files, reports templates, etc. should be stored under the offline Automation\Data subfolder so they are kept with the Archived files.
The Historical data should be kept in separate folders; otherwise, they will make the size of the archived file unreasonably large and challenging to manage.
I am getting a warning for assigning too many points to a Data logging group. What does it mean and how do I get rid of it?
When configuration historian, each point can be configured to be stored in a Data logging group.
You can think of the Data logging groups as tables.
Sinolta Historian creates a separate Historian database file for each data logging group until it reaches the configured maximum size or period specified in the Historian task configuration.
For example, setting up the maximum number of records for the Historical Trend database to 100,000 records causes the Historian to create a separate file for every 100,000 records.
Now, if you have 100 points that are configured to log every 5 seconds, it will take Sinolta Historian to store 100,000 records in a single file within 5000 seconds (or roughly about 83 minutes).
Generally, the larger the data logging files get, the slower the query results may be. On the other hand, the smaller the files are, the more frequently they have to be logged, which will make both hard drive and Historian very busy and also slows down the system.
Based on our experience, on average, we should try to configure our logging groups that can store 100,000 records and are not being filled any faster than one hour.
To calculate how fast each data logging group fills up, multiply the number of points by their logging interval for that group. This calculation works when the dead band is 0. If dead-band has a value, the amount of stored data for each logging file will dramatically drop. The actual number of records will depend on the frequency and the size of each change for each point. You can only calculate this by examining the frequency of the creation of each logging file that is stored in the Historian primary logging folder.