Updating Control Tool Configuration in Production Systems
After a system is in production, Control Tool updates are typically applied for one or more of the following reasons:
• To provide control actions for new device classes that are being added to the network (see Adding New Device Classes).
• To map existing actions to existing device classes (see Mapping Existing Actions to Existing Device Classes).
• To add new actions (for existing device classes; see Adding New Actions).
• To change when an action is enabled (see Changing When Actions are Enabled).
Adding New Device Classes
Configure the new classes in your [project]_inheritance.dat to inherit from the correct superclass so that it automatically gets the desired Control Tool buttons.
Mapping Existing Actions to Existing Device Classes
Either change the inheritance of certain device classes to get the desired set of buttons, or change the <Visible> and the <ControlAction> elements in the buttons to include the added superclass.
Adding New Actions
Add a new CONTROL_ACT record and reference a new JBot Action name in it.Then use the existing PROJECTS_ACTIONS.inc examples as a guide and add the new JBot Action to it.
Also create the button in the Control.xml file, reference the CONTROL_ACT.act_key in it, and set up the <Visible> and <Enabled> tags.
Changing When Actions are Enabled
Modify the <Enabled> tag in the Control.xml file, as with the other JBot tools.
Aggregate, Secondary, or Associated Devices
If you have the AGGREGATE_DEVICES model table populated and you wish to operate devices from a different device's Control Tool, you will need to make use of the UseAggregateModelDeviceCommand and UsePrimaryDeviceCommand. Use the UseAggregateModelDeviceCommand and pass it the index of the aggregate to use and the subsequent operation Commands will operate the aggregate device. Use the UsePrimaryDeviceCommand to move control back to the selected device if you are performing aggregate actions.
Note that the Look Ahead does not take into account any previously instructed actions. So when you instruct an aggregate action on multiple devices, the Look Ahead results will not reflect the results of any previous actions.
Customer Counts Lists in the Look Ahead
The Drop Count, Pickup Count, and ATO Customers tabs in the Look Ahead can display four standard rows, plus any number of grouped critical customer type rows.
• NUMCUST: Total Customers
• CRITCUST: Critical Customers
• DERKVA: DER kVA
• REVENUE: Total Revenue (Not used in standard product configuration)
The "critCustGroup" SRS Rule allows you to configure groupings of different critical customer types, which are also available in these tables. For example, product configuration contains groups for KEY, EMER, and MED, so CRIT_KEY, CRIT_EMER, and CRIT_MED are also available as rows.
Define the row labels using the LOOKAHEAD_ROW_NAME JBotFormat, and configure the order using the LOOKAHEAD_ROW_NUM. Hide unwanted rows using the SetFilterCommand in your DLG_LOOKAHEAD.xml.
Configurable Device Lists in the Look Ahead
Product is configured to display a "View Cap. and Reg." table. This set of devices is configured using the lookahead_dev_list abstract base class. However, you can configure any set of device classes in this tab using this inheritance scheme, and you can rename the tab to match.