Personal tools
The Open Lighting Project has moved!

We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.

Difference between revisions of "OLA Merging Algorithms"

From wiki.openlighting.org

Jump to: navigation, search
Line 78: Line 78:
 
Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output port X continues to sends the data from port B, output port Y continues to send the data from port B with priority 120.
 
Continuing on from Case 2, data is received on port A with a priority of 20. The ''active priority'' is still 120 so this data is discarded. Output port X continues to sends the data from port B, output port Y continues to send the data from port B with priority 120.
  
[[File:Ola-merge-case3.gif]]
+
[[File:Ola-merge-case3.gif|center]]
  
 
=== Case 4: Conflict Merge ===
 
=== Case 4: Conflict Merge ===
  
 
New data is received on port A with a priority of 120. With two data sources of the same priority, the merge mode setting of the universe kicks in and the data from ports A and B is [[HTP]] or [[LTP]] merged depending on the universe setting. Port B continues to send with a priority of 120.
 
New data is received on port A with a priority of 120. With two data sources of the same priority, the merge mode setting of the universe kicks in and the data from ports A and B is [[HTP]] or [[LTP]] merged depending on the universe setting. Port B continues to send with a priority of 120.
 +
 +
[[File:ola-merge-case4.gif|center]]
  
 
=== Case 5: Priority Escalation ===
 
=== Case 5: Priority Escalation ===

Revision as of 11:12, 6 January 2010

This document outlines a draft proposal for multi-source merging in OLA. Please add any discussion on the talk page (remember to include author tags)

Problem Definition

The current version of OLA has two merge modes, HTP & LTP. This doesn't allow for priority based merging of multiple DMX sources and in particular, doesn't work well with automated lights.

Ideally a user could configure two input ports to be bound to the same universe, and set the priorities of the ports such that data on one is preferred over another. This can be used to implement backup controllers.

A separate but related problem is that some devices (such as the E1.31 device) support a priority field when sending DMX data. These fields should be customizable.

The protocols known to support priorities are:

Proposal

From the E1.31 standard, we define a source priority which is an integer in the range 0 to 200 with 0 the lowest priority and 200 the highest. The default priority is 100.

Each universe will have an active priority which is the priority that data is being handled for. Data received with a lower priority will be ignored, while data received with a higher priority will raise the universe's active priority to match that of the new data.

Input ports

Input ports will be separated into two types, those that support priorities and those that don't.

Ports that support priorities will offer two modes, inherit and override. Inherit mode will use the priority provided by the device/protocol. Override mode will allow the user to set a priority.

Ports that don't support priorities will allow the user to specify the priority, defaulting to 100.

Output ports

Output ports that support priorities will again provide inherit and override modes. Inherit mode will use the universe's active priority, ports operating in override mode will allow the user to specify a priority.

Output ports that don't support priorities won't change.

Source Clients

Source clients will be able to set a source priority when sending DMX data, this will default to 100.

Sink Clients

No changes required. We may provide the universe's active priority in the data packet if required.

Resolution of Equal Priority Data

Universes will offer a choice of HTP and LTP merge modes for when data is received from multiple ports with the same priority.

Data Timeouts

When a data source doesn't receive data for a specified interval (known as the timeout interval) it's considered disconnected. At this point the source is removed from the list of available sources and the universe's active priority may reduce. Different ports may have different timeout intervals.


Use Cases

Consider the following

  • Input port A, supports priorities, operating in inherit mode.
  • Input port B, doesn't support priorities, manually set to 120
  • Source client without a priority (defaults to 100)
  • Output port X, doesn't support priorities
  • Output port Y, supports priorities

All ports are bound to the same universe. The cases described below are sequential (the events described in Case 2 assume the events of Case 1 have already occurred)

Case 1: No Merge

No data is received from either input port and the source client sends data. The active priority is 100. Output port X sends the data, output port Y sends the data with priority 100.

Ola-merge-case-1.gif

Case 2: Simple Merge

Data is now also received on port B. The new active priority is 120. Output port X sends the data from port B, output port Y sends the data from port B with priority 120.

Ola-merge-case2.gif

Case 3: Another Simple Merge

Continuing on from Case 2, data is received on port A with a priority of 20. The active priority is still 120 so this data is discarded. Output port X continues to sends the data from port B, output port Y continues to send the data from port B with priority 120.

Ola-merge-case3.gif

Case 4: Conflict Merge

New data is received on port A with a priority of 120. With two data sources of the same priority, the merge mode setting of the universe kicks in and the data from ports A and B is HTP or LTP merged depending on the universe setting. Port B continues to send with a priority of 120.

Ola-merge-case4.gif

Case 5: Priority Escalation

New data is received on Port A with a priority of 180. The new active priority is 180 and the conflict merge stops. Output port X sends the data from port A, output port Y sends the data from port A with priority 180.

Case 6: Overriding the Output Port Priority

The user changes the mode of Port Y from inherit to override and sets a value of 130. Output port X continues to send the data from port A, output port Y sends the data from port A but with a priority of 130.

Case 7: Source Removal

Port A stops receiving data and is considered disconnected. The active priority drops to 120 and both output ports use the data from port B. Port Y continues to send a priority of 130 because it's operating in override mode.

Further Information