Pathfinder Core PRO’s event system is called Logic Flows, and it enables information visualization so that you can see how things work within your system.
Click the Logic Flows link in the navigation bar to open the Logic Flows user interface.
Each Logic Flow can be thought of as an event. More specifically, a Logic Flow is a set of property translations. During an event, we convert an input property value to an output property value.
There are four components that may be used to design a Logic Flow:
Using these tools, you can visually build Logic Flows to accomplish just about any task you want.
When you first look at the Logic Flows screen you will see an organizational panel on the right called Views. Think of Views as folders in your computer’s file system - organizational containers into which you can place Flows, allowing you to keep all Flows related to a certain subject in the same place.
Important Note: Clicking the Views tab allows the panel to slide in and out.
To create a new View:
Check an existing View (this will become the parent View).
Click the Add (plus) button in the Views panel.
Type a Name for the new View and click OK.
Like your computer folder structure, you can nest Views as deep as you like. While you can add Flows to the master LogicFlows View (your “Root” folder), this is not recommended as LogicFlows is the one View that you cannot completely delete. Instead, devise a View naming strategy and create additional Views underneath LogicFlows to store your Flows.
Important Note: Each View is limited to 100 Flows.
There are two special Views called HardwareMaps and _panels. These Views are created by the system and used to manage the mapping of software buttons to hardware controls and bindings in HTML5 user panels. This is described in the chapter on HTML5 panels, but it is important to understand that these Views are managed by the system and should not be deleted.
With a View selected:
Important Note: You cannot select multiple Views for copy and paste operations, though if you select a View with child Views, those child Views are included in the copy operation. All pasted Logic Flows will be in a disabled state whether the operation started as a cut or a copy.
It is assumed that after completing a copy and paste you will want to modify the Start and End Points of the Flow to reproduce behavior using different End Points.
View, copy, and paste operations are completed by the Pathfinder Core PRO appliance rather than by the browser and so they do not require an Apply.
Under the hood, the browser sets a write-only CopyTo property on the copied View folder object via a SapV2 Set message. The value used in the set message is the path to which the View should be copied. The Pathfinder Core PRO Logic Flow engine then handles the data cloning.
To delete a View:
Select the View
Click the X button in the Views panel
The system will ask for confirmation; all Logic Flows and descendent Views of the View selected for deletion will be deleted as well
From left to right, the Toolbar controls are:
Toolbar controls will be enabled or disabled depending on whether the control is currently valid. For example, the Cut icon will not be enabled if you do not have a Flow selected that can be cut.
Understanding how these tools are used will be easier if we walk through creating a Flow.
Click the Logic Flows checkbox then click the Plus icon in the Views panel
Type a name for the new View and click OK
You can select "multiple Views" to view the Flows from multiple Views together on the same screen; in order to create new Flows, you must select a single View since the system has to know into which View to place the new Flow; click the newly created View’s checkbox to select the new View; click the root Logic Flows View to uncheck its checkbox so only your new View is selected
Once a single View is selected, the Add button (plus) in the main control panel for Logic Flows will switch from its disabled grey state to green; click the Add button to create a new Flow consisting of a Start Point, a Translator, and an End Point
Important Note: This Flow is in black and gray indicating that these are pending changes that have not been submitted to the system yet. So far, they only live in your local browser.
All Flows must have at least one Start Point, one Translator, and one End Point, which is the simplest Flow you can creat. However, we have not yet set parameters to define what this Flow will do. You can define the options for each block in this Flow by double-clicking on the block, though double-clicking on the Translator itself will not do anything until the Start Point and End Point are defined. The reason for this will be explained shortly.
Double-click on the Start Point block; its background will turn orange on the first click to indicate that it is selected.
The second click opens the property selector dialog. This dialog is used to select a property in the system that the new Flow will monitor for changes.
Use the arrows to expand and navigate into the objects in the system until you find the object and property you want to select. Properties will have a green dot next to them as opposed to the expansion arrow.
You can either click the property you want to monitor and then click Select, or just double-click the property to select it.
In this example, we are selecting the PinState property of GPI#1, Pin#1 on the Fusion device at 192.168.2.62. Notice that as you select properties in this dialog, a description of the property will usually appear underneath the tree window providing more detail about the property’s purpose.
Important Note: The property selector dialog has a simple list and an API list. The API list is only recommended for advanced users and so will not be discussed until later in the documentation.
Important Note: Hovering over the Start Point that has been assigned a property will cause a pop-up hover box to appear with more detailed information about the selected property.
Double-click on the End Point block and repeat the procedure to select the End Point or property we want this Flow to change; in this example, we are going to pick an LCD button, but you could also pick a GPO in order to make the GPO state follow the GPI state
At this point, the Flow looks something like:
Important Note: The list of available properties differs depending on whether you are editing a Start Point or an End Point. This is because the system is intelligent enough to know if a property is read only, read write, or write only. Properties that are read only may not be used as an End Point (something you want to change). The system will only display properties that make sense for the type of block you are editing.
With configured Start and End Points, you can edit the translation table by double-clicking the ListTranslator block
The dialog that opens allows you to enter a list of translations you want to execute as part of this Logic Flow. The other buttons on the translation list screen can be used to move translation definitions up and down in the list, insert new ones, and remove them.
Select the top translation point (*=*) to enable the drop-down boxes below; the left drop-down has Low and High as options, and the right drop-down has a list of indicator states; for this example, select Low in the left drop-down and On in the right drop-down
Click Add to add another translation to the list
For this example, select High in the left drop-down and Off in the right drop-down
You cannot edit the translation block until the Start and End Point properties are configured because the system will filter the list of possible options depending on the property selected. For example, in this case, Low and High were available options on the left, and indicator states were available on the right. If the Start Point had been the CurrentSource property of a destination, the right drop-down would present a list of available router sources.
Your Flow should now look something like this:
What we have just defined is that if the Start Point (GPI) is Low, then we are going to set the LCD Button indicator on the button to On. If the GPI is High, then we are going to set the LCD button indicator to Off. We are essentially defining a list of rules as to what the End Point value should be depending on the Start Point property value.
When creating translation items, the asterisk serves as a special wildcard that will be evaluated as “any” value. For example, we could have made the second entry in this translation list *=OFF.
Since the list is analyzed in order, this would mean that if the GPI is Low, then the indicator should be turned On. If the GPI is anything else other than Low, then the indicator should be turned OFF. In this case, using * or explicitly defining the High are equivalent because the GPI only has two possible states.
Where the * comes in useful is in situations where there are multiple options on the Start Point side. For example, if the Start Point was the current source routed to a destination, we could build the translation such that if a specific source is selected the indicator would be On, and then use the * to say if there is any other source routed, turn it Off.
Order is important. If you were to move *=Off to the top of the list, the indicator would always be Off because the first item in the list says if anything, then Off, and the system would never analyze any of the other items in the list.
Generally, a * should almost always appear at the end of a list of translations as a catchall. If there is a * on the right-hand side of the translation it means to pass the value from the left on unchanged. So *=* would pass anything from the Start Point to the End Point (or next step in the Flow) unchanged.
For those of you familiar with programming languages, this list works very much like a select case or switch statement. When the Start Point property changes, the value is analyzed in order through this list until a match is found and then the correct value is applied to the End Point or next step in the Flow. If no match is found, the End Point is not changed.
Once you are finished, click Done. The Flow will now look something like this:
This Flow is not active yet, and the black and gray states are showing us that this Flow has not been committed to Pathfinder Core PRO; in the top toolbar, the flashing Apply button indicates changes are pending; click Apply to commit the changes to Pathfinder Core PRO
The Flow will now change colors to indicate that it is a live and active Flow:
The Flow diagram does not simply show the design of the Logic Flows in your system. It also shows the live up-to-the-second state of each of the Flows. Using the Flow example created above, if we trip the source GPI to Low, we will see the diagram change to:
And if we switch it to High, it will change to:
Within the top of the translation box, we see the currently active translation state in text and a color change depending on that state. These dynamic changes indicating the state of the Flow makes for much easier monitoring and troubleshooting.
Note: These colors come from a file that may be edited in an advanced web page if necessary.
Translation points are one-to-one only. In other words, we are translating one value from a property to another value on another property. Combiners, on the other hand, allow us to pass values to multiple End Points and make logical decisions based on more than one Start Point.
To add a Combiner, click a Translator in an existing Flow to enable the Combiner tool in the toolbar; click the tool to insert a Combiner into the Flow
Using the Flow we created in the example above, it will look like this:
Combiners can perform many useful functions, but each Combiner type both require a minimum number of inputs and are limited to a maximum number of inputs.
As you attempt to change Combiner types, you will only see options that meet these restrictions. For example, with the single input in our sample Logic Flow, we are restricted to NOT, PASSTHRU, and DELAY Combiner types:
We can access the other Combiner types by adding the requisite number of inputs by clicking on the Combiner to select it; notice that both the Start Point and End Point tools then become available
Click on the Start Point tool to add a second input to our Flow
By adding a second input, you will notice the Combiner switches to AND.
With two inputs, we can perform other Combiner operations, including: AND, OR, NAND, NOR, XOR, XNOR, EQUALITY, and RELAY.
In this case, since the default AND Combiner is a logic gate, the translation types entering and exiting the Combiner are automatically switched to True/False. By assigning a second GPI pin to the second Start Point…
…we can change this event so that two buttons must be held simultaneously for the End Point change to happen. This Flow will light the indicator light on the button only if both GPI 1 and 2 are Low.
As it is, this Flow is not very useful, but if we were to change the End Point to be a route destination, it becomes more interesting; to do so, double-click on the End Point and instead of a GPIO, expand the Routers section and select the CurrentSourcePath property of one of the router destinations
Your Flow should now look something like this:
Edit the translation which is after the Combiner and change the translation so that True= one of the sources in the right-hand drop-down of the translation dialog; remove the False translation as we do not want to do anything if the buttons are released, and you end up with:
This essentially means a user must hold two GPIO buttons down simultaneously and then source SRC 4 will be routed to destination DST 2. This is a common scenario where we don’t want an accidentally bumped button to change the air chain routing.
Logical Combiners include AND, OR, NAND, NOR, XOR, XNOR, and NOT. All of these except NOT accept multiple inputs which must be translated to True or False on the input side. NOT only accepts a single input. In each case, the translation that feeds the input of these Combiners should be converted to a True or False like we did in the example above.
The output of the Translator then becomes either True or False based on the truth table associated with the logical type selected.
The PASSTHRU Combiner allows only one input but can pass the value from the Start Point translation to as many output Translators as you like, allowing you to change multiple output properties based on a single input property.
The RELAY Combiner allows you to define one Start Point property that will translate to a True or False. If it evaluates to True, the value from the second Start Point is passed through the Combiner to any translations on the output of the Combiner.
The diagram within the combination displays which Start Point translation is acting as the trigger and which is acting as the PASSTHRU:
This will achieve the same functionality as our previous example but in a different way. GPI 1 must be Low in order for changes taking place on GPI 2 to pass thru. If it is Low then changes from GPI 2 will be passed to the output translation which converts the Low to a route change.
The EQUALITY Combiner takes multiple inputs and will result in an output value of True or False depending on whether all input values match.
The EQUALITY Combiner also has a Case Insensitive checkbox which defines whether comparisons are done in a case sensitive or insensitive way:
This Combiner can be used in situations where the primary concern is whether the property states are equivalent or not.
The DELAY Combiner takes a single input and introduces delay directly into the Logic Flow. It works like a PASSTHRU Combiner in that it takes the input value and passes it through to the output but only after a configured number of milliseconds. There are also some additional parameters that can affect how this Combiner functions:
DELAY Combiners can be used in many situations where you need to introduce some delay into a Logic Flow. Previously this required using an interval timer. Therefore, there will be many situations where an interval timer is no longer necessary to accomplish the task as the delay can be built directly into the Flow. This also reduces licensing requirements as the DELAY Combiner does not require an intermediary timer End Point.
Interval timers are still useful in situations where a single delay needs to be stopped, started, reset, or manipulated by different Flows.
In this example, the EQUALITY Combiner outputs True or False depending on whether two silence alarms are in the same state. This can be useful if two audio channels should have the same audio. Silence is expected in certain situations, but we are trying to make sure that if audio is present on one, it is present on both and if it is silent on one then it is silent on both. True or False is translated into a message of AudioMatches or AudioDiffers. A delay is introduced to expunge short variations of alarm states and only pass on definitive states. This is one example of how the DELAY and EQUALITY Combiners might be used.
In many cases you may want the DELAY to pass a value through after the delay but then reset the output for the next change. For example, if we want a Flow that requires a user to hold a button down for a length of time before making a change, the Flow might look something like:
Our goal with this Flow is the following:
If the button is pressed, start a 5 second timer
If the button is released cancel the timer
If the button is held for 5 seconds make the route change
The DELAY Combiner has an input value and an output value. Changes only get passed to the output Translator when the Combiner’s output value changes. And the delay is only analyzed for countdown when the Combiner’s input value changes. For this example, we would set the DELAY Combiner parameters as follows:
The timer starts counting
If the user releases the button before the timer elapses, the input value of the Combiner gets set to False. Since this matches the cancel value, the delay timer stops counting
A route change is made
Since the Clear Value and Clear Output after countdown completes options are set, the output value of the Combiner is then set to False again so it is ready for the next button press
When the user releases the button, the Combiner input is set to False but since that is the Cancel field no change to the Combiner output is made
Without the Clear Value and Clear Output after countdown completes options, the output of the Combiner would remain True and so the next press would not change the output and therefore would not trigger another route.
If we cleared the Cancel value and did not use the Clear options, releasing the button would pass False to the output but 5 seconds after the button was released. It is important to note that a Cancel value if set will cancel the countdown, but the Cancel value does not get passed through.
These parameters will allow you to produce differing effects using the DELAY Combiner depending on the required goal.
By adding Combiners and Translators you can make any individual Flow as deep as you need it to be.
This example is not created to do anything specific; it is just shown to illustrate that you can theoretically continue to add Translators and Combiners as needed to get the logical job done. Translators and Combiners must alternate. You cannot have a Combiner next to a Combiner or a Translator next to a Translator, but the user interface helps with that by only enabling the controls you can use depending on which logic block you currently have selected.
Another relevant example is EAS. This is a pretty common EAS Flow that we see customers make:
Important Note: if you are going to use a Flow like this, it is critically important that you also turn on the Skip startup state request and wait for next change option. See the Advanced Options section on this option.
Without enabling this option, a restart of the system will request the current GPI state which is High and will therefore toggle the Previous route. In many cases this will route “nothing” to the air chain because no previous state exists yet.
However, even with that option enabled this Flow may produce unforeseen results. For example, what happens if the GPI goes Low and someone manually changes the route before it goes High again? At that point EAS is now the previous source when it does go High. This can be solved by using a slightly more complex Flow and Previous:
In this example, a route to Previous will only happen if the GPI is High and we are currently on the EAS source. This will function in a much more reliable manner.
While these examples have been EAS related the same rules apply to other uses of previous. More importantly, if you can avoid the use of Previous and design the Flows to be more specific, the outcome will also be more reliably specific.
If you select the End Point of a Flow, you will notice that the right Translator control in the control panel is available and not disabled. This is what is referred to as "extending a Flow". You can create a second Flow whose Start Point is the same as the End Point of the previous Flow.
If we go back to this example Flow:
Click on the End Point and then click the End Point control in the tool bar.
Our Flow now looks something like this:
In this case, the second Flow is joined to the first Flow because the Start and End properties are the same. Likewise, if we had added a second Flow using the + button and then set the Start Point to the DST 2 destination’s CurrentSourcePath, after we applied the change, the system would detect that the Flows should be joined and join them.
In this example we could now set the indicator of a button at the End Point of the second Flow:
What we have designed is a Flow where if you hold GPI buttons 1 and 2 down, PC4 source will be routed to PC4 destination. And if PC 4 source is routed to PC4 destination then LCD button 1’s indicator will be turned on. If anything else is routed to that destination then the Indicator will be off.
The system is intelligent enough to recognize when Flows should be joined into a single logical entity.
Cut, Copy, and Paste are standard tools and require little explanation. You can select a Flow by clicking in the area surrounding a Flow at which point the cut and copy icons become available. "Cut" will remove the Flow from the View and place it on the clipboard while "copy" will just make a copy of it on the clipboard. Once a Flow exists on the clipboard it can be pasted back into the current View or any other View.
The system does make some assumptions regarding pasting. If you copy a Flow and paste it back into the same View, the system assumes you are trying to duplicate the functionality with a new set of End Points. It will clear the outer Start and End Points of the pasted Flow so you can select new ones.
It is important to reiterate that none of the changes involved in a cut/copy/paste operation ever become a reality on the system until you click the Apply button, and that clicking the Cancel button will return to the last known applied state.
Each Flow can be assigned a title. If you double-click in the whitespace surrounding a Flow, the system will ask you for a title for the Flow. Click Apply to apply the title. Flows that have titles will display the titling text underneath the Flow.
Titling is a very important habit to form as it makes it much easier to glance at a Logic Flow View and understand the states of the Flows and which Flows are performing which functions. Additionally, it is useful as an organizational tool as Flows with titles will be displayed alphabetically within the View. Otherwise the Flow order within the View is somewhat arbitrary.
Translators, Combiners, and entire Flows may be enabled or disabled. Select the Translator, Combiner, or entire Flow (by clicking in the whitespace within the Flow), and then use the disable/enable button on the control panel.
This change is the only one that takes place immediately within Pathfinder Core PRO Logic Flows without the need to click Apply. The object will become greyed out and that particular object will no longer function, stopping the Logic Flow at that point. For example:
If you trigger the GPIs, their states will change within the attached Translators, but the End Point in the first half of the Flow will not change because the Combiner is disabled. This is a useful tool if you are testing logic up to a point but do not want the End Point (which might be an air chain change) to change. It is also useful if you want to temporarily disable a Flow during testing or troubleshooting.
If your system is clustered and you are Viewing Logic Flows on the secondary system, you may see a lighter gray form of disabling:
Also with clustering the upper right corner will show an Event System state:
In this case you are being shown that the final output will not actually execute on this server because the other server is currently in control of the event system. On that server, you will see:
And in the right corner:
Important Note: The event system is never actually turned off in Pathfinder Core PRO. When a Logic Flow needs to make a change to an End Point, it first checks to see if it has the lowest IP address of the currently active and online servers in the cluster. If so then it executes the action. If not, then it does not.
The Event System True or False will be hidden on systems that are not in a cluster because in that case the Logic Flow End Points will not be disabled by the clustering system.
You may notice when editing the Start or End Point of a Flow that if you select an object in the property selection tree (arrow icon) instead of a property (green dot icon), you will get a warning message that looks like:
Object translations are a slightly more advanced subject and should be used with caution (hence the warning), but they can also be extremely powerful. Object translations will most likely be used in situations where you want to mirror several different property states across a couple of objects. We could create a Translator Logic Flow where the Start Point is a VMIX sub mixer on Engine 1 and the End Point is a different VMIX sub mixer on a different engine:
This Translator looks slightly different in that the Start and End Points only have two pieces of information rather than the usual three.
If we do not alter the translation pattern from the default *=*, every change to every property of every sub-object under the sub mixer 1 will get mirrored to the equivalent object and property under sub mixer 2. For example, if sub mixer 1, channel 1 gets turned On, then sub mixer 2, channel 1 would also be turned On. If sub mixer 1, channel 3 has its TimeDown property changed, then sub mixer 2, channel 3 will also get its TimeDown property changed. This allows us to mirror an object’s settings.
When you edit the translation list and select an object translation, there are additional drop‑downs that allow us to specify the object’s properties as well as its values. For example, we could change the translation pattern from *=* to:
In this case, we are specifying that we only want this translation to operate on State properties. If sub mixer 1, channel 4’s State property gets turned on, so would sub mixer 2, channel 4’s state property. Other properties would not be affected.
Or, we could apply values such as:
This allows us to invert the states on the second sub mixer. Now when sub mixer 1, channel 5’s State property gets turned on, sub mixer 2 channel 5’s State property gets turned off and vice versa.
Another useful way to use Object Translators is when you want to set multiple properties on an object. For example:
In this case the Start Point is a normal property but the End Point is an object selection. If we click on the translation properties we can make the configuration look like this:
In this case, we are setting two different properties on the button each time the GPIO pin state changes High or Low. This can simplify the Flows and greatly reduce the licensing counts used when there are many button states that need to be set.
Object translation is extremely powerful in situations where you want to match multiple properties across two similar objects or multiple properties on a single object.
It is common to need a button to latch, where each press of the button will toggle something back and forth. Using the kind of logic shown above to accomplish this can get complicated because the state becomes a condition which is also an action. For example, many novice Pathfinder Core PRO users may try to create a Flow that looks like this:
Warning: Do not use this Flow. This is an example of what NOT to do!
The goal of this Flow is that each time a GPI goes Low, the user wants to toggle the on state of the fader back and forth between on and off.
The user has tried to create a Flow where if the GPI is Low and the button is on, it turns off, and if the GPI is Low and the button is off, then it turns on. The problem is that this creates a loop that lasts as long as the GPI is Low.
Setting the GPI to Low changes the state of the console channel which in turn causes the second half of the Flow to change it again and so on until the GPI is returned to High. This leads to interesting and convoluted loops resulting from trying to solve what on the surface appears to be a simple problem. To avoid this scenario, we have crafted two much simpler approaches to latching in Pathfinder Core PRO.
Many of the properties that have two states (On/Off, Low/High, etc.) also have a value that you can set called Swap. For example:
In this case, each time the button is pressed, the button state will be swapped (On to Off or Off to On).
If a Swap value is available, it is always preferable to other options.
To achieve similar behaviors for properties that do not have the Swap value, you can use the Latching Memory Slot. While basic memory slots can be created using the Logic Flows property tree as a shortcut, there are additional types that can only be created from the memory slots page as outlined in the Memory Slots chapter.
To create latching functionality, go to the memory slots link in the Navigation Bar and add a new memory slot using the plus icon. In the resulting dialog, switch the memory slot type to “Latching Memory Slot”. Provide a name for the slot and click Apply to create the slot.
The Latching memory slot can only have a value of True or False. For example, in Logic Flows we could now add a Flow such that whenever a button is pressed on the console, the Translator sets the trigger property to True:
It also has a property called "Trigger" which is write-only and cannot be read. Whenever you apply a True value to it, it automatically switches the SlotValue property of the memory slot from True or False to the opposite state. This simple Logic Flow will cause the latching memory slot to switch its value back and forth every time button 10 is pressed.
Next, we can create a second Logic Flow that defines what we want to happen depending on whether the Latching memory slot is True or False. For example:
Now the button will cause the latching memory slot to switch back and forth between True and False. If the slot’s value is True source sa_server_05, it will be routed to Destination sa_server_04. If the slot value is False, then whatever the previous source contains will be routed back to Destination sa_server_04.
It is important to reiterate that Swap is preferable where it is available. For example:
In this case, the Trigger property causes the latching memory slot to Swap between True and False each time the GPI goes Low, and then that True or False is translated to the on/off state of the fader. Engaging the GPIO repeatedly will cause the fader to turn on and off. The problem with this Flow is that the fader can also be turned on and off with the actual console button which causes the latching memory slot to get out of sync with the fader state. This could be solved with a third Flow if we allowed you to force the state of the memory slot each time the fader state changed, but this requires numerous Flows and the creation of a memory slot for every instance of this functionality. This approach feels too complicated to accomplish what should be a simple task.
The Swap value makes this much simpler and is all that is needed to solve this problem:
Each time the GPI goes Low, a value of Swap is sent to the fader. The device manager picks up this request, checks to see whether the fader is currently on or off, and sends the opposite state as a command to the equipment. The problem with the earlier Flows is that the Flow logic had to encapsulate all viable options of the existing state and specifically request what state to move to accordingly. The Swap property removes that complexity from the Flow logic and allows the system to handle it for you.
It is important to note that the Swap value is an action and so will only appear in the translation options for an End Point. It has no meaning for a Start Point because placed there, there it is not an actual state accordingly will not appear in the options on a Start Point. The user interface will present the option only where it is available. For example:
Important Note: Axia LCD buttons and user button indicators represent a special case in that they have more than two options including On, Off, Flash, Wink, and a variety of other flashing states. However, we chose to add a Swap value to this property because On and Off are the states that are most often used. If a button indicator is Off and the Swap value is sent, it will turn the indicator on. If it is in any other state when the Swap value is sent, the indicator will be turned off.
Detected devices identified as Infinity products have a SendToRestAPI property which can be used by Logic Flows to address the Infinity Rest API. The format of the commands addressed to this property should be as follows:
For example:
Note that Gets have not yet been implemented as we do not want to encourage polling logic. It is also important to know whether or not the value being sent needs to be wrapped in quotes.
Contact Telos support for details on properties that may be manipulated using the Infinity Rest API.
Dialing and status items are exposed in the Logic Flows simple tree under the Z/Ip One branch.
When viewing a Start Point there are several options:
It is important to understand the difference between Call#0 > State and ConnectionState. Call#0 > State lists all possible connection statuses including multiple options for Idle and options for how the connection was established. ConnectionState offers only Idle, Connecting, and Connected options making it suitable for situations where logic needs to be fired based on the connection being active or disconnected.
The ConnectedTo property will contain the phone book entry matching the one selected in the Call Connect property allowing you to display the current call connection phonebook entry name.
Important Note: In addition to these properties, the API tree contains a much larger set of properties matching those from the Z/Ip One Lwcp API. Consult the Z/Ip One documentation for details on these other properties.
When selecting an End Point in the Simple tree, the Z/Ip One branch includes several properties for any Z/Ip One in the system:
Connect and Drop can be used to establish and drop connections. After selecting the Connect property as a Logic Flow End Point, the translation list will display the list of entries in the Z/Ip One phone book. Currently, only phone book entries may be used for dialing:
Important Note: In general, the Codec settings will not be used as an End Point since those settings are normally stored within the call phone book entries.
There is also a special phonebook entry that only lives in Pathfinder Core PRO called None which, when dialed, will behave the same as the Drop item.
For example:
This Flow will dial the Z/Ip One every time Fader 1 is turned on and drop the call every time it is turned off.
The iPort branch in the simple tree exposes the Encoder and Decoder Enable and Disable options. We have limited those options to the simple tree as most other properties related to the iPort MPEG side of the configuration are considered advanced and are not normally dynamically adjusted.
Most of the other settings found on the Configuration pages of the iPort are available via the API.
Some additional explanation is needed regarding the VX and its control protocol. This protocol allows Pathfinder Core PRO logic flows and user panel controls to monitor and change Vx calls in a studio. Control points such as lines, studios, call states, comments, and call actions are available to be used by Pathfinder Core PRO via this protocol.
It is important to understand that when you connect to a VX engine on the control port, you have to select which studio to interact with. As a result, if you want to monitor multiple VX engine studios in Pathfinder Core PRO at the same time, a separate TCP connection is required for each studio. Rather than enabling this by default when many customers may not need this functionality, we decided to allow the administrator to enable the studios they wish PathfinderCore PRO to interact with and leave the others disconnected. This conserves resources.
To begin using the VX Control protocol, go to the Logic Flows tab and select a logic flow view. Add a flow and double click on the end point. Within the tree you will see a new branch called VxEngine Call Control.
Clicking on the [Add Studio] branch will bring up a dialog where you can select which studios you want Pathfinder Core PRO to use and monitor.
Select the VxEngine whose studios you wish to enable from the drop down and then enable the check boxes for the studios you wish to have available. You need to click apply for each engine whose studios you enable or disable. If you have changed the Lwcp password in the VxEngine, you need to supply the correct password in this dialog as well. If you change the password after adding the studios into PathfinderCore PRO, come back to this dialog, deselect the studios and apply and then reselect them using the new password and apply again. This is not a dialog that is specific to this instance of logic flow editing. You are adding or removing that studio support from the system and so it is generally a one-time change, and does require some cpu resources while adding or removing the studio. We decided to place this dialog within logic flow because that will be where customers will most frequently be interacting with the VX Control protocol data points.
Once added, the studio and property items will then be available in logic flows under the specified engine:
Warning: If you add new studios to an engine, you need to collapse and re-expand the engine branch to see the new studio. Also if you uncheck (remove) a studio, you may need to refresh the logic flows web page before it is removed from the property tree. Removing (unchecking) a studio removes it from Pathfinder’s control and monitoring entirely which may affect any other flows that use that studio.
As an example as to how this might be used, you could cause a gpio to light an indicator whenever a given line rings. To accomplish this, you would create a flow where the start point is the line’s callstate property and the endpoint is a gpio.
The flow would look like:
For the translation you would create something like:
Additional flows could be added to trip other gpio pins for different lines.
It is important to note that the properties will differ significantly depending on whether you are selecting a start or end point. There are numerous properties that are “read only” or “write only” and so will only display in either the start or end point editing. Selecting a property in the logic flows tree will also display a brief description as to what the property does.
You can also use these properties in user panels. So for example, you could use a label object and bind the label’s background color to the line call state and the textContent to the caller_id field. A button could then be used to answer and drop the calls. One of our support engineers crafted the following using the html 5 user panel designer during our initial testing.
This uses a large label where the call state is bound to the background color, and smaller transparent labels on top of that are bound to the caller_id, comment, and time properties. An image was also overlaid that swaps between multiple images to represent call state. Finally, additional buttons were added for the additional call actions such as seize, drop, hold, etc. Using these items you can develop a user interface to your liking that works with the vx phone system. This also allows you to create a user interface that mixes console fader control, call control, and other user interface items to achieve your specific needs.
Below find a list of the commonly used properties. Additional properties may be available that are not included in this list, so review the logic flow tree and property descriptions within the tree. Items in this table that are marked as true only in the syntax are write only actions where setting the property to true is a momentary state that triggers the action.
Each Quasar 4 fader panel device type has a QSCONN property within the lwrp protocol. If you already have Quasar fader panels in your system, before upgrading to 1.18, you may need to remove then and re-add them in order to get the correct object type. If they are appearing in your devices list as Quasar_4-Fader as opposed to QuasarFader4, you might need to remove and add the panel to PathfinderCore PRO again.
The QSCONN object is accessible via the API tree in logic flows under the Devices\<QuasarFaderPanelDevice>\LwrpInterpreter\LwrpRoot\QSCONN path. It is not a normally used object and so does not appear in the simple tree. It has two properties:
Master: (RW): Holds the IP address of the master module to which this fader bank is attached.
Status: (RO): Whether the Fader panel is currently connected or disconnected from the master panel.
The master property may be changed with a new ip address to change what master module the fader panel is connected to. This functionality should be used with care and discussed with support to be sure you understand the ramifications, but it can be used to make a fader module address a different master module dynamically.
Additionally, in the current version of PathfinderCore PRO code and Quasar code, this Fader Module does not push changes to Core PRO. As a result status and master changes made in the web page of the device may not be reflected in Core PRO until the next poll time. Additionally changes made by one Core PRO server of this object may not be detected by a second server until its next poll time. This limitation may change in future software revisions.
This version adds support for the FPSTAT object in xNodes. The FPSTAT object carries several read-only properties related to temperature, power supply status, network link, etc. It's found in the Simple tree under the DeviceConnections branch and the API tree under the device's LWRP path.
In the current version of xNode software, these parameters require polling to obtain state and do not automatically push changes. By default, PathfinderCore PRO will poll these properties every 15 seconds.
There is an advanced option in the Configuration, Advanced Options settings to change this called FpStatePollRate. You may need to view the default settings to obtain and override its syntax. FpStatePollRate is a global setting and should only be changed with caution and understanding of the consequences. In networks with many xNodes, decreasing this poll rate can affect the amount of communication that PathfinderCore PRO needs to process.
The properties available are:
Master: Whether this node is clock master. Without respect to the actual setting. The xNode could be set to allow it to become a master but is not currently. 1 indicates Master.
Sync: Status information regarding the clock sync state. A numerical value of the xNodes SYNC indicator. Blank is no SYNC. (Normal if this device is Master). 12 is fully synced (SYNC is not blinking). 1 indicates furthest away from the synced state. The closer the xNode gets to a fully synchronized state, the higher the number.
LivewireActive: Whether the device is receiving livewire advertisements
Temperature: Temperature in Celcius of the main board
Plug Power: Whether the power supply has power from the IEC plug port.
PowerOverEthernet: Whether the power supply is receiving power from the Ethernet port.
Network0Active: Whether ethernet port 0 is active (this is NET 1 on the xNode).
Network1Active: Whether ethernet port 1 is active (this is NET 2 on the xNode).
LivewireNetwork: Which Nic (0 or 1) is the livewire network
It is important to note that you should use these settings in conjunction with the online property and not as a replacement. For example, if all power is lost from the xNode, we will likely not see the Plug Power or POE properties change because we will have lost connection to the object that hosts those properties before we could read the change. So we must rely on the online state to know we are no longer connected. On the other hand, if you have both Plug Power and POE power applied and one of them is lost, the status shows online, but we get an alert that one of the supplies is down. Similarly, if you lose connection on the NIC that you are using to monitor this object, then the NIC states in Core PRO for this object will not change. We have to rely on the Online state for that. On the other hand, if you set up the NICs in the xNode to be redundant and one fails, we can detect and alarm this condition.
When editing a Start Point or End Point, the property selection dialog has two modes: Simple and API.
The simple tree is what most users should use. It is designed to present the most commonly used objects and properties organized for quick access. Occasionally there may be a job that requires reaching beyond the normal options, and selecting the API tree will present a much wider array of objects and properties.
Pathfinder Core PRO has an advanced protocol called SapV2 which extends beyond most typical protocols and reaches the level of an API (application programming interface). It allows virtually complete control over the system. This API is the protocol used for all internal messaging between system services. If you want to learn more about this API, see the SapV2 appendix.
For this API to do its job successfully, almost every property and object must be available. The API section of the property selection dialog exposes the object and property tree available via that API.
To configure advanced options on a Translator, click the Advanced link on the Translator Properties window.
In the expanded Translator dialog is the Advanced Skip startup state request and wait for next change option:
By default, when the system starts (or when a Flow is applied to the system) the Flow asks for the current state of the Start Point and then applies the correct result to the End Point. In most cases this is desirable, but not always. For example, what if the Logic Flow in question was a latching GPIO on the Start Point and an automation system that gets tripped on the End Point?
If we needed to restart Pathfinder during that event, we would not want the automation system to be tripped again. Checking the Skip startup state request and wait for next change option overrides the default behavior and forces the system to wait for the next change that would cause the Flow to execute.
Important Note: When designing a system, it is important to test your logic before it goes live on air in case of a system restart and/or device restart.
Another highly relevant example for where the Skip Startup State option becomes important is with the commonly-used EAS example shown earlier in this section.
If the Logic Flow system detects a given Translator being activated more than 20 times in 1000 milliseconds, it will assume there is recursion involved and the Translator will be disabled to prevent excess CPU load. In some situations, this can create a False positive. For example:
In this Flow, the same memory slot is used for multiple entry points to a Flow, so a change to that memory slot could cause multiple pass-throughs of some Translators. If this Flow were to grow to a much larger variation with many more entry points of the same memory slot, it is possible to trip the recursion detection incorrectly.
Important Note: If a Translator gets disabled via the recursion detection, a log message is generated and an attempt will be made to send an email message to the critical event email address if configured.
Recursion detection threshold settings are modified in the expanded Translator dialog.
This value includes two parts separated by a forward slash. The first value indicates the analysis frequency; the second indicates the analysis duration in milliseconds. For example, typing 50/1000 will disable the Translator if it is being analyzed more than 50 times per 1000 milliseconds.
Additionally, there is an API property that that can change the default recursion settings for all new Translators:
This setting should be modified with extreme care as it will also update any existing Translators that are currently at the default settings. This can be CPU intensive and require a significant amount of writing to disk. Please make a backup before changing this value.
It is common to have a conversion list item in a translator of:
*=*
However, the * on the ToValue side does not need to be by itself. For example, you could have:
*=Hello I am *
In this case, the input value would replace the * in the output value. If the input value is Dan, the ToValue example above would output the string:
Hello I am Dan
This can provide similar functionality natively in the Flow translation as string builder memory slots.
* cannot be used in the middle of data on the "from" side. Use regular expressions for complex matching if needed.
The Advanced Conversion field, available in the expanded Translator dialog, allows users to bypass some of the helper dialogs and enter conversion statements directly.
While bypassing the helper dialogs can be useful in certain unique scenarios, those dialogs present information that is helpful when selecting a property but may or may not be the underlying value needed in the conversion. For example, when using the CurrentSourcePath property, the conversion list and normal drop-down list will show you the friendly name of the source. However, the actual conversion list item needs the uri based pathio which looks something like:
"tcp://172.16.1.53:93?l=SRC&d=src&i=6&t=aaudio"
If you are uncertain about the value requirement, create an example of what you are trying to do using the normal conversion list selection methods and then select it in the Advanced field to see the actual values that need to be applied. If you have questions, contact support.
Important note: Incorrectly entering data into this field can cause unpredictable results.
Conversion text syntax is:
<FromValue>=<ToValue>
For example:
l=True
If the From or True value needs to include a literal equals sign, then enclose the value in quotes. The From value will be abc=frz in this example:
"abc=frs"=True
If <NoChange> is applied to the ToValue portion of a translation, the output of the translator will not be changed. For example:
AAA=True
BBB=<NoChange>
*=False
In this case, an input FromValue of AAA will result in True, BBB will not cause anything to change on the output of the translator, and any other FromValue will result in False.
In many cases, a <NoChange> is not required because you can just opt not to supply the input which will result in nothing happening when that input occurs. But in a situation where you are using the * wildcard as a catchall but want to explicitly exclude a value from making a change, this can be used.
Important Note: <NoChange> is not applicable to the FromValue side of a translation and will be interpreted literally if entered on the FromValue side.
Regular expressions as described in the Watchers and Regular Expressions section in the Device Emulators chapter can also be used in the FromValue portion of a conversion list item. Regular expressions are added to the Advanced Conversion field as follows:
In this example, we are using the IsMatch property. Fader_Gain values that are not negative will result in a button turning On; otherwise, the button indicator will be Off. Because Fader_Gain generates significant data as it slides, we have also increased the recursion detection value to prevent this Flow from getting disabled.
Important Note: Using regular expressions can be slower and more CPU intensive. Use them only where needed and use the normal translations elsewhere.
Over the course of the examples above, you may have noticed an additional property in Combiners that we have not discussed yet called Raise Output.
The values for this property are Raise Output on Set and Raise Output on Change. The effects of this property are subtle but are important to understand:
In this Flow, if both pin 1 and pin 2 are Low, then pin 4 will be set Low. If either pin 1 or pin 2 is High, pin 4 will be set High. If the Combiner is set to Raise Output on Set, then any time either pin 1 or pin 2 is changed a message will be sent to set pin 4 to the corresponding value. So, if we assume pin 4 is currently High or Low and we set pin 1 to Low when pin 2 is still High, a message will get sent to pin 4 to go High.
However, if the setting is set to Raise Output on Change, no message will be sent to pin 4. When both pin 1 and 2 were High the resulting output of the And Combiner is False. When pin 1 goes Low, the resulting output of the And Combiner is still False. Its output value has not changed and so no message is sent.
The difference is subtle, but essentially with “Raise Output on Set”, a change message will be sent to the End Point any time the input of the Combiner changes even if it evaluates to the same output the Combiner was at before, whereas with “Raise Output on Change”, a change message will only be sent when the Combiner’s output changes.
Let’s look at another example of when Raise Output on Change could be useful:
In this example, GPIO pin state 4 appears at each pair of And Combiners on the left-hand side of the Flow. The buttons are button 1 of three different LCD panels. If all the Combiners in this Flow are set to Raise Output on Set, then the resulting End Point may get set 3 times when GPIO pin 4 changes. This is because a change to the pin would get fully passed through the Flow for each instance where it appears as a Start Point. However, if the left And Combiners are all set to Raise on Change, then the output will only get set for Combiners where the pin state change actually causes a different state on the output of the Combiner. This can greatly reduce load and improve performance in large and complex systems.
It is also important to note that this property is a new variable that must be stored in the backing storage. For backward compatibility with older software versions, Raise on Set will store the same way it historically has. However, any Flows that are changed to use Raise on Change will not be loadable by older software versions that do not support this property.
For advanced users, it is possible to change all of the Combiners to a particular setting using the port 9600 API. Each Logic Flow View has a write-only property called ChangeAllCombinerRaiseOutput. Using this property, all Combiners in a View and that View’s sub-Views can be set to the same value. This is useful for changing many Combiners at once but should be used with caution. It is recommended that a backup be taken before using this api command. For example:
See the API reference in Appendix 2 for details on how to use these commands.
Providing a list of every object and property in the system is beyond the scope of this documentation. One of the reasons we provide the description within the property selection dialog is to make the software self-documenting. However, it is useful to describe some of the more commonly used properties here if for no other reason than to generate ideas for how to use Flows within your environment. While this list is not inclusive, we encourage you to spend some time browsing the tree and examining the various available properties and their descriptions. And as always, our support staff stands ready to assist. Remember that due to the read/write nature of some of the properties, they may only appear and be available for use with a Start Point or an End Point.
Audio Alarms
AlarmState: Once an audio alarm has been configured, this property exhibits the current state of the alarm; it can be Unknown, AudioPresent, AudioSilent, or Clipping; logical decisions can be made when this state changes
LvlState: When a silence alarm is configured, Pathfinder Core PRO requests updates whenever the threshold value is passed for more than 250ms; this property carries the current state regardless of the current alarm countdown
Buttons
BackColorOn: Used to set the backcolor value when the button is on
BackColorOff: Used to set the backcolor value when the button is off
Ind: Used to set the indicator of the button on, off, or in a variety of flash states
Text: Used to set the Text value of a button
Key: This property will be UP or DOWN depending on whether the button is pressed or released
Console
ShowProfId: The id of the show profile loaded on the console; this can also be used to change the currently loaded show profile
ShowProfName: The name of the show profile loaded on the console
Asg_PGM1-4: Used to set or determine whether a specific console fader is assigned to any of the 4 program busses
Asg_Prev: Used to set or determine whether a specific console fader is assigned to the preView buss
Fader_Gain: Used to change the gain of a fader
MUTE_State: Used to set or determine if the mute state on a fader is engaged
OFF_But: Whether the Off button on a fader is up or down.
ON_But: Whether the On button on a fader is up or down
ON_State: Used to set or determine if a console fader is on or off
src_lwch: Carries the Livewire channel number loaded to a fader
talkback: Used to engage or sense the engagement of the talkback button on a fader
tt_cr: Used to engage or sense the engagement of the talk to control room button
tt_st: Used to engage or sense the engagement of the talk to studio button
tt_prev: Used to engage or sense the engagement of the talk to preView button
IND: Used to change the indicator state of user definable buttons on the console
KEY: Used to sense the key state of certain user definable buttons on the console
DeviceConnections
Connected: This property can be used to sense and react to connection problems with any of the Axia devices
Online: This property senses whether a device is responding to commands
Body: Used to change the body text of an email message
Subject: Used to change the subject of an email message
Send: Used to send a predefined email message
Emulators
Triggered: Used to determine when a Generic emulator’s watcher detects a defined input value
ToSend: Used to send data out a generic emulator port
Gpio
PinState: Used to change or sense changes on a GPIO pin
Memory
SlotValue: Used to sense changes or change the value of a memory slot
Trigger: Used to change the value of a latching memory slot from True to False or False to True
Routers
CurrentSourcePath: Used to sense or activate a route change on a specific destination
CurrentChannelNumber: Used to sense the Livewire channel number assigned to a destination. This property can also be used to make router changes using Livewire channel numbers for the source
CurrentSourceName: This property is updated with the name of the source that is currently routed to the selected destination
Scenes
IsActive: This property will be either True or False depending on whether all states in the scene are currently active
: Setting this property to True will make Pathfinder Core PRO initiate all of the changes in a scene
Startup
StartupFileProcessed: This property can be used to set up certain states after Pathfinder Core PRO has been restarted
Time
Enabled: Used to enable or disable a timer. Logical decisions can also be made depending on whether a timer is enabled or disabled
Elapsed: Becomes True when a timer elapses
VMIX
Gain: Used to sense or make changes to a VMIX fader’s gain setting
State: Used to turn VMIX channels on or off and sense the same state changes
TimeDown: Used to sense or make changes to the length of the fade-out when a VMIX fader is turned off
TimeUp: Used to sense or make changes to the length of the fade-in when a VMIX channel is turned on
Master_Gain: Used to sense or make changes to the master gain of a VMIX submixer
VMODE
AUDIO_MODE: Used to sense changes to the audio mode state of a VMODE IO
IN_SELECT: Used to sense changes to the IN_SELECT state of a VMODE IO
While this chapter has reviewed the details of Logic Flows, many of the other chapters of this manual will touch more on their uses as we detail how the aspects of the system functions and therefore what capabilities may be used.
If the user presses the button, the input value gets set to True based on the inbound translation:
If the user does not release the button for 5 seconds, then the True value gets passed to the Combiner output which is being monitored by the output Translator:
Name
Description
Start Point
A property in the system being monitored for changes.
End Point
A property in the system which will be changed by the Logic Flow.
Translator
A list of changes that can be applied to the value of a property.
Combiner
A way to logically combine multiple states using logical operators such as AND, OR, NOT, etc.
Control
Description
Start Point
Allows you to add a Start Point and a Translator to the left side of a Combiner or to extend the Flow’s start to a new Flow.
Combiner
Allows you to add a Combiner.
End Point
Allows you to add an End Point and a Translator to the right side of a Combiner or to extend the Flow’s end into a new Flow.
Delete
Allows you to delete a Flow, Flow Combiner, or Translator.
Add
Creates a new Flow.
Cut
Cuts a Flow to the clipboard.
Copy
Copies a Flow to the clipboard.
Paste
Pastes a Flow from the clipboard.
Disable/Enable
Disables or Enables a Flow, Combiner, or Translator.
Apply Button
Applies pending changes to the system.
Clear Button
Clears pending changes and reverts to the system’s actual state.
Size Slider
Increases or decreases the size of the Flow objects in order to display more items on one screen.
Type
Minimum Inputs
Maximum Inputs
AND
2
Any
OR
2
Any
NAND
2
Any
NOR
2
Any
XOR
2
Any
XNOR
2
Any
NOT
1
1
RELAY
2
2
PASSTHRU
1
1
EQUALITY
2
Any
DELAY
1
1
Type
Minimum Inputs
Maximum Inputs
NOT
1
1
PASSTHRU
1
1
DELAY
1
1
Type
Minimum Inputs
Maximum Inputs
AND
2
Any
OR
2
Any
NAND
2
Any
NOR
2
Any
XOR
2
Any
XNOR
2
Any
RELAY
2
2
EQUALITY
2
Any
Field
Description
Delay Time
Type the Delay duration in milliseconds.
Reset delay if input changes
The delay countdown starts every time the input changes its value. If this option is selected the countdown will be reset whenever the input value changes.
If you have a parameter that is fluttering and you only want an action to happen if it settles down to a fixed value for more than x milliseconds, this option should be checked.
If you want the value to happen x milliseconds after a change even if additional changes happen during the countdown (delay time) then this option should be unchecked.
Output Value
From the drop-down list, select the option that defines whether the value that is passed through is the input value at the start of the delay countdown (Value at input when timer starts) or the end of the countdown (Value at input when timer ends).
This option accounts for the possibility that the input value could change again during the delay countdown and allows you to define which value gets passed through.
Cancel Value
Type an input value that will cancel the timer and not make any change to the Combiner output (not pass any different value through).
Clear output after countdown completes
Used to make the delay Combiner function in a momentary fashion. See note below.
Clear Value
Type a specific value as the clear state when the clear output after countdown completes option is selected.
Object
Property
ReadWrite
Description
Syntax
Line
call
W
Call out using a specific hybrid.
<hybridnumber>_
<numbertocall>
Line
caller_id
R
Caller Id
Text
Line
callstate
R
Call State
List of states
Line
comment
RW
Comment for the Line
Text
Line
direction
R
Direction for the Call
NONE
INCOMING OUTGOING
Line
drop
W
Drop a line
True
Line
fixed
R
Is line fixed or selectable
True/False
Line
handset
R
Is call on the handset
True/False
Line
hold
W
Hold a line
ON_HOLD_READY
ON_HOLD
Line
hybrid
R
Take the next call to the specified Hybrid
List of hybrid ids by name
Line
local
R
Local Phone Number
Text
Line
lock
W
Lock a line
True/False
Line
name
R
Name of the Line
Text
Line
owner_ip
R
IP address of the current line owner
Text
Line
raise
W
Raise a line in priority
True
Line
remote
R
Remote Phone Number
Text
Line
seize
W
Seize a line to reserve it for this client
True
Line
state
R
Line State
List of states
Line
take
W
Take the next call to the specified hybrid
List of hybrid ids by name
Line
time
R
Line Time
Time
Studio
busy_all
RW
Sets and reads studio busy_all state
True/False
Studio
drop
W
Drop a specific hybrid
List of hybrid ids by name
Studio
drop_all
W
Drop all calls
True
Studio
hold
W
Hold the call that is currently on a specific hybrid
List of hybrid ids by name
Studio
message
RW
Instant Message
Text
Studio
mode
W
Set the studio mode for backwardAxia compatibility
TALENT
PRODUCER
Studio
mute
RW
Studio Mute
True/False
Studio
show_id
RW
Set or read Show Id
List of show ids by name
Studio
take
W
Take a call
True
Studio
next
R
Position of line that should be answered next
Number
Icon
Function
Description
Rename
Clicking this icon gives you the option to Rename the selected View.
Cut
With a single View selected, click this icon to move the selected View to the clipboard.
Copy
With a single View selected (see note below), click this icon to copy the selected View to the clipboard.
Paste
After pasting a cut View back into the system, the original View is deleted. When pasting a copied View back into the system, you will be prompted to give the pasted View a new name.
State Toggle
Clicking this button will toggle all Logic Flows in the selected Views between Enabled and Disabled state. The recursion checkbox, if enabled, will also enable or disable flows in sub views if desired.
