wiki.openlighting.org - User contributions [en]

OLA on Linux

2012-05-15T04:30:16Z

66.92.11.32: /* Debian / Ubuntu */

This describes how to get [[OLA]] working on a Linux system either from the git repo or by using a [http://code.google.com/p/linux-lighting/downloads/list released tarball].

=Install dependencies =

You need a couple of libraries installed for everything to work correctly. Some of these are available as packages in distros but others need to be downloaded and built manually.

First you'll need at least the following:
* cppunit
* uuid or ossp uuid
* pkg-config
* curses
* lex (or flex)
* yacc (or bison)
* the protocol buffers library [http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/] (version 2.3.0 or later)
* microhttpd [ftp://ftp.gnu.org/gnu/libmicrohttpd/ ftp://ftp.gnu.org/gnu/libmicrohttpd/] (if you want the web UI). You need version >= 0.4.0 of microhttpd

If you're building from git you'll also need the following:

* libtool
* automake
* autoconf

== Debian / Ubuntu ==

Debian/Ubuntu users can install them with apt:

sudo apt-get install libcppunit-dev libcppunit-1.12-1 uuid-dev pkg-config libncurses5-dev libtool autoconf automake g++ libmicrohttpd-dev libmicrohttpd5 protobuf-c-compiler libprotobuf-lite7 python-protobuf libprotobuf-dev zlib1g-dev bison flex

Note: More recent distributions may offer libprotobuf-lite7 instead of libprotobuf-lite6, which is an acceptable substitution.

If you're using Ubuntu 11.04 or later you can just use the command above. The versions of libprotobuf in earlier versions of Ubuntu are too old, so you'll need to install them by hand.

== Other Distributions ==

Install using your package manager, or build everything by hand

If you installed things by hand (rather than using your package manager), you need to run ldconfig as root to pick up the new libraries

sudo ldconfig

=Checkout or Download an Archive=

You can either download a tarball, or pull the latest version from the git repo

== Tarball ==

Download the most recent tarball from http://code.google.com/p/linux-lighting/downloads/list
Extract using

tar -zxf ola-0.X.Y.tar.gz

== Git ==

If you don't have '''git''' yet, you'll need to install it with your distro's package manager. On Debian / Ubuntu run:

apt-get install git

Check out the git repo with the following command:

git clone https://code.google.com/p/linux-lighting/ ola

{{ MacOLABuild }}

Finally run ldconfig so you can use the new libraries.

sudo ldconfig

=Device drivers=
Note that, for some devices, it is necessary to install drivers for OLA to work with them. For example, the [[Open DMX USB]] device needs an additional kernel module that could be built using the instuctions on [[LLA_and_Q_Light_Controller_Ubuntu_Tutorial]]. For other devices, refer to the corresponding device page on this wiki.

=Known Issues=

If you get an error like the following:

/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/software/protobuf-cpp/2.0.3_0/opt/local/include/ -g -O2 -c -o ltdl.lo ltdl.c
./libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 1142: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.

Your system uses a different version of libtool. Run:

libtoolize --ltdl -c -f

and then start from the autoreconf step again.

If you should get the following error try to fix it with one of [http://groups.google.com/group/open-lighting/msg/72060f6327d30df6 two available solutions]:

Rpc.pb.cc: In copy constructor 'ola::rpc::RpcMessage::RpcMessage(const ola::rpc::RpcMessage&)':
Rpc.pb.cc:143: error: base class 'class google::protobuf::Message' should be explicitly initialized in the copy constructor

You should be able to prevent this by [http://groups.google.com/group/open-lighting/msg/c6d86d03dd74ed5b editing <code>./src/Makefile.am</code>], removing <code>-Werror</code> and then start from the autoreconfig step again.

OLA DMX Trigger

2011-12-26T19:16:36Z

66.92.11.32: /* Usage */

ola_trigger executes programs based on the values of DMX512 data. This allows a lighting console to trigger events on a computer, like playing music samples, advancing slides in presentations etc. . ola_trigger supports variable assignment, which offers a flexible way to control the behavior of the programs with the DMX512 data.

= Config File Syntax =

The config file defines the mapping of slot values to actions. Each line is a directive and directives are either ''action definitions'' or ''variable assignment''. The order of directives within the config file doesn't matter - actions are triggered in the order of their slot numbers.

Any characters between a '#' and the end of the line are comments and are ignored.

== Action Definitions ==

Action definitions are specified one per line, in the following form:

<pre>
[Slot Number] [Slot Values] [Action]
</pre>

The columns must be separated by whitespace.

=== Slot Number ===

The first column, slot number, specifies the DMX512 slot the action is valid for. Slot numbers range from 0 to 511. Slot numbers may be offset by using the --offset option (see the Usage section below).

=== Slot Values ===

The second column controls which DMX512 values trigger the action. Slot values range from 0 to 255. Multiple values are separated by commas. Ranges can be specified with a hyphen.

<pre>
1,2,3,4 # Values 1 through to 4
1-4,10-14 # Values 1 to 4 and 10 to 14 (inclusive)
</pre>

The % character the is default match. It triggers for all values that don't have an explicit action configured

<pre>
0-100 # Values 0 to 100
% # Triggers for everything else (101 - 255)
</pre>

Actions are only triggered when the value changes. In the example above, if the value of slot 0 in the previous frame was 10, and a frame with slot 0 @ 10 arrived, the action will not be triggered. If a frame with slot 0 @ 5 arrives, the action will trigger again.

=== Actions ===

The third column specifies the action to run. Actions can be either variable assignments or commands.

==== Variable Assignment ====

Variables can be assigned values which can then be used in later commands. Variable assignments are in the form

<pre>
variable=value
</pre>

The value must be quoted if it contains whitespace:

<pre>
variable="a quoted value"
</pre>

==== Commands ====

Commands are enclosed in back ticks (`). Command arguments are separated by whitespace, quotes can be used with arguments that contain whitespace.

<pre>
`echo hello world` # Execute the '''echo''' command with two arguments [hello, world]
`echo "hello world"` # Execute the '''echo''' command with single argument "hello world".
</pre>

Variables are specified with ${ }.

<pre>
`echo ${foo}` # Run echo with the value of the foo variable.
</pre>

Variables can be nested, which means you can do things like

<pre>
# if i=1 and count_1=foo
`echo ${count_${i}}` # runs echo foo
</pre>

=== Full Action Definition Example ===

Putting everything together, the following will run `echo hello world` whenever the value of the first DMX slot changes to 0, 5 or 10.

<pre>
0 0,5,10 `echo hello world`
</pre>

== Variables ==

Variables can be assigned default values using the same syntax as variable assignment actions:

<pre>
# set the default value of foo
foo=bar
</pre>

=== Special Variables ===

The variables ${slot_offset} and ${slot_value} are available for use within commands. For example:

<pre>
0 % `echo "Slot ${slot_offset} is at ${slot_value}"`
</pre>

You should always use ${slot_offset} rather than hard coding slot numbers within command definitions, since the slot number may change with the --offset option.

= Usage =

Before running ola_trigger, make sure that olad is running and the universe has been configured with a DMX512 source. The config file is provided on the command line:

<pre>
ola_trigger example.conf
</pre>

Some useful options include:
; -l, --log-level <level>
: This change the logging level, valid values are 0 (minimum logging) to 4 (full logs). At log level 3 (INFO) and above, all actions (variable assignments and commands) will be logged.
;-o, --offset <slot_offset>
: This applies an offset to the configured slots. For example if the config file contains definitions for slots 0 and 1, if ola_trigger is run with -o 10 it will watch for values on slots 10 and 11. Defaults to 0.
; -u, --universe <universe>
: Specifies the universe to use. Defaults to 1.

= Sample Configs =

Sample configs are provided in the [http://code.google.com/p/linux-lighting/source/browse/#git%2Ftools%2Fola_trigger%2Fcontrib tools/ola_trigger/contrib] directory.

A full example config is provided in the tools/ola_trigger directory. If you have configs that may be useful to others please submit them.

<pre>
# Example DMX Trigger Config File

# Variable definitions
###############################################################################
# The default value of slot 2, this won't ever be used, since the variable is
# only used with slot 3, which implies we already got data for slot 2.
slot_2_value = "nan" # nan isn't special in any way

# Triggers
###############################################################################
# Slot Trigger Values Action

# Slot 0 prints the current value of slot 0
0 % `echo "Slot ${slot_offset} is at ${slot_value}"`

# Slot 1 runs a different command line tools
1 1 `ls`
1 2 `ps aux`
1 3 `who`

# Slot 2 sets a variable
2 % slot_2_value="${slot_value}"

# Slot 3 prints the value of slot2 if slot3 is greater than 50%
3 128-255 `echo "Previous slot is ${slot_2_value}"`
</pre>

OLA DMX Trigger

2011-12-25T22:34:45Z

66.92.11.32:

ola_trigger executes programs based on the values of DMX512 data. This allows a lighting console to trigger events on a computer, like playing music samples, advancing slides in presentations etc. . ola_trigger supports variable assignment, which offers a flexible way to control the behavior of the programs with the DMX512 data.

= Config File Syntax =

The config file defines the mapping of slot values to actions. Each line is a directive and directives are either ''action definitions'' or ''variable assignment''. The order of directives within the config file doesn't matter - actions are triggered in the order of their slot numbers.

Any characters between a '#' and the end of the line are comments and are ignored.

== Action Definitions ==

Action definitions are specified one per line, in the following form:

<pre>
[Slot Number] [Slot Values] [Action]
</pre>

The columns must be separated by whitespace.

=== Slot Number ===

The first column, slot number, specifies the DMX512 slot the action is valid for. Slot numbers range from 0 to 511. Slot numbers may be offset by using the --offset option (see the Usage section below).

=== Slot Values ===

The second column controls which DMX512 values trigger the action. Slot values range from 0 to 255. Multiple values are separated by commas. Ranges can be specified with a hyphen.

<pre>
1,2,3,4 # Values 1 through to 4
1-4,10-14 # Values 1 to 4 and 10 to 14 (inclusive)
</pre>

The % character the is default match. It triggers for all values that don't have an explicit action configured

<pre>
0-100 # Values 0 to 100
% # Triggers for everything else (101 - 255)
</pre>

Actions are only triggered when the value changes. In the example above, if the value of slot 0 in the previous frame was 10, and a frame with slot 0 @ 10 arrived, the action will not be triggered. If a frame with slot 0 @ 5 arrives, the action will trigger again.

=== Actions ===

The third column specifies the action to run. Actions can be either variable assignments or commands.

==== Variable Assignment ====

Variables can be assigned values which can then be used in later commands. Variable assignments are in the form

<pre>
variable=value
</pre>

The value must be quoted if it contains whitespace:

<pre>
variable="a quoted value"
</pre>

==== Commands ====

Commands are enclosed in back ticks (`). Command arguments are separated by whitespace, quotes can be used with arguments that contain whitespace.

<pre>
`echo hello world` # Execute the '''echo''' command with two arguments [hello, world]
`echo "hello world"` # Execute the '''echo''' command with single argument "hello world".
</pre>

Variables are specified with ${ }.

<pre>
`echo ${foo}` # Run echo with the value of the foo variable.
</pre>

Variables can be nested, which means you can do things like

<pre>
# if i=1 and count_1=foo
`echo ${count_${i}}` # runs echo foo
</pre>

=== Full Action Definition Example ===

Putting everything together, the following will run `echo hello world` whenever the value of the first DMX slot changes to 0, 5 or 10.

<pre>
0 0,5,10 `echo hello world`
</pre>

== Variables ==

Variables can be assigned default values using the same syntax as variable assignment actions:

<pre>
# set the default value of foo
foo=bar
</pre>

=== Special Variables ===

The variables ${slot_offset} and ${slot_value} are available for use within commands. For example:

<pre>
0 % `echo "Slot ${slot_offset} is at ${slot_value}"`
</pre>

You should always use ${slot_offset} rather than hard coding slot numbers within command definitions, since the slot number may change with the --offset option.

= Usage =

Before running ola_trigger, make sure that olad is running and the universe has been configured with a DMX512 source. The config file is provided on the command line:

<pre>
ola_trigger example.conf
</pre>

Some useful options include:
; -l, --log-level <level>
: This change the logging level, valid values are 0 (minimum logging) to 4 (full logs).
;-o, --offset <slot_offset>
: This applies an offset to the configured slots. For example if the config file contains definitions for slots 0 and 1, if ola_trigger is run with -o 10 it will watch for values on slots 10 and 11. Defaults to 0.
; -u, --universe <universe>
: Specifies the universe to use. Defaults to 1.

= Sample Configs =

Sample configs are provided in the [http://code.google.com/p/linux-lighting/source/browse/#git%2Ftools%2Fola_trigger%2Fcontrib tools/ola_trigger/contrib] directory.

A full example config is provided in the tools/ola_trigger directory. If you have configs that may be useful to others please submit them.

<pre>
# Example DMX Trigger Config File

# Variable definitions
###############################################################################
# The default value of slot 2, this won't ever be used, since the variable is
# only used with slot 3, which implies we already got data for slot 2.
slot_2_value = "nan" # nan isn't special in any way

# Triggers
###############################################################################
# Slot Trigger Values Action

# Slot 0 prints the current value of slot 0
0 % `echo "Slot ${slot_offset} is at ${slot_value}"`

# Slot 1 runs a different command line tools
1 1 `ls`
1 2 `ps aux`
1 3 `who`

# Slot 2 sets a variable
2 % slot_2_value="${slot_value}"

# Slot 3 prints the value of slot2 if slot3 is greater than 50%
3 128-255 `echo "Previous slot is ${slot_2_value}"`
</pre>

OLA DMX Trigger

2011-12-24T17:12:46Z

66.92.11.32:

ola_trigger executes programs based on the values of DMX512 data. This allows a lighting console to trigger events like music samples, power point presentations etc. ola_trigger supports variable assignment, which offers a flexible way to control the behavior of the programs with DMX.

= Usage =

Before running ola_trigger, make sure that olad is running and the universe has been configured with a DMX512 source. ola_trigger reads a config file, which contains the mappings of DMX slot values to actions. The config file is provided on the command line:

<pre>
ola_trigger example.conf
</pre>

Some useful options include:
; -l, --log-level <level>
: This change the logging level, valid values are 0 (minimum logging) to 4 (full logs).
;-o, --offset <slot_offset>
: This applies an offset to the configured slots. For example if the config file contains definitions for slots 0 and 1, if ola_trigger is run with -o 10 it will watch for values on slots 10 and 11. Defaults to 0.
; -u, --universe <universe>
: Specifies the universe to use. Defaults to 1.

= Config File Syntax =

The config file defines which commands are to be run. Each line is a directive The config file contains '''action definitions''' and '''default variable assignment'''.

== Action Definitions ==

Action definitions are specified one per line, in the following form:

<pre>
[Slot Offset] [Slot Values] [Action]
</pre>

The columns must be separated by whitespace.

=== Slot Offset ===

The first column, Slot Offset, specifies the slot the action is valid for. Slot offsets range from 0 to 511.

=== Slot Values ===

The second column controls which slot values trigger the action. Slot values range from 0 to 255.

Values are separated by commas. Ranges can be specified with a hyphen.

<pre>
1,2,3,4 # Trigger on values 1 through to 4
1-4,10-14 # Trigger on values 1 to 4 and 10 to 14 (inclusive)
</pre>

The % character the is default match. It triggers for all values that don't have an explicit action configured

<pre>
0-100 # Values 0 to 100
% # Triggers for everything else (101 - 255)
</pre>

Actions are only executed when the value changes. In the example above, if the value of slot 0 in the previous frame was 10, and a frame with slot 0 @ 10 arrived, the action will not be triggered. If a frame with slot 0 @ 5 arrives, the action will execute again.

=== Command Execution ===

The third column specifies the action to run. Actions can be either variable assignments or commands.

==== Variable Assignment ====

Variables can be assigned values, and can be used in commands. Variable assignments are in the form

<pre>
variable=value
</pre>

The value can be quoted.

==== Commands ====

Commands are enclosed in back ticks (`). Command arguments are separated by whitespace, quotes can be used to group arguments.

<pre>
`echo hello world` # Execute the '''echo''' command with two arguments [hello, world]
`echo "hello world"` # Execute the '''echo''' command with single argument "hello world".
</pre>

Variables are specified with ${ }.

<pre>
`echo ${foo}` # Run echo with the value of the foo variable.
</pre>

Variables can be nested, which means you can do things like

<pre>
# if i=1 and count_1=foo
`echo ${count_${i}}` # runs echo foo
</pre>

=== Example ===

As an example, the following will run `echo hello world` whenever the value of the first DMX slot changes to 0, 5 or 10.

<pre>
0 0,5,10 `echo hello world`
</pre>

== Variables ==

Rather than executing a command, an action can set a variable

=== Special Variables ===

The variables ${slot_offset} and ${slot_value}

== Comments ==

The # character comments out the rest of the text until the end of the line. This can be used at any location.

= Example =

A full example config is provided in the tools/ola_trigger directory.

<pre>
# Example DMX Trigger Config File

# Variable definitions
###############################################################################
# The default value of slot 2, this won't ever be used, since the variable is
# only used with slot 3, which implies we already got data for slot 2.
slot_2_value = "nan" # nan isn't special in any way

# Triggers
###############################################################################
# Slot Trigger Values Action

# Slot 0 prints the current value of slot 0
0 % `echo "Slot ${slot_offset} is at ${slot_value}"`

# Slot 1 runs a different command line tools
1 1 `ls`
1 2 `ps aux`
1 3 `who`

# Slot 2 sets a variable
2 % slot_2_value="${slot_value}"

# Slot 3 prints the value of slot3 if slot3 is greater than 50%
3 128-255 `echo "Slot 2 is ${slot_2_value}"`
</pre>

Open Lighting Architecture

2011-10-21T15:28:25Z

66.92.11.32:

[[Image:Ola.png|right]]
Link: http://code.google.com/p/linux-lighting/ 
{{Features|free=yes|tx=yes|rx=yes|linux=yes|osx=yes|http=yes|rdm=yes}}
[[Image:Ola-download.png |right|link=http://code.google.com/p/linux-lighting/downloads/list]]
[[Image:Llad_home.png| thumb |200px|right|Universe Settings]]
[[Image:Ola-rdm.png|thumb|200px|right|RDM Devices Page]]
[[Image:OLA_patching.png|thumb|200px|right|Drag & Drop RDM Patching]]
[[Image:Ola-mobile.png|thumb|200px|right|Mobile UI]]

__NOTOC__
The Open Lighting Architecture (OLA) is part of the [[Open Lighting Project]] and provides applications with a mechanism to send and receive [[DMX512]] & [[RDM]] commands using hardware devices and DMX over IP protocols. This enables [[:Category:Controllers | software lighting controllers]] to communicate with hardware either via Ethernet or traditional DMX512 networks.

OLA can also convert DMX512 data sent using DMX over IP protocols from one format to another, allowing devices from different manufacturers to interact with one another. For example a [[Strand_Lighting|Strand]] Lighting Console using ShowNet can send DMX512 to an [[Enttec]] [[DmxEtherGate MKII|EtherGate]]. When combined with a physical DMX interface such as the [[DMX USB Pro]], OLA can send and receive data from wired DMX512 networks.

==Main Features ==

* Supports a variety of DMX over IP Protocols and a dozen different USB DMX devices.
* Priority based merging of different sources.
* Built in web based configuration including:
** [[RDM]] controller
** Drag and drop RDM patching with an automatic patcher
** Custom UI for mobile devices (iPhone, Android)
* Command line tools which enable scripting of configuration and RDM commands.
* Python, C++, Objective-C++ APIs for developers to build their own applications.
* Runs on Mac OS X (ppc, i386, x86_64) & Linux ( i386, x86-64, arm).
* Source code is open and available at no cost.

A port to Windows is feasible if someone wants to add the necessary platform-dependent code. For now it can be run on Windows using VMWare (see [[OLA on Windows with VMWare]])

Questions: See the [http://groups.google.com/group/open-lighting mailing list]

Bugs: Check the [http://code.google.com/p/linux-lighting/issues/list bug tracker]

Contribute: Looking to help? Visit the [[OLA Contributors]] page. The page also lists people and companies who have supported OLA. Please support them in return!

==Supported Protocols==

{| border=1 cellspacing="0"
! '''Protocol'''!! Linux !! '''Mac OS X'''
|-
|| [[:Category:ArtNet|ArtNet, ArtNet 2, ArtNet 3]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]] || [[Image:Green-tick.png|center]]
[[Image:Rdm.gif|center]]
|-
|| [[E1.31]] / [[ACN]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ESP Net|ESP Net]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Pathport|Pathport]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Sandnet|Sandnet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ShowNet|ShowNet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|}

==Supported Devices==

{| border=1 cellspacing="0"
! '''Device'''!! Linux !! '''Mac OS X'''
|-
|| [[Anyma uDMX]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[Arduino RGB Mixer]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]]
|-
|| [[DMX 4 Linux]] || [[Image:Trans.gif|center]] ||
|-
|| [[DMX USB Pro]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]]
|-
|| [[DMX-TRI]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[DMXking USB DMX512-A]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]]
|-
|| [[DMXter4 RDM]] / [[MiniDMXter]] || [[Image:Rdm.gif|center]] || [[Image:Rdm.gif|center]]
|-
|| [[Eurolite USB DMX512 PRO]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[Open DMX USB]] || [[Image:Trans.gif|center]] ||
|-
|| [[Packetheads USB_DMX Dongle]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[RDM USB Pro]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]]
|-
|| [[RDM-TRI]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]]
|-
|| [[Robe Universal Interface]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]]
|-
|| [[RUNIT WTX]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]]
|-
|| [[StageProfi]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] (Ethernet version only)
|-
|| [http://machosehead.wordpress.com/2010/06/12/udmx_asp/ uDMX_asp] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[USBDMX2]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[Velleman K8062]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[Velleman_K8062_Upgrade|VX8062]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|}

==Getting Started==

Start here if you've never used OLA before and read these in order.
* [[Download OLA]]
* [[OLA on OS X]] or [[OLA on Linux]] or [[OLA on Windows with VMWare]] - How to install OLA.
* [[Using OLA]] - A basic introduction
* [[OLA Command Line Tools]] - Documentation for the tools in ola-examples
* [[OLA Device Specific Configuration]]
* [[OLA Tips & Tricks]]
* [[RDM with OLA]]

Tutorials
* [[OlaOutput Max External]] - Setup OlaOutput on Mac OS X to send DMX messages from Max/MSP/Jitter
* [[OLAGuruPlug]] - Running OLA on a [http://www.globalscaletechnologies.com/c-4-guruplugs.aspx GuruPlug]
* [[OlaLED]] - control RGB LED via http
* [[OLA RDM Responder Testing]]

Advanced Topics:
* [[OLA Merging Algorithms]]
* [[OLA DiffServ support]] (QOS settings)

Developer Documentation:
* [[OLA developer info]] - about the source code and structure
* [[OLA Client API]] - the C++ API
* [[OLA Python API]] - easy DMX programming
* [[Build OLA Mac Packages]] - notes for building the .dmg images
* [[Building OLA for Windows]] - Notes on Windows support (in progress)
* [[Using OLA with Xcode]] - on a Mac, in Objective-C++
* [[Writing RDM Responder Tests]]
* [[Port Throttling]]
* [[OLA Performance Stats]]

Tutorials, these refer to the previous release but parts of them are still relevant.
* [[LLA Sandnet Tutorial]] - Setup Horizon using Sandnet and LLA
* [[LLA and Q Light Controller Ubuntu Tutorial]] - Setup LLA on Ubuntu/Debian-type distro with QLC
* [[LLA and Q Light Controller OSX Tutorial]] - Setup LLA on Mac OS X with QLC

[[Category:ArtNet]]
[[Category:ESP Net]]
[[Category:E1.31]]
[[Category:Sandnet]]
[[Category:ShowNet]]
[[Category:Utilities]]
[[Category:Pathport]]

RDM Discovery

2011-10-21T04:42:10Z

66.92.11.32:

This documents various scenarios that should be considered when writing software that performs RDM Discovery. Unlike [[DMX]], [[RDM]] is bi-directional, which means bugs in devices / responders can cause controller to crash or go in to an infinite loop.

This page is not a substitute for the E1.20 standard, which takes precedence over all information presented here. It simply presents situations which designers of controllers should consider when writing their software.

== Process Overview ==

Each responder has a unique identifier (UID) which consists of a 2 byte ESTA manufacturer ID, and a 4 byte device ID. Like a MAC address, no two responders should have the same UID. The 'all devices' UID (ffff:ffffffff) is a broadcast address, to which all devices will listen but not necessarily take action or respond.

There are three RDM messages used during the discovery process, all use the DISCOVERY_COMMAND Command Class.

* DISC_UNIQUE_BRANCH, which takes two parameters, a lower and an upper UID. Any responders within this range (inclusive) must respond.
* DISC_MUTE
* DISC_UN_MUTE

There are many different ways to implement the discovery process, one (simplified) method is described below:

# Send a DISC_UNMUTE to the ALL DEVICES UID
# Send a DISC_MUTE to any previously discovered devices, if they don't respond after multiple attempts remove them from the UID list.
# Send a DISC_UNIQUE_BRANCH with a range of (0000:00000000, ffff:ffffffff). One of three things may happen
#* No response, which generally means there are no further responders to be muted
#* A single response with a valid checksum. In this case the controller should attempt to mute the responder (DISC_MUTE) and if that succeeds, add the responder to the list of UIDs.
#* A collision, in which case a controller should divide the range in two (0000:7fff:ffffffff), (8000:00000000, ffff:ffffffff) and proceed from step 3.

If everything goes well, eventually all devices will be muted, and sending a DISC_UNIQUE_BRANCH with a range of (0000:00000000, ffff:ffffffff) will result in no responses.

== Failure Modes ==

=== Responders that reply outside their range ===

Responders may have bugs in the UID inequality code, causing them to reply to DISC_UNIQUE_BRANCH which don't cover their UID. One example may be a responder that replies when just the Manufacturer ID part of the UID matches. Depending on the type of bug, discovery can sometimes proceed in these cases and usually all other devices are found and muted first before the bad responder is located.

The worst case is a responder that replies to every DISC_UNIQUE_BRANCH request, which usually prevents discovery of any other responders.

=== Responders that don't reply when within range ===

The opposite of the case above is where a responder fails to respond to a DISC_UNIQUE_BRANCH request for a range which it is part of. A common example of this is the off-by-one case, where a responder doesn't reply if it's at the endpoints of the range. This can cause responders to 'disappear' which happens when a range that previously caused a collision, produces no responses when split in two.

Without proper detection, this can cause controllers to loop indefinitely as they try to locate the missing responders.

=== Responders that don't reply to Mute ===

Some responders may not reply to the MUTE_DEVICE message. This case must be differentiated from the case where the MUTE_DEVICE message is corrupted or lost so the responder never replies. The pseudo-code in the [[E1.20]] standard attempts to mute each device up to 10 times before continuing.

=== Responders that don't mute ===

Not to be confused with the scenario above, some responders may acknowledge the mute request but continue to respond to discovery requests. If there is only one responder that behaves this way controllers should be able to succeed,

=== Proxied Devices ===

The [[E1.20]] states that a proxy shall not provide more than one DISC_UNIQUE_BRANCH response at once. This means that once the proxy has been located and muted, controllers must continue to

== Example Implementation ==

The implementation of the RDM discovery algorithm as used in the [[Open Lighting Architecture]] can be seen [http://code.google.com/p/linux-lighting/source/browse/common/rdm/DiscoveryAgent.cpp here] . The tests which cover the cases above are in [http://code.google.com/p/linux-lighting/source/browse/common/rdm/DiscoveryAgentTest.cpp DiscoveryAgentTest.cpp]

[[Category:Articles]]

Pipe vs Unix Socket Performance

2011-08-14T18:38:39Z

66.92.11.32:

Here are some numbers on pipe() vs socketpair() performance. The sample program used either pipe() or socketpair() to create a set of file descriptors. The main thread sent 512MB of data through the fds and then closed the sending side. A receiving thread read all the data until EOF and then exited.

== Mac OS X 10.6.8 ==

<pre>
Pipes
real 0m8.501s
user 0m5.751s
sys 0m4.185s

real 0m8.462s
user 0m5.721s
sys 0m4.078s

Unix Sockets
real 0m9.782s
user 0m6.329s
sys 0m7.301s

real 0m9.992s
user 0m6.360s
sys 0m7.417s
</pre>

== Linux 2.6.26-2-amd64 ==

<pre>
Pipes
real 0m8.376s
user 0m5.376s
sys 0m2.952s

real 0m8.319s
user 0m5.184s
sys 0m3.096s

Unix Sockets
real 0m9.469s
user 0m5.840s
sys 0m3.480s

real 0m9.364s
user 0m5.500s
sys 0m3.792s
</pre>

== Linux 2.6.32 armv5tel ==

This benchmark only sent 51 MB of data.

<pre>
Pipes
real 0m11.083s
user 0m8.560s
sys 0m2.480s

real 0m12.079s
user 0m9.070s
sys 0m2.250s

Unix Sockets
real 0m12.882s
user 0m9.920s
sys 0m2.930s

real 0m11.944s
user 0m8.650s
sys 0m3.030s
</pre>

== Linux 2.6.18 VM ==

This benchmark only sent 51 MB of data because it was running in a VM.

<pre>
Pipes
real 0m9.359s
user 0m2.377s
sys 0m1.603s

real 0m11.233s
user 0m2.253s
sys 0m2.345s

Unix Sockets
real 0m10.903s
user 0m2.178s
sys 0m2.380s

real 0m11.053s
user 0m2.280s
sys 0m2.422s
</pre>

Talk:OLA Device Specific Configuration

2011-07-04T22:09:04Z

66.92.11.32: Blanked the page

Open SLP Notes

2011-06-26T17:10:30Z

66.92.11.32:

The last stable release of Open SLP was 1.2.1 in 2006. This page has my notes from getting this version working on a number of systems.

=== Registrations timing out too early ===

slpd ages the registration database every 15 seconds (#define SLPD_AGE_INTERVAL 15) rather than tracking per registration timeouts. This means that your entry can timeout up to 15 seconds before it was supposed to.

Besides fixing the slpd code, the only way around this is to re-register less than 15 seconds before the expiry interval. For this reason I recommend the absolute minimum SLP lifetime used is 30s.

=== Interface Selection on Mac OS X ===

On Mac, slpd relies on reverse dns for the machine's hostname returning an IP (stupid I know but that's how it is). Without reverse DNS the startup log will look like this:

<pre>
Sun Jun 19 16:59:45 2011
SLPD daemon started
****************************************
Command line = slpd
Using configuration file = /opt/local/etc/slp.conf
Using registration file = /opt/local/etc/slp.reg
Listening on loopback...
Multicast socket on 127.0.0.1 ready
Unicast socket on 127.0.0.1 ready
Agent Interfaces = 127.0.0.1
Agent URL = service:service-agent://127.0.0.1
Startup complete entering main run loop ...
</pre>

If you don't have working reverse DNS for you domain, you can edit your /etc/hosts file. First get the full hostname & local address of the interface you want to use:

<pre>
$ hostname
simonn-macbookpro.local
$ ifconfig en1 | grep "inet " | awk '{print $2}'
192.168.1.204
</pre>

Then add a line like the following to /etc/hosts

<pre>
192.168.1.204 simonn-macbookpro.local
</pre>

Now SLP recognizes the interface correctly:

<pre>

Sun Jun 19 17:03:42 2011
SLPD daemon started
****************************************
Command line = slpd
Using configuration file = /opt/local/etc/slp.conf
Using registration file = /opt/local/etc/slp.reg
Listening on loopback...
Listening on 192.168.1.204 ...
Multicast socket on 192.168.1.204 ready
Unicast socket on 192.168.1.204 ready
Agent Interfaces = 192.168.1.204
Agent URL = service:service-agent://192.168.1.204
Startup complete entering main run loop ...
</pre>

=== Denial of Service against libslp ===

libslp has code like this:

<pre>
if(FD_ISSET(sockets->sock[i],&readfds)) {
/* Peek at the first 16 bytes of the header */
bytesread = recvfrom(sockets->sock[i],
peek,
16,
MSG_PEEK,
(struct sockaddr *)peeraddr,
&peeraddrlen);
printf(" read %d bytes\n", bytesread);
if(bytesread == 16 || ...) {

}
}
</pre>

Which means if you send a UDP packet less than 16 bytes, libslp spins in a loop trying to receive the rest of the data.

Open SLP Notes

2011-06-20T03:43:06Z

66.92.11.32:

Open SLP Notes

2011-06-20T00:04:02Z

66.92.11.32: Created page with "A stable release of Open SLP last occurred in 2006. This page has a === Interface Selection on Mac OS X === On Mac, slpd relies on reverse dns for the machine's hostname retu…"

A stable release of Open SLP last occurred in 2006. This page has a

=== Interface Selection on Mac OS X ===

On Mac, slpd relies on reverse dns for the machine's hostname returning an IP (stupid I know but that's how it is). Without reverse DNS the startup log will look like this:

<pre>
Sun Jun 19 16:59:45 2011
SLPD daemon started
****************************************
Command line = slpd
Using configuration file = /opt/local/etc/slp.conf
Using registration file = /opt/local/etc/slp.reg
Listening on loopback...
Multicast socket on 127.0.0.1 ready
Unicast socket on 127.0.0.1 ready
Agent Interfaces = 127.0.0.1
Agent URL = service:service-agent://127.0.0.1
Startup complete entering main run loop ...
</pre>

If you don't have working reverse DNS for you domain, you can edit your /etc/hosts file. First get the full hostname & local address of the interface you want to use:

<pre>
$ hostname
simonn-macbookpro.local
$ ifconfig en1 | grep "inet " | awk '{print $2}'
192.168.1.204
</pre>

Then add a line like the following to /etc/hosts

<pre>
192.168.1.204 simonn-macbookpro.local
</pre>

Now SLP recognizes the interface correctly:

<pre>

Sun Jun 19 17:03:42 2011
SLPD daemon started
****************************************
Command line = slpd
Using configuration file = /opt/local/etc/slp.conf
Using registration file = /opt/local/etc/slp.reg
Listening on loopback...
Listening on 192.168.1.204 ...
Multicast socket on 192.168.1.204 ready
Unicast socket on 192.168.1.204 ready
Agent Interfaces = 192.168.1.204
Agent URL = service:service-agent://192.168.1.204
Startup complete entering main run loop ...
</pre>

Building OLA for Windows

2011-05-08T23:37:52Z

66.92.11.32: /* Current TODO */

This describes how to get OLA compiled for windows, it's a work in progress so it's unlikely to work as is. This tutorial uses gcc as the compiler, other compilers have not been tested.

== Install Mingw, msys & build tools ==

Together MinGW & msys provide a unix-style shell environment & compiler suite for windows. Read the instructions at the [http://www.mingw.org/ MinGW] site for more info. MinGW now provides an installer to get most of the system up and running quickly. [http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/ Download] the installer and make sure you select "C++ Compiler". "MSYS Basic System" & "MinGW Developer Toolkit" when prompted.

Once the installer has completed, open the msys shell (under Programs > MinGW) and install some additional packages:

$ mingw-get.exe install msys-automake msys-autoconf libtool

== Install Git ==

Git is used to checkout (and commit) the ola sources. See http://code.google.com/p/msysgit/, be sure to select "checkout as is, commit unix style" during the install otherwise you'll get autoconf errors.

Add the following line to your .bashrc file so that git can be used within msys:

PATH="$PATH:/c/Program Files/Git/bin"
alias git=git.exe

== Install Dependencies ==

For each of these it should be as simple as downloading the package, placing it in C:\MinGW\msys\1.0\home\USER , un-taring the package and running ./configure , make & make install.

* http://code.google.com/p/protobuf/ . Note you need to install the .tar.gz as the zip just contains protoc (we need the libraries as well)
* http://www.ossp.org/pkg/lib/uuid/
* http://sourceforge.net/projects/cppunit/files/
* http://plibc.sourceforge.net/ (required for microhttpd)
* ftp://ftp.gnu.org/gnu/libmicrohttpd/ (skip this for now - it's not building yet)

== Install pkg-config ==

This is a bit of a pain - see [http://www.mingw.org/wiki/FAQ MinGW FAQ] . The packages can be found [http://www.gtk.org/download-windows.html here]. The easiest is to download the latest "All-in-one bundles" and extract it to C:\MinGW\msys\1.0 .

You also need to add

export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
CPPFLAGS="-I/usr/local/include"
LDFLAGS="-L/usr/local/lib"

to your .bashrc file.

== Build OLA ==

* Do a git checkout of OLA

$ git.exe clone http://git.openlighting.org/ola/

* Run ./configure
$ ./configure

* Build
$ make

== Current State / TODO ==

* Everything in common/ now builds under win32
* The USB Pro plugin needs a way to find devices, obviously /dev doesn't exist
* The DMX USB requires libusb win32. Not sure what the status of this is

== Problems ==

Building OLA for Windows

2011-05-07T18:41:18Z

66.92.11.32: /* Install Dependencies */

This describes how to get OLA compiled for windows, it's a work in progress so it's unlikely to work as is. This tutorial uses gcc as the compiler, other compilers have not been tested.

== Install Mingw, msys & build tools ==

Together MinGW & msys provide a unix-style shell environment & compiler suite for windows. Read the instructions at the [http://www.mingw.org/ MinGW] site for more info. MinGW now provides an installer to get most of the system up and running quickly. [http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/ Download] the installer and make sure you select "C++ Compiler". "MSYS Basic System" & "MinGW Developer Toolkit" when prompted.

Once the installer has completed, open the msys shell (under Programs > MinGW) and install some additional packages:

$ mingw-get.exe install msys-automake msys-autoconf libtool

== Install Git ==

Git is used to checkout (and commit) the ola sources. See http://code.google.com/p/msysgit/, be sure to select "checkout as is, commit unix style" during the install otherwise you'll get autoconf errors.

Add the following line to your .bashrc file so that git can be used within msys:

PATH="$PATH:/c/Program Files/Git/bin"
alias git=git.exe

== Install Dependencies ==

For each of these it should be as simple as downloading the package, placing it in C:\MinGW\msys\1.0\home\USER , un-taring the package and running ./configure , make & make install.

* http://code.google.com/p/protobuf/ . Note you need to install the .tar.gz as the zip just contains protoc (we need the libraries as well)
* http://www.ossp.org/pkg/lib/uuid/
* http://sourceforge.net/projects/cppunit/files/
* http://plibc.sourceforge.net/ (required for microhttpd)
* ftp://ftp.gnu.org/gnu/libmicrohttpd/ (skip this for now - it's not building yet)

== Install pkg-config ==

This is a bit of a pain - see [http://www.mingw.org/wiki/FAQ MinGW FAQ] . The packages can be found [http://www.gtk.org/download-windows.html here]. The easiest is to download the latest "All-in-one bundles" and extract it to C:\MinGW\msys\1.0 .

You also need to add

export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
CPPFLAGS="-I/usr/local/include"
LDFLAGS="-L/usr/local/lib"

to your .bashrc file.

== Build OLA ==

* Do a git checkout of OLA

$ git.exe clone http://git.openlighting.org/ola/

* Run ./configure
$ ./configure

* Build
$ make

== Current TODO ==

* Fix the Socket & SelectServer classes or replace them with whatever makes sense on windows
* The USB Pro plugin needs a way to find devices, obviously /dev doesn't exist
* The DMX USB requires libusb win32. Not sure what the status of this is

== Problems ==

Building OLA for Windows

2011-04-30T16:56:18Z

66.92.11.32: /* Install Git */

This describes how to get OLA compiled for windows, it's a work in progress so it's unlikely to work as is. This tutorial uses gcc as the compiler, other compilers have not been tested.

== Install Mingw, msys & build tools ==

Together MinGW & msys provide a unix-style shell environment & compiler suite for windows. Read the instructions at the [http://www.mingw.org/ MinGW] site for more info. MinGW now provides an installer to get most of the system up and running quickly. [http://sourceforge.net/projects/mingw/files/Automated%20MinGW%20Installer/mingw-get-inst/ Download] the installer and make sure you select "C++ Compiler". "MSYS Basic System" & "MinGW Developer Toolkit" when prompted.

Once the installer has completed, open the msys shell (under Programs > MinGW) and install some additional packages:

$ mingw-get.exe install msys-automake msys-autoconf libtool

== Install Git ==

Git is used to checkout (and commit) the ola sources. See http://code.google.com/p/msysgit/, be sure to select "checkout as is, commit unix style" during the install otherwise you'll get autoconf errors.

Add the following line to your .bashrc file so that git can be used within msys:

PATH="$PATH:/c/Program Files/Git/bin"

== Install Dependencies ==

For each of these it should be as simple as downloading the package, placing it in C:\MinGW\msys\1.0\home\USER , un-taring the package and running ./configure , make & make install.

* http://code.google.com/p/protobuf/ . Note you need to install the .tar.gz as the zip just contains protoc (we need the libraries as well)
* http://www.ossp.org/pkg/lib/uuid/ , be sure to run configure with ./configure --prefix=/mingw --includedir /mingw/include/ossp
* http://sourceforge.net/projects/cppunit/files/
* ftp://ftp.gnu.org/gnu/libmicrohttpd/

== Build OLA ==

* Do a git checkout of OLA

$ git.exe clone http://git.openlighting.org/ola/

* Run ./configure
$ ./configure

* Build
$ make

== Current TODO ==

* Fix the Socket & SelectServer classes or replace them with whatever makes sense on windows
* The USB Pro plugin needs a way to find devices, obviously /dev doesn't exist
* The DMX USB requires libusb win32. Not sure what the status of this is

== Problems ==

Build OLA Mac Packages

2011-04-25T04:03:48Z

66.92.11.32: /* protobuf */

These are my notes on building universal binary packages for mac.

==Directory setup==

<pre>
# extracted tarballs
~/mac-packaging/build/libartnet-1.1.0
~/mac-packaging/build/libmicrohttpd-0.4.2
~/mac-packaging/build/protobuf-2.2.0
~/mac-packaging/build/ctemplate-
~/mac-packaging/build/libusb-1.0.6
# install desintations
~/mac-packaging/non-flat-packages/libartnet
~/mac-packaging/non-flat-packages/libmicrohttpd
~/mac-packaging/non-flat-packages/protobuf
~/mac-packaging/non-flat-packages/ctemplate
~/mac-packaging/non-flat-packages/libusb
</pre>

== Building OLA Dependancies ==

=== libusb ===

In ~/mac-packaging/build/libusb-1.0.6:

<pre>
./configure --disable-dependency-tracking
make CFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/libusb/ make install
</pre>

=== libmicrohttpd ===

<pre>
./configure --disable-dependency-tracking --with-libgcrypt-prefix=/tmp/foo
make CFLAGS="-arch ppc -arch i386" CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/microhttpd/ make install
</pre>

=== protobuf ===

<pre>
./configure --disable-dependency-tracking
make CFLAGS="-arch ppc -arch i386 -arch x86_64" CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/protobuf/ make install
./configure --disable-dependency-tracking
sudo make install
cd python
python setup.py install --root ~/lighting/mac-packaging/non-flat-packages/protobuf --prefix /usr/local/
</pre>

The second make install is required so that ola-examples builds. I'm sure there is a way around this but I can't figure it out...

=== Cleanup ===

In ~/lighting/mac-packaging/non-flat-packages, run

<pre>
find ./ -name ".DS_Store" -exec rm {} \;
</pre>

== Creating Dependancy Packages ==

Using PackageMaker, create a distribution package for each of the dependancies. Remember to fix the permissions and set Package Location to 'Same Level'. Build the package and save it in ~/lighting/mac-packaging/non-flat-packages

~/lighting/mac-packaging/non-flat-packages should now look something like:

<pre>
libusb 1.0.8.mpkg
libusb 1.0.8.pkg
microhttpd 0.4.2.mpkg
microhttpd.pkg
protobuf 2.2.0.mpkg
protobuf 2.2.0.pkg
</pre>

== Building ola & ola-examples ==

Unpack the ola tarball, then run

<pre>
./configure --disable-dependency-tracking
make CPPFLAGS="-arch ppc -arch i386 -arch x86_64 -mmacosx-version-min=10.5" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
make check
sudo make install
DESTDIR=/Users/simonn/lighting/mac-packaging/ola make install
</pre>

Again, The first make install is required so that ola-examples builds. I'm sure there is a way around this but I can't figure it out...

Unpack the ola-examples tarball and run:

<pre>
./configure --disable-dependency-tracking
make CPPFLAGS="-arch ppc -arch i386 -arch x86_64 -mmacosx-version-min=10.5" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/ola-examples make install
</pre>

Clean up the .DS_Store and static libs in ola & ola-tools

<pre>
find ./ -name "*.DS_Store" -exec rm {} \;
find ./ -name "*.a" -exec rm {} \;
</pre>

== Create the main package & build ==

Add the 4 dependancies, ola & ola-tools

Open Lighting PIDs

2011-04-16T20:42:51Z

66.92.11.32: Created page with "This page documents RDM PIDs used by the open lighting project. 0x8000 This sets the serial number of the device. The serial number is combined with the ESTA ID to create t…"

This page documents [[RDM]] PIDs used by the open lighting project.

0x8000

This sets the serial number of the device. The serial number is combined with the ESTA ID to create the UID.

Running the tests

2011-03-02T16:32:19Z

66.92.11.32:

This describes how to run the [[OLA RDM Responder Testing | RDM Responder Tests]]. Before starting you may want to read the [[Responder Testing FAQ]].

== Install OLA ==

Follow one of [[OLA on OS X]] or [[OLA on Linux]] or [[OLA on Windows with VMWare]] to install [[OLA]]. If you want the biggest benefit from the tests you should use the version in the git repo as tests are added regularly.

== Setup the Test Rig ==

The following controller devices are supported:
* [[RDM-TRI]]
* [[DMXter4 RDM]] / [[MiniDMXter]]

Connect the device under test to the controller device and start ''olad''. Patch the output port on the controller device to a universe (UNIVERSE_NUMBER). Then run ''ola_rdm_discover'', you should see the responder's UID appear:

$ ola_rdm_discover -u UNIVERSE_NUMBER
00a1:00010003
7a70:ffffff00

== Running the Tests ==

The tests are written in Python and run using ''ola_rdm_test.py''. Below is the output from a typical test run:

$ ./ola_rdm_test.py --universe 1 00a1:00010003
Starting tests, universe 3, UID 00a1:00010003
SetManufacturerLabel: Passed
SetSoftwareVersionLabel: Passed
GetManufacturerLabel: Passed
GetSoftwareVersionLabelWithData: Failed
...
------------- Warnings --------------
------------ By Category ------------
Product Information: 7 / 7 100%
RDM Information: 1 / 1 100%
Core Functionality: 2 / 2 100%
Error Conditions: 10 / 16 62%
DMX512 Setup: 3 / 3 100%
-------------------------------------
29 / 30 tests run, 23 passed, 6 failed, 0 broken

== Useful Options ==

''ola_rdm_test.py'' has some options which can assist in debugging failures. For a full list of options run with -h

; -d, --debug
: Show all debugging output, including actual & expected responses.
; -l, --log
: Log the output of the tests to a file. The UID and timestamp is appended to the filename
; -t Test1,Test2 , --tests=Test1,Test2
: Only run a subset of the Tests. Only the tests listed (and their dependencies) will be run.

Running the tests

2011-03-02T16:31:12Z

66.92.11.32:

This describes how to run the [[OLA RDM Responder Testing | RDM Responder Tests]]. Before starting you may want to read the [[Responder Testing FAQ]].

== Install OLA ==

Follow one of [[OLA on OS X]] or [[OLA on Linux]] or [[OLA on Windows with VMWare]] to install [[OLA]]

== Setup the Test Rig ==

The following controller devices are supported:
* [[RDM-TRI]]
* [[DMXter4 RDM]] / [[MiniDMXter]]

Connect the device under test to the controller device and start ''olad''. Patch the output port on the controller device to a universe (UNIVERSE_NUMBER). Then run ''ola_rdm_discover'', you should see the responder's UID appear:

$ ola_rdm_discover -u UNIVERSE_NUMBER
00a1:00010003
7a70:ffffff00

== Running the Tests ==

The tests are written in Python and run using ''ola_rdm_test.py''. Below is the output from a typical test run:

$ ./ola_rdm_test.py --universe 1 00a1:00010003
Starting tests, universe 3, UID 00a1:00010003
SetManufacturerLabel: Passed
SetSoftwareVersionLabel: Passed
GetManufacturerLabel: Passed
GetSoftwareVersionLabelWithData: Failed
...
------------- Warnings --------------
------------ By Category ------------
Product Information: 7 / 7 100%
RDM Information: 1 / 1 100%
Core Functionality: 2 / 2 100%
Error Conditions: 10 / 16 62%
DMX512 Setup: 3 / 3 100%
-------------------------------------
29 / 30 tests run, 23 passed, 6 failed, 0 broken

== Useful Options ==

''ola_rdm_test.py'' has some options which can assist in debugging failures. For a full list of options run with -h

; -d, --debug
: Show all debugging output, including actual & expected responses.
; -l, --log
: Log the output of the tests to a file. The UID and timestamp is appended to the filename
; -t Test1,Test2 , --tests=Test1,Test2
: Only run a subset of the Tests. Only the tests listed (and their dependencies) will be run.

Responder Testing FAQ

2011-02-12T20:40:23Z

66.92.11.32: /* I disagree with the output of a test / I disagree with the interpretation of the standard */

== General Information ==

==== Is this a E1.20 Compliance Test? ====

No. There is no known industry standard compliance tests for [[E1.20]]. Developing these sort of tests is expensive and the industry is reasonably small.

==== How is this related to PLASA and the PLASA Standards Group ? ====

Although some of the test developers sit on the PLASA Control Protocols Working Group and/or various Task Groups, this effort is in no way affiliated with PLASA.

== Testing Devices ==

==== Can I run the tests myself? ====

Yes. You need one of the [[#Which RDM controllers are supported?| supported controllers]] and a system on which to run [[OLA]].

==== Can I send my equipment somewhere to have it tested? ====

Yes. You can send RDM responders to us (located in California) and we'll run the tests and send you the output. You'll either need to organize return postage, or agree to leave the hardware with us. If you provide us with a way to upgrade firmware on your devices we'll test new firmware versions for you.

==== I'll only send RDM responders if you pay a deposit, sign an NDA etc. ====

Sorry, this is a best effort volunteer service. We don't have the financial or legal resources to get into this.

==== Can someone work with me to debug my responder? ====

We'll do the best we can to explain the expected behavior and why tests fail. We don't provide consulting services but can recommend freelance RDM developers.

==== Can I pay someone to perform testing for me? ====

Not at the moment. We may provide this service in the future.

== Technical Questions ==

==== Which RDM controllers are supported? ====

Currently the following controller devices are supported:
* [[RDM-TRI]]
* [[DMXter4 RDM]] / [[MiniDMXter]]

==== I make RDM Controllers and I'd like to have my device supported ====

The fastest way is to write the code yourself. Failing that, if you provide the hardware we can work on supporting it.

==== Why isn't signal timing checked? ====

Simply because the developers haven't had time to add this. The amount of information on signal timing is limited by what the RDM controller interfaces provide to the host PC. For now we recommend adding a inline RDM sniffer and using that to check for timing problems.

==== I disagree with the output of a test / I disagree with the interpretation of the standard ====

Where the [[E1.20]] standard is ambiguous, the test output reflects the consensus reached by well respected engineers within the industry. If you think one of the test cases is wrong please start a discussion on the [http://www.rdmprotocol.org/ RDM Protocol Forums].

Writing RDM Responder Tests

2011-02-01T16:57:25Z

66.92.11.32:

This page describes how to author new RDM Responder tests. Read [[OLA RDM Responder Testing]] for information on running the tests and some general information about the testing framework.

== Basic Test Structure ==

The tests are defined in tools/rdm/TestDefinitions.py . Each test subclasses the ResponderTest class and provides the Test() method which is used to send the RDM request.

=== Dependencies ===

Tests can have dependencies, which enables the conditional running of tests if conditions match. Dependencies are defined in the DEPS variable

=== Categories ===

Each test belongs to a category (defined in tools/rdm/ResponderTest.py). Categories follow those in the RDM Categories/Parameter ID Defines table in the E1.20 document but there are some extra categories for specific behavior like TestCategory.ERROR_CONDITIONS and TestCategory.SUB_DEVICES . The category a test belongs to is defined in the CATEGORY variable.

=== PID ===

The PID variable defined which PID this test will exercise (tests can exercise multiple PIDs but that's more complicated). The PID variable should be set to a string that exists in the PidStore data file.

== Example 1 ==

This shows a test which checks that a GET request for PID ''DMX Start Address'' behaves correctly.

<pre>
class GetStartAddress(ResponderTest):
"""GET the DMX start address."""
CATEGORY = TestCategory.DMX_SETUP
PID = 'dmx_start_address'
DEPS = [GetDeviceInfo]

def Test(self):
result = ExpectedResult.NackResponse(self.pid.value,
RDMNack.NR_UNKNOWN_PID)
if self.Deps(GetDeviceInfo).GetField('dmx_footprint') > 0:
result = ExpectedResult.AckResponse(self.pid.value, ['dmx_address'])
self.AddExpectedResults(result)
self.SendGet(PidStore.ROOT_DEVICE, self.pid)
</pre>

Things to note:
* The GetStartAddress test depends on the GetDeviceInfo test to ensure that the device reports a dmx footprint > 0. This is because devices with a footprint of 0 are not required to implement the DMX Start Address PID.

== Advanced Functionality ==

=== Warnings ===

Warnings can be recorded when we detect behavior which while not serious enough to cause a failure should still be correctly handled. Warnings are printed in the summary section of the test output. To record a warning use the AddWarning() method:

<pre>
if footprint > MAX_DMX_ADDRESS:
self.AddWarning('DMX Footprint of %d, was more than 512' % footprint)
</pre>

=== Advisory Messages ===

Advisory messages are similar to warnings but they indicate issues that are not covered by the standard but are likely to cause problems i.e a sensor temperature out side of the stated scale range.

<pre>
if sensor.value > sensor.max:
self.AddAdvisory('Sensor value %d greater than max range %d' % (sensor.value, sensor.max))
</pre>

=== Skipping Tests ===

A test may not want to run if certain conditions aren't satisfied. Calling SetNotRun() means that a test will be marked as skipped. For example, we only want to run the GetParamDescription test if we find manufacturer specific PIDS:

<pre>
def Test(self):
self.params = self.Deps(GetSupportedParameters).manufacturer_parameters[:]
if len(self.params) == 0:
self.SetNotRun(' No manufacturer params found')
self.Stop()
return

# test continues here
</pre>

=== Verification Methods ===

Sometimes it's not enough to check the presences of fields, or use simple equality matching. The VerifyResult() method is passed the full RDM response and can be used to implement complex inter-field checking.

<pre>
def VerifyResult(self, unused_status, fields):
"""Check the footprint, personalities & sub devices."""
footprint = fields['dmx_footprint'] if footprint > MAX_DMX_ADDRESS:
self.AddWarning('DMX Footprint of %d, was more than 512' % footprint)
if footprint > 0:
personality_count = fields['personality_count']
current_personality = fields['current_personality']
if personality_count == 0:
self.AddWarning('DMX Footprint non 0, but no personalities listed')
</pre>

== Mixins ==

Mixins are classes which abstract away common functionality to make it easier to author tests. Mixins are defined in tools/rdm/TestMixins.py.

<pre>
class GetDeviceLabel(TestMixins.GetLabelMixin, ResponderTest):
"""GET the device label."""
CATEGORY = TestCategory.PRODUCT_INFORMATION
PID = 'device_label'
</pre>

This test didn't need any code at all. We simply inherit from the GetLabelMixin, which provides it's own Test() method. Remember when using Mixins to inherit from ResponderTest last, otherwise the Test() method in ResponderTest will be used and the test will be marked as BROKEN.

The ''IsSupportedMixin'' allows for easy testing based on whether support for the parameter has been declared. From the mixin code:

<pre>

class IsSupportedMixin(object):
"""A Mixin that changes the result if the pid isn't in the supported list."""
DEPS = [GetSupportedParameters]

def PidSupported(self):
return self.Deps(GetSupportedParameters).SupportsPid(self.pid)

def AddIfSupported(self, result):
if not self.PidSupported():
result = ExpectedResult.NackResponse(self.pid.value,
RDMNack.NR_UNKNOWN_PID)
self.AddExpectedResults(result)
</pre>

Tests can use this like so:

<pre>

class GetFactoryDefaults(IsSupportedMixin, ResponderTest):
"""GET the factory defaults pid."""
CATEGORY = TestCategory.PRODUCT_INFORMATION
PID = 'factory_defaults'

def Test(self):
self.AddIfSupported(
ExpectedResult.AckResponse(self.pid.value, ['using_defaults']))
self.SendGet(PidStore.ROOT_DEVICE, self.pid)
</pre>

This test will send a GET request for the ''factory_defaults'' pid. If this pid was listed in the supported parameters the test will expect a ACK response. If this pid wasn't listed, a NR_UNKNOWN_PID will be expected.

== Guidelines ==

* Avoid the use of multiple expected responses. With good use of test dependencies, a test should know what to expect before we send the request.
* Always include a doc string. These are used in the debugging output to describe the test
* Try to keep the number of dependencies for each test to a minimum. Additional dependencies increase the chance the test won't be run because a dependency failed.
* Use the IsSupportedMixin where ever possible.

Responder Testing FAQ

2011-01-31T03:44:47Z

66.92.11.32: Created page with "== General Information == ==== Is this a E1.20 Compliance Test? ==== No. There is no known industry standard compliance tests for E1.20. Developing these sort of tests is e…"

== General Information ==

==== Is this a E1.20 Compliance Test? ====

No. There is no known industry standard compliance tests for [[E1.20]]. Developing these sort of tests is expensive and the industry is reasonably small.

==== How is this related to PLASA and the PLASA Standards Group ? ====

Although some of the test developers sit on the PLASA Control Protocols Working Group and/or various Task Groups, this effort is in no way affiliated with PLASA.

== Testing Devices ==

==== Can I run the tests myself? ====

Yes. You need one of the [[#Which RDM controllers are supported?| supported controllers]] and a system on which to run [[OLA]].

==== Can I send my equipment somewhere to have it tested? ====

Yes. You can send RDM responders to us (located in California) and we'll run the tests and send you the output. You'll either need to organize return postage, or agree to leave the hardware with us. If you provide us with a way to upgrade firmware on your devices we'll test new firmware versions for you.

==== I'll only send RDM responders if you pay a deposit, sign an NDA etc. ====

Sorry, this is a best effort volunteer service. We don't have the financial or legal resources to get into this.

==== Can someone work with me to debug my responder? ====

We'll do the best we can to explain the expected behavior and why tests fail. We don't provide consulting services but can recommend freelance RDM developers.

==== Can I pay someone to perform testing for me? ====

Not at the moment. We may provide this service in the future.

== Technical Questions ==

==== Which RDM controllers are supported? ====

Currently the following controller devices are supported:
* [[RDM-TRI]]
* [[DMXter4 RDM]] / [[MiniDMXter]]

==== I make RDM Controllers and I'd like to have my device supported ====

The fastest way is to write the code yourself. Failing that, if you provide the hardware we can work on supporting it.

==== Why isn't signal timing checked? ====

Simply because the developers haven't had time to add this. The amount of information on signal timing is limited by what the RDM controller interfaces provide to the host PC. For now we recommend adding a inline RDM sniffer and using that to check for timing problems.

==== I disagree with the output of a test / I disagree with the interpretation of the standard ====

Where the [[E1.20]] standard is ambiguous, the . If you think one of the test cases is wrong start a discussion on the [[http://www.rdmprotocol.org/ RDM Protocol Forums]].

Open Lighting Architecture

2011-01-31T02:00:17Z

66.92.11.32:

[[Image:Ola.png|right]]
Link: http://code.google.com/p/linux-lighting/ 
{{Features|free=yes|tx=yes|rx=yes|linux=yes|osx=yes|http=yes|rdm=yes}}
[[Image:Ola-download.png |right|link=http://code.google.com/p/linux-lighting/downloads/list]]
[[Image:Llad_home.png| thumb |200px|right|Universe Settings]]
[[Image:Ola-rdm.png|thumb|200px|right|RDM Devices Page]]
[[Image:OLA_patching.png|thumb|200px|right|Drag & Drop RDM Patching]]
[[Image:Ola-mobile.png|thumb|200px|right|Mobile UI]]

__NOTOC__
The Open Lighting Architecture (OLA) is part of the [[Open Lighting Project]] and provides applications with a mechanism to send and receive [[DMX512]] & [[RDM]] commands using hardware devices and DMX over IP protocols. This enables [[:Category:Controllers | software controllers]] to communicate with hardware either via Ethernet or over traditional DMX512 networks.

OLA can also convert DMX512 data sent using DMX over IP protocols from one format to another, allowing devices from different manufacturers to interact with one another. For example a [[Strand_Lighting|Strand]] Lighting Console using ShowNet can send DMX512 to an [[Enttec]] [[DmxEtherGate MKII|EtherGate]]. When combined with a physical DMX interface such as the [[DMX USB Pro]], OLA can send and receive data from wired DMX512 networks.

==Main Features ==

* Supports a variety of DMX over IP Protocols and a dozen different USB DMX devices.
* Priority based merging of different sources.
* Built in web based configuration including:
** [[RDM]] controller
** Drag and drop RDM patching with an automatic patcher
** Custom UI for mobile devices (iPhone, Android)
* Command line tools which enable scripting of configuration and RDM commands.
* Python, C++, Objective-C++ APIs for developers to build their own applications.
* Runs on Mac OS X (ppc, i386, x86_64) & Linux ( i386, x86-64, arm).
* Source code is open and available at no cost.

A port to Windows is feasible if someone wants to add the necessary platform-dependent code. For now it can be run on Windows using VMWare (see [[OLA on Windows with VMWare]])

Questions: See the [http://groups.google.com/group/open-lighting mailing list]

Bugs: Check the [http://code.google.com/p/linux-lighting/issues/list bug tracker]

Contribute: Looking to help? Visit the [[OLA Contributors]] page. The page also lists people and companies who have supported OLA. Please support them in return!

==Supported Protocols==

{| border=1 cellspacing="0"
! '''Protocol'''!! Linux !! '''Mac OS X'''
|-
|| [[:Category:ArtNet|ArtNet]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]] || [[Image:Green-tick.png|center]]
[[Image:Rdm.gif|center]]
|-
|| [[E1.31]] / [[ACN]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ESP Net|ESP Net]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Pathport|Pathport]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Sandnet|Sandnet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ShowNet|ShowNet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|}

==Supported Devices==

{| border=1 cellspacing="0"
! '''Device'''!! Linux !! '''Mac OS X'''
|-
|| [[Anyma uDMX]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[Arduino RGB Mixer]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[DMX 4 Linux]] || [[Image:Trans.gif|center]] ||
|-
|| [[DMX USB Pro]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]]
|-
|| [[DMX-TRI]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[DMXking USB DMX512-A]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]]
|-
|| [[DMXter4 RDM]] / [[MiniDMXter]] || [[Image:Rdm.gif|center]] || [[Image:Rdm.gif|center]]
|-
|| [[Open DMX USB]] || [[Image:Trans.gif|center]] ||
|-
|| [[Packetheads USB_DMX Dongle]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[RDM-TRI]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]]
|-
|| [[StageProfi]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] (Ethernet version only)
|-
|| [http://machosehead.wordpress.com/2010/06/12/udmx_asp/ uDMX_asp] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[USBDMX2]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[Velleman K8062]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|}

==Getting Started==

Start here if you've never used OLA before and read these in order.
* [[Download OLA]]
* [[OLA on OS X]] or [[OLA on Linux]] or [[OLA on Windows with VMWare]] - How to install OLA.
* [[Using OLA]] - A basic introduction
* [[OLA Command Line Tools]] - Documentation for the tools in ola-examples
* [[OLA Device Specific Configuration]]
* [[OLA Tips & Tricks]]
* [[RDM with OLA]]

Tutorials
* [[OlaOutput Max External]] - Setup OlaOutput on Mac OS X to send DMX messages from Max/MSP/Jitter
* [[OLAGuruPlug]] - Running OLA on a [http://www.globalscaletechnologies.com/c-4-guruplugs.aspx GuruPlug]
* [[OlaLED]] - control RGB LED via http
* [[OLA RDM Responder Testing]]

Advanced Topics:
* [[OLA Merging Algorithms]]
* [[OLA DiffServ support]] (QOS settings)

Developer Documentation:
* [[OLA developer info]] - about the source code and structure
* [[OLA Client API]] - the C++ API
* [[OLA Python API]] - easy DMX programming
* [[Build OLA Mac Packages]] - notes for building the .dmg images
* [[Building OLA for Windows]] - Notes on Windows support (in progress)
* [[Using OLA with Xcode]] - on a Mac, in Objective-C++
* [[Writing RDM Responder Tests]]
* [[Port Throttling]]
* [[OLA Performance Stats]]

Tutorials, these refer to the previous release but parts of them are still relevant.
* [[LLA Sandnet Tutorial]] - Setup Horizon using Sandnet and LLA
* [[LLA and Q Light Controller Ubuntu Tutorial]] - Setup LLA on Ubuntu/Debian-type distro with QLC
* [[LLA and Q Light Controller OSX Tutorial]] - Setup LLA on Mac OS X with QLC

[[Category:ArtNet]]
[[Category:ESP Net]]
[[Category:E1.31]]
[[Category:Sandnet]]
[[Category:ShowNet]]
[[Category:Utilities]]
[[Category:Pathport]]

OLA on Windows with VMWare

2011-01-29T21:30:58Z

66.92.11.32:

== Setting up the Linux System ==

This is based on these [http://www.howtogeek.com/howto/11287/how-to-run-ubuntu-in-windows-7-with-vmware-player/ excellent instructions]. The instructions are for Windows 7, but work fine on XP as well.

=== Download & Install VMWare Player ===

Download the free [http://www.vmware.com/download/player/ VMWare Player]. You'll need to complete the survey and provide an email address. Install this on your windows machine. Reboot.

=== Download a Linux Distribution ===

I recommend Ubuntu. It's fairly easy to use and stays up to date. Get the latest version from [http://www.ubuntu.com/desktop/get-ubuntu/download here]. Once this is done you should have an .iso file which will be around 600MB.

=== Setup a New Virtual Machine ===

Open VMWare Player, select "Create New Virtual Machine". Choose "Installer Disk Image" and point to the Linux .iso file you downloaded.

On the next screen setup a username & password. You can then control where the VM image is stored and the size of the image. The defaults are fine.

Click Finish to setup the Linux image. Installation of Ubuntu then begins.

You'll be asked if you want to install VMWare tool for Linux. Say yes and the download will continue along with the install. This stage can take quite a while.

Writing RDM Responder Tests

2011-01-21T03:01:45Z

66.92.11.32:

This page describes how to author new RDM Responder tests. Read [[OLA RDM Responder Testing]] for information on running the tests and some general information about the testing framework.

== Basic Test Structure ==

The tests are defined in tools/rdm/TestDefinitions.py . Each test subclasses the ResponderTest class and provides the Test() method which is used to send the RDM request.

=== Dependencies ===

Tests can have dependencies, which enables the conditional running of tests if conditions match. Dependencies are defined in the DEPS variable

=== Categories ===

Each test belongs to a category (defined in tools/rdm/ResponderTest.py). Categories follow those in the RDM Categories/Parameter ID Defines table in the E1.20 document but there are some extra categories for specific behavior like TestCategory.ERROR_CONDITIONS and TestCategory.SUB_DEVICES . The category a test belongs to is defined in the CATEGORY variable.

=== PID ===

The PID variable defined which PID this test will exercise (tests can exercise multiple PIDs but that's more complicated). The PID variable should be set to a string that exists in the PidStore data file.

== Example 1 ==

This shows a test which checks that a GET request for PID ''DMX Start Address'' behaves correctly.

<pre>
class GetStartAddress(ResponderTest):
"""GET the DMX start address."""
CATEGORY = TestCategory.DMX_SETUP
PID = 'dmx_start_address'
DEPS = [GetDeviceInfo]

def Test(self):
result = ExpectedResult.NackResponse(self.pid.value,
RDMNack.NR_UNKNOWN_PID)
if self.Deps(GetDeviceInfo).GetField('dmx_footprint') > 0:
result = ExpectedResult.AckResponse(self.pid.value, ['dmx_address'])
self.AddExpectedResults(result)
self.SendGet(PidStore.ROOT_DEVICE, self.pid)
</pre>

Things to note:
* The GetStartAddress test depends on the GetDeviceInfo test to ensure that the device reports a dmx footprint > 0. This is because devices with a footprint of 0 are not required to implement the DMX Start Address PID.

== Advanced Functionality ==

=== Warnings ===

Warnings can be recorded when we detect behavior which while not serious enough to cause a failure should still be correctly handled. Warnings are printed in the summary section of the test output. To record a warning use the AddWarning() method:

<pre>
if footprint > MAX_DMX_ADDRESS:
self.AddWarning('DMX Footprint of %d, was more than 512' % footprint)
</pre>

=== Advisory Messages ===

Advisory messages are similar to warnings but they indicate issues that are not covered by the standard but are likley to cause problems i.e a sensor temperature out side of the stated scale range.

<pre>
if sensor.value > sensor.max:
self.AddAdvisory('Sensor value %d greater than max range %d' % (sensor.value, sensor.max))
</pre>

=== Pre Conditions ===

A test may not want to run if certain conditions aren't satisfied. The PreCondition() method allows a test to prevent itself from running. For example, we only want to run the GetParamDescription test if we find manufacturer specific PIDS:

<pre>
def PreCondition(self):
params = self.Deps(GetSupportedParameters).supported_parameters
self.params = [p for p in params if p >= 0x8000 and p < 0xffe0]
return len(self.params) > 0
</pre>

=== Verification Methods ===

Sometimes it's not enough to check the presences of fields, or use simple equality matching. The VerifyResult() method is passed the full RDM response and can be used to implement complex inter-field checking.

<pre>
def VerifyResult(self, unused_status, fields):
"""Check the footprint, personalities & sub devices."""
footprint = fields['dmx_footprint'] if footprint > MAX_DMX_ADDRESS:
self.AddWarning('DMX Footprint of %d, was more than 512' % footprint)
if footprint > 0:
personality_count = fields['personality_count']
current_personality = fields['current_personality']
if personality_count == 0:
self.AddWarning('DMX Footprint non 0, but no personalities listed')
</pre>

== Mixins ==

Mixins are classes which abstract away common functionality to make it easier to author tests. Mixins are defined in tools/rdm/TestMixins.py.

<pre>
class GetDeviceLabel(TestMixins.GetLabelMixin, ResponderTest):
"""GET the device label."""
CATEGORY = TestCategory.PRODUCT_INFORMATION
PID = 'device_label'
</pre>

This test didn't need any code at all. We simply inherit from the GetLabelMixin, which provides it's own Test() method. Remember when using Mixins to inherit from ResponderTest last, otherwise the Test() method in ResponderTest will be used and the test will be marked as BROKEN.

The ''IsSupportedMixin'' allows for easy testing based on whether support for the parameter has been declared. From the mixin code:

<pre>

class IsSupportedMixin(object):
"""A Mixin that changes the result if the pid isn't in the supported list."""
DEPS = [GetSupportedParameters]

def PidSupported(self):
return self.Deps(GetSupportedParameters).SupportsPid(self.pid)

def AddIfSupported(self, result):
if not self.PidSupported():
result = ExpectedResult.NackResponse(self.pid.value,
RDMNack.NR_UNKNOWN_PID)
self.AddExpectedResults(result)
</pre>

Tests can use this like so:

<pre>

class GetFactoryDefaults(IsSupportedMixin, ResponderTest):
"""GET the factory defaults pid."""
CATEGORY = TestCategory.PRODUCT_INFORMATION
PID = 'factory_defaults'

def Test(self):
self.AddIfSupported(
ExpectedResult.AckResponse(self.pid.value, ['using_defaults']))
self.SendGet(PidStore.ROOT_DEVICE, self.pid)
</pre>

This test will send a GET request for the ''factory_defaults'' pid. If this pid was listed in the supported parameters the test will expect a ACK response. If this pid wasn't listed, a NR_UNKNOWN_PID will be expected.

== Guidelines ==

* Avoid the use of multiple expected responses. With good use of test dependencies, a test should know what to expect before we send the request.
* Always include a doc string. These are used in the debugging output to describe the test
* Try to keep the number of dependencies for each test to a minimum. Additional dependencies increase the chance the test won't be run because a dependency failed.
* Use the IsSupportedMixin where ever possible.

OLA on Linux

2011-01-13T05:27:56Z

66.92.11.32:

This describes how to get [[OLA]] working on a Linux system either from the git repo or by using a [http://code.google.com/p/linux-lighting/downloads/list released tarball].

=Checkout or Download an Archive=

Either download a tarball from the releases page, or check out the git repo with the following command:

git clone http://git.opendmx.net/ola

If you don't have '''git''' yet, you'll need to install it with your distro's package manager.

=Install libraries=

You need a couple of libraries installed for everything to work correctly. Some of these are available as packages in distros but others need to be downloaded and built manually.

First up you'll need the following:
* cppunit
* uuid or ossp uuid
* pkg-config
* curses

Debian/Ubuntu users can install them with apt:

apt-get install libcppunit-dev libcppunit-1.12-1 uuid-dev pkg-config libncurses5-dev

If you're building from git you'll also need the following:

* libtool
* automake
* autoconf

apt-get install libtool autoconf automake

Next, you need '''Protocol Buffers''' [http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/] version 3.2.0 or above from Google (BSD license). Most likely, you'll need to download and build them yourself.

Debian (and Ubuntu) users can, in some cases, use the following packages (not yet in stable):
libprotobuf2 (libprotobuf3), libprotobuf-dev, protobuf-compiler

Finally, if you want to use the built in webserver, you'll need '''microhttpd'''. Note: you'll need version >= 0.4.0 of microhttpd else you will get errors:

* [ftp://ftp.gnu.org/gnu/libmicrohttpd/ ftp://ftp.gnu.org/gnu/libmicrohttpd/]

Once everything is installed, run ldconfig as root to pick up the new libraries

sudo ldconfig

=Configure=

If you checked out the sources from git, you'll need to run

autoreconf -i

After that run

./configure

=Building & Testing=

Build
make

If you get an error like the following:

/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/software/protobuf-cpp/2.0.3_0/opt/local/include/ -g -O2 -c -o ltdl.lo ltdl.c
./libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 1142: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.

Your system uses a different version of libtool. Run:

libtoolize --ltdl -c -f

and then start from the autoreconf step again.

Run the tests
make check

And install OLA
sudo make install
sudo ldconfig

=Install ola-examples=

The [[OLA Command Line Tools]] come separately. Again either download a tarball or checkout from the git repo:

git clone http://www.nomis52.net/git/lla-examples

The steps are similar to building the main package.

autoreconf -i # if you used the git repo
./configure
make
sudo make install

Note in order for ola_dmxmonitor and ola_dmxconsole to build you *must* have curses installed.

USB Protocol Extensions

2010-11-15T04:32:15Z

66.92.11.32:

This documents the additional message types added to the [[Enttec]] [[DMX USB Pro]] protocol to support multiple device types. As the number of devices supporting the protocol grows, it becomes difficult for software like [[OLA]] to differentiate the device types. The ''Device Manufacturer'' & ''Device Name'' messages allow the host software to determine the device and know which set of messages it supports.

== Other Solutions ==

=== USB Serial Number ===

Enttec USB Pro devices have only started programming the serial numbers recently (>2008?).
When using the standard USB Serial drivers on Mac & Linux, the host application doesn't have access to the serial numbers. This would require us to write our own USB drivers using libusb to expose this information.

=== Use the User Addressable EEPROM ===

Some devices don't support the ''Set Widget Parameters'' message so this isn't an option. Also it suffers from the bootstrapping issue, we need to know what device it is before we can write the information about what device it is...

== Device Manufacturer, Label = 77, no data ==

This message requests the device manufacturer information from the widget. The response is of the form:

{| border=1
! '''Size in Bytes'''!! Description
|-
|| 2 || [[ESTA]] ID, Least significant byte first
|-
|| 32 || Up to 32 bytes containing the manufacturer name. Not null terminated.
|}

== Device Name, Label = 78, no data ==

This message requests the device name information from the widget. The response is of the form:

{| border=1
! '''Size in Bytes'''!! Description
|-
|| 2 || Device Type ID, Manufacturer assigned. Least significant byte first.
|-
|| 32 || Up to 32 bytes containing the device type. Not null terminated.
|}

== Devices Supporting these Message Types ==

* [[Arduino RGB Mixer]] , ESTA ID: 0x7a70, Device ID: 0x1
* [[Packetheads USB_DMX Dongle]] , ESTA ID: 0x7a70, Device ID: 0x2
* [[DMX-TRI]], ESTA ID: 0x6864, Device ID 0x0: 0x1
* [[RDM-TRI]], ESTA ID: 0x6864, Device ID 0x0: 0x2
* [[DMXking USB DMX512-A]], ESTA ID: 0x6A6B, Device ID: 0x0
* [[DMXter4_RDM]], ESTA ID: 0x4744, Device ID: 0x4D44
* [[MiniDMXter]], ESTA ID: 0x4744, Device ID: 0x494D

== External References ==

* [http://www.enttec.com/docs/dmx_usb_pro_api_spec.pdf DMX Pro API]
* [http://www.esta.org/tsp/working_groups/CP/mfctrIDs.php ESTA IDs]

USB Protocol Extensions

2010-11-14T03:44:40Z

66.92.11.32: /* Devices Supporting these Message Types */

This documents the additional message types added to the [[Enttec]] [[DMX USB Pro]] protocol to support multiple device types. As the number of devices supporting the protocol grows, it becomes difficult for software like [[OLA]] to differentiate the device types. The ''Device Manufacturer'' & ''Device Name'' messages allow the host software to determine the device and know which set of messages it supports.

== Other Solutions ==

=== USB Serial Number ===

Enttec USB Pro devices have only started programming the serial numbers recently (>2008?).
When using the standard USB Serial drivers on Mac & Linux, the host application doesn't have access to the serial numbers. This would require us to write our own USB drivers using libusb to expose this information.

=== Use the User Addressable EEPROM ===

Some devices don't support the ''Set Widget Parameters'' message so this isn't an option. Also it suffers from the bootstrapping issue, we need to know what device it is before we can write the information about what device it is...

== Device Manufacturer, Label = 77, no data ==

This message requests the device manufacturer information from the widget. The response is of the form:

{| border=1
! '''Size in Bytes'''!! Description
|-
|| 2 || [[ESTA]] ID, Least significant byte first
|-
|| 32 || Up to 32 bytes containing the manufacturer name. Not null terminated.
|}

== Device Name, Label = 78, no data ==

This message requests the device name information from the widget. The response is of the form:

{| border=1
! '''Size in Bytes'''!! Description
|-
|| 2 || Device Type ID, Manufacturer assigned. Least significant byte first.
|-
|| 32 || Up to 32 bytes containing the device type. Not null terminated.
|}

== Devices Supporting these Message Types ==

* [[Arduino RGB Mixer]] , ESTA ID: 0x7a70, Device ID: 0x1
* [[Packetheads USB_DMX Dongle]] , ESTA ID: 0x7a70, Device ID: 0x2
* [[DMX-TRI]], ESTA ID: 0x6864, Device ID 0x0: 0x1
* [[RDM-TRI]], ESTA ID: 0x6864, Device ID 0x0: 0x2
* [[DMXking USB DMX512-A]], ESTA ID: 0x6A6B, Device ID: 0x0

== External References ==

* [http://www.enttec.com/docs/dmx_usb_pro_api_spec.pdf DMX Pro API]
* [http://www.esta.org/tsp/working_groups/CP/mfctrIDs.php ESTA IDs]

Build OLA Mac Packages

2010-10-31T21:19:14Z

66.92.11.32:

These are my notes on building universal binary packages for mac.

==Directory setup==

<pre>
# extracted tarballs
~/mac-packaging/build/libartnet-1.1.0
~/mac-packaging/build/libmicrohttpd-0.4.2
~/mac-packaging/build/protobuf-2.2.0
~/mac-packaging/build/ctemplate-
~/mac-packaging/build/libusb-1.0.6
# install desintations
~/mac-packaging/non-flat-packages/libartnet
~/mac-packaging/non-flat-packages/libmicrohttpd
~/mac-packaging/non-flat-packages/protobuf
~/mac-packaging/non-flat-packages/ctemplate
~/mac-packaging/non-flat-packages/libusb
</pre>

== Building OLA Dependancies ==

=== libusb ===

In ~/mac-packaging/build/libusb-1.0.6:

<pre>
./configure --disable-dependency-tracking
make CFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/libusb/ make install
</pre>

=== libmicrohttpd ===

<pre>
./configure --disable-dependency-tracking --with-libgcrypt-prefix=/tmp/foo
make CFLAGS="-arch ppc -arch i386" CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/microhttpd/ make install
</pre>

=== protobuf ===

<pre>
./configure --disable-dependency-tracking
make CFLAGS="-arch ppc -arch i386 -arch x86_64" CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/protobuf/ make install
./configure --disable-dependency-tracking
sudo make install
</pre>

The second make install is required so that ola-examples builds. I'm sure there is a way around this but I can't figure it out...

=== Cleanup ===

In ~/lighting/mac-packaging/non-flat-packages, run

<pre>
find ./ -name ".DS_Store" -exec rm {} \;
</pre>

== Creating Dependancy Packages ==

Using PackageMaker, create a distribution package for each of the dependancies. Remember to fix the permissions and set Package Location to 'Same Level'. Build the package and save it in ~/lighting/mac-packaging/non-flat-packages

~/lighting/mac-packaging/non-flat-packages should now look something like:

<pre>
libusb 1.0.8.mpkg
libusb 1.0.8.pkg
microhttpd 0.4.2.mpkg
microhttpd.pkg
protobuf 2.2.0.mpkg
protobuf 2.2.0.pkg
</pre>

== Building ola & ola-examples ==

Unpack the ola tarball, then run

<pre>
./configure --disable-dependency-tracking
make CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
make check
sudo make install
DESTDIR=/Users/simonn/lighting/mac-packaging/ola make install
</pre>

Again, The first make install is required so that ola-examples builds. I'm sure there is a way around this but I can't figure it out...

Unpack the ola-examples tarball and run:

<pre>
./configure --disable-dependency-tracking
make CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/ola-examples make install
</pre>

Clean up the .DS_Store files in ola & ola-tools

<pre>
find ./ -name "*.DS_Store" -exec rm {} \;
</pre>

== Create the main package & build ==

Add the 4 dependancies, ola & ola-tools

Build OLA Mac Packages

2010-10-31T21:02:31Z

66.92.11.32:

These are my notes on building universal binary packages for mac.

==Directory setup==

<pre>
# extracted tarballs
~/mac-packaging/build/libartnet-1.1.0
~/mac-packaging/build/libmicrohttpd-0.4.2
~/mac-packaging/build/protobuf-2.2.0
~/mac-packaging/build/ctemplate-
~/mac-packaging/build/libusb-1.0.6
# install desintations
~/mac-packaging/non-flat-packages/libartnet
~/mac-packaging/non-flat-packages/libmicrohttpd
~/mac-packaging/non-flat-packages/protobuf
~/mac-packaging/non-flat-packages/ctemplate
~/mac-packaging/non-flat-packages/libusb
</pre>

== Building OLA Dependancies ==

=== libusb ===

In ~/mac-packaging/build/libusb-1.0.6:

<pre>
./configure --disable-dependency-tracking
make CFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/libusb/ make install
</pre>

=== libmicrohttpd ===

<pre>
./configure --disable-dependency-tracking --with-libgcrypt-prefix=/tmp/foo
make CFLAGS="-arch ppc -arch i386" CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/microhttpd/ make install
</pre>

=== protobuf ===

<pre>
./configure --disable-dependency-tracking
make CFLAGS="-arch ppc -arch i386 -arch x86_64" CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/protobuf/ make install
./configure --disable-dependency-tracking
sudo make install
</pre>

The second make install is required so that ola-examples builds. I'm sure there is a way around this but I can't figure it out...

=== Cleanup ===

In ~/lighting/mac-packaging/non-flat-packages, run

<pre>
find ./ -name ".DS_Store" -exec rm {} \;
</pre>

== Creating Dependancy Packages ==

Using PackageMaker, create a distribution package for each of the dependancies. Remember to fix the permissions and set Package Location to 'Same Level'. Build the package and save it in ~/lighting/mac-packaging/non-flat-packages

~/lighting/mac-packaging/non-flat-packages should now look something like:

<pre>
microhttpd 0.4.2.mpkg
microhttpd.pkg
protobuf 2.2.0.mpkg
protobuf 2.2.0.pkg
</pre>

== Building ola & ola-examples ==

Unpack the ola tarball, then run

<pre>
./configure --disable-dependency-tracking
make CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
make check
sudo make install
DESTDIR=/Users/simonn/lighting/mac-packaging/ola make install
</pre>

Again, The first make install is required so that ola-examples builds. I'm sure there is a way around this but I can't figure it out...

Unpack the ola-examples tarball and run:

<pre>
./configure --disable-dependency-tracking
make CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/ola-examples make install
</pre>

Clean up the .DS_Store files in ola & ola-tools

<pre>
find ./ -name "*.DS_Store" -exec rm {} \;
</pre>

== Create the main package & build ==

Add the 4 dependancies, ola & ola-tools

Build OLA Mac Packages

2010-10-31T20:59:56Z

66.92.11.32:

These are my notes on building universal binary packages for mac.

==Directory setup==

<pre>
# extracted tarballs
~/mac-packaging/build/libartnet-1.1.0
~/mac-packaging/build/libmicrohttpd-0.4.2
~/mac-packaging/build/protobuf-2.2.0
~/mac-packaging/build/ctemplate-
~/mac-packaging/build/libusb-1.0.6
# install desintations
~/mac-packaging/non-flat-packages/libartnet
~/mac-packaging/non-flat-packages/libmicrohttpd
~/mac-packaging/non-flat-packages/protobuf
~/mac-packaging/non-flat-packages/ctemplate
~/mac-packaging/non-flat-packages/libusb
</pre>

== Building OLA Dependancies ==

=== libusb ===

In ~/mac-packaging/build/libusb-1.0.6:

<pre>
/configure --disable-dependency-tracking
make CFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/libusb/ make install
</pre>

=== libmicrohttpd ===

<pre>
./configure --disable-dependency-tracking --with-libgcrypt-prefix=/tmp/foo
make CFLAGS="-arch ppc -arch i386" CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/microhttpd/ make install
</pre>

=== protobuf ===

<pre>
./configure --disable-dependency-tracking
make CFLAGS="-arch ppc -arch i386 -arch x86_64" CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/non-flat-packages/protobuf/ make install
./configure --disable-dependency-tracking
sudo make install
</pre>

The second make install is required so that ola-examples builds. I'm sure there is a way around this but I can't figure it out...

=== Cleanup ===

In ~/lighting/mac-packaging/non-flat-packages, run

<pre>
find ./ -name ".DS_Store" -exec rm {} \;
</pre>

== Creating Dependancy Packages ==

Using PackageMaker, create a distribution package for each of the dependancies. Remember to fix the permissions and set Package Location to 'Same Level'. Build the package and save it in ~/lighting/mac-packaging/non-flat-packages

~/lighting/mac-packaging/non-flat-packages should now look something like:

<pre>
microhttpd 0.4.2.mpkg
microhttpd.pkg
protobuf 2.2.0.mpkg
protobuf 2.2.0.pkg
</pre>

== Building ola & ola-examples ==

Unpack the ola tarball, then run

<pre>
./configure --disable-dependency-tracking
make CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
make check
sudo make install
DESTDIR=/Users/simonn/lighting/mac-packaging/ola make install
</pre>

Again, The first make install is required so that ola-examples builds. I'm sure there is a way around this but I can't figure it out...

Unpack the ola-examples tarball and run:

<pre>
./configure --disable-dependency-tracking
make CPPFLAGS="-arch ppc -arch i386 -arch x86_64" LDFLAGS=" -arch ppc -arch i386 -arch x86_64"
DESTDIR=/Users/simonn/lighting/mac-packaging/ola-examples make install
</pre>

Clean up the .DS_Store files in ola & ola-tools

<pre>
find ./ -name "*.DS_Store" -exec rm {} \;
</pre>

== Create the main package & build ==

Add the 4 dependancies, ola & ola-tools

OLA Device Specific Configuration

2010-10-31T20:45:48Z

66.92.11.32:

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==ArtNet ==

If you've having problems sending ArtNet data is may be because your receivers don't support ArtNet II and/or send ArtPollReply messages. You can force OLA to always broadcast data by changing ~/.ola/ola-artnet.conf to contain:

always_broadcast = true

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available [http://code.google.com/p/linux-lighting/downloads/detail?name=libdmxusbshield.dmg| here]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

KiNET

2010-10-31T00:26:20Z

66.92.11.32:

KiNet is the protocol used by Color Kinetics to control LED fixtures. It uses UDP on port 6038. Fixtures can be configured with the [http://www.colorkinetics.com/support/addressing/ Quick Play Pro] tool.

==Protocol Spec==

http://webcache.googleusercontent.com/search?q=cache:RnG2kf5JOAYJ:www.directionless.org/color-kinetics/Ethernet+KiNet+port+6038&cd=2&hl=en&ct=clnk&gl=us

http://www.cycling74.com/forums/topic.php?id=22163

# my $strange_ck_header = join("",
# '0401dc4a', # magic, L
# '0100', # ver, H
# '0101', # type, H
# '00000000', # seq, L
# '00', # port, B
# '00', # padding, x
# '0000', # flags, H
# 'ffffffff', # timerVal V, L
# '00', # uni, B
# );

Followed by 512 bytes of DMX data.

[[Category:Definitions]]

ArtNet, RDM and Packet Interleaving

2010-09-06T22:57:02Z

66.92.11.32:

== RDM over Artnet ==

[[ArtNet]] nodes behave as pass-through devices for non-discovery [[RDM]] data. The normal sequence of RDM commands looks like this:

[[Image:ArtNetRDMSequence.png|center]]

== The Potential Problem ==

The problem occurs when the RDM device responds with an ACK_OVERFLOW message. From the standard:

''To receive the remaining data, the controller should continue to send GET_COMMANDS for the same PID. The responder shall send subsequent blocks of data with a response type of RESPONSE_TYPE_ACK_OVERFLOW until the remaining data can fit in a single message. The responder shall set the response type to RESPONSE_TYPE_ACK on the final response message in the sequence, to indicate completion of the data transfer. ''

Assuming that PID A causes an ACK_OVERFLOW, the sequence now looks like this:

[[Image:ArtNetRDMOverflowSequence.png|center]]

But the standard also states:

''The responder shall abort a partial transfer of overflow data for a PID when receiving a command for a different PID before the overflow data transfer is complete. A subsequent command for the overflow PID will result in a new data transfer starting at the beginning of the data set.''

So any RDM packet interleaved between the two ''GET PID A' commands in the above example will cause the transfer to abort.

[[Image:ArtNetRDMOverflowResetSequence.png|center]]

'''Note''': The [http://www.goddarddesign.com/rdm_lab_pack.html Labpack] has a bug where it will not abort the transfer so this continues to work. This is present in version 0x20009

== Possible Solutions ==

There are two cases i) the single controller case ii) the multi-controller case. Nothing in the existing protocol can solve the latter, so it's out of scope for the rest of the discussion.

=== Send a single RDM command at once ===

This is obviously the most reliable but has the drawback of requiring a full round trip between the controller and responder for each message. Testing with a [[Net-Lynx]] showed an average response time of 7ms as seen on the controller when the RTT was 1.3ms. This solution also has the desirable property of not over-running the ArtNet node's buffers. Obviously the controller needs a timeout to detect dropped packets and either re-transmit or move on to the next packet.

=== Send multiple packets at once without waiting for a response ===

This appears to be what [[DMX Workshop]] does and has the potential to break ACK_OVERFLOW sequences.

=== Send multiple packets at once and back off when an ACK_OVERFLOW is received ===

Similar to the above, this sends multiple packets at once but stops sending other packets when an ACK_OVERFLOW is received until the sequence completes (or a timeout occurs). This reduces the chance of an aborted transfer, but doesn't eliminate it.

=== Send multiple packets at once, serialize commands expected to generate ACK_OVERFLOWS and back off when an ACK_OVERFLOW is received ===

Of the PIDs described in E1.20, the following have the potential to generate an ACK_OVERFLOW:

* PROXIED_DEVICES
* STATUS_MESSAGES - but this uses it's own queuing mechanism
* SUPPORTED_PARAMETERS
* LANGUAGE_CAPABILITIES
* SLOT_INFO
* DEFAULT_SLOT_VALUE

When the Controller sends any of these PIDs it can wait to see if an ACK_OVERFLOW occurs before sending any other RDM commands. Of course this doesn't solve the problem for manufacturer specific PIDs, instead it relies on the back off mechanism above.

== References ==

* [http://www.artisticlicence.com/WebSiteMaster/User%20Guides/art-net.pdf ArtNet Protocol Specification]
* [http://www.esta.org/tsp/documents/published_docs.php E1.20 RDM Specification]

ArtNet, RDM and Packet Interleaving

2010-09-06T20:44:44Z

66.92.11.32: /* Send a single RDM command at once */

== RDM over Artnet ==

[[ArtNet]] nodes behave as pass-through devices for non-discovery [[RDM]] data. The normal sequence of RDM commands looks like this:

[[Image:ArtNetRDMSequence.png|center]]

== The Potential Problem ==

The problem occurs when the RDM device responds with an ACK_OVERFLOW message. From the standard:

''To receive the remaining data, the controller should continue to send GET_COMMANDS for the same PID. The responder shall send subsequent blocks of data with a response type of RESPONSE_TYPE_ACK_OVERFLOW until the remaining data can fit in a single message. The responder shall set the response type to RESPONSE_TYPE_ACK on the final response message in the sequence, to indicate completion of the data transfer. ''

Assuming that PID A causes an ACK_OVERFLOW, the sequence now looks like this:

[[Image:ArtNetRDMOverflowSequence.png|center]]

But the standard also states:

''The responder shall abort a partial transfer of overflow data for a PID when receiving a command for a different PID before the overflow data transfer is complete. A subsequent command for the overflow PID will result in a new data transfer starting at the beginning of the data set.''

So any RDM packet interleaved between the two ''GET PID A' commands in the above example will cause the transfer to abort.

[[Image:ArtNetRDMOverflowResetSequence.png|center]]

'''Note''': The [http://www.goddarddesign.com/rdm_lab_pack.html Labpack] has a bug where it will not abort the transfer so this continues to work. This is present in version 0x20009

== Possible Solutions ==

There are two cases i) the single controller case ii) the multi-controller case. Nothing in the existing protocol can solve the latter, so it's out of scope for the rest of the discussion.

=== Send a single RDM command at once ===

This is obviously the most reliable but has the drawback of requiring a full round trip between the controller and responder for each message. Testing with a [[Net-Lynx]] showed an average response time of 7ms as seen on the controller when the RTT was 1.3ms. This solution also has the desirable property of not over-running the ArtNet node's buffers. Obviously the controller needs a timeout to detect dropped packets and either re-transmit or move on to the next packet.

=== Send multiple packets at once without waiting for a response ===

This appears to be what [[DMX Workshop]] does and has the potential to break ack_overflow sequences.

=== Send multiple packets at once and back off when an ACK_OVERFLOW is received ===

Similar to the above, this sends multiple packets at once but stops sending other packets when an ACK_OVERFLOW is received until the sequence completes (or a timeout occurs). This reduces the chance of an aborted transfer, but doesn't eliminate it.

=== Send multiple packets at once, serialize commands expected to generate ACK_OVERFLOWS and back off when an ACK_OVERFLOW is received ===

Of the PIDs described in E1.20, the following have the potential to generate an ACK_OVERFLOW:

* PROXIED_DEVICES
* STATUS_MESSAGES
* SUPPORTED_PARAMETERS
* LANGUAGE_CAPABILITIES
* SLOT_INFO
* DEFAULT_SLOT_VALUE

When the Controller sends any of these PIDs it can wait to see if an ACK_OVERFLOW occurs before sending any other RDM commands. Of course this doesn't solve the problem for manufacturer specific PIDs, instead it relies on the back off mechanism above.

== References ==

* [http://www.artisticlicence.com/WebSiteMaster/User%20Guides/art-net.pdf ArtNet Protocol Specification]
* [http://www.esta.org/tsp/documents/published_docs.php E1.20 RDM Specification]

ArtNet, RDM and Packet Interleaving

2010-09-06T18:55:49Z

66.92.11.32: /* Possible Solutions */

== RDM over Artnet ==

[[ArtNet]] nodes behave as pass-through devices for non-discovery [[RDM]] data. The normal sequence of RDM commands looks like this:

[[Image:ArtNetRDMSequence.png|center]]

== The Potential Problem ==

The problem occurs when the RDM device responds with an ACK_OVERFLOW message. From the standard:

''To receive the remaining data, the controller should continue to send GET_COMMANDS for the same PID. The responder shall send subsequent blocks of data with a response type of RESPONSE_TYPE_ACK_OVERFLOW until the remaining data can fit in a single message. The responder shall set the response type to RESPONSE_TYPE_ACK on the final response message in the sequence, to indicate completion of the data transfer. ''

Assuming that PID A causes an ACK_OVERFLOW, the sequence now looks like this:

[[Image:ArtNetRDMOverflowSequence.png|center]]

But the standard also states:

''The responder shall abort a partial transfer of overflow data for a PID when receiving a command for a different PID before the overflow data transfer is complete. A subsequent command for the overflow PID will result in a new data transfer starting at the beginning of the data set.''

So any RDM packet interleaved between the two ''GET PID A' commands in the above example will cause the transfer to abort.

[[Image:ArtNetRDMOverflowResetSequence.png|center]]

'''Note''': The [http://www.goddarddesign.com/rdm_lab_pack.html Labpack] has a bug where it will not abort the transfer so this continues to work. This is present in version 0x20009

== Possible Solutions ==

There are two cases i) the single controller case ii) the multi-controller case. Nothing in the existing protocol can solve the latter, so it's out of scope for the rest of the discussion.

=== Send a single RDM command at once ===

This is obviously the most reliable but has the drawback of requiring a full round trip between the controller and responder for each message. Testing with a [[Net-Lynx]] showed an average response time of 7ms as seen on the controller when the RTT was 1.3ms. This solution also has the desirable property of not over-running the ArtNet node's buffers.

=== Send multiple packets at once without waiting for a response ===

This appears to be what [[DMX Workshop]] does and has the potential to break ack_overflow sequences.

=== Send multiple packets at once and back off when an ACK_OVERFLOW is received ===

Similar to the above, this sends multiple packets at once but stops sending other packets when an ACK_OVERFLOW is received until the sequence completes (or a timeout occurs). This reduces the chance of an aborted transfer, but doesn't eliminate it.

=== Send multiple packets at once, serialize commands expected to generate ACK_OVERFLOWS and back off when an ACK_OVERFLOW is received ===

Of the PIDs described in E1.20, the following have the potential to generate an ACK_OVERFLOW:

* PROXIED_DEVICES
* STATUS_MESSAGES
* SUPPORTED_PARAMETERS
* LANGUAGE_CAPABILITIES
* SLOT_INFO
* DEFAULT_SLOT_VALUE

When the Controller sends any of these PIDs it can wait to see if an ACK_OVERFLOW occurs before sending any other RDM commands. Of course this doesn't solve the problem for manufacturer specific PIDs, instead it relies on the back off mechanism above.

== References ==

* [http://www.artisticlicence.com/WebSiteMaster/User%20Guides/art-net.pdf ArtNet Protocol Specification]
* [http://www.esta.org/tsp/documents/published_docs.php E1.20 RDM Specification]

RDM with OLA

2010-09-06T16:38:06Z

66.92.11.32:

[[RDM]] devices can be configured through the web interface (only partially complete) or from the command line. Even if you don't have any RDM devices you can still experiment using the fake RDM device created by the Dummy Plugin.

To follow these examples, patch the Dummy Port to universe 1.

== Device Discovery ==

Each RDM device has a unique ID (UID) made up of a two byte manufacturer ID and a four byte device ID. The ''ola_rdm_discovery'' tool displays the UIDs found for each universe.

<pre>
$ ola_rdm_discover -u 1
7a70:ffffff00
</pre>

A single device should be found with a manufacturer ID of 7a70 (Open Lighting) and a device ID of ffffff00 (the dummy device).

Passing the -f option will force the discovery algorithm to be run for the particular universe. This won't produce any output unless an error occurs.

<pre>
$ ola_rdm_discover -u 1 -f
</pre>

== Device Configuration ==

Now that a device has been found, we can query it to find the parameters it supports. Each parameter is assigned a two byte identifier known as a PID. The ''ola_rdm_get'' and ''ola_rdm_set'' commands are used to read / write the values of parameters. The first thing to do is to view a list of all known parameters:

<pre>
$ ola_rdm_get --list_pids
boot_software_version_id
boot_software_version_label
capture_preset
clear_status_id
comms_status
default_slot_value
device_hours
device_info
...
</pre>

This doesn't query the RDM device at all, it simply lists out the names of standard parameters. To see which particular parameters a device supports use:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 supported_parameters
Supported Parameters
0x50 (supported_parameters)
0x60 (device_info)
0x80 (device_model_description)
0x81 (manufacturer_label)
0x82 (device_label)
0xc0 (software_version_label)
0xf0 (dmx_start_address)
</pre>

One of the most useful parameters is device_info:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 device_info
Device Info
RDM Protocol Version: 1.0
Device Model: 0x1
Product Category: other
Software Version: 0x1
DMX Footprint: 10
DMX Personality: 1 / 1
DMX Start Address: 1
# of Subdevices: 0
Sensor Count: 0
</pre>

Here we see some general information about the device including the DMX start address and the # of DMX channels used (DMX Footprint). We can also get the DMX start address by using the dmx_start_address parameter directly:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 dmx_start_address
DMX Start Address: 1
</pre>

To set the start address, the ''ola_rdm_set'' program is used:

<pre>
$ ola_rdm_set --universe 1 --uid 7a70:ffffff00 dmx_start_address 10
</pre>

No output is displayed unless the request failed. Now we can check that the set worked:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 dmx_start_address
DMX Start Address: 10
</pre>

Finally, the full list of options for ''ola_rdm_get'' and ''ola_rdm_set'' can be found by running with --help:

<pre>
-d, --sub_device <device> target a particular sub device (default is 0)
-h, --help display this help message and exit.
-l, --list_pids display a list of pids
-u, --universe <universe> universe number.
--uid <uid> the UID of the device to control.
</pre>

== RDM With ArtNet ==

If you have a copy of DMXWorkshop, you can experiment with RDM over ArtNet by patching an ArtNet Input Port to the same universe as the Dummy Plugin. You can then discover the Dummy Device using DMXWorkshop and configure it's start address over the LAN.

Note that the design of the RDM-over-ArtNet protocol has a significant limitation, see [[ArtNet, RDM and Packet Interleaving]]

== Useful Tricks ==

If you're using bash, it's worthwhile to set up tab completion of PIDs:

<pre>
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_get
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_set
</pre>

Open Lighting Architecture

2010-09-05T18:00:05Z

66.92.11.32:

[[Image:Ola.png|right]]
Link: http://code.google.com/p/linux-lighting/ 
{{Features|free=yes|tx=yes|rx=yes|linux=yes|osx=yes|http=yes|rdm=yes}}
[[Image:Llad_home.png|300px|right]]

The Open Lighting Architecture (OLA) is an open source framework which provides applications with a mechanism to send and receive [[DMX512]] & [[RDM]] commands using hardware devices and DMX over IP protocols. It enables [[:Category:Controllers | software controllers]] to communicate with hardware either via Ethernet or over traditional DMX512 networks.

OLA can also convert DMX512 data sent using DMX over IP protocols from one format to another, allowing devices from different manufacturers to interact with one another. For example a [[Strand_Lighting|Strand]] Lighting Console using ShowNet can send DMX512 to an [[Enttec]] [[DmxEtherGate MKII|EtherGate]]). When combined with a physical DMX interface such as the [[DMX USB Pro]], OLA can send and receive data from wired DMX512 networks.

OLA runs on both Mac OS X and Linux on a number of architectures. A port to Windows is feasible if someone wants to add the necessary platform-dependent code.

Contribute: Looking to help? Visit the [[OLA Contributors]] page. The page also lists people and companies who have supported OLA. Please support them in return!

Bugs: Check the [http://code.google.com/p/linux-lighting/issues/list bug tracker]

Questions: See the [http://groups.google.com/group/open-lighting mailing list]

Supported Protocols:

{| border=1 cellspacing="0"
! '''Protocol'''!! Linux !! '''Mac OS X'''
|-
|| [[:Category:ArtNet|ArtNet]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]] || [[Image:Green-tick.png|center]] [[Image:Rdm.gif|center]]
|-
|| [[E1.31]] / [[ACN]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ESP Net|ESP Net]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Pathport|Pathport]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Sandnet|Sandnet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ShowNet|ShowNet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|}

Supported Devices:

{| border=1 cellspacing="0"
! '''Device'''!! Linux !! '''Mac OS X'''
|-
|| [[Anyma uDMX]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[Arduino RGB Mixer]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[DMX 4 Linux]] || [[Image:Trans.gif|center]] ||
|-
|| [[DMX USB Pro]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]]
|-
|| [[DMX-TRI]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[DMXking USB DMX512-A]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]] || [[Image:Trans.gif|center]] [[Image:Recv.gif|center]]
|-
|| [[Open DMX USB]] || [[Image:Trans.gif|center]] ||
|-
|| [[Packetheads USB_DMX Dongle]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[RDM-TRI]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]] || [[Image:Trans.gif|center]] [[Image:Rdm.gif|center]]
|-
|| [[StageProfi]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]] (Ethernet version only)
|-
|| [http://machosehead.wordpress.com/2010/06/12/udmx_asp/ uDMX_asp] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[USBDMX2]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|-
|| [[Velleman K8062]] || [[Image:Trans.gif|center]] || [[Image:Trans.gif|center]]
|}

Getting Started

Start here if you've never used OLA before and read these in order.
* [[Download OLA]]
* [[OLA on OS X]] or [[OLA on Linux]] - How to install OLA.
* [[Using OLA]] - A basic introduction
* [[OLA Command Line Tools]] - Documentation for the tools in ola-examples
* [[OLA Device Specific Configuration]]
* [[OLA Tips & Tricks]]
* [[RDM with OLA]]

Tutorials
* [[OlaOutput Max External]] - Setup OlaOutput on Mac OS X to send DMX messages from Max/MSP/Jitter
* [[OLAGuruPlug]] - Running OLA on a [http://www.globalscaletechnologies.com/c-4-guruplugs.aspx GuruPlug]
* [[OlaLED]] - control RGB LED via http

Advanced Topics:
* [[OLA Merging Algorithms]]
* [[OLA DiffServ support]] (QOS settings)

Developer Documentation:
* [[OLA developer info]] - about the source code and structure
* [[OLA Client API]] - the C++ API
* [[OLA Python API]] - easy DMX programming
* [[Build OLA Mac Packages]] - notes for building the .dmg images
* [[Building OLA for Windows]] - Notes on Windows support (in progress)
* [[Using OLA with Xcode]] - on a Mac, in Objective-C++
* [[Port Throttling]]
* [[OLA Performance Stats]]

Tutorials, these refer to the previous release but parts of them are still relevant.
* [[LLA Sandnet Tutorial]] - Setup Horizon using Sandnet and LLA
* [[LLA and Q Light Controller Ubuntu Tutorial]] - Setup LLA on Ubuntu/Debian-type distro with QLC
* [[LLA and Q Light Controller OSX Tutorial]] - Setup LLA on Mac OS X with QLC

Deprecated Documentation
* [[OLA 0.3]] - Release Notes

[[Category:ArtNet]]
[[Category:ESP Net]]
[[Category:E1.31]]
[[Category:Sandnet]]
[[Category:ShowNet]]
[[Category:Utilities]]
[[Category:Pathport]]

OLA on Linux

2010-08-14T23:42:18Z

66.92.11.32:

This describes how to get [[OLA]] working on a Linux system either from the git repo or by using a [http://code.google.com/p/linux-lighting/downloads/list released tarball].

=Checkout or Download an Archive=

Either download a tarball from the releases page, or check out the git repo with the following command:

git clone http://www.nomis52.net/git/lla

If you don't have '''git''' yet, you'll need to install it with your distro's package manager.

=Install libraries=

You need a couple of libraries installed for everything to work correctly. Some of these are available as packages in distros but others need to be downloaded and built manually.

First up you'll need the following:
* cppunit
* uuid or ossp uuid
* pkg-config
* curses

Debian/Ubuntu users can install them with apt:

apt-get install libcppunit-dev libcppunit-1.12-1 uuid-dev pkg-config libncurses5-dev

If you're building from git you'll also need the following:

* libtool
* automake
* autoconf

apt-get install libtool autoconf automake

Next, you need '''Protocol Buffers''' [http://code.google.com/p/protobuf/ http://code.google.com/p/protobuf/] version 2.1.0 or above from Google (BSD license). Most likely, you'll need to download and build them yourself.

Debian (and Ubuntu) users can, in some cases, use the following packages (not yet in stable):
libprotobuf2 (libprotobuf3), libprotobuf-dev, protobuf-compiler

Finally, if you want to use the built in webserver, you'll need '''microhttpd''' and '''ctemplate'''. Note: you'll need version >= 0.4.0 of microhttpd else you will get errors:

* [ftp://ftp.gnu.org/gnu/libmicrohttpd/ ftp://ftp.gnu.org/gnu/libmicrohttpd/]
* [http://code.google.com/p/google-ctemplate/ http://code.google.com/p/google-ctemplate/]

Once everything is installed, run ldconfig as root to pick up the new libraries

sudo ldconfig

=Configure=

If you checked out the sources from git, you'll need to run

autoreconf -i

After that run

./configure

=Building & Testing=

Build
make

If you get an error like the following:

/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/software/protobuf-cpp/2.0.3_0/opt/local/include/ -g -O2 -c -o ltdl.lo ltdl.c
./libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 464: CDPATH: command not found
/Users/simonn/lighting/lla/libltdl/libtool: line 1142: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.

Your system uses a different version of libtool. Run:

libtoolize --ltdl -c -f

and then start from the autoreconf step again.

Run the tests
make check

And install OLA
sudo make install
sudo ldconfig

=Install ola-examples=

The [[OLA Command Line Tools]] come separately. Again either download a tarball or checkout from the git repo:

git clone http://www.nomis52.net/git/lla-examples

The steps are similar to building the main package.

autoreconf -i # if you used the git repo
./configure
make
sudo make install

Note in order for ola_dmxmonitor and ola_dmxconsole to build you *must* have curses installed.

Template:News

2010-08-08T02:56:27Z

66.92.11.32:

<div style="float:right; margin:8px; width:50%; border:1px solid #0000ff">
{| width="100%" cellpadding="4" cellspacing="0"
|-
| bgcolor="#A7C1F2" align="center" | '''Lighting News'''
|-
| {{NewsHeading}} '''OLA 0.8.0 released, now with RDM''' 7/8/10
|-
| [[OLA]] 0.8.0 is the first release to support [[RDM]]. The instructions at [[RDM with OLA]] explain how to get started with RDM, even if you don't own any RDM devices.
|-
| {{NewsHeading}} '''OLA now running on the GuruPlug''' 21/5/10
|-
| [[OLA]] 0.7.4 has been released, and ARM packages for the GuruPlug are now [[OLAGuruPlug|available]]. OLA now supports 9 USB to DMX devices.
|-
| {{NewsHeading}} '''OLA for Max/MSP Released''' 13/4/10
|-
| [http://code.google.com/p/olaoutput/ OlaOutput] allows [http://cycling74.com/products/maxmspjitter/ Max] to communicate with [[OLA]]. See the [[OlaOutput Max External]] tutorial on how to set this up.
|-
| {{NewsHeading}} '''Arduino RGB USB Device''' 7/2/10
|-
| The [[Arduino RGB Mixer]] is a simple & inexpensive way to control RGB LED strips using USB.
|-
| {{NewsHeading}} '''Open Lighting Architecture 0.5.0 Released''' 21/11/09
|-
| [[OLA]] 0.5.0 has been released. It now supports SandNet and automatic USB Pro detection.
|-
| {{NewsHeading}} '''Open Lighting Architecture 0.4.0 Released''' 18/10/09
|-
| [[OLA]] 0.4.0 now supports Streaming DMX over ACN known as [[E1.31]].
|-
|}
</div>

RDM with OLA

2010-08-08T02:50:16Z

66.92.11.32:

[[RDM]] devices can be configured through the web interface (only partially complete) or from the command line. Even if you don't have any RDM devices you can still experiment using the fake RDM device created by the Dummy Plugin.

To follow these examples, patch the Dummy Port to universe 1.

== Device Discovery ==

Each RDM device has a unique ID (UID) made up of a two byte manufacturer ID and a four byte device ID. The ''ola_rdm_discovery'' tool displays the UIDs found for each universe.

<pre>
$ ola_rdm_discover -u 1
7a70:ffffff00
</pre>

A single device should be found with a manufacturer ID of 7a70 (Open Lighting) and a device ID of ffffff00 (the dummy device).

Passing the -f option will force the discovery algorithm to be run for the particular universe. This won't produce any output unless an error occurs.

<pre>
$ ola_rdm_discover -u 1 -f
</pre>

== Device Configuration ==

Now that a device has been found, we can query it to find the parameters it supports. Each parameter is assigned a two byte identifier known as a PID. The ''ola_rdm_get'' and ''ola_rdm_set'' commands are used to read / write the values of parameters. The first thing to do is to view a list of all known parameters:

<pre>
$ ola_rdm_get --list_pids
boot_software_version_id
boot_software_version_label
capture_preset
clear_status_id
comms_status
default_slot_value
device_hours
device_info
...
</pre>

This doesn't query the RDM device at all, it simply lists out the names of standard parameters. To see which particular parameters a device supports use:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 supported_parameters
Supported Parameters
0x50 (supported_parameters)
0x60 (device_info)
0x80 (device_model_description)
0x81 (manufacturer_label)
0x82 (device_label)
0xc0 (software_version_label)
0xf0 (dmx_start_address)
</pre>

One of the most useful parameters is device_info:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 device_info
Device Info
RDM Protocol Version: 1.0
Device Model: 0x1
Product Category: other
Software Version: 0x1
DMX Footprint: 10
DMX Personality: 1 / 1
DMX Start Address: 1
# of Subdevices: 0
Sensor Count: 0
</pre>

Here we see some general information about the device including the DMX start address and the # of DMX channels used (DMX Footprint). We can also get the DMX start address by using the dmx_start_address parameter directly:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 dmx_start_address
DMX Start Address: 1
</pre>

To set the start address, the ''ola_rdm_set'' program is used:

<pre>
$ ola_rdm_set --universe 1 --uid 7a70:ffffff00 dmx_start_address 10
</pre>

No output is displayed unless the request failed. Now we can check that the set worked:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 dmx_start_address
DMX Start Address: 10
</pre>

Finally, the full list of options for ''ola_rdm_get'' and ''ola_rdm_set'' can be found by running with --help:

<pre>
-d, --sub_device <device> target a particular sub device (default is 0)
-h, --help display this help message and exit.
-l, --list_pids display a list of pids
-u, --universe <universe> universe number.
--uid <uid> the UID of the device to control.
</pre>

== RDM With ArtNet ==

If you have a copy of DMXWorkshop, you can experiment with RDM over ArtNet by patching an ArtNet Input Port to the same universe as the Dummy Plugin. You can then discover the Dummy Device using DMXWorkshop and configure it's start address over the LAN.

== Useful Tricks ==

If you're using bash, it's worthwhile to set up tab completion of PIDs:

<pre>
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_get
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_set
</pre>

RDM with OLA

2010-08-08T02:47:18Z

66.92.11.32:

[[RDM]] devices can be configured through the web interface (only partially complete) or from the command line. Even if you don't have any RDM devices you can still experiment using the fake RDM device created by the Dummy Plugin.

To follow these examples, patch the Dummy Port to universe 1.

== Device Discovery ==

Each RDM device has a unique ID (UID) made up of a two byte manufacturer ID and a four byte device ID. The ''ola_rdm_discovery'' tool displays the UIDs found for each universe.

<pre>
$ ola_rdm_discover -u 1
7a70:ffffff00
</pre>

A single device should be found with a manufacturer ID of 7a70 (Open Lighting) and a device ID of ffffff00 (the dummy device).

Passing the -f option will force the discovery algorithm to be run for the particular universe. This won't produce any output unless an error occurs.

<pre>
$ ola_rdm_discover -u 1 -f
</pre>

== Device Configuration ==

Now that a device has been found, we can query it to find the parameters it supports. Each parameter is assigned a two byte identifier known as a PID. The ''ola_rdm_get'' and ''ola_rdm_set'' commands are used to read / write the values of parameters. The first thing to do is to view a list of all known parameters:

<pre>
$ ola_rdm_get --list_pids
boot_software_version_id
boot_software_version_label
capture_preset
clear_status_id
comms_status
default_slot_value
device_hours
device_info
...
</pre>

This doesn't query the RDM device at all, it simply lists out the names of standard parameters. To see which particular parameters a device supports use:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 supported_parameters
Supported Parameters
0x50 (supported_parameters)
0x60 (device_info)
0x80 (device_model_description)
0x81 (manufacturer_label)
0x82 (device_label)
0xc0 (software_version_label)
0xf0 (dmx_start_address)
</pre>

One of the most useful parameters is device_info:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 device_info
Device Info
RDM Protocol Version: 1.0
Device Model: 0x1
Product Category: other
Software Version: 0x1
DMX Footprint: 10
DMX Personality: 1 / 1
DMX Start Address: 1
# of Subdevices: 0
Sensor Count: 0
</pre>

Here we see some general information about the device including the DMX start address and the # of DMX channels used (DMX Footprint). We can also get the DMX start address by using the dmx_start_address parameter directly:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 dmx_start_address
DMX Start Address: 1
</pre>

To set the start address, the ''ola_rdm_set'' program is used:

<pre>
$ ola_rdm_set --universe 1 --uid 7a70:ffffff00 dmx_start_address 10
</pre>

No output is displayed unless the request failed. Now we can check that the set worked:

<pre>
$ ola_rdm_get --universe 1 --uid 7a70:ffffff00 dmx_start_address
DMX Start Address: 10
</pre>

Finally, the full list of options for ''ola_rdm_get'' and ''ola_rdm_set'' can be found by running with --help:

<pre>
-d, --sub_device <device> target a particular sub device (default is 0)
-h, --help display this help message and exit.
-l, --list_pids display a list of pids
-u, --universe <universe> universe number.
--uid <uid> the UID of the device to control.
</pre>

== Useful Tricks ==

If you're using bash, it's worthwhile to set up tab completion of PIDs:

<pre>
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_get
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_set
</pre>

OlaLED

2010-07-27T05:16:09Z

66.92.11.32:

=== Introduction ===

In this topic, you will learn how to install a python script to permit to control a LED / RGB system via webcontrol (or other python script)

==== prerequisites ====

You need to have a fully functional ola system

==== Install script ====

create a directory to store all these new functionnality

mkdir -p /srv/dmx/

write a this new python script in this folder :

nano /srv/dmx/server.py

<pre>
#!/usr/bin/python

import SocketServer
import threading
import time
from ola_send_dmx import *

my_thread = 0
my_command = 'start'

actual_program = 'color' ## program wanted
param1 = 'red' ## first param
intensity = 100 ## current intensity
actual_fixed_color = 0 ## if fixed color choice, put args here to remember (if having to change intensity)
R_before = 0 # current color state
G_before = 0
B_before = 0

pitch = 1

class MyTCPHandler(SocketServer.BaseRequestHandler):
"""
The RequestHandler class for our server.

It is instantiated once per connection to the server, and must
override the handle() method to implement communication to the
client.
"""

def handle(self):
# self.request is the TCP socket connected to the client
global my_thread

self.data = self.request.recv(1024).strip()

# was a test
#if self.data == 'reset' :
# global my_command
# my_command = 'reset'
#else :

command = self.data.split()
command = command[0]

if command == 'intensity': # We separe intensity because should lauch in parallel
another_thread = Thread_dmx(self.data) # thread named different for able controlling mythread
another_thread.start()
print "thread intensite lance"
# just send back the same data, but upper-cased
self.request.send(self.data.upper())
else:
if my_thread != 0 : #if thread is already launched and is not about intensity
try:
my_thread.stop() #stop thread
my_thread.join() #stop program to be sure thread is stopped
except NameError:
print "An error occured when trying to stop previous thread."
print "launching thread " + self.data
my_thread = Thread_dmx(self.data)
my_thread.start()
# just send back the same data to the client, but upper-cased
self.request.send(self.data.upper())

class Thread_dmx(threading.Thread):

def __init__(self, nom = ''):
threading.Thread.__init__(self)
self.nom = nom
self.Terminated = False
def run(self):
global actual_program
global intensity
global fixed_color
## separate command and arguments ##
words = self.nom.split()
if len(words) == 0:
print('Error: empty request\n')
return

command = words[0]
args = words[1:]

methodname = 'do_' + command

## relauch sending DMX for fixed color, if intensity changed
if command=='intensity':

intensity = abs(int(args[0]))
if intensity > 100:
return
if actual_program == 'fade':
method = getattr(self, 'do_fade')
method(*fixed_color)

else:

actual_program = command

## take care of inexistent function
if not hasattr(self, methodname):
print('Error: ',command,' is not a valid command')
return

## save color if fixed color
if command=='fade':
fixed_color = args

## launch corresponding function
method = getattr(self, methodname)
method(*args)

## Stop the thread if called
def stop(self):
self.Terminated = True

## Go to specified DMX adresses from previous adresses in fade
def do_fade(self,R_after,G_after,B_after,speed):

global R_before
global G_before
global B_before
global intensity

R_after=int(round((int(R_after)*intensity)/100))
G_after=int(round((int(G_after)*intensity)/100))
B_after=int(round((int(B_after)*intensity)/100))

if(R_after==R_before and G_after==G_before and B_after==B_before):
print('Etat deja atteint')
return

speed=float(speed)

actual_intensity = intensity
time_to_sleep=(speed/max(abs(R_before-R_after),abs(G_before-G_after),abs(B_before-B_after)))

# count to know wich pitch to apply (processor free)

speed_reference=float(0.01)
print(time_to_sleep)
pitch=int(speed_reference/time_to_sleep)
print(pitch)
if pitch == 0:
pitch = int(1)
print(pitch)

## while ending color are not reached or no order for stopping, increment data
while (R_before-R_after!=0 or G_before-G_after!=0 or B_before-B_after!=0) and (not self.Terminated) :
## If intensity was changed, take care of this
if actual_intensity != intensity:
R_after=int(round((int(R_after)*intensity)/100))
G_after=int(round((int(G_after)*intensity)/100))
B_after=int(round((int(B_after)*intensity)/100))
actual_intensity = intensity

R_diff=R_before-R_after
G_diff=G_before-G_after
B_diff=B_before-B_after

if R_diff <= -pitch :
R_before += pitch
elif R_diff >= pitch :
R_before-= pitch
else :
R_before = R_after
if G_diff <= -pitch :
G_before += pitch
elif G_diff >= pitch :
G_before -= pitch
else :
G_before=G_after
if B_diff <= -pitch :
B_before += pitch
elif B_diff >=pitch :
B_before -= pitch
else :
B_before=B_after

#print('AFTER : ',R_after,G_after,B_after)
print('values =',R_before,G_before,B_before)
print('sleep =',time_to_sleep*pitch)
print('pitch =',pitch)
dmx_send(R_before,G_before,B_before)
time.sleep(time_to_sleep*pitch)

## make a chase from red to blue, indefinitely
def do_chase(self,speed):
intensity = 255
speed = float(speed)
while not self.Terminated :
self.do_fade(intensity,0,intensity,speed)
print("7")
print("1")
self.do_fade(intensity,0,0,speed)
print("2")
self.do_fade(intensity,intensity,0,speed)
print("3")
self.do_fade(0,intensity,0,speed)
print("4")
self.do_fade(0,intensity,intensity,speed)
print("5")
self.do_fade(0,0,intensity,speed)
print("6")
#self.do_fade(intensity,0,intensity,speed)
#print("7")

if __name__ == "__main__":
HOST, PORT = "localhost", 9999

# Create the server, binding to localhost on port 9999
server = SocketServer.TCPServer((HOST, PORT), MyTCPHandler)

# Activate the server; this will keep running until you
# interrupt the program with Ctrl-C
server.serve_forever()

</pre>

copy client_wrapper.py in this folder :

cp /usr/src/ola-0.7.4/python/examples/client_wrapper.py /srv/dmx/

create a new python file function : ola_send_dmx.py

nano /srv/dmx/ola_send_dmx.py

RDM with OLA

2010-07-20T05:18:39Z

66.92.11.32:

RDM devices can be configured through the web interface (only partially complete) or from the command line.

== Device Discovery ==

The ''ola_rdm_discovery'' tool displays the UIDs found for each universe.
<pre>
$ ola_rdm_discover -u 1
414c:010014b3
</pre>

Passing the -f options will force the discovery algorithm to be run for the particular universe. This won't produce any output unless and error occurs.

<pre>
$ ola_rdm_discover -u 1 -f
</pre>

== Device Configuration ==

The ''ola_rdm_get'' and ''ola_rdm_get'' commands allow attributes of the devices to be controlled. The first thing to do is to view a list of all known attributes:

<pre>
$ ola_rdm_get --list_pids
boot_software_version_id
boot_software_version_label
capture_preset
clear_status_id
comms_status
default_slot_value
device_hours
device_info
...
</pre>

To fetch the value of a PID from a device use:

<pre>
$ ola_rdm_get --universe 1 --uid 414c:010014b3 device_info
</pre>

Changing the value works in a similar way:

<pre>
$ ola_rdm_set --universe 1 --uid 414c:010014b3 comms_status # clear the communication counters
</pre>

The full list of options can be found by running with --help:

<pre>
-d, --sub_device <device> target a particular sub device (default is 0)
-h, --help display this help message and exit.
-l, --list_pids display a list of pids
-u, --universe <universe> universe number.
--uid <uid> the UID of the device to control.
</pre>

== Useful Tricks ==

If you're using bash, it's worthwhile to set up tab completion of PIDs:

<pre>
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_get
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_set
</pre>

RDM with OLA

2010-07-20T05:18:10Z

66.92.11.32:

RDM devices can be configured through the web interface (only partially complete) or from the command line.

== Device Discovery ==

The ''ola_rdm_discovery'' tool displays the UIDs found for each universe.
<pre>
$ ola_rdm_discover -u 1
414c:010014b3
</pre>

Passing the -f options will force the discovery algorithm to be for the particular universe. This won't produce any output unless and error occurs.

<pre>
$ ola_rdm_discover -u 1 -f
</pre>

== Device Configuration ==

The ''ola_rdm_get'' and ''ola_rdm_get'' commands allow attributes of the devices to be controlled. The first thing to do is to view a list of all known attributes:

<pre>
$ ola_rdm_get --list_pids
boot_software_version_id
boot_software_version_label
capture_preset
clear_status_id
comms_status
default_slot_value
device_hours
device_info
...
</pre>

To fetch the value of a PID from a device use:

<pre>
$ ola_rdm_get --universe 1 --uid 414c:010014b3 device_info
</pre>

Changing the value works in a similar way:

<pre>
$ ola_rdm_set --universe 1 --uid 414c:010014b3 comms_status # clear the communication counters
</pre>

The full list of options can be found by running with --help:

<pre>
-d, --sub_device <device> target a particular sub device (default is 0)
-h, --help display this help message and exit.
-l, --list_pids display a list of pids
-u, --universe <universe> universe number.
--uid <uid> the UID of the device to control.
</pre>

== Useful Tricks ==

If you're using bash, it's worthwhile to set up tab completion of PIDs:

<pre>
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_get
$ complete -W "$(ola_rdm_get -l | xargs)" ola_rdm_set
</pre>

RDM with OLA

2010-07-12T03:31:49Z

66.92.11.32: Created page with 'RDM devices can be configured through the web interface (only partially complete) or from the command line. == Device Discovery == The ''ola_rdm_discovery'' tool displays the …'

RDM devices can be configured through the web interface (only partially complete) or from the command line.

== Device Discovery ==

The ''ola_rdm_discovery'' tool displays the UIDs found for each universe.
<pre>
$ ola_rdm_discover -u 1
414c:010014b3
</pre>

Passing the -f options will force the discovery algorithm to be for the particular universe. This won't produce any output unless and error occurs.

<pre>
$ ola_rdm_discover -u 1 -f
</pre>

== Device Configuration ==

The ''ola_rdm_get'' and ''ola_rdm_get'' commands allow attributes of the devices to be controlled. The first thing to do is to view a list of all known attributes:

<pre>
$ ola_rdm_get --list_pids
boot_software_version_id
boot_software_version_label
capture_preset
clear_status_id
comms_status
default_slot_value
device_hours
device_info
...
</pre>

To fetch the value of a PID from a device use:

<pre>
$ ola_rdm_get --universe 1 --uid 414c:010014b3 device_info
</pre>

Changing the value works in a similar way:

<pre>
$ ola_rdm_set --universe 1 --uid 414c:010014b3 comms_status # clear the communication counters
</pre>

The full list of options can be found by running with --help:

<pre>
-d, --sub_device <device> target a particular sub device (default is 0)
-h, --help display this help message and exit.
-l, --list_pids display a list of pids
-u, --universe <universe> universe number.
--uid <uid> the UID of the device to control.
</pre>

Open Lighting Architecture

2010-06-13T17:31:56Z

66.92.11.32:

[[Image:Ola.png|right]]
Link: http://code.google.com/p/linux-lighting/ 
{{Features|free=yes|tx=yes|rx=yes|linux=yes|osx=yes|http=yes}}

OLA (Open Lighting Architecture) is an open source framework which provides applications with a mechanism to send and receive [[DMX512]] using hardware devices and DMX over IP protocols. It enables [[:Category:Controllers | software controllers]] to communicate with DMX hardware either via Ethernet or over traditional DMX512 networks.

[[Image:Llad_home.png|right]]
OLA can also convert DMX data sent using DMX over IP protocols from one format to another, allowing devices from different manufacturers to interact with each other. For example a [[Strand_Lighting|Strand]] Lighting Console using ShowNet can send DMX to an [[Enttec]] [[DmxEtherGate MKII|EtherGate]]). When combined with a physical DMX interface such as the [[DMX USB Pro]], OLA can send and receive data from traditional wired DMX networks.

OLA can run on Linux and on Mac OS X. A port to Windows is feasible if someone wants to add the necessary platform-dependent code.

Contribute: Looking to help? Visit the [[OLA Contributors]] page. The page also lists people and companies who have supported OLA. Please support them in return!

Bugs: Check the bug tracker at http://code.google.com/p/linux-lighting/issues/list

Questions: See the news group at http://groups.google.com/group/open-lighting

Supported Protocols:

{| border=1 cellspacing="0"
! '''Protocol'''!! Linux !! '''Mac OS X'''
|-
|| [[:Category:ArtNet|ArtNet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[E1.31]] / [[ACN]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ESP Net|ESP Net]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Pathport|Pathport]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:Sandnet|Sandnet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[:Category:ShowNet|ShowNet]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|}

Supported Devices:

{| border=1 cellspacing="0"
! '''Device'''!! Linux !! '''Mac OS X'''
|-
|| [[Anyma uDMX]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[Arduino RGB Mixer]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[DMX 4 Linux]] || [[Image:Green-tick.png|center]] ||
|-
|| [[DMX USB Pro]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[DMX-TRI]] || [[Image:Green-tick.png|center]] Output only || [[Image:Green-tick.png|center]] Output only
|-
|| [[DMXking USB DMX512-A]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[Open DMX USB]] || [[Image:Green-tick.png|center]] ||
|-
|| [[Packetheads USB_DMX Dongle]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[RDM-TRI]] || [[Image:Green-tick.png|center]] Output only || [[Image:Green-tick.png|center]] Output only
|-
|| [[StageProfi]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]] Ethernet version only
|-
|| [[USBDMX2]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|-
|| [[Velleman K8062]] || [[Image:Green-tick.png|center]] || [[Image:Green-tick.png|center]]
|}

Getting Started

Start here if you've never used OLA before and read these in order.
* [[Download OLA]]
* [[OLA on OS X]] or [[OLA on Linux]] - How to install OLA.
* [[Using OLA]] - A basic introduction
* [[OLA Command Line Tools]] - Documentation for the tools in ola-examples
* [[OLA Device Specific Configuration]]
* [[OLA Tips & Tricks]]

Tutorials
* [[OlaOutput Max External]] - Setup OlaOutput on Mac OS X to send DMX messages from Max/MSP/Jitter
* [[OLAGuruPlug]] - Running OLA on a [http://www.globalscaletechnologies.com/c-4-guruplugs.aspx GuruPlug]

Advanced Topics:
* [[OLA Merging Algorithms]]
* [[OLA DiffServ support]] (QOS settings)

Developer Documentation:
* [[OLA developer info]] - about the source code and structure
* [[OLA Client API]] - the C++ API
* [[OLA Python API]] - easy DMX programming
* [[Build OLA Mac Packages]] - notes for building the .dmg images
* [[Building OLA for Windows]] - Notes on Windows support (in progress)
* [[Using OLA with Xcode]] - on a Mac, in Objective-C++
* [[Port Throttling]]
* [[OLA Performance Stats]]

Tutorials, these refer to the previous release but parts of them are still relevant.
* [[LLA Sandnet Tutorial]] - Setup Horizon using Sandnet and LLA
* [[LLA and Q Light Controller Ubuntu Tutorial]] - Setup LLA on Ubuntu/Debian-type distro with QLC
* [[LLA and Q Light Controller OSX Tutorial]] - Setup LLA on Mac OS X with QLC

Deprecated Documentation
* [[OLA 0.3]] - Release Notes

OLA can also run on a wireless access point. [http://nomis52.net/?section=projects&sect2=artnet&page=node]

[[Category:ArtNet]]
[[Category:ESP Net]]
[[Category:E1.31]]
[[Category:Sandnet]]
[[Category:ShowNet]]
[[Category:Utilities]]
[[Category:Pathport]]

OLAGuruPlug

2010-05-17T05:34:25Z

66.92.11.32: /* Installation */

This describes how to setup [[OLA]] on a [http://www.globalscaletechnologies.com/c-4-guruplugs.aspx GuruPlug]. These devices make excellent low cost [[DMX512]] nodes.

== Prerequisites ==

This assumes you have a shell on the guru plug and that it can contact the internet to download the packages. Note that the default guru plug is insecure and comes with a lot of extras (samba, myqls, lighthttpd etc.) that aren't required. Fixing this is outside the scope of this tutorial.

== Installation ==

Add the following line to /etc/apt/sources.list:

deb http://www.nomis52.net/data/ola-arm ./

Then apt-get install ola:

$ apt-get install olad

== Setup ==

Add a user ''ola'' for the daemon to run as:

$ adduser ola

If you intend to use USB devices, you need to add this user to the plugdev & dialout groups. Modify the lines in /etc/group:

dialout:x:20:ola
plugdev:x:46:ola

Finally add any udev rules that you'll need. See [[OLA Device Specific Configuration]]

== Running ==

Change to the ''ola'' user and the start the daemon:

$ su ola
$ olad -l 3

OLAGuruPlug

2010-05-17T05:33:05Z

66.92.11.32: /* Installation */

This describes how to setup [[OLA]] on a [http://www.globalscaletechnologies.com/c-4-guruplugs.aspx GuruPlug]. These devices make excellent low cost [[DMX512]] nodes.

== Prerequisites ==

This assumes you have a shell on the guru plug and that it can contact the internet to download the packages. Note that the default guru plug is insecure and comes with a lot of extras (samba, myqls, lighthttpd etc.) that aren't required. Fixing this is outside the scope of this tutorial.

== Installation ==

Add the following line to /etc/apt/sources.list:

deb http://www.nomis52.net/data/ola ./

Then apt-get install ola:

$ apt-get install olad

== Setup ==

Add a user ''ola'' for the daemon to run as:

$ adduser ola

If you intend to use USB devices, you need to add this user to the plugdev & dialout groups. Modify the lines in /etc/group:

dialout:x:20:ola
plugdev:x:46:ola

Finally add any udev rules that you'll need. See [[OLA Device Specific Configuration]]

== Running ==

Change to the ''ola'' user and the start the daemon:

$ su ola
$ olad -l 3

OLA Device Specific Configuration

2010-05-17T03:57:34Z

66.92.11.32: /* Linux */

==Anyma ==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the anyma dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"
</pre>

==StageProfi==

This comes in two flavors, a USB model and an Ethernet/IP model.

device = /dev/ttyUSB0
device = 192.168.1.250

==USB Pro==

===Mac===

Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm

After a restart run:

ls /dev/cu.usbserial-*

Make sure your ~/.ola/ola-usbpro.conf file matches the path above:

device_dir = /dev
device_prefix = ttyUSB
device_prefix = cu.usbserial-

i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*

OLA also comes with a tool to update the firmware on a USB Pro:

./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file>

==USBDMX2==

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the usbdmx2 dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"
</pre>

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

===Mac===

There is an issue where the device isn't detected correctly the first time. You may need to restart OLA once the DMX Transmit led comes on.

==Velleman VM166 / K8062==

===Mac===

If you're installed from source you'll need the codeless KEXT which is available [http://code.google.com/p/linux-lighting/downloads/detail?name=libdmxusbshield.dmg| here]. If you installed OLA from the mac binary package this is already included.

===Linux===

You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules

<pre>
# udev rules file for the velleman dmx device
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"
</pre>

Then make sure the user olad runs as is a member of plugdev.

OLA Client API

2010-05-02T20:04:56Z

66.92.11.32: /* Example I: Sending an DMX update using the StreamingClient */

OLA provides a client library which allows other applications to send/receive DMX as well as control the OLA server. When writing a client application you have to choose between the ''StreamingClient'' and the full fledged ''OlaClient'' (provided by the ''SimpleClient'' helper class). The ''StreamingClient'' only allows a client to send DMX data to the OLA server, while the full client allows DMX data to be received and control messages to be sent to the server to change things like port patchings etc.

==Example I: Sending an DMX update using the StreamingClient==

The simplest interface to OLA is the StreamingClient which just allows an application to send DMX data to the OLA server

#include <stdlib.h>
#include <ola/Closure.h>
#include <ola/DmxBuffer.h>
#include <ola/Logging.h>
#include <ola/StreamingClient.h>

#include <iostream>

using std::cout;
using std::endl;

/*
* This is called if the remove end closes the connection
*/
int SocketClosed() {
cout << "The OLA server closed the connection";
return 0;
}

int main(int argc, char *argv[]) {
unsigned int universe = 1; // universe to use for sending data
unsigned int i;

// turn on OLA logging
ola::InitLogging(ola::OLA_LOG_WARN, ola::OLA_LOG_STDERR);

// Create a new DmxBuffer to hold the data
ola::DmxBuffer buffer;
// set all channels to 0
buffer.Blackout();

// create a new client and set the Error Closure
ola::StreamingClient ola_client;
ola_client.SetErrorClosure(ola::NewClosure(&SocketClosed));

// Setup the client, this connects to the server
if (!ola_client.Setup()) {
cout << "Setup failed" << endl;
exit(1);
}

// send the data to the ola server
for (i = 0; i < 100; i++) {
buffer.SetChannel(0, i);
if (!ola_client.SendDmx(universe, buffer)) {
cout << "Send DMX failed" << endl;
exit(1);
}
usleep(20000); // sleep for 20ms between updates
}

// close the connection
ola_client.Stop();
return 0;
}

Note there isn't any need to poll for updates from the server in this case because the communication is all one way (client -> server). This also means that you can't receive DMX data or modify state on the server (like port patching and device parameters) when using the StreamingClient.

Also take note of the call to usleep(). Without this you're likely to fill the network socket buffer at which point the client code will detect an error and close the socket (you may need to increase the number of loop iterations to trigger this).

==Example II: Sending an DMX update using the SimpleClient==

This example simply connects to the OLA Server and sends one DMX update just like the example above but using the SimpleClient. It's about as basic as you can get because it requires no callbacks and exits immediately. We use two classes in this example, ''ola::SimpleClient'', and ''ola::OlaClient''.

#include <ola/DmxBuffer.h>
#include <ola/Logging.h>
#include <ola/SimpleClient.h>

int main() {
ola::InitLogging(ola::OLA_LOG_WARN, ola::OLA_LOG_STDERR);
ola::DmxBuffer buffer;
buffer.Blackout();
// some dummy dmx data
buffer.SetChannel(0, 255);

ola::SimpleClient simple_client;
if (!simple_client.Setup())
//setup failed
return -1;

// Get the underlying OlaClient object
ola::OlaClient *client = simple_client.GetClient();

// Send the DMX data
client->SendDmx(1, buffer);
}

The main class used to communicate with the LLA Server is ''OlaClient''. For ease of use, the ''SimpleClient'' class sets up ''OlaClient'' with a connection to an LLA Server running on the localhost:LLA_DEFAULT_PORT. You can call GetClient() on a ''SimpleClient'' instance to get a pointer to the underlying ''OlaClient''.

==Example III: Sending multiple updates==

The previous example only sent a single DMX update before quitting. This next example adds a timeout which sends DMX every 50ms. This introduces a new class ''SelectServer'' which is used for registering timeouts.

#include <ola/DmxBuffer.h>
#include <ola/network/SelectServer.h>
#include <ola/Logging.h>
#include <ola/SimpleClient.h>
#include <ola/Closure.h>

// Maximum value of a dmx channel
static const unsigned int MAX_DMX = 255;
// How often to send updates
static const unsigned int TIMEOUT_MS = 50;

class DmxTimeout {
public:
DmxTimeout(ola::OlaClient *client): m_tick(0),
m_client(client) {
buffer.Blackout();
m_buffer.SetChannel(0, MAX_DMX);
}

// Called on timeout
int SendDmx() {
m_buffer.SetChannel(1, m_tick)
m_buffer.SetChannel(2, MAX_DMX - m_tick)
m_client->SendDmx(1, buffer);
m_tick++;
m_tick %= MAX_DMX + 1;
// we must return 0 else we get canceled
return 0;
}
private:
unsigned int m_tick;
ola::DmxBuffer m_buffer;
ola::OlaClient *m_client;
};

int main() {
ola::InitLogging(ola::OLA_LOG_WARN, ola::OLA_LOG_STDERR);
ola::SimpleClient simple_client;

if (!simple_client.Setup())
return -1;

// Create a timeout and register it
DmxTimeout timeout(simple_client.GetClient());
ola::network::SelectServer ss = simple_client.GetSelectServer();
ss->RegisterTimeout(TIMEOUT_MS,
ola::NewClosure(&timeout, &DmxTimeout::SendDmx),
true); // we want this to repeat

// Start the main loop
ss->Run();
}

In this example we create ''DmxTimeout'' class whose ''SendDmx()'' method is called every time the timer expires.

The other important part here is the ''SelectServer''. As well as the ''RegisterTimeout'' method we've used above, this can also be used to register sockets so we can respond to network activity. The ''Run()'' method starts the main event processing loop which will halt if an error occurs or ''Terminate()'' is called.

==Example IV: Receiving DMX data==

The third example shows how to listen and respond to event from the LLA server.

#include <ola/Logging.h>
#include <ola/SimpleClient.h>

static const unsigned int UNIVERSE = 1;

class OurObserver: public ola::OlaClientObserver {
public:
// Called when new DMX values arrive
void NewDmx(unsigned int universe,
const DmxBuffer &data,
const std::string &error) {
OLA_INFO << "Received " << (int) data.Size() <<
" channels for universe " << (int) universe;
}
};

int main() {
ola::InitLogging(ola::OLA_LOG_INFO, ola::OLA_LOG_STDERR);
ola::SimpleClient simple_client;
OurObserver observer;

if (!simple_client.Setup())
return -1;

ola::OlaClient *client = simple_client.GetClient();
// Set the observer and register our interest in this universe
client->SetObserver(&observer);
client->RegisterUniverse(UNIVERSE, ola::REGISTER);
simple_client.GetSelectServer()->Run();
}

Here we inherit from the ''OlaClientObserver'' class and override the methods we're interested in receiving notification for.

In the main function we set the observer object and register our interest in a universe.

==Example V: More complex client==

The above is all well and good but what if the main application has it's own event processing loop? An example of this is a GTK/Glib application which uses GMainLoop.

On the other hand, what if you're not connecting to the LLA Server over TCP? Sometimes it may be desirable to embed the LLA server within the main application.

Bypassing the SimpleClient and using OlaClient directly addresses both these problems.

#include <ola/OlaClient.h>
#include <ola/select_server/SelectServer.h>
#include <ola/select_server/Socket.h>

using ola::select_server::PipeSocket;

int main() {
// Create the select server
ola::select_server::SelectServer ss;

// Create the pipe socket to talk to the server on
PipeSocket *pipe_socket = new PipeSocket();
if (!pipe_socket->Init())
return -1;

// Remember to add this socket to the SelectServer
ss.AddSocket(pipe_socket);

// Setup the OlaClient
ola::OlaClient client(pipe_socket);
if (!client.Setup())
return -1;

// At this point the client is setup. We then need to setup the LLAServer
// ...

// Once that is done we add the pipe as a new connection
ola_server->NewConnection(m_pipe_socket->OppositeEnd());
}

This example shows how we can create our own instance of a ''ConnectedSocket'' (''PipeSocket'' is a subclass of ''ConnectedSocket'') and pass it to the ''OlaClient'' to use. This code is very similar to what ''SimpleClient'' does under the hood.