Version 1.7.6.08 Changes

Build Process

This version is a product of redesigning how PathfinderCore PRO code, images, and update packages are built to bring that process more in line with other Telos Alliance products and continuous integration policies. Please report any bugs you encounter.

Scenes, Timers, and Virtual Mixing Routers

Virtual mixing routers are inherently different in how they function from other routers. For details on Virtual Mixing Routers, see their section in this document under Version 1.7.0.02. With Virtual mixing destinations you do not change the source that is routed to the destination. Instead you add sources that will be mixed together by the mixing destination up to the supported quantity of the destination. As a result it uses different routing properties than a normal router. For example, AddSource adds a source to the mixing destination, and RemoveSource removes a source from the destination freeing that slot up for another source. Therefore when importing a destination to a scene or timer event, you need to be able to define whether the change will add or remove a source. To support this, a new drop down will appear in the import destination list when creating a scene item or defining a start or end property in a timer.

The Mixing property drop down allows you to select whether the operation will add or remove a selected source to/from the destination. For example:

In this example the timer will add Source 1 to the destination at the start of the event time range, and it will remove it at the end.

Scenes and Virtual Mixing Routers

The AddSource and RemoveSource properties of a Virtual Mixing Router destination are write only properties. You are applying a source to the property to change the underlying routing state, but the property itself will not have a value. Whenever you use write only properties in a scene, the state cannot be determined and therefore the IsActive property will never become true on such scenes. In a future version we may add some special code to handle the situation of virtual mixing routers such that the scene will detect if after the source is applied whether it exists on the destination and adjust the value of the scene line accordingly. But for now scenes will not become IsActive using these properties.

Numeric Memory Slots – Range and LoopAction

Numeric Memory slots now have an optional range and loop action property.

If the range field is left blank, then the numeric memory slot operates the way it always has. If you apply a range by filling the range field with a low and high value separated by a hyphen, then increment and decrement will not exceed the specified range. The LoopAction property only works in conjunction with a range and does nothing if no range is specified. The loop action field defines what happens when you try to increment or decrement beyond the specified range as follows:

• None = Incrementing beyond the max or decrementing below the min will do nothing and no change will be applied to the Value.

• Forward = Incrementing beyond the max will cause the value to loop back to the min, but decrementing below the min will make no changes.

• Backward = Decrementing below the min will cause the value to loop to the max, but incrementing beyond the max will make no changes.

• Both = Incrementing beyond the max will cause the value to loop to the min value, and decrementing below the min value will cause it to loop to the max value.

These properties make it easy to assert a valid range to a numeric memory slot as well as to implement things like paging functions where paging beyond the maximum number of pages will take you back to page 1.

Quasar 4 fader panel QSCONN Lwrp object

This version adds support for the QSCONN object in Quasar fader panels. It also creates a new object specifically for such panels. If you already have fader panels in your system, 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.

XNodes and FPSTAT Lwrp object

This version adds support for the FpStat object in xNodes. The Fpstat object carries a number of read-only properties related to temperature, power supply status, NIC link, etc. It can be found in the Simple tree under the DeviceConnections branch, and in 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. This is a global setting and should be changed with caution and understanding of the consequences. In networks with large numbers of 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 these settings should be used in conjunction with the online property as opposed to replacing it. For example, if all power is lost from the box, it is likely we will not actually see the change in the Plug Power or POE properties 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 and POE power applied and one of them is lost, we will still show as online but we can 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 the NICs in the xNode are set up to be redundant and one fails, we can now detect and alarm this condition.