Overview
The property group feature allows you to group several properties together for redundancy or synchronization purposes. To add new property groups, visit the Property Groups navigation bar link:
There are three types of property groups: RedundancyGroups, SynchronizationGroups, and SynchronizationMasterGroups.
Redundancy Groups
Redundancy groups are used for properties that should usually be in sync and are therefore redundant to protect against device failures. For example, you could wire up a device to the same GPI pins on two different xNodes. In normal situations both nodes would be tripped and Pathfinder would see two reasonably simultaneous closures. An "Or" logic flow could be created to trip off of whichever one came in. But without some complex logic there is the possibility of double processing of inbound signals. Property groups build intelligence into this using a combination of timing logic and (where possible) message ids to create a redundant path, but only process one of the two messages if both are received. An example diagram might look like:
In this situation the output of the PropertyGroup inherits the syntax of the input properties which is supplied to the logic flow editor. The property group handles the logic of understanding whether a new closure is the redundant closure to one on the opposing xNode, or if it is a new closure that needs to be processed. The PropertyGroup then only outputs unique signals. Then the logic flow can just work on the actual functionality that should occur without worrying about the redundancy aspect of the signals.
Creating a Redundancy Property Group
To create a Redundancy Property Group, click on the plus icon to add a new property group:
Give the property group a name and select Redundancy from the drop down. Case sensitivity determines whether values that are the same except for case should be considered equivalent. For example, in our gpio example, case sensitivity plays a role in whether H is the same as h. The pending interval is the amount of time that an event will stay in the pending state waiting for the recursive event from the other device before being removed. This does not pause the execution of the event, but if the duplicate event from the other device never comes, eventually we should stop waiting for it. If the duplicate event does come, then we clear the pending state but do not indicate the change since it has already been indicated.
Next we need to use the plus icon to add the GPI pin state property into the group. This will present a dialog where several properties can be configured:
The only property that is required is the signal property. The other two are used for very specific use cases where a group of properties are obtained at once and need to be evaluated only when the trigger property is set or when there is additional id information available that the system can use to identify unique events. In this case, set the Signal property to the GPI pin state property of xNode A by clicking the ellipsis button next to the signal property and selecting the Gpio pin. Leave the Id and Trigger properties blank. After selecting this pin state property click Apply, and the new property will be added to the group. Then repeat the procedure with the pin from xNode B. The result will look something like this:
We have basically defined that we expect to receive a pin closure from two different xNodes and to treat them as if they were one signal. The pending interval helps with the underlying logic to track unique cues versus redundantly received cues. Applying the changes to this property group will create the new group in the property groups list.
You will notice that the screen will also show the current value of the property and whether the property from each of the hosts is in sync or out of sync. Out of sync means signals have been received from one device that have not been received from the other.
Once this property group has been created, it can be used as the start point to a logic flow by setting the start point to the GroupValue property of the property group.
This logic flow will turn a VMIX channel on and off based on a GPIO closure except that the GPIO closure is fed via redundant sources in case of an xNode outage.
This can be extended beyond GPIOs to any other property in the system. So for example you could set up redundant device emulator paths and pair the resulting watchers from both emulators into a property group.
The output of a property group could also be applied to a Sap Property router. The example below is grouping some device specific meta-data and sending that information into a Sap Property router for distribution to automation systems:
The group state property of the property group can also be used to track redundancy states that are broken by using a delay in a logic flow such that if the property group remains out of sync for more than a certain amount of time, an alarm is raised.
Synchronization Groups
Whereas a redundancy property groups pairs redundant incoming signals, a synchronization group attempts to keep groups of properties in sync. For example you could group to GPO pins together and whenever and one of the pins in the group changes, that same state would be pushed to all other pins in the groups. This could also be accomplished via a logic flow, but this option simplifies the logical combinations when you are trying to keep multiple properties in sync.
Creating a Synchronization Property Group
To create a Synchronization Property Group, from the Property Groups view, click the + icon, and select Synchronization from the type. Give the group a name.
Click the plus icon to add a property. In this case you will just get the property selector dialog.
Add the properties you want to synchronize to the group.
In the example above, changing any pin on this port will cause all of the pins to be changed to that state. Click Apply to apply the changes.
This example could also be extended beyond gpio pins. For example, it could be used to keep VMIX On/Off states in sync between mix engines. Also notice that the GroupState property can be used in a logic flow to alert an administrator about states that remain out of sync for a period of time using a delay in a logic flow.
Synchronization Master Groups
The differences between Synchronization Group and Synchronization Master are subtle but important in determining which is appropriate.
Synchronization Group attempts to keep items in sync by using the last change to any item in the group. When one item is changed, the others are sent commands to change to the same value. In the case a device reboots and comes back in a state that is different from the group, the new state is the most recent and therefore would be used. However, this also means that a manual change on one item in the group will automatically get sent to all other items in the group.
Synchronization Master on the other hands has a property called MasterValue. Setting that MasterValue property to a certain value will send the value to all items in the group. In the case where one of the items in the group gets changed manually or via a reboot, there are two possibilities depending on the Allow Out Of Sync Parameter. If allow out of sync is true, then the groups state will get set to "out of sync" and no other action will take place. In that case, you can build your own logic to decide what action should be taken. If the Allow Out Of Sync property is false, then a command will be sent to try to force the item back into synchronization. Any time an item in the group changes its value away from whatever is defined in MasterValue, an attempt will be made to force it back if the Allow Out Of Sync Property is false.
<NoChange>
The one exception to the rules above is if the MasterValue is set to <NoChange>. In that case, the items in the group can behave independently again until an actual value is set in the MasterValue again. The state will still show whether the items are in sync or out of sync, but this can be used to disable the enforcement of master value when necessary. It is important to note that the MasterValue is not retained between restarts of PathfinderCore PRO. By default when a SynchronizationMaster group is first started, the MasterValue will be set to <NoChange>. If you wish the value to be retained between restarts, this can be accomplished using a memory slot with the StartupState set to LastValue and a logic flow that hooks the memory slot to the MasterValue property. Then you can change the MasterValue property by changing the memory slot, and the value will get reset when PathfinderCore PRO restarts.