[00:00] Ignition offers a built-in way to maintain a historical record of tag values. We can save tag values and time stamps to a database where they can be retrieved later. Ignition can store history to many kinds of databases, including MySQL, Microsoft SQL, and Oracle DB. The nice thing about using the tag historian is that no SQL knowledge or legwork is required. As long as you have a database connection, Ignition will handle the rest. Of course, there are many historical configuration options, including partitioning and pruning options that we'll discuss in later videos. For now, we'll simply walk through configuring history on a tag. So I have a Pressure Tag here in the Tag browser. And we can see the Value is updating every second. And let's say I want to configure history on this tag. So I want to store the Value to the database every time it changes. Doing this is going to be pretty straightforward. I'm just going to right-click on the tag and go into Edit Tag. And then in the Tag Editor, I'm going to scroll all the way down to the bottom. And under History, where it says History Enabled, I'm going to set this to true. Let's scroll down again. Here we're provided a list of configuration options for our tag history setup on this tag. Now for starters, I need to specify a Storage Provider. This will simply be the database connection I'd like to store history on. So I'll expand the dropdown here, and I have a database connection that's just called MySQL. So I'm going to select that one. Now, if we'd like, we could leave things here, press OK, and we'd have history set up for our tag. But there are definitely some properties we can fine-tune here. These properties broadly control how often and on what values we should store tag history. We have a Deadband Style property, for example. Without getting into nitty-gritty tag history details, the Discrete style should be used when you're dealing with a tag that has a fixed number of states. For instance, a status tag that has a value of zero for off and a value of one for on, should use a Discrete style. Whereas a tag like this one, which is being driven from some property of the environment and doesn't necessarily have a fixed number of states, should use the Analog style. The default choice of Auto will specify the Deadband Style based on the data type of the tag. So let's go ahead and use an Analog style here. Now, I have two properties that go in tandem here, the Deadband Mode and the Historical Deadband. Basically in this configuration, if the value changes by less than 0.01, the change will not be logged in tag history. So a large Deadband will prevent small changes from being stored. Now, if I want to change this functionality to be based on a percentage of the current value rather than an absolute amount of change, I can change the Deadband Mode to Percent. So if say I wanted to only log a new value went it falls at least 10% outside the range of the previously logged value, we could use a Deadband Mode of Percent to accomplish this. But I'm going to leave it on Absolute for now. Next, we have a Sample Mode property. This provides us a chance to custom configure how often history should be logged for this tag. At Sample Mode of On Change, the value will be logged whenever it falls outside the Deadband we just specified. But I could change this setting if I liked. I could change it to Periodic, meaning we'll check to see if the value falls outside the Deadband every, say, 10 seconds. I can also use a Sample Mode of Tag Group which will allow us to only check against the Deadband when a certain Tag Group executes. I'm just going to leave the Sample Mode on On Change. And now we see there are two final sets of properties we can adjust here. By default, if the value doesn't change for three days, we won't log a new value in the database for three days. In some situations, this might prove undesirable. So we could specify a Max Time Between Samples. So that's, say, a value has to be logged every hour or every day. Similarly, we can set a Minimum Time Between Samples so that a fast executing tag doesn't continuously flood our database with new values. It's worth keeping in mind that all of these properties might benefit from some fine-tuning. Typically, there's some amount of data logging that's right for your project. But since the historian is running 24/7, some database considerations and constraints might come into play. So that's all I'm going to configure on this tag. Now, I'm going to hit OK. And I have a Perspective view set up here. This is just a proof of concept. I've set up a tag history binding on this table, that's simply fetching the values of this Pressure tag as it's stored to the database. Basically, just demonstrating that once the values are historized, we have easy access to that information from within Ignition. In future videos, we'll look at configuring tag history bindings like this one and also fine-tuning some more advanced settings in tag history.