[00:00] In this lesson, we'll demonstrate some sample usage of several IEC 61850 driver scripting functions. For this driver, the available scripting functions are THE recommended means to perform writes to its various operation control attributes. For a full list of all available functions and their APIs, please consult the online Ignition User Manual. We won't demonstrate each function in this lesson, but we'll show the general approach of how to use them. Let's start by examining this Perspective view. It will be made available as an Ignition Exchange resource. Please see the link appearing beneath this video for how to obtain it. This view demonstrates interaction with a simulated IEC 61850 device to control a circuit breaker. The four blue buttons each run underlying event scripts using four of the available API functions: getControlParams(), select(), operate(), and cancel(). The big picture workflow here will be to: select a connected IEC 61850 device, obtain a full list of its operation control attributes, filter that list down to a specific subset of interest, use those parameters to write an on or off value to the device, and finally, confirm the commanded change in the breaker state.

[01:21] For the breaker state value, let's take a look at its data binding. Its read only display value is bound to a specific named tag, then that numerical value is mapped to a text value as shown here. Now, your tag path of course will likely differ from this one. Then that tag is also shown over here in our Tag Browser. Here it represents a display only operation control attribute on our connected device. We need to access this attribute in order to control our power breaker, but it's important to keep in mind that for this device driver, we must do this using available scripting functions instead of writing directly to this tag. Next let's take a quick look at the underlying event script for the Get Control Params button.

[02:09] We won't go through each line of this script. Hopefully the comments will guide you in that, but I will do a control+mouse wheel to make this text a little bigger and easier to read. So line 11 shows the key statement, the call to the getControlParams() API function. Its one input is the name of the connected IEC 61850 device, which comes from the line 8 drop down component. Once allResults is returned, the for loop at line 17 reassembles those results into a specified ordering, and lines 23 to 25 apply a filtering string if specified. Scrolling down a little bit, on line 31, the results are converted into a dataset, and then used to populate a table of control parameters. Okay, so now let's begin running through an intended testing sequence. When we go up here to Preview mode, we notice that all the buttons become disabled and we must select a device to proceed. So we'll select our one configured device, which then enables Get Control Params. When we press this button, we run the first script we examined earlier, and we're presented with a table of all available control points, with all operation control attributes beneath for reference.

[03:27] This winds up being a lot of results, and maybe we're just interested in a certain subset of them, such as these ones up near the top. So we can specify a filtering pattern. Let's use SUBA_DCULD1 like so, and run Get Control Params again. So now we're down to the subset of five results. Next, in order to perform an actual control value write, we need to specify one of these control access points. Let's select this last one. When we do this several things happen. The other top pane fields now populate.

[04:05] We have specified a ctlModel of 1 which indicates direct with normal security. Because this is not one of the select-before-operate, or sbo options, this means we only need to use the operate() function to write. The Select and Cancel buttons are conditionally enabled based upon ctlModel, so they remain disabled. Their underlying scripts will be comparable to what we will see for Operate. With that in mind, let's also look at the event script for the Operate button, but we'll need to go back to Design mode first, before we can select the Operate button and open its event script. Once again, I'll use control+mouse wheel to make the text a little bit bigger for easier reading. And again, we won't go over each line, but here are the key points. Line 22 shows the key statement, the call to the operate() API function. Its 3 inputs are: the device name, coming from the line 9 drop down component, the control parameters, assembled using the line 10 function call, then two values reset to other preferred defaults, and the control value to be written to the device, coming from the line 20 drop down component.

[05:20] If we go back into Preview mode, now we are ready to turn our breaker on and off. We see the current breaker state is off, which corresponds to this displayed stVal tag value of 1. We can then specify a write of 2, or breaker on, and press Operate. After some short latency, we now see a breaker state of on, and the tag value updates to 2, which represents the on state. By the way, note that if we try to command the same state as the state it's already in, the function would fail. Finally, let's turn the breaker back off. We can now specify a write of 0, or breaker off, and press Operate.

[06:02] Again, after some short latency, we now see a breaker state of off, and the tag value updates to 1, which represents the off state. And yes, that is correct, a commanded write of 0 results in an off state of 1 per the standard. So in this lesson, we've shown how one might make use of several driver API scripting functions to control the state of a connected IEC 61850 device.