[00:00] In this lesson we'll take a look at the historian simulator which is a simulator provider that's built into the tag historian module. This simulator is unique in that you don't need any sort of tags or external connections to retrieve some data from it. You can simply provide it a path and it will return a result set for you. To use it we first need to create an instance of the provider, so on our gateway here under the config section, I'm going to scroll on down and under tags, I'll click on history. Now I do have some history providers already configured but we'll ignore those 'cause I'm not going to use them in this video, instead, I'm going to click on the create new historical tag provider link. And from the list here, let's go ahead and click on simulator, I'll click next and we can give this a name here. So how about just simulator, I'll then go ahead and click the create new historical tag provider and that's all we have to do on the gateway side, we're actually ready to start using this new provider.

[01:05] So I'll switch over to my designer here and really you can use this provider anywhere in ignition that can request tag history queries or call them. So tag history bindings, for example, in Vision or Perspective, I'm not going to show you all of the different places since there's quite a bit, instead I'm just going to focus on the reporting module here, just because it gives me a lot of room to show off the feature. Now I have a report here, I have a blank time series charts, It doesn't have any data, so let's go ahead and populate this with some data. I'll switch to the data tab here and I'll hit the little plus button to add a new tag historian query. And here we do see that we have the simulator and we have a whole bunch of built in historical tags that we can use. We'll talk about the notation in the path here in just a moment, but I think to start with I'll go ahead and I'll grab this ramp tag, drag it over and then I'll play with some of the settings here, I'll go ahead and switch us over to real time, we'll say how about maybe just five minutes and I'll switch the aggregation mode to time weighted average. And I should add the reason I'm making changes to the history settings here is because it makes the resulting data set a little bit easier to talk about, so these aren't like mandatory for using the provider, you can set these to whatever you prefer.

[02:13] Now I'll switch over to design here and on my charts, let's go ahead and we'll add our tag history data source as the data key and then I'll grab that little ramp key there. We'll add that as a pen and now we can switch over to preview and We now have some data, now I can see it's doing this repeating ramping behavior and kind of just starts over every so often, it gets close to about a hundred or so. Now if we head back to the data tab here and we look at the path here notice that it does have a couple of pieces of information in the path that kind of stand out really. First of all, everything's delimited by an underscore, next you'll notice some commonalities with our data, our trend was ramping and we see the word ramp here. It peaked around 100 and we see 100 here. Now, if you look at the available historical tags tree here you'll notice one of the entries states function, period, amplitude and resolution. This one tag is an example that points out the various arguments that go into the tag path. So depending on what values you provide these arguments in the path here, the return results set will be modified.

[03:18] So to compare it to our tag, function determines what function to use. In our case we're using ramp period is the duration of the function from start to finish, so each peak in our ramp function will be spread across the amount of time specified by this argument. Amplitude is the peak for the function to use, resolution determines how many raw data points will make up the underlying results, we'll look closer at this one later on. Now if I make changes to my path here, say I changed the period to five M or five minutes, and we'll change the peak to 250. I'll switch back to preview and you can see we only get one peak over this five minute period of time and it does peak at 250. They'll also notice that it doesn't start at zero, rather the start here is midway up the peak, to help simulate real world usage, the results don't just initialize with zero here. Instead, the resulting data set acts as if the tag has been changing prior to the requested time range.

[04:12] If we were to change the range on our tag history data source, we'd see the earlier points in the day where this fictitious data would have peaked over and over again. Anyways, our path asks for a single peak add 250 over five minute period and you can see that's how the data is being presented. Now let's talk about the final argument in the path, which was resolution. If we look at the XML preview here we see the data starts at row zero. If I scroll to the bottom, we see the final row ends at row 99, so this trend has made up of 100 data points that 100 is actually due to the reporting module. Let's switch back to the data tab, the preview limit here on the right, which has nothing to do with the simulator, this is a setting provided by the reporting module. It's set to 100, so it's restricting the number of rows this query can return. I'll uncheck this just to remove the limit, I'll switch back to preview and we can see we are now at row 999, so 1,000 rows. Now this 1000 row is due to the history settings we have, so if I go back to the data tab, we're using a fixed sample size, so this query is aggregating all of the raw data that the history system has access to for this tag here and bringing it to 1000 points.

[05:20] Now, if I were to change this to on change instead, our results that is going to be driven purely by the raw data. Here's where the resolution argument comes into play because this ultimately determines how often a raw data point is generated within the simulator. Right now it's set to one second, so our simulated path will request a raw data point every one second over the specified range, which is five minutes. If we switched back to preview and look at the XML again we see 300 data points, which makes sense in a five minute period, there are 300 seconds. If we go back to data, we can change this from every one second to 200 ms or milliseconds. So if you wanted the raw data to be more granular you can modify the resolution. Back to preview, we can see considerably more rows and we ended up at 1499 or 1500 rows. Now the main benefit of the resolution argument here is that you can get a better idea of how the various aggregation modes and settings will be applied to the results of the query, but that about wraps up the simulator here. As you can see, it's pretty straightforward to use. There is more documentation in the user manual. You can go ahead just search for the historian simulator page, if you wanted to see the full list of all of the functions.