https://wiki.openlighting.org/api.php?action=feedcontributions&user=Nomis52&feedformat=atomwiki.openlighting.org - User contributions [en]2024-03-28T19:17:44ZUser contributionsMediaWiki 1.29.1https://wiki.openlighting.org/index.php?title=OLA_LED_Pixels&diff=5900OLA LED Pixels2021-12-25T21:04:03Z<p>Nomis52: </p>
<hr />
<div>{{PageMigrated|url=https://www.openlighting.org/ola/tutorials/ola-led-pixels/}}<br />
[[Image:Lpd8806.jpeg|300px|right]]<br />
<br />
Since March 2013, [[OLA]] contains an [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus SPI] plugin, which allows you to drive strings of LEDs pixels provided your platform has an SPI interface. Using embedded Linux platforms like the [[OLA_Raspberry_Pi | Raspberry Pi]], this allows one to build Pixel strings controllable via any of the [[OLA#Supported_Protocols|supported protocols]] ([[ArtNet]], [[E1.31]], [[OSC]] & more) for less than $100.<br />
<br />
Alternatively if you don't want network control, you can send [[DMX512]] to the LEDs using the Python, C++ or Java client library running on the host itself.<br />
<br />
This page is focused on the Raspberry Pi, but may be applicable to other hardware such as the BeagleBone. If you're using a Raspberry Pi you can save yourself a lot of time by using the pre-built images, see [[OLA_Raspberry_Pi| OLA on the Raspberry Pi]] for details.<br />
<br />
== Host Hardware ==<br />
<br />
The Raspberry Pi contains three SPI interfaces, but only one of these is wired to the 26-pin connector. The interface comes with 3 chip-enable (CE) lines but again only two are connected (pins 24 & 26). With the default mode, pin 24 is pulled low when the /dev/spi0.0 device is used and pin 26 is pulled low when /dev/spi0.1 is used.<br />
<br />
The Pi uses 3.3V logic. You can usually get away with connecting the pins directly to the pixel hardware which uses 5V for testing, but for reliable operation it's best to use a driver circuit to convert the voltage levels from 3.3v to 5v especially if you have a cable run between the Pi and the Pixel string. There is a [https://github.com/hackerspaceshop/RaspberryPI_WS2801_Bridge schematic] available or you can buy a [http://www.hackerspaceshop.com/raspberrypi-ws2801.html kit].<br />
<br />
Here are some timings stats collected from the Pi:<br />
<br />
{| border=1 cellspacing="0"<br />
! SPI Speed !! Number of bytes || time taken for write() !! Time on the wire <br />
|-<br />
|| 1MHz || 75 || 13.5ms || 11.1ms<br />
|-<br />
|| 2MHz || 75 || 8.1ms || 5.6ms<br />
|-<br />
|| 4MHz || 75 || 4.7 ms || 3.0 ms<br />
|-<br />
|| 8MHz || 75 || 3.7ms || 1.4ms<br />
|-<br />
|| 12MHz || 75 || 3.2ms || 0.75 ms<br />
|-<br />
|| 1MHz || 516 || 78.5 ms || 76.15 ms<br />
|-<br />
|| 2MHz || 516 || 40.2 ms || 38.2ms<br />
|-<br />
|| 4MHz || 516 || 21.5 ms || 19.1 ms<br />
|-<br />
|| 8MHz || 516 || 12.2ms || 9.6ms<br />
|-<br />
|| 12MHz || 516 || 7.4ms || 4.83 ms<br />
|-<br />
|}<br />
<br />
It also takes somewhere between 3.6 and 4.6 ms to toggle a GPIO pin using the /sys/class/gpio interface. The importance of these numbers will be clear in a minute. <br />
<br />
<br />
Beyond the Pi, any SPI hardware supported by the Linux kernel should work modulo the timing restrictions. By default OLA looks for devices that match the /dev/spi* .<br />
<br />
== Pixel Hardware ==<br />
<br />
On the pixel side the following is supported:<br />
* LPD8806, e.g. https://www.adafruit.com/products/306. since 0.8.27<br />
* WS2801, e.g. https://www.adafruit.com/products/738, since 0.8.28<br />
<br />
Each of these uses 3 DMX slots per pixel, so you can drive up to 170 pixels from a universe of DMX data.<br />
<br />
== Hardware Setup ==<br />
<br />
The simplest setup is to connect SCLK (pin 23) to the pixel string's clock line and MOSI (pin 19) to the pixel string's DATA line. You'll need a separate power supply for the pixel string, check the pixel specifications but 1A per m is a good rule of thumb. Don't forget to connect the ground on the power supply to a ground pin (e.g. 25) on the Pi.Do not connect the 5V rail of the pixel power supply to the Pi.<br />
<br />
=== Multiplexer ===<br />
<br />
If you want to drive more than one string in parallel you'll need to use a de-multiplexer. For a two-line multiplexer one can use the CE0 and CE1 lines to select the output string. To run more than 2 strings you'll need to use some of the GPIO pins as chip-enables. However these pins are slow (~4ms) which limits the update rate.<br />
<br />
There is a 8 way demultiplexer schematic [https://drive.google.com/file/d/0B7Z8oqKsoX5HWE1qV2hCeDNNOU0/view?usp=sharing&resourcekey=0-8yDZLnlQ-8FlPaSRPqrIgQ here].<br />
<br />
== OLA SPI Plugin ==<br />
<br />
The [[OLA]] SPI plugin is pretty flexible, the primary limitation is how long it takes to write the data out the SPI interface, and this limits the overall refresh rate. Each SPI interface (/dev/spi*) is represented as an OLA Device. Devices can have multiple 'ports' since each port can consume at most one universe of DMX512 data (170 RGB pixels). Each port can be configured (via RDM) with a start address and personality (pixel type). This allows a combination of various strings lengths & pixel hardware types. <br />
<br />
Each SPI device uses a backend to write the SPI data. Right now there are two types backends available: a software backend which merges the SPI data from one or more ports, and a hardware backend which uses the GPIO pins to control a hardware demultiplexer.<br />
<br />
=== Timing ===<br />
<br />
It all comes down to timing. Consider the following example:<br />
<br />
* 170 LPD8806 pixels per string (results in 516 bytes written)<br />
* Two strings using the built in CE lines to drive a hardware demultipliexer. <br />
* SPI speed of 2Mhz<br />
<br />
Using timing table above, we can see this will take 40.2 ms x 2 = 80ms to update all pixels. That means you'll only be able to do 12 updates per second. Most DMX systems run at 40 updates per second so we'll end up dropping updates. <br />
<br />
If we tried to use GPIO pins rather than the CE ones it gets worse. Consider a second example:<br />
<br />
* 32 WS2801 pixels per string (results in 75 bytes written)<br />
* Four strings using two GPIO lines to drive a hardware demultipliexer. <br />
* SPI speed of 2Mhz<br />
<br />
Now each write requires setting GPIO pins. Worse case both pins will need to change which adds 8ms. The write itself takes 8.1 ms, so that's 16.1 ms per string or 64.4 ms to update all strings. That gives you an update rate of 15 updates per second. Still not close to DMX's 40 updates per second.<br />
<br />
== Software Setup ==<br />
You'll need a suitable [[OLA_Device_Specific_Configuration#SPI|udev config]], so that OLA has permission to talk to your SPI port. There is also some Raspberry Pi specific config (enabling a kernel module) on the same page.<br />
<br />
If you're using the GPIO pins to drive an hardware demultiplexer, you'll need to run the following as root prior to starting olad.<br />
<br />
<pre><br />
for pin in 17 21; do<br />
echo $pin > /sys/class/gpio/export;<br />
chmod a+w /sys/class/gpio/gpio${pin}/value;<br />
chmod a+w /sys/class/gpio/gpio${pin}/direction;<br />
done<br />
</pre><br />
<br />
Once you have OLA running it's a matter of patching an SPI Output port to a universe and then patching the desired input port. This can be done from the OLA web UI or by using ola_patch<br />
.<br />
[[Image:Ola-spi-artnet.png| thumb|center |200px|Example of an ArtNet controlled LED String]]<br />
<br />
== Configuration ==<br />
<br />
The type of LED drivers, operating mode and DMX Start Address are configurable via [[RDM]]. Click on the RDM tab and you'll see the options.<br />
<br />
[[Image:Ola-spi-rdm.png| thumb|center |200px|Using RDM to set the hardware type and DMX start address]]<br />
<br />
<br />
The number of LEDs and SPI speed is set using the ola-spi.conf file.<br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-dmx-address = 1<br />
spidev0.0-personality = 1<br />
spidev0.0-pixel-count = 25<br />
spidev0.0-spi-speed = 100000<br />
spidev0.1-dmx-address = 1<br />
spidev0.1-personality = 2<br />
spidev0.1-pixel-count = 25<br />
spidev0.1-spi-speed = 1000000<br />
</pre><br />
<br />
== Example Configs ==<br />
<br />
=== Single Pixel String ===<br />
<br />
For a simple single-string output we can use the software backend and ignore the CE lines. This config is for 25 WS2801 pixels running at 1Mhz on /dev/spi0.0. From the timing information above this should support about 75 updates / second.<br />
<br />
<pre><br />
base_uid = 7a70:00000100 <br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-pixel-count = 25<br />
spidev0.0-0-personality = 1<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 1<br />
spidev0.0-spi-speed = 1000000<br />
</pre><br />
<br />
=== Two Pixel Strings, using the CE lines ===<br />
<br />
This example is for 25 WS2801 pixels and 32 LPD8806 pixels. Both strings run at 2Mhz and are connected to the spi bus, and we're using the CE chips to de-multiplex. We want to CE lines to be active-high.<br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-personality = 1<br />
spidev0.0-0-pixel-count = 25<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 1<br />
spidev0.0-spi-ce-high = true<br />
spidev0.0-spi-speed = 200000<br />
spidev0.1-0-dmx-address = 1<br />
spidev0.1-0-personality = 1<br />
spidev0.1-0-pixel-count = 25<br />
spidev0.1-backend = software<br />
spidev0.1-ports = 1<br />
spidev0.1-spi-ce-high = true<br />
spidev0.1-spi-speed = 2000000 <br />
</pre><br />
<br />
=== Two Pixel Strings, using a single output ===<br />
<br />
This example is a string of 300 WS2801 pixels. Since this is more than one universe of data, we need to use multiple ports. <br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-personality = 1<br />
spidev0.0-0-pixel-count = 150<br />
spidev0.0-1-dmx-address = 1<br />
spidev0.0-1-personality = 1<br />
spidev0.0-1-pixel-count = 150<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 2<br />
spidev0.0-spi-speed = 1000000<br />
spidev0.0-sync-port = -2<br />
</pre><br />
<br />
SPI data is written when data arrives on the second port (sync-port = -2). See the plugin description for more info.<br />
<br />
== Exported Variables ==<br />
<br />
The SPI plugin exports a number of useful variables. These can be found at http://<ip>:9090/debug. Each is indexed by the device name e.g. /dev/spi0.0 . <br />
<br />
;spi-writes<br />
: Number of writes to each SPI device<br />
; spi-write-errors<br />
: Number of writes that resulted in an error<br />
; spi-drops<br />
: Number of DMX updates that were skipped. The happens if DMX data is arriving faster than it can be written to the SPI bus.<br />
<br />
== Related Links ==<br />
<br />
http://www.solderlab.de/index.php/software/glediator (Pixel Control Software that outputs ArtNet)</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Project&diff=5881Open Lighting Project2017-11-02T03:26:50Z<p>Nomis52: </p>
<hr />
<div>The Open Lighting Project is a multi-faceted effort aimed at accelerating the adoption of new, standardized control protocols, while also providing high quality, reliable, open software for the lighting industry. This site acts as a resource for anyone looking for information about DMX software and the associated control systems, as well as a variety of Open Source and free lighting software.<br />
<br />
<table style="width: 100%; margin:4px 0 0 0; background:none; border-spacing: 5px;"><br />
<tr><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:OLA-Logo-Fitted-48px.png|right|link=OLA]] <br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">[[OLA | The Open Lighting Architecture]]</h2><br />
<div style="clear: left"><br />
The [[OLA | Open Lighting Architecture]] provides a framework for distributing lighting control information. It supports many protocols such as E1.31 (sACN), ArtNet, ShowNet, Pathport, RDM and over a dozen USB devices. It can run as a standalone service, which is useful for converting signals between protocols, or alternatively it can be used as the backend for [[:Category:Controllers | Controller Applications]]. OLA runs on many different platforms including ARM, which makes it a perfect fit for low cost Ethernet to DMX gateways.<br />
</div><br />
</td><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:rdm-logo-small.png|right|link=]]<br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">[[RDM_Responder_Testing | RDM Responder Tests]]</h2><br />
<div style="clear: left"><br />
Testing RDM Responder used to involve manually sending commands and verifying the responses. Not any longer! The [[RDM_Responder_Testing | RDM Responder Tests]] automate all of this and provide a detailed breakdown of how well a responder complies with the [[E1.20]] (RDM) standard. This saves time during the product development process and raises the quality of RDM implementations across the industry.<br />
<br />
For questions about the RDM Responder tests, email the [http://groups.google.com/group/rdm-testing RDM Testing List].<br />
</div><br />
</td> <br />
</tr><br />
<tr><td colspan="2">&nbsp;</td></tr><br />
<tr><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:raspi-logo-small.png|right|link=]]<br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">[[OLA_Raspberry_Pi | OLA on the Raspberry Pi]]</h2><br />
<div style="clear: left"><br />
The [http://www.raspberrypi.org/ Raspberry Pi] is one of the most popular platforms for running [[OLA]]. With the addition of a USB to DMX device, one can build a low cost, but fully functional Ethernet gateway. The [[OLA_Raspberry_Pi | OLA on Raspberry Pi]] tutorial has a step by step guide to installing OLA on the Pi.<br />
</div><br />
</td><br />
<br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:Robin-1200.png|right|link=]]<br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">rdm.openlighting.org</h2><br />
<div style="clear: left"><br />
The http://rdm.openlighting.org site contains an index of RDM-enabled products as well as the specifications for many of the manufacturer specific PIDs. The site has recently been expanded to display the results of the RDM Responder Tests. The data on the site is available free of charge through APIs. <br />
</div><br />
</td><br />
</tr><br />
<br />
<tr><td colspan="2">&nbsp;</td></tr><br />
<tr><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:Email-icon.png|right|link=]]<br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">Contact / Support</h2><br />
<div style="clear: left"><br />
Since this is an Open Source project, there is no commercial support for our products at this time. There are a number of ways of reaching the community though:<br />
<br />
* Primary User & Developer Discussion [http://groups.google.com/group/open-lighting Open Lighting Discuss] (typically a few messages per day).<br />
* Announcements are posted to [http://groups.google.com/group/open-lighting-announce Open Lighting Announce] (low volume, typically 1-2 per month)<br />
* RDM Testing Discussion [http://groups.google.com/group/rdm-testing RDM Testing].<br />
* IRC #openlighting on freenode.net (or [http://webchat.freenode.net/?channels=openlighting webchat])<br />
There is also an [https://plus.google.com/106460627923808853381 Open Lighting Community] on Google+. This is less OLA centric and more about sharing cool lighting projects people are working on. We also have a cafepress store where you can buy OLA t-shirts, stickers, and a few other random things. Visit [http://www.cafepress.com/openlighting Open Lighting at Cafepress]! Prices may change in the future. <br />
</div><br />
</td><br />
<br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">Other Projects</h2><br />
<div style="clear: left"><br />
* [http://www.openlighting.org/libartnet-main/ libartnet]. The library that started it all, libartnet is an [[ArtNet]] implementation for Mac, Linux, Windows & iPhone.<br />
* [[Logic RDM Sniffer]] - Use a [http://saleae.com/logic Saleae Logic] device as a RDM analyzer. <br />
* [[Arduino RGB Mixer]], open source firmware for Arduinos, so that they can be used as a simple RGB Color Mixer. Now with RDM support!<br />
* [[OLA_DMX_Trigger | DMX Trigger]], this can execute command line programs based on DMX values. It's useful for building DMX controlled media players.<br />
* [[E1.33 SLP SA Tests]], similar to the RDM Responder Tests, this performs tests against a RDMNet Device's SLP implementation.<br />
* [[OLA LED Pixels]], drive pixel strings using OLA<br />
</div><br />
</td><br />
</tr><br />
<br />
<br />
<tr><td colspan="2">&nbsp;</td></tr><br />
<tr><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">Project Supporters</h2><br />
<div style="clear: left">Moved to the [http://www.openlighting.org/openlightingproject/supporters/ openlighting.org] site.<br />
</div><br />
</td><br />
<br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">Get Involved</h2><br />
<div style="clear: left"><br />
There is plenty of opportunity to get involved. If you would like to help with any of the following (or have your own ideas) then please get in touch with us on the [http://groups.google.com/group/open-lighting Open Lighting Group]<br />
<br />
* Open Lighting participates in [[OLA SOC Ideas Page|Google Summer of Code]]<br />
* Technical Writers, the documentation could do with some cleanup.<br />
* Packagers, we need people to build binary packages for Mac, Debian/Ubuntu and RPM-based distros<br />
* Windows programmers, are you interested in helping [[Building_OLA_for_Windows| port OLA to Windows]]? <br />
* Java programmers, we need someone to write the Java client API [https://github.com/OpenLightingProject/ola/issues/16]<br />
* Equipment donation, do you own or know of a [[:Category:USB | USB interface]] or RDM device we don't support yet? Consider lending it to us.<br />
* Web designers, the web UI could do with a facelift.<br />
<br />
</div><br />
</td><br />
</tr><br />
</table><br />
<br />
<br />
__NOTOC__</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Projects_List&diff=5852Open Lighting Projects List2015-12-28T15:53:07Z<p>Nomis52: </p>
<hr />
<div>This page contains a list of projects where software from the Open Lighting project has been used. If you know of any more please add them.<br />
<br />
<br />
[[libartnet]]<br />
<br />
* http://www.mediaarchitecture.org/boxleds/<br />
* D::Light http://www.nicole-banana.com<br />
<br />
[[OLA]]<br />
<br />
* Minoru Yasui Building, Denver, http://adamfrank.com/sunlight/sunlight.htm<br />
* San Jose International Airport, http://01sj.org/2010/venues/sjc-airport/<br />
* [http://www.petrovsky.de/THE%20GLOBAL%20PURSUIT%20OF%20HAPPINESS-50-image-THE%20ARMY%20OF%20LUCK-622 The Army of Luck], [http://www.petrovsky.de/MATRIX%20ABC%2052-51 Matrix 52], [http://www.petrovsky.de/THE%20NIXIE%20MIXIE%20MATRIX-35 The Nixie Mixie Matrix], [http://www.petrovsky.de/PART%20I-34 Part I] and [http://www.petrovsky.de/URBANES%20UNTERHOLZ%20MEETS%20YOU&ME-ISMS-41 iJam] by Boris Petrovsky<br />
* http://www.kcmag.com/fashion/kc-style/8188-artist-lisa-lala-saw-the-light, by Lisa Lala<br />
* https://ca.rstenpresser.de/blag/2013/11/using-ola-to-controll-a-led-sign/<br />
* http://www.youtube.com/watch?v=n6QiI2DRK94&feature=youtu.be&t=1m41s<br />
* http://www.youtube.com/watch?v=ObN3mfdBclA<br />
* https://vine.co/v/hb3hu61blu2<br />
* http://www.youtube.com/watch?v=_Sucd3FdL_4<br />
* https://vimeo.com/148511951</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5846Open Lighting Allocations2015-10-07T03:49:39Z<p>Nomis52: /* UIDs */</p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule LED Model<br />
|-<br />
|| 0x0101 || Ja Rule Proxy<br />
|-<br />
|| 0x0102 || Ja Rule Moving Light<br />
|-<br />
|| 0x0103 || Ja Rule Sensor Only<br />
|-<br />
|| 0x0104 || Ja Rule Network<br />
|-<br />
|| 0x0105 || Ja Rule Dimmer<br />
|-<br />
|| 0x0106 || Ja Rule Proxy Child Device<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:10000000 - 7a70:1fffffff || Microchip devices (Ja Rule)<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Development<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Status Message Ids ==<br />
<br />
Status Message ID Value Data Value 1 Data Value 2 Status ID Description<br />
<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Status Message ID'''!! '''Value''' !! '''Data Value 1''' !! '''Data Value2 ''' !! '''Status ID Description'''<br />
|-<br />
|| STS_OLP_TESTING || 0x8000 || Cycle counter major || Cycle counter minor || Counter cycle %d.%d<br />
|-<br />
|| STS_OLP_SELFTEST_PASSED || 0x8001 || Self Test ID || N/A || Self test %d ok<br />
|-<br />
|| STS_OLP_SELFTEST_FAILED || 0x8002 || Self Test ID || N/A || Self test %d failed<br />
<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Device_Specific_Configuration&diff=5845OLA Device Specific Configuration2015-09-10T03:02:56Z<p>Nomis52: </p>
<hr />
<div>==Anyma ==<br />
<br />
<br />
===Linux===<br />
<br />
You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules<br />
<br />
<pre><br />
# udev rules file for the anyma dmx device<br />
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="16c0", ATTRS{idProduct}=="05dc", GROUP="plugdev"<br />
</pre><br />
<br />
==ArtNet ==<br />
<br />
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:<br />
<br />
always_broadcast = true<br />
==Streaming ACN / E1.31==<br />
<br />
===All Platforms===<br />
Some older networking gear only supports an old revision of E1.31 Called Revision 20. To use this older version you need to change a line in ola-e131.conf. Change this line<br />
<pre><br />
revision = 0.46<br />
</pre><br />
to this line<br />
<pre><br />
revision = 0.2<br />
</pre><br />
Only do this if the older gear cannot accept the standardized version of E1.31.<br />
<br />
===Linux===<br />
If you are planning to receive large amounts of multicast traffic 20+, you will need to adjust the maximum amount of igmp memberships.<br />
Use the following command:<br />
<pre><br />
echo <number_of_memberships> | sudo tee /proc/sys/net/ipv4/igmp_max_memberships<br />
</pre><br />
<br />
For example this command sets the maximum number of igmp memberships to 256:<br />
<pre><br />
echo 256 | sudo tee /proc/sys/net/ipv4/igmp_max_memberships<br />
</pre><br />
<br />
==Eurolite USB DMX512 PRO==<br />
<br />
===Linux===<br />
<br />
Sometime the cdc_acm kernel module claims the device. If this happens you'll see errors like "Cannot claim device" and/or "another process has device opened for exclusive access". To avoid this you can remove the module (rmmod). A udev rule like what is used for the Anyma device should also work.<br />
<br />
You may also need the following:<br />
<br />
<pre><br />
SUBSYSTEMS=="usb", ATTRS{idVendor}=="04d8",ATTRS{idProduct}=="0xfa63", MODE="0660", GROUP="plugdev"<br />
</pre><br />
<br />
===Mac===<br />
<br />
Install the [http://code.google.com/p/open-lighting/downloads/detail?name=euroliteusbshield.dmg&can=2&q=#makechanges KEXT].<br />
<br />
== General Purpose I/O ==<br />
<br />
This has only been tested on a Raspberry Pi device. You can find information about the GPIO features on a Pi at [http://elinux.org/RPi_Low-level_peripherals elinux.org]<br />
<br />
===Linux===<br />
<br />
You'll need to export the GPIO pins. For example, to use pin 23, as root run:<br />
<br />
<pre><br />
$ echo 23 > /sys/class/gpio/export<br />
</pre><br />
<br />
You'll also need to ensure that the user olad runs as has permission to change the level of the Pins. Each of the following files should be writeable:<br />
<br />
<pre><br />
/sys/class/gpio/gpio23/direction<br />
/sys/class/gpio/gpio23/value<br />
</pre><br />
<br />
You could for example do this by running the following as root (assuming olad is in the plugdev group, which you can check with "groups olad")<br />
<pre><br />
chgrp plugdev /sys/class/gpio/gpio23/direction<br />
chmod g+w /sys/class/gpio/gpio23/direction<br />
chgrp plugdev /sys/class/gpio/gpio23/value<br />
chmod g+w /sys/class/gpio/gpio23/value<br />
</pre><br />
<br />
== Ja Rule ==<br />
<br />
===Linux===<br />
<br />
<pre><br />
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="aced", GROUP="plugdev" MODE="660"<br />
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1209", ATTRS{idProduct}=="acee", GROUP="plugdev" MODE="660"<br />
</pre><br />
== OSC ==<br />
<br />
The message types are described in the [http://opensoundcontrol.org/spec-1_0 OSC Spec] .<br />
<br />
=== Receiving DMX ===<br />
<br />
The OSC plugin accepts a number of message formats:<br />
<br />
{| border=1 cellspacing="0"<br />
! Path !! OSC Message Type !! Data !! Comments <br />
|-<br />
|| /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.<br />
|-<br />
|| /path/N || 'i' || Slot value from 0 to 255 || Update a single slot. N is the slot number from 1 - 512. <br />
|-<br />
|| /path/N || 'f' || Slot value from 0.0 to 1.0 || Update a single slot. N is the slot number from 1 - 512. <br />
|-<br />
|| /path || 'ii' || Slot number from 0 to 511, slot value from 0 to 255 || Update a single slot.<br />
|-<br />
|| /path || 'if' || Slot number from 0 to 511, slot value from 0.0 to 1.0 || Update a single slot.<br />
|}<br />
<br />
=== Sending DMX ===<br />
<br />
The following formats are available for sending data:<br />
<br />
{| border=1 cellspacing="0"<br />
! Config Option !! Path !! OSC Message Type !! Data !! Comments <br />
|-<br />
|| blob || /path || 'b' || Blob of length 1 to 512. || The most efficient way of sending DMX data over OSC.<br />
|-<br />
|| float_array || /path || N * 'f' || Slot values from 0.0 to 1.0 || Not quite as efficient as the blob type.<br />
|-<br />
|| int_array || /path || N * 'i' || Slot values from 0 to 255 || Not quite as efficient as the blob type.<br />
|-<br />
|| individual_float || /path/N || 'f' || Slot value from 0.0 to 1.0 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this. <br />
|-<br />
|| individual_int || /path/N || 'i' || Slot value from 0 to 255 || N is the slot number from 1 - 512. Results in a lot of messages being sent, avoid using this. <br />
|}<br />
<br />
<br />
==Open DMX USB / FTDI RS485 ==<br />
<br />
There are two options, the 'Open DMX' plugin that requires the kernel module and the native FTDI driver.<br />
<br />
The Open DMX Plugin requires the dmx_usb kernel module, which means it's Linux only. The FTDI driver can be used on either Mac or Linux.<br />
<br />
=== Linux, Open DMX Kernel Module ===<br />
<br />
Make sure the opendmx plugin is enabled.<br />
Make sure the dmx_usb kernel module is loaded. <br />
<br />
===Mac FTDI ===<br />
<br />
You must have libftdi-dev installed before you run ./configure. Otherwise the FTDI DMX plugin won't show up in the list of OLA plugins. <br />
<br />
Enable the FTDI driver (ola-ftdidmx ) and disable the USB Serial and Open DMX drivers (ola-usbserial.conf & ola-opendmx.conf) <br />
<br />
=== Linux, FTDI ===<br />
<br />
Same as Mac, but you also need to make sure that you add the following udev rule:<br />
<br />
<pre><br />
# udev rules for ftdi devices<br />
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", GROUP="plugdev"<br />
</pre><br />
<br />
==Scanlime Fadecandy==<br />
<br />
===Linux===<br />
<br />
You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules<br />
<br />
<pre><br />
# udev rules file for the Scanlime Fadecandy device<br />
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="1d50", ATTRS{idProduct}=="607a", GROUP="plugdev"<br />
</pre><br />
<br />
== SPI ==<br />
<br />
This plugin is designed for the Raspberry Pi. It may work on other hardware, but that's up to you. For instructions on the hardware side of things see [[OLA LED Pixels]].<br />
<br />
Enable the spi-bcm2708 module, depending on the version of Raspbian you're running it will either be via Device Tree or by editing /etc/modprobe.d/raspi-blacklist.conf.<br />
<br />
For recent versions you can use raspi-config's Advanced Options then SPI, see here for more info:<br />
https://www.raspberrypi.org/documentation/configuration/raspi-config.md<br />
<br />
Or alternatively by manually enabling the SPI Device Tree by uncommenting the dtparam=spi=on line in /boot/config.txt as explained here:<br />
https://www.raspberrypi.org/documentation/configuration/device-tree.md<br />
<br />
For older machines, edit /etc/modprobe.d/raspi-blacklist.conf and comment out the "blacklist spi-bcm2708" line. The file should look something like this:<br />
<br />
<pre><br />
# blacklist spi and i2c by default (many users don't need them)<br />
<br />
#blacklist spi-bcm2708<br />
blacklist i2c-bcm2708<br />
</pre><br />
<br />
In both cases, to allow non-root access, add the following to /etc/udev/rules.d/99-spi.rules<br />
<br />
<pre><br />
SUBSYSTEM=="spidev", MODE="0666"<br />
</pre><br />
<br />
==StageProfi==<br />
<br />
This comes in two flavors, a USB model and an Ethernet/IP model.<br />
<br />
device = /dev/ttyUSB0<br />
device = 192.168.1.250<br />
<br />
==UART native DMX==<br />
<br />
===Linux===<br />
<br />
====Raspberry Pi====<br />
<br />
First stop anything else using the serial port; either use raspi-config (Advanced Options, Serial) or follow the instructions here:<br />
<br />
[http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port http://elinux.org/RPi_Serial_Connection#Preventing_Linux_using_the_serial_port]<br />
<br />
To make this work, you will also need to raise the Pi's UART clock, because the default one maxes out at 115kbaud. So you will need to add<br />
<br />
<pre><br />
init_uart_clock=16000000<br />
</pre><br />
<br />
to the /boot/config.txt file on the system. This won't affect any other user of the serial port provided you have a recent kernel.<br />
<br />
Another useful link is [http://fw.hardijzer.nl/?p=138 http://fw.hardijzer.nl/?p=138].<br />
<br />
==USB Pro==<br />
<br />
===Mac===<br />
<br />
Make sure you install the drives: http://www.ftdichip.com/Drivers/VCP.htm<br />
<br />
After a restart run:<br />
<br />
ls /dev/cu.usbserial-*<br />
<br />
Make sure your ~/.ola/ola-usbpro.conf file matches the path above: <br />
<br />
device_dir = /dev<br />
device_prefix = ttyUSB<br />
device_prefix = cu.usbserial-<br />
<br />
i.e. Look for devices at /dev/ttyUSB* , /dev/cu.usbserial-*<br />
<br />
OLA also comes with a tool to update the firmware on a USB Pro:<br />
<br />
./tools/usbpro_firmware -d /dev/cu.usbserial-0000101D -f <firmware_file><br />
<br />
==USBDMX2==<br />
<br />
===Linux===<br />
<br />
You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules<br />
<br />
<pre><br />
# udev rules file for the usbdmx2 dmx device<br />
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="0962", GROUP="plugdev"<br />
</pre><br />
<br />
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.<br />
<br />
===Mac===<br />
<br />
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.<br />
<br />
==Velleman VM166 / K8062==<br />
<br />
===Mac===<br />
<br />
If you're installed from source you'll need the codeless KEXT which is available for [http://downloads.openlighting.org/Velleman%20kext.dmg OS X 10.9 and above] or [http://code.google.com/p/open-lighting/downloads/detail?name=libdmxusbshield.dmg OS 10.8 and below]. If you installed OLA from the mac binary package this is already included.<br />
<br />
===Linux===<br />
<br />
You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/10-local.rules<br />
<br />
<pre><br />
# udev rules file for the velleman dmx device<br />
SUBSYSTEM=="usb|usb_device", ACTION=="add", ATTRS{idVendor}=="10cf", ATTRS{idProduct}=="8062", GROUP="plugdev"<br />
</pre><br />
<br />
Then make sure the user olad runs as is a member of plugdev.<br />
<br />
==KarateLight, KarateDMX==<br />
<br />
===Linux===<br />
<br />
You need a [http://www.reactivated.net/writing_udev_rules.html udev rule] like this in /etc/udev/rules.d/81-karate.rules<br />
<br />
<pre><br />
# udev rules file for the karate-device<br />
KERNEL=="ttyACM?", ATTRS{product}=="DMX2USB simple", SYMLINK+="kldmx0"<br />
</pre><br />
Then make sure the user olad runs as is a member of 'dialout' which is the default group owning ttyACM?.</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Project&diff=5844Open Lighting Project2015-08-28T01:40:34Z<p>Nomis52: </p>
<hr />
<div>The Open Lighting Project is a multi-faceted effort aimed at accelerating the adoption of new, standardized control protocols, while also providing high quality, reliable, open software for the lighting industry. This site acts as a resource for anyone looking for information about DMX software and the associated control systems, as well as a variety of Open Source and free lighting software.<br />
<br />
<table style="width: 100%; margin:4px 0 0 0; background:none; border-spacing: 5px;"><br />
<tr><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:OLA-Logo-Fitted-48px.png|right|link=OLA]] <br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">[[OLA | The Open Lighting Architecture]]</h2><br />
<div style="clear: left"><br />
The [[OLA | Open Lighting Architecture]] provides a framework for distributing lighting control information. It supports many protocols such as E1.31 (sACN), ArtNet, ShowNet, Pathport, RDM and over a dozen USB devices. It can run as a standalone service, which is useful for converting signals between protocols, or alternatively it can be used as the backend for [[:Category:Controllers | Controller Applications]]. OLA runs on many different platforms including ARM, which makes it a perfect fit for low cost Ethernet to DMX gateways.<br />
</div><br />
</td><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:rdm-logo-small.png|right|link=]]<br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">[[RDM_Responder_Testing | RDM Responder Tests]]</h2><br />
<div style="clear: left"><br />
Testing RDM Responder used to involve manually sending commands and verifying the responses. Not any longer! The [[RDM_Responder_Testing | RDM Responder Tests]] automate all of this and provide a detailed breakdown of how well a responder complies with the [[E1.20]] (RDM) standard. This saves time during the product development process and raises the quality of RDM implementations across the industry.<br />
<br />
For questions about the RDM Responder tests, email the [http://groups.google.com/group/rdm-testing RDM Testing List].<br />
</div><br />
</td><br />
</tr><br />
<tr><td colspan="2">&nbsp;</td></tr><br />
<tr><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:raspi-logo-small.png|right|link=]]<br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">[[OLA_Raspberry_Pi | OLA on the Raspberry Pi]]</h2><br />
<div style="clear: left"><br />
The [http://www.raspberrypi.org/ Raspberry Pi] is one of the most popular platforms for running [[OLA]]. With the addition of a USB to DMX device, one can build a low cost, but fully functional Ethernet gateway. The [[OLA_Raspberry_Pi | OLA on Raspberry Pi]] tutorial has a step by step guide to installing OLA on the Pi.<br />
</div><br />
</td><br />
<br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:Robin-1200.png|right|link=]]<br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">rdm.openlighting.org</h2><br />
<div style="clear: left"><br />
The http://rdm.openlighting.org site contains an index of RDM-enabled products as well as the specifications for many of the manufacturer specific PIDs. The site has recently been expanded to display the results of the RDM Responder Tests. The data on the site is available free of charge through APIs. <br />
</div><br />
</td><br />
</tr><br />
<br />
<tr><td colspan="2">&nbsp;</td></tr><br />
<tr><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
[[Image:Email-icon.png|right|link=]]<br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">Contact / Support</h2><br />
<div style="clear: left"><br />
Since this is an Open Source project, there is no commercial support for our products at this time. There are a number of ways of reaching the community though:<br />
<br />
* Primary User & Developer Discussion [http://groups.google.com/group/open-lighting Open Lighting Discuss] (typically a few messages per day).<br />
* Announcements are posted to [http://groups.google.com/group/open-lighting-announce Open Lighting Announce] (low volume, typically 1-2 per month)<br />
* RDM Testing Discussion [http://groups.google.com/group/rdm-testing RDM Testing].<br />
* IRC #openlighting on freenode.net (or [http://webchat.freenode.net/?channels=openlighting webchat])<br />
There is also an [https://plus.google.com/106460627923808853381 Open Lighting Community] on Google+. This is less OLA centric and more about sharing cool lighting projects people are working on. We also have a cafepress store where you can buy OLA t-shirts, stickers, and a few other random things. Visit [http://www.cafepress.com/openlighting Open Lighting at Cafepress]! Prices may change in the future. <br />
</div><br />
</td><br />
<br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">Other Projects</h2><br />
<div style="clear: left"><br />
* [http://www.openlighting.org/libartnet-main/ libartnet]. The library that started it all, libartnet is an [[ArtNet]] implementation for Mac, Linux, Windows & iPhone.<br />
* [[Logic RDM Sniffer]] - Use a [http://saleae.com/logic Saleae Logic] device as a RDM analyzer. <br />
* [[Arduino RGB Mixer]], open source firmware for Arduinos, so that they can be used as a simple RGB Color Mixer. Now with RDM support!<br />
* [[OLA_DMX_Trigger | DMX Trigger]], this can execute command line programs based on DMX values. It's useful for building DMX controlled media players.<br />
* [[E1.33 SLP SA Tests]], similar to the RDM Responder Tests, this performs tests against a RDMNet Device's SLP implementation.<br />
* [[OLA LED Pixels]], drive pixel strings using OLA<br />
</div><br />
</td><br />
</tr><br />
<br />
<br />
<tr><td colspan="2">&nbsp;</td></tr><br />
<tr><br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">Project Supporters</h2><br />
<div style="clear: left">Moved to the [http://www.openlighting.org/openlightingproject/supporters/ openlighting.org] site.<br />
</div><br />
</td><br />
<br />
<td style="width:45%; border:1px solid #cedff2; background:#f5faff; vertical-align:top; padding: 4px"><br />
<h2 style="float:left; font-size:120%; padding: .2em; margin:3px; font-weight:bold;">Get Involved</h2><br />
<div style="clear: left"><br />
There is plenty of opportunity to get involved. If you would like to help with any of the following (or have your own ideas) then please get in touch with us on the [http://groups.google.com/group/open-lighting Open Lighting Group]<br />
<br />
* Open Lighting participates in [[OLA SOC Ideas Page|Google Summer of Code]]<br />
* Technical Writers, the documentation could do with some cleanup.<br />
* Packagers, we need people to build binary packages for Mac, Debian/Ubuntu and RPM-based distros<br />
* Windows programmers, are you interested in helping [[Building_OLA_for_Windows| port OLA to Windows]]? <br />
* Java programmers, we need someone to write the Java client API [https://github.com/OpenLightingProject/ola/issues/16]<br />
* Equipment donation, do you own or know of a [[:Category:USB | USB interface]] or RDM device we don't support yet? Consider lending it to us.<br />
* Web designers, the web UI could do with a facelift.<br />
<br />
</div><br />
</td><br />
</tr><br />
</table><br />
<br />
<br />
__NOTOC__</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5838Open Lighting Allocations2015-08-04T14:35:09Z<p>Nomis52: /* RDM Model Numbers */</p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule LED Model<br />
|-<br />
|| 0x0101 || Ja Rule Proxy<br />
|-<br />
|| 0x0102 || Ja Rule Moving Light<br />
|-<br />
|| 0x0103 || Ja Rule Sensor Only<br />
|-<br />
|| 0x0104 || Ja Rule Network<br />
|-<br />
|| 0x0105 || Ja Rule Dimmer<br />
|-<br />
|| 0x0106 || Ja Rule Proxy Child Device<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Development<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Status Message Ids ==<br />
<br />
Status Message ID Value Data Value 1 Data Value 2 Status ID Description<br />
<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Status Message ID'''!! '''Value''' !! '''Data Value 1''' !! '''Data Value2 ''' !! '''Status ID Description'''<br />
|-<br />
|| STS_OLP_TESTING || 0x8000 || Cycle counter major || Cycle counter minor || Counter cycle %d.%d<br />
|-<br />
|| STS_OLP_SELFTEST_PASSED || 0x8001 || Self Test ID || N/A || Self test %d ok<br />
|-<br />
|| STS_OLP_SELFTEST_FAILED || 0x8002 || Self Test ID || N/A || Self test %d failed<br />
<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_PIDs&diff=5837Open Lighting PIDs2015-08-04T14:13:39Z<p>Nomis52: </p>
<hr />
<div>This page documents [[RDM]] PIDs used by the Open Lighting project.<br />
<br />
For the live list in use, visit the [http://rdm.openlighting.org/pid/manufacturer?manufacturer=31344|RDM Parameter Index].<br />
<br />
===0x8000===<br />
This sets the serial number of the device. The serial number is combined with the ESTA ID to create the UID.<br />
<br />
===0x8001===<br />
This just returns the current version of the OLA code that's running. It's a manufacturer specific PID used by the dummy responder, so that it provides a manufacturer specific PID for testing purposes.<br />
<br />
===0x8002===<br />
GETs / SETs the device model.<br />
<br />
===0x8003===<br />
GET a list of device models that can be used<br />
<br />
===0x8004===<br />
Reserved<br />
<br />
===0x8005===<br />
GET / SET the pixel type<br />
<br />
===0x8006===<br />
GET / SET the pixel count</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_PIDs&diff=5836Open Lighting PIDs2015-08-03T13:33:04Z<p>Nomis52: </p>
<hr />
<div>This page documents [[RDM]] PIDs used by the Open Lighting project.<br />
<br />
For the live list in use, visit the [http://rdm.openlighting.org/pid/manufacturer?manufacturer=31344|RDM Parameter Index].<br />
<br />
===0x8000===<br />
This sets the serial number of the device. The serial number is combined with the ESTA ID to create the UID.<br />
<br />
===0x8001===<br />
This just returns the current version of the OLA code that's running. It's a manufacturer specific PID used by the dummy responder, so that it provides a manufacturer specific PID for testing purposes.<br />
<br />
===0x8002===<br />
GETs / SETs the device model.<br />
<br />
===0x8003===<br />
GET a list of device models that can be used<br />
<br />
===0x8005===<br />
GET / SET the pixel type<br />
<br />
===0x8006===<br />
GET / SET the pixel count</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5835Open Lighting Allocations2015-08-01T15:11:57Z<p>Nomis52: </p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule Simple Model<br />
|-<br />
|| 0x0101 || Ja Rule Proxy<br />
|-<br />
|| 0x0102 || Ja Rule Moving Light<br />
|-<br />
|| 0x0103 || Ja Rule Sensor Only<br />
|-<br />
|| 0x0104 || Ja Rule Network<br />
|-<br />
|| 0x0105 || Ja Rule Dimmer<br />
|-<br />
|| 0x0106 || Ja Rule Proxy Child Device<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Development<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Status Message Ids ==<br />
<br />
Status Message ID Value Data Value 1 Data Value 2 Status ID Description<br />
<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Status Message ID'''!! '''Value''' !! '''Data Value 1''' !! '''Data Value2 ''' !! '''Status ID Description'''<br />
|-<br />
|| STS_OLP_TESTING || 0x8000 || Cycle counter major || Cycle counter minor || Counter cycle %d.%d<br />
|-<br />
|| STS_OLP_SELFTEST_PASSED || 0x8001 || Self Test ID || N/A || Self test %d ok<br />
|-<br />
|| STS_OLP_SELFTEST_FAILED || 0x8002 || Self Test ID || N/A || Self test %d failed<br />
<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5834Open Lighting Allocations2015-08-01T14:52:14Z<p>Nomis52: /* RDM Model Numbers */</p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule Simple Model<br />
|-<br />
|| 0x0101 || Ja Rule Proxy<br />
|-<br />
|| 0x0102 || Ja Rule Moving Light<br />
|-<br />
|| 0x0103 || Ja Rule Sensor Only<br />
|-<br />
|| 0x0104 || Ja Rule Network<br />
|-<br />
|| 0x0105 || Ja Rule Dimmer<br />
|-<br />
|| 0x0106 || Ja Rule Proxy Child Device<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Development<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5833Open Lighting Allocations2015-08-01T14:51:56Z<p>Nomis52: /* RDM Model Numbers */</p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule Simple Model<br />
|-<br />
|| 0x0101 || Ja Rule Proxy<br />
|-<br />
|| 0x0102 || Ja Rule Moving Light<br />
|-<br />
|| 0x0103 || Ja Rule Sensor Only<br />
-<br />
|| 0x0104 || Ja Rule Network<br />
-<br />
|| 0x0105 || Ja Rule Dimmer<br />
-<br />
|| 0x0106 || Ja Rule Proxy Child Device<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Development<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_PIDs&diff=5832Open Lighting PIDs2015-07-18T22:57:47Z<p>Nomis52: </p>
<hr />
<div>This page documents [[RDM]] PIDs used by the Open Lighting project.<br />
<br />
For the live list in use, visit the [http://rdm.openlighting.org/pid/manufacturer?manufacturer=31344|RDM Parameter Index].<br />
<br />
===0x8000===<br />
This sets the serial number of the device. The serial number is combined with the ESTA ID to create the UID.<br />
<br />
===0x8001===<br />
This just returns the current version of the OLA code that's running. It's a manufacturer specific PID used by the dummy responder, so that it provides a manufacturer specific PID for testing purposes.<br />
<br />
===0x8002===<br />
GETs / SETs the device model.</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5831Open Lighting Allocations2015-07-18T22:55:43Z<p>Nomis52: /* RDM Model Numbers */</p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule Simple Responder<br />
|-<br />
|| 0x0101 || Ja Rule Proxy Responder<br />
|-<br />
|| 0x0102 || Ja Rule Moving Light Responder<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Development<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5830Open Lighting Allocations2015-07-17T00:05:37Z<p>Nomis52: </p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule Simple Responder<br />
|-<br />
|| 0x0100 || Ja Rule Proxy Responder<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Development<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5826Open Lighting Allocations2015-06-12T18:32:58Z<p>Nomis52: </p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule Test Responder<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Development<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5825Open Lighting Allocations2015-05-29T00:11:31Z<p>Nomis52: /* RDM Model Numbers */</p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 0x0001 || Dummy Device<br />
|-<br />
|| 0x0002 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 0x0003 || SPI Device<br />
|-<br />
|| 0x0004 || Dummy Dimmer<br />
|-<br />
|| 0x0005 || Dummy Moving Light<br />
|-<br />
|| 0x0006 || Dummy Ack Timer<br />
|-<br />
|| 0x0007 || Dummy Sensor Responder<br />
|-<br />
|| 0x0008 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 0x0009 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule Test Responder<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Ja Rule Controllers<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5824Open Lighting Allocations2015-05-29T00:11:06Z<p>Nomis52: /* RDM Model Numbers */</p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 1 || Dummy Device<br />
|-<br />
|| 2 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 3 || SPI Device<br />
|-<br />
|| 4 || Dummy Dimmer<br />
|-<br />
|| 5 || Dummy Moving Light<br />
|-<br />
|| 6 || Dummy Ack Timer<br />
|-<br />
|| 7 || Dummy Sensor Responder<br />
|-<br />
|| 8 || Dummy E1.37-1 Dimmer<br />
|-<br />
|| 9 || Dummy E1.37-2 Network Responder<br />
|-<br />
|| 0x0100 || Ja Rule Test Responder<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000001 || [[Arduino RGB Mixer]] default UID<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Ja Rule Controllers<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=RDM_PID_Definitions&diff=5823RDM PID Definitions2015-05-11T03:11:32Z<p>Nomis52: </p>
<hr />
<div>== Parameter Definitions and OLA ==<br />
<br />
[[OLA]] reads the structure of [[RDM]] parameter messages at runtime. This allows the users to update PID definitions without upgrading the binaries and also means we can add knowledge of new manufacturer PIDs to the RDM controller software very quickly. <br />
<br />
To enable this, we've designed a parameter definition language which allows us to describe the structure of RDM parameter messages in a language-independent manner. This language has the following assumptions:<br />
<br />
* The structure of a message (i.e. # of repeated values and the length of variable sized fields) must be able to be determined solely from the parameter definition and the length of the message. All parameters in E1.20 and E1.37-1 conform to this, as well as every manufacturer parameter I've encountered. This means that only one variable-sized field can be present in each message, and that [http://en.wikipedia.org/wiki/Type-length-value TLV] style messages aren't supported.<br />
<br />
To get the full benefits of the definition language, the parameter definitions should also:<br />
<br />
* Use big-endian for multi-byte fields<br />
* When integer values are used, the values are stores as normal int values, not as ASCII.<br />
<br />
The canonical parameter definitions are stored on the http://rdm.openlighting.org site. The data from the site is used to generate an ASCII [http://code.google.com/p/protobuf protocol buffer] which is then checked into the OLA codebase and distributed with the tarball. One day we may support automatic updating of the parameter definition files.<br />
<br />
You can see the latest pid protobufs at <tt>[https://github.com/OpenLightingProject/ola/blob/master/data/rdm/pids.proto pids.proto]</tt> and <tt>[https://github.com/OpenLightingProject/ola/blob/master/data/rdm/manufacturer_pids.proto manufacturer_pids.proto]</tt>. In the tarball the files are in <tt>data/rdm/</tt> and they are usually installed into <tt>/usr/local/share/ola/pids/</tt>.<br />
<br />
== Adding New Parameters ==<br />
<br />
Parameters are added to the rdm.openlighting.org site by specifying the message structure, as well as properties like the parameter name and PID in a Python file. To get started, clone the rdm.openlighting.org code from https://github.com/OpenLightingProject/rdm-app. The definitions are found in <tt>data/pid_data.py</tt>. Once you have edited this file push the change to a public git repo and email the open-lighting list asking for a pull request. Simon will sanity check the new parameters and push them to the rdm.openlighting.org site.<br />
<br />
You can use RDM Pid Builder to add your definitions:<br />
http://imaginux.com/lighting/pids/addpids.php<br />
<br />
Or use the tool locally:<br />
https://github.com/RenZ0/rdm-pid-builder<br />
<br />
== Structure ==<br />
<br />
The section describes the syntax of the parameter definition language in the Python representation used by the rdm.openlighting.org site. The protobuf representation is very similar and the concepts are the same for both representations.<br />
<br />
The parameter definitions file is just a Python data structure. At the top level there are two variables <tt>MANUFACTURER_PIDS</tt> and <tt>ESTA_PIDS</tt>. <br />
<br />
<pre><br />
MANUFACTURER_PIDS = [<br />
{'id': <int>, # the manufacturer ID, written in hex<br />
'name': <string>, # the manufacturer name<br />
'pids': [<parameter_definition>],<br />
},<br />
...<br />
]<br />
<br />
ESTA_PIDS = [<br />
<parameter_definition><br />
]<br />
</pre><br />
<br />
Each Parameter Definition takes the form: <br />
<br />
<pre><br />
{<br />
'get_request': {'items': [<item>]},<br />
'get_response': {'items': [<item>]},<br />
'get_sub_device_range': <int>,<br />
'name': <string>,<br />
'set_request': {'items': [<item>]},<br />
'set_response': {'items': [<item>]},<br />
'set_sub_device_range': <int>,<br />
'link': <string>, # the URL for more information<br />
'notes': <string>,<br />
'value': <int>, # the PID <br />
}<br />
</pre><br />
<br />
; {get,set}_request<br />
: The structure of the GET / SET request. This specifies a list of items which are the fields in the parameter message. See the section below for more details.<br />
; {get,set}_response<br />
: The structure of the GET / SET response, same structure as the _request fields.<br />
; {get,set}_sub_device_range<br />
: A value between 0 and 3 which places restrictions on the value of the SubDevice field in the RDM message.<br />
; name<br />
: The name of the PID, should be in CAPS like the names in E1.20<br />
; link<br />
: A URL pointing to where this information was obtained, set to the empty string is there isn't one<br />
; notes<br />
: A text description of what this parameter does. This should be explain to the user how to use the parameter.<br />
; value<br />
: The parameter ID (PID).<br />
<br />
The allowed values for the sub_device_ranges are:<br />
<br />
; 0<br />
: ROOT_DEVICE, implies the subdevice field is 0x0000<br />
; 1<br />
: ROOT_OR_ALL_SUBDEVICE, the subdevice field is 0x0000 to 0x0200 or 0xffff<br />
; 2<br />
: ROOT_OR_SUBDEVICE, the subdevice field is 0x0000 to 0x0200<br />
; 3<br />
: ONLY_SUBDEVICES, the sub device field is 0x0001 to 0x0200<br />
<br />
If a {get,set}_request field isn't present, this means the parameter doesn't support the GET / SET operation. In that case the corresponding _response field should also not be present. Note that this differs from a _request field which is present, but contains no items. The latter means that the parameter data length is 0.<br />
<br />
== Items ==<br />
<br />
Items represent the data fields within each message. An item can also be a group of items, which is how repeated fields are supported. There are only two required attributes for an item:<br />
<br />
<pre><br />
{<br />
'name': <string>,<br />
'type': <string>',<br />
}<br />
</pre><br />
<br />
Item names should be all lower case, with spaces replaced by _ . In OLA, item names are run through CustomCapitalizeLabel() before being displayed to the user. This replaces '_' with ' ' and capitalizes words. For more details see the code in [http://code.google.com/p/open-lighting/source/browse/common/utils/StringUtils.cpp StringUtils.cpp].<br />
<br />
The valid item types are:<br />
<br />
* bool<br />
* uint8<br />
* uint16<br />
* uint32<br />
* int8<br />
* int16<br />
* int32<br />
* string<br />
* group, a group of items, see below for more details.<br />
* ipv4, a 32 bit IP address<br />
* uid, a 48 bit UID.<br />
<br />
All multi-byte items are big endian.<br />
<br />
=== Optional Attributes ===<br />
<br />
These are only defined for certain item types.<br />
<br />
==== Labels ====<br />
<br />
Labels can be used with int items (uint8, uint16, uint32, int8, int16, int32) to attach string descriptions to values.<br />
<br />
Using DISPLAY_INVERT as an example:<br />
<br />
<pre><br />
{'name': 'invert_status', 'type': 'uint8',<br />
'labels': [(0, 'Off'), (1, 'On'), (2, 'Auto')],<br />
}<br />
</pre><br />
<br />
Labels implicitly restrict the values that the item can hold. In the example above, a value outside the range 0-2 will generate an exception.<br />
<br />
==== Ranges ====<br />
<br />
Ranges are used to limit the values for an int item. Using REAL_TIME_CLOCK as the example:<br />
<br />
<pre><br />
{'name': 'month', 'type': 'uint8', 'range': [(1, 12)]}<br />
</pre><br />
<br />
If both ranges and labels are specified, the union of values is used as the set of allowed values for the item.<br />
<br />
==== Multiplier ====<br />
<br />
This is used to shift the decimal point for int items. For example, in PRESET_INFO, the fade times are reported in 10ths of a second. <br />
<br />
<pre><br />
{'name': 'max_preset_fade_time', 'type': 'uint16', 'multiplier': -1},<br />
</pre> <br />
<br />
==== Max Size ====<br />
<br />
This limits the maximum size of a string, or the maximum allowed groups in a repeated item. From DEVICE_LABEL:<br />
<br />
<pre><br />
{'name': 'label', 'max_size': 32, 'type': 'string'}<br />
</pre><br />
<br />
==== Min Size ====<br />
<br />
The opposite of max_size, used for strings and groups. From LANGUAGE_CAPABILITIES:<br />
<br />
<pre><br />
{'name': 'language', 'max_size': 2, 'min_size': 2, 'type': 'string'}<br />
</pre><br />
<br />
=== Item Groups ===<br />
<br />
<br />
TODO: fill this in<br />
<br />
== Examples ==<br />
<br />
These examples show how parameters from E1.20 are described using the PID Definitions Syntax.<br />
<br />
=== DEVICE_INFO ===<br />
<br />
A simple example is DEVICE_INFO. This is only defined for GET commands, and returns a message with various mixed-type fields:<br />
<br />
<pre><br />
{'get_request': {'items': []},<br />
'get_response': {'items': [<br />
{'name': 'protocol_major', 'type': 'uint8'},<br />
{'name': 'protocol_minor', 'type': 'uint8'},<br />
{'name': 'device_model', 'type': 'uint16'},<br />
{'name': 'product_category', 'type': 'uint16'},<br />
{'name': 'software_version','type': 'uint32'},<br />
{'name': 'dmx_footprint', 'type': 'uint16'},<br />
{'name': 'current_personality', 'type': 'uint8'},<br />
{'name': 'personality_count','type': 'uint8'},<br />
{'name': 'dmx_start_address', 'type': 'uint16'},<br />
{'name': 'sub_device_count','type': 'uint16'},<br />
{'name': 'sensor_count', 'type': 'uint8'}]},<br />
'get_sub_device_range': 2,<br />
'name': 'DEVICE_INFO', <br />
'value': 96},<br />
</pre><br />
<br />
=== DEVICE_LABEL === <br />
<br />
DEVICE_LABEL is defined for GET and SET. This example shows how to limit the length of a string.<br />
<br />
<pre><br />
{'get_request': {'items': []},<br />
'get_response': {'items': [<br />
{'name': 'label', 'max_size': 32, 'type': 'string'}<br />
]},<br />
'get_sub_device_range': 2,<br />
'name': 'DEVICE_LABEL', <br />
'set_request': {'items': [<br />
{'name': 'label','max_size': 32, 'type': 'string'}<br />
]},<br />
'set_response': {'items': []},<br />
'set_sub_device_range': 1,<br />
'value': 130},<br />
}<br />
</pre><br />
<br />
=== SLOT_INFO ===<br />
<br />
This example shows how repeated fields work:<br />
<br />
<pre><br />
{'get_request': {'items': []},<br />
'get_response': {'items': [<br />
{'name': 'slots',<br />
'type': 'group',<br />
'items': [<br />
{'name': 'slot_offset', 'type': 'uint16'},<br />
{'name': 'slot_type', 'type': 'uint8'},<br />
{'name': 'slot_label_id', 'type': 'uint16'}<br />
]},<br />
]},<br />
'get_sub_device_range': 2,<br />
'name': 'SLOT_INFO', <br />
'value': 288},<br />
</pre></div>Nomis52https://wiki.openlighting.org/index.php?title=OlaOutput_Max_External&diff=5820OlaOutput Max External2015-05-01T14:57:52Z<p>Nomis52: /* Install and Use OlaOutput in Max/MSP/Jitter */</p>
<hr />
<div>=== How to use the OlaOutput Max External ===<br />
<br />
<br />
'''This article describes how to configure OlaOutput on Mac OS X 10.6 (or greater) for use in Cycling 74's Max/MSP/Jitter or Ableton MaxForLive environments. The object is compatible with Max 5 and 6 (both 32-bit and 64-bit versions), and Ableton Live 8 and 9.<br />
'''<br />
<br />
If you would like to build your own copy of the OlaOutput plugin, follow these [[OlaOutput_Build_Intructions| instructions]].<br />
<br />
<br />
==Download and Install OLA==<br />
<br />
<br />
*[https://github.com/OpenLightingProject/ola/releases Download the latest build of OLA] and install it. OlaOutput is only compatible with OS X (for now).<br />
<br />
*IMPORTANT: If you are planning on [[OLA_Install_Using_MacPorts|installing OLA via MacPorts]], you must install OLA with the '''+universal''' option<br />
<br />
*OLA is a separate application from Ableton Live and Max/MSP/Jitter. To use OlaOutput to send DMX, you need to start the OLA daemon first. <br />
'''NOTE:''' Before you do this, make sure any USB devices you wish to use are plugged in and their drivers are installed.<br />
<br />
<br />
*Open Terminal (found in Applications/Utilities), type the following and press enter:<br />
<br />
<code><pre>olad</pre></code><br />
<br />
This starts the OLA daemon.<br />
<br />
==Configure OLA==<br />
<br />
<br />
*OLA has a HTTP web interface for configuration. You can access it at: [http://localhost:9090 http://localhost:9090]<br />
<br />
<br />
*OLA won’t do anything until it’s configured. You need to setup which DMX universe each hardware device will operate on. To do this, select ‘Devices’ from the left-hand menu in the OLA web interface.<br />
<br />
<br />
*Click on the + next to the device you wish to use. You will see a variety of boxes labeled ‘IN’ and ‘OUT’. We want to configure a universe for output, so choose the correct ‘OUT’ box for the port you wish to use and enter a number into it to specify the universe. A universe value of 1 a typical starting value.<br />
<br />
<br />
*Once you’ve done this, click ’Save Changes’ at the bottom of the list.<br />
<br />
<br />
*Click on ‘Universes’ on the left-hand menu. You should now see a list of the universes specified for output, which should include the one you just specified.<br />
<br />
<br />
*Click on the 'Console' link, and use the sliders to test that OLA is controlling your DMX devices<br />
<br />
<br />
==Install and Use OlaOutput in Max/MSP/Jitter==<br />
<br />
<br />
*To install OlaOutput as a Max/MSP external, download the latest version and place the files in a folder somewhere on your system. Make a note of this path for the next step.<br />
<br />
<br />
*Load Max/MSP. Choose ''Options>File Preferences…''. Then use the plus button on the lower left to add the path to the folder containing the externals you wish to install. This will tell Max to look in this folder for externals to use. Make sure you keep the files in this place, or Max will be unable to locate them. <br />
<br />
<br />
*Create a new Max patcher, and add an olaoutput object. If Max is unable to find olaoutput, it will log a message to its output window.<br />
<br />
<br />
*The OlaOutput object has 2 inlets. The left inlet is used to send a series of DMX messages using the list structure. The (optional) right inlet is used to set the universe that is the destination for messages. For further details about how to use OlaOutput in Max, consult the ''olaoutput.maxhelp'' file included in the download (you can access this quickly from Max by alt-clicking on the object).<br />
<br />
<br />
*Create a message object in Max with the values <code>128 200 250</code> (separated by spaces). Connect the outlet of this message object to the left inlet of the OlaOutput object.<br />
<br />
<br />
*Lock the patcher, and click on the message object. The above values (128, 200, 250) should be sent out to channels 1, 2, 3 respectively.<br />
<br />
==Wrapping Up==<br />
<br />
<br />
*Once you’re done, you can shut down olad using the 'stop olad' link on the ‘Home’ page of OLA's web interface. OLA will remember your universe patchings next time you start it up.<br />
<br />
<br />
For additional help and information about OLA, visit the [[OLA| OLA Wiki]] page.<br />
<br />
[[Category:Articles]]</div>Nomis52https://wiki.openlighting.org/index.php?title=OlaOutput_Build_Instructions&diff=5819OlaOutput Build Instructions2015-05-01T14:55:29Z<p>Nomis52: </p>
<hr />
<div>This describes how to build a 64bit version of the OlaOutput MAX/MSP plugin. Building a 32bit plugin is left as an exercise for the reader.<br />
<br />
==Download the Max SDK ==<br />
<br />
Download the MAX/MSP SDK from https://cycling74.com/downloads/sdk/. Extract the zip file.<br />
<br />
== Install XCode ==<br />
<br />
Download [https://developer.apple.com/xcode/ XCode]<br />
<br />
== Install OLA ==<br />
<br />
Follow the [https://www.openlighting.org/ola/mac-install/ instructions for installing OLA]. The easiest way is to install using MacPorts, which will install into the /opt/local path.<br />
<br />
== Clone the OlaOutput Git Repo ==<br />
<br />
Clone the [https://github.com/OpenLightingProject/olaoutput git repo].<br />
<br />
Move the olaoutput directory under the Max SDK directory from the zip file. It should now look something like:<br />
<br />
<pre><br />
simon:~/Downloads/max-sdk-7.0.3 $ ls -l<br />
total 12016<br />
-rwxr-xr-x@ 1 simon 5000 516 Apr 30 05:38 MaxAPI-7.0.3.html<br />
-rwxr-xr-x@ 1 simon 5000 6137127 Apr 30 05:38 MaxAPI-7.0.3.pdf<br />
-rwxr-xr-x@ 1 simon 5000 265 Apr 30 05:38 README.md<br />
drwxr-xr-x@ 105 simon 5000 3570 Apr 30 05:38 help<br />
drwxr-xr-x@ 831 simon 5000 28254 Apr 30 05:38 html<br />
drwxr-xr-x 3 simon 5000 102 May 1 22:37 max_build<br />
drwxr-xr-x 9 simon 5000 306 May 1 22:36 olaoutput<br />
-rwxr-xr-x@ 1 simon 5000 214 Apr 30 05:38 package-info.json<br />
drwxr-xr-x@ 15 simon 5000 510 Apr 30 05:38 source<br />
</pre> <br />
<br />
== Build ==<br />
<br />
Start XCode and open the olaoutput/olaoutput/olaoutput.xcodeproj file. You should see something like the screenshot below.<br />
<br />
[[File:Olaoutput-xcode1.png|thumb|center]]<br />
<br />
Note that XCode can't find commonsyms.c or libprotobuf.8.dylib. Click on commonsyms.c on the left, then in the right panel click on the folder icon and navigate to source/c74support/max-includes/common/commonsyms.c .<br />
<br />
For libprotobuf.8.dylib, it's a similar story, click on the folder icon and then select /opt/local/lib/libprotobuf.9.dylib. If you didn't use MacPorts to install OLA, the protobuf library may be in a different location.<br />
<br />
Next you'll need to fix the C74SUPPORT path. Click on the 'olaoutput project' in the left pane, then choose 'Build Settings'. Set C74SUPPORT to the correct path (see screenshot).<br />
<br />
[[File:Olaoutput-xcode2.png|thumb|center]]<br />
<br />
Finally change the dropdown in the center pane from 'max-external' to olaoutput. Then under build settings remove i386 from the list of Valid Architectures. <br />
<br />
[[File:Olaoutput-xcode3.png|thumb|center]]<br />
<br />
At this point the build should succeed. The .mxo file will be in the max_build directory under the MAX SDK directory.<br />
<br />
<br />
== Extra Info ==<br />
<br />
The plugin will only work on machines where the OLA libraries are installed in the same paths. This means you can build a plugin on a machine where OLA was installed from a tarball and then expect it to work on a machine where OLA was installed using MacPorts.<br />
<br />
If you want to build a 386 (32-bit) version, you'll need to build all the MacPorts software with i386 support. See the [https://guide.macports.org/chunked/internals.configuration-files.html build_arch] variable.</div>Nomis52https://wiki.openlighting.org/index.php?title=File:Olaoutput-xcode3.png&diff=5818File:Olaoutput-xcode3.png2015-05-01T14:50:01Z<p>Nomis52: </p>
<hr />
<div></div>Nomis52https://wiki.openlighting.org/index.php?title=File:Olaoutput-xcode2.png&diff=5817File:Olaoutput-xcode2.png2015-05-01T14:43:39Z<p>Nomis52: </p>
<hr />
<div></div>Nomis52https://wiki.openlighting.org/index.php?title=File:Olaoutput-xcode1.png&diff=5816File:Olaoutput-xcode1.png2015-05-01T14:38:40Z<p>Nomis52: Nomis52 uploaded a new version of &quot;File:Olaoutput-xcode1.png&quot;</p>
<hr />
<div></div>Nomis52https://wiki.openlighting.org/index.php?title=OlaOutput_Build_Instructions&diff=5815OlaOutput Build Instructions2015-05-01T14:23:14Z<p>Nomis52: </p>
<hr />
<div>This describes how to build a 64bit version of the OlaOutput MAX/MSP plugin. Building a 32bit plugin is left as an exercise for the reader.<br />
<br />
==Download the Max SDK ==<br />
<br />
Download the MAX/MSP SDK from https://cycling74.com/downloads/sdk/. Extract the zip file.<br />
<br />
== Install XCode ==<br />
<br />
Download [https://developer.apple.com/xcode/ XCode]<br />
<br />
== Install OLA ==<br />
<br />
Follow the [https://www.openlighting.org/ola/mac-install/ instructions for installing OLA]. The easiest way is to install using MacPorts, which will install into the /opt/local path.<br />
<br />
== Clone the OlaOutput Git Repo ==<br />
<br />
Clone the [https://github.com/OpenLightingProject/olaoutput git repo].<br />
<br />
Move the olaoutput directory under the Max SDK directory from the zip file. It should now look something like:<br />
<br />
<pre><br />
simon:~/Downloads/MaxSDK-6.1.4 $ ls -l<br />
total 8640<br />
-rw-r--r--@ 1 simonn 5000 516 Oct 21 2013 MaxAPI-6.1.4.html<br />
-rw-r--r--@ 1 simonn 5000 4419158 Oct 21 2013 MaxAPI-6.1.4.pdf<br />
drwxr-xr-x@ 5 simonn 5000 170 Oct 21 2013 c74support<br />
drwxr-xr-x@ 14 simonn 5000 476 Oct 25 2013 examples<br />
drwxr-xr-x@ 398 simonn 5000 13532 Oct 21 2013 html<br />
drwxr-xr-x 8 simonn wheel 272 May 1 22:04 olaoutput<br />
</pre> <br />
<br />
== Build ==<br />
<br />
Start XCode and open the olaoutput/olaoutput/olaoutput.xcodeproj file. You should see something like the screenshot below.<br />
<br />
[[File:Olaoutput-xcode1.png|thumb|center]]<br />
<br />
Note that XCode can't find commonsyms.c or libprotobuf.8.dylib. Click on commonsyms.c on the left, then in the right panel click on the folder icon and navigate to c74support/max-includes/common/commonsyms.c .<br />
<br />
For libprotobuf.8.dylib, it's a similar story, click on the folder icon and then select /opt/local/lib/libprotobuf.9.dylib. If you didn't use MacPorts to install OLA, the protobuf library may be in a different location.</div>Nomis52https://wiki.openlighting.org/index.php?title=OlaOutput_Build_Instructions&diff=5814OlaOutput Build Instructions2015-05-01T14:21:17Z<p>Nomis52: </p>
<hr />
<div>==Download the Max SDK ==<br />
<br />
Download the MAX/MSP SDK from https://cycling74.com/downloads/sdk/. Extract the zip file.<br />
<br />
== Install XCode ==<br />
<br />
Download [https://developer.apple.com/xcode/ XCode]<br />
<br />
== Install OLA ==<br />
<br />
Follow the [https://www.openlighting.org/ola/mac-install/ instructions for installing OLA]. The easiest way is to install using MacPorts, which will install into the /opt/local path.<br />
<br />
== Clone the OlaOutput Git Repo ==<br />
<br />
Clone the [https://github.com/OpenLightingProject/olaoutput git repo].<br />
<br />
Move the olaoutput directory under the Max SDK directory from the zip file. It should now look something like:<br />
<br />
<pre><br />
simon:~/Downloads/MaxSDK-6.1.4 $ ls -l<br />
total 8640<br />
-rw-r--r--@ 1 simonn 5000 516 Oct 21 2013 MaxAPI-6.1.4.html<br />
-rw-r--r--@ 1 simonn 5000 4419158 Oct 21 2013 MaxAPI-6.1.4.pdf<br />
drwxr-xr-x@ 5 simonn 5000 170 Oct 21 2013 c74support<br />
drwxr-xr-x@ 14 simonn 5000 476 Oct 25 2013 examples<br />
drwxr-xr-x@ 398 simonn 5000 13532 Oct 21 2013 html<br />
drwxr-xr-x 8 simonn wheel 272 May 1 22:04 olaoutput<br />
</pre> <br />
<br />
== Build ==<br />
<br />
Start XCode and open the olaoutput/olaoutput/olaoutput.xcodeproj file. You should see something like the screenshot below.<br />
<br />
[[File:Olaoutput-xcode1.png|thumb|center]]<br />
<br />
Note that XCode can't find commonsyms.c or libprotobuf.8.dylib. Click on commonsyms.c on the left, then in the right panel click on the folder icon and navigate to c74support/max-includes/common/commonsyms.c .<br />
<br />
For libprotobuf.8.dylib, it's a similar story, click on the folder icon and then select /opt/local/lib/libprotobuf.9.dylib. If you didn't use MacPorts to install OLA, the protobuf library may be in a different location.</div>Nomis52https://wiki.openlighting.org/index.php?title=File:Olaoutput-xcode1.png&diff=5813File:Olaoutput-xcode1.png2015-05-01T14:20:06Z<p>Nomis52: </p>
<hr />
<div></div>Nomis52https://wiki.openlighting.org/index.php?title=OlaOutput_Build_Instructions&diff=5812OlaOutput Build Instructions2015-05-01T14:19:33Z<p>Nomis52: Created page with "==Download the Max SDK == Download the MAX/MSP SDK from https://cycling74.com/downloads/sdk/. Extract the zip file. == Install XCode == Download [https://developer.apple.co..."</p>
<hr />
<div>==Download the Max SDK ==<br />
<br />
Download the MAX/MSP SDK from https://cycling74.com/downloads/sdk/. Extract the zip file.<br />
<br />
== Install XCode ==<br />
<br />
Download [https://developer.apple.com/xcode/ XCode]<br />
<br />
== Install OLA ==<br />
<br />
Follow the [https://www.openlighting.org/ola/mac-install/ instructions for installing OLA]. The easiest way is to install using MacPorts, which will install into the /opt/local path.<br />
<br />
== Clone the OlaOutput Git Repo ==<br />
<br />
Clone the [https://github.com/OpenLightingProject/olaoutput git repo].<br />
<br />
Move the olaoutput directory under the Max SDK directory from the zip file. It should now look something like:<br />
<br />
<pre><br />
simon:~/Downloads/MaxSDK-6.1.4 $ ls -l<br />
total 8640<br />
-rw-r--r--@ 1 simonn 5000 516 Oct 21 2013 MaxAPI-6.1.4.html<br />
-rw-r--r--@ 1 simonn 5000 4419158 Oct 21 2013 MaxAPI-6.1.4.pdf<br />
drwxr-xr-x@ 5 simonn 5000 170 Oct 21 2013 c74support<br />
drwxr-xr-x@ 14 simonn 5000 476 Oct 25 2013 examples<br />
drwxr-xr-x@ 398 simonn 5000 13532 Oct 21 2013 html<br />
drwxr-xr-x 8 simonn wheel 272 May 1 22:04 olaoutput<br />
</pre> <br />
<br />
== Build ==<br />
<br />
Start XCode and open the olaoutput/olaoutput/olaoutput.xcodeproj file. You should see something like the screenshot below.<br />
<br />
Note that XCode can't find commonsyms.c or libprotobuf.8.dylib. Click on commonsyms.c on the left, then in the right panel click on the folder icon and navigate to c74support/max-includes/common/commonsyms.c .<br />
<br />
For libprotobuf.8.dylib, it's a similar story, click on the folder icon and then select /opt/local/lib/libprotobuf.9.dylib. If you didn't use MacPorts to install OLA, the protobuf library may be in a different location.</div>Nomis52https://wiki.openlighting.org/index.php?title=OlaOutput_Max_External&diff=5811OlaOutput Max External2015-05-01T13:58:03Z<p>Nomis52: </p>
<hr />
<div>=== How to use the OlaOutput Max External ===<br />
<br />
<br />
'''This article describes how to configure OlaOutput on Mac OS X 10.6 (or greater) for use in Cycling 74's Max/MSP/Jitter or Ableton MaxForLive environments. The object is compatible with Max 5 and 6 (both 32-bit and 64-bit versions), and Ableton Live 8 and 9.<br />
'''<br />
<br />
If you would like to build your own copy of the OlaOutput plugin, follow these [[OlaOutput_Build_Intructions| instructions]].<br />
<br />
<br />
==Download and Install OLA==<br />
<br />
<br />
*[https://github.com/OpenLightingProject/ola/releases Download the latest build of OLA] and install it. OlaOutput is only compatible with OS X (for now).<br />
<br />
*IMPORTANT: If you are planning on [[OLA_Install_Using_MacPorts|installing OLA via MacPorts]], you must install OLA with the '''+universal''' option<br />
<br />
*OLA is a separate application from Ableton Live and Max/MSP/Jitter. To use OlaOutput to send DMX, you need to start the OLA daemon first. <br />
'''NOTE:''' Before you do this, make sure any USB devices you wish to use are plugged in and their drivers are installed.<br />
<br />
<br />
*Open Terminal (found in Applications/Utilities), type the following and press enter:<br />
<br />
<code><pre>olad</pre></code><br />
<br />
This starts the OLA daemon.<br />
<br />
==Configure OLA==<br />
<br />
<br />
*OLA has a HTTP web interface for configuration. You can access it at: [http://localhost:9090 http://localhost:9090]<br />
<br />
<br />
*OLA won’t do anything until it’s configured. You need to setup which DMX universe each hardware device will operate on. To do this, select ‘Devices’ from the left-hand menu in the OLA web interface.<br />
<br />
<br />
*Click on the + next to the device you wish to use. You will see a variety of boxes labeled ‘IN’ and ‘OUT’. We want to configure a universe for output, so choose the correct ‘OUT’ box for the port you wish to use and enter a number into it to specify the universe. A universe value of 1 a typical starting value.<br />
<br />
<br />
*Once you’ve done this, click ’Save Changes’ at the bottom of the list.<br />
<br />
<br />
*Click on ‘Universes’ on the left-hand menu. You should now see a list of the universes specified for output, which should include the one you just specified.<br />
<br />
<br />
*Click on the 'Console' link, and use the sliders to test that OLA is controlling your DMX devices<br />
<br />
<br />
==Install and Use OlaOutput in Max/MSP/Jitter==<br />
<br />
<br />
*To install OlaOutput as a Max/MSP external, [http://code.google.com/p/olaoutput/downloads/list download the latest version] and place the files in a folder somewhere on your system. Make a note of this path for the next step.<br />
<br />
<br />
*Load Max/MSP. Choose ''Options>File Preferences…''. Then use the plus button on the lower left to add the path to the folder containing the externals you wish to install. This will tell Max to look in this folder for externals to use. Make sure you keep the files in this place, or Max will be unable to locate them. <br />
<br />
<br />
*Create a new Max patcher, and add an olaoutput object. If Max is unable to find olaoutput, it will log a message to its output window.<br />
<br />
<br />
*The OlaOutput object has 2 inlets. The left inlet is used to send a series of DMX messages using the list structure. The (optional) right inlet is used to set the universe that is the destination for messages. For further details about how to use OlaOutput in Max, consult the ''olaoutput.maxhelp'' file included in the download (you can access this quickly from Max by alt-clicking on the object).<br />
<br />
<br />
*Create a message object in Max with the values <code>128 200 250</code> (separated by spaces). Connect the outlet of this message object to the left inlet of the OlaOutput object.<br />
<br />
<br />
*Lock the patcher, and click on the message object. The above values (128, 200, 250) should be sent out to channels 1, 2, 3 respectively.<br />
<br />
<br />
==Wrapping Up==<br />
<br />
<br />
*Once you’re done, you can shut down olad using the 'stop olad' link on the ‘Home’ page of OLA's web interface. OLA will remember your universe patchings next time you start it up.<br />
<br />
<br />
For additional help and information about OLA, visit the [[OLA| OLA Wiki]] page.<br />
<br />
[[Category:Articles]]</div>Nomis52https://wiki.openlighting.org/index.php?title=Building_a_Custom_Raspbian_Image&diff=5808Building a Custom Raspbian Image2015-03-24T15:09:22Z<p>Nomis52: </p>
<hr />
<div>This page lists the differences between the default Raspbian wheezy image and the one from the [[Open Lighting Project]]. If you create your own install from scratch you probably want to do most of these changes as well. The goal of this image is to produce an image as small as possible for end user use. To this aim, development packages, compilers and non-essential packages are removed.<br />
<br />
* Password for the pi account changed to 'openlighting'<br />
* Rootfs expanded to 4GB using `sudo raspi-config`<br />
* Simon's key installed into /home/pi/.ssh/authorized_keys<br />
* Timezone set to US/Pacific<br />
* Remove Desktop and python_games in the /home/pi directory<br />
* Modified /etc/rc.local to regenerate keys on first boot<br />
* Copied over .screenrc and .vimrc files<br />
* Added the Open Lighting Debian Repo to /etc/apt/sources.lists : deb http://apt.openlighting.org/raspbian wheezy main<br />
* Root ssh access has been disabled in /etc/ssh/sshd_config<br />
* Add init_uart_clock=16000000 to /boot/config.txt so the UART plugin works. <br />
<br />
* Packages installed:<br />
<br />
<pre><br />
apt-get install screen vim deborphan debfoster localepurge<br />
</pre><br />
<br />
And the ola packages:<br />
<pre><br />
apt-get install ola ola-rdm-tests ola-conf-plugins <br />
</pre><br />
<br />
* Packages removed:<br />
<br />
<pre><br />
dbus-x11 desktop-base desktop-file-utils dillo gdb gdbserver gconf-service gconf2 gconf2-common gnome-icon-theme gnome-themes-standard gpicview<br />
gtk2-engines:armhf hicolor-icon-theme <br />
gcc g++ g++-4.6 gcc-4.6 gcc-4.4-base gcc-4.5-base gcc-4.6-base libc6-dev libtagcoll2-dev libwibble-dev libxapian-dev<br />
libfm-gtk-bin libfm-gtk1 libgtk2.0-0:armhf libgtk2.0-bin libgtk2.0-common netsurf-gtk<br />
penguinspuzzle omxplayer netsurf-common mupdf menu-xdg lxde-icon-theme lxmenu-data luajit <br />
samba-common scratch smartsim squeak-plugins-scratch squeak-vm usbmuxd <br />
xserver-common xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-video-fbdev<br />
xdg-utils xauth x11-xkb-utils x11-utils x11-common <br />
cups-bsd cups-client cups-common libcups2 libcupsimage2 <br />
</pre><br />
<br />
* Additional packages removed from the Pi2 image:<br />
<br />
<pre><br />
weston python-minecraftpi protobuf-compiler fakeroot libmtdev1 libwayland0 libxcb-shape0 libxcb-xfixes0 libxcursor1 libxkbcommon0 <br />
fonts-freefont-ttf gcc-4.7-base gstreamer1.0-plugins-base gnome-themes-standard-data gstreamer1.0-x <br />
</pre><br />
* Auto remove<br />
<br />
<pre><br />
apt-get autoremove<br />
</pre><br />
<br />
* Remove orphaned packages: <br />
<pre><br />
deborphan | xargs apt-get -y remove --purge <br />
</pre><br />
* Purge removed packages (if you didn't use --purge above)<br />
<pre><br />
dpkg -l | awk ' /^rc/ {print $2}' | xargs apt-get -y remove --purge<br />
</pre><br />
* Upgrade & clean up: <br />
<pre><br />
apt-get update && apt-get upgrade<br />
apt-get autoremove <br />
apt-get clean<br />
</pre><br />
* Finally zero out the remaining space, so that the zipped image is smaller:<br />
<pre><br />
cat /dev/zero > fill<br />
rm fill<br />
</pre><br />
<br />
This gets the image down to 609MB in the root fs or 662MB if you leave gcc/g++ installed.<br />
<br />
== Git Image ==<br />
<br />
The following additional changes are done for the git image. The ola debian package normally does this, but since we're installing from source we need to do it ourselves.<br />
<br />
* OLA dependancies have been installed (microhttpd, libusb, etc.)<br />
* The OLA git repo has been cloned into /home/ola/ola<br />
* The pi account was added and added to the dialout & plugdev groups<br />
* /etc/udev/rules.d/10-local.rules was updated according to [[OLA_Device_Specific_Configuration]]</div>Nomis52https://wiki.openlighting.org/index.php?title=Open_Lighting_Allocations&diff=5805Open Lighting Allocations2015-03-16T15:14:46Z<p>Nomis52: </p>
<hr />
<div>== RDM Model Numbers ==<br />
For the live list in use, see [[code:include/ola/rdm/OpenLightingEnums.h|here]].<br />
<br />
{| border=1 cellspacing="0"<br />
! '''Number'''!! '''Assigned To'''<br />
|-<br />
|| 1 || Dummy Device<br />
|-<br />
|| 2 || [[Arduino RGB Mixer]]<br />
|-<br />
|| 3 || SPI Device<br />
|}<br />
<br />
== UIDs ==<br />
<br />
The Open Lighting code is 0x7a70<br />
<br />
{| border=1 cellspacing="0"<br />
! '''UID Range'''!! '''Assigned To'''<br />
|-<br />
|| 7a70:00000100 - 7a70:000001ff || SPI Devices<br />
|-<br />
|| 7a70:fffffe00 - 7a70:fffffefe || Ja Rule Controllers<br />
|-<br />
|| 7a70:ffffff00 - 7a70:fffffffe || Dummy Devices<br />
|}<br />
<br />
== Manufacturer Specific PIDs ==<br />
{{:Open Lighting PIDs}}</div>Nomis52https://wiki.openlighting.org/index.php?title=Building_a_Custom_Raspbian_Image&diff=5801Building a Custom Raspbian Image2015-03-03T15:25:22Z<p>Nomis52: </p>
<hr />
<div>This page lists the differences between the default Raspbian wheezy image and the one from the [[Open Lighting Project]]. If you create your own install from scratch you probably want to do most of these changes as well. The goal of this image is to produce an image as small as possible for end user use. To this aim, development packages, compilers and non-essential packages are removed.<br />
<br />
* Password for the pi account changed to 'openlighting'<br />
* Rootfs expanded to 4GB using `sudo raspi-config`<br />
* Simon's key installed into /home/pi/.ssh/authorized_keys<br />
* Timezone set to US/Pacific<br />
* Remove Desktop and python_games in the /home/pi directory<br />
* Modified /etc/rc.local to regenerate keys on first boot<br />
* Copied over .screenrc and .vimrc files<br />
* Added the Open Lighting Debian Repo to /etc/apt/sources.lists : deb http://apt.openlighting.org/raspbian wheezy main<br />
* Root ssh access has been disabled in /etc/ssh/sshd_config<br />
* Add init_uart_clock=16000000 to /boot/config.txt so the UART plugin works. <br />
<br />
* Packages installed:<br />
<br />
<pre><br />
apt-get install screen vim deborphan debfoster localepurge<br />
</pre><br />
<br />
And the ola packages:<br />
<pre><br />
apt-get install ola ola-rdm-tests ola-conf-plugins <br />
</pre><br />
<br />
* Packages removed:<br />
<br />
<pre><br />
dbus-x11 desktop-base desktop-file-utils dillo gdb gdbserver gconf-service gconf2 gconf2-common gnome-icon-theme gnome-themes-standard gpicview<br />
gtk2-engines:armhf hicolor-icon-theme <br />
gcc g++ g++-4.6 gcc-4.6 gcc-4.4-base gcc-4.5-base gcc-4.6-base libc6-dev libtagcoll2-dev libwibble-dev libxapian-dev<br />
libfm-gtk-bin libfm-gtk1 libgtk2.0-0:armhf libgtk2.0-bin libgtk2.0-common netsurf-gtk<br />
penguinspuzzle omxplayer netsurf-common mupdf menu-xdg lxde-icon-theme lxmenu-data luajit <br />
samba-common scratch smartsim squeak-plugins-scratch squeak-vm usbmuxd <br />
xserver-common xserver-xorg xserver-xorg-core xserver-xorg-input-all xserver-xorg-input-evdev xserver-xorg-input-synaptics xserver-xorg-video-fbdev<br />
xdg-utils xauth x11-xkb-utils x11-utils x11-common <br />
cups-bsd cups-client cups-common libcups2 libcupsimage2 <br />
</pre><br />
<br />
* Auto remove<br />
<br />
<pre><br />
apt-get autoremove<br />
</pre><br />
<br />
* Remove orphaned packages: <br />
<pre><br />
deborphan | xargs apt-get -y remove --purge <br />
</pre><br />
* Purge removed packages (if you didn't use --purge above)<br />
<pre><br />
dpkg -l | awk ' /^rc/ {print $2}' | xargs apt-get -y remove --purge<br />
</pre><br />
* Upgrade & clean up: <br />
<pre><br />
apt-get update && apt-get upgrade<br />
apt-get autoremove <br />
apt-get clean<br />
</pre><br />
* Finally zero out the remaining space, so that the zipped image is smaller:<br />
<pre><br />
cat /dev/zero > fill<br />
rm fill<br />
</pre><br />
<br />
This gets the image down to 609MB in the root fs or 662MB if you leave gcc/g++ installed.<br />
<br />
== Git Image ==<br />
<br />
The following additional changes are done for the git image. The ola debian package normally does this, but since we're installing from source we need to do it ourselves.<br />
<br />
* OLA dependancies have been installed (microhttpd, libusb, etc.)<br />
* The OLA git repo has been cloned into /home/ola/ola<br />
* The pi account was added and added to the dialout & plugdev groups<br />
* /etc/udev/rules.d/10-local.rules was updated according to [[OLA_Device_Specific_Configuration]]</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Notes_on_Building_Debian_Packages&diff=5797OLA Notes on Building Debian Packages2015-02-05T16:58:08Z<p>Nomis52: </p>
<hr />
<div>These are mostly Simon's notes to himself on how to build the packages to the Raspberry Pi. RenZO looks after the Debian config files.<br />
<br />
* Install the helper packages<br />
<pre><br />
apt-get install dupload devscripts<br />
</pre><br />
<br />
* Download release tarball, unpack<br />
* Edit debian/changelog to have the following<br />
<br />
<pre><br />
ola (0.8.22-1~squeeze1) squeeze; urgency=low<br />
</pre><br />
<br />
* Run debuild -B, to build the arch dependent, binary packages (arch-independent packages are done by Renzo).<br />
* Make sure that your files are chmod 644 (-rw-r--r--)<br />
* Make sure ~/.dupload.conf is setup correctly:<br />
<br />
<pre><br />
package config;<br />
<br />
delete $preupload{'changes'};<br />
<br />
$cfg{'openlighting-debian'} = {<br />
fqdn => "upload.openlighting.org",<br />
login => "simon",<br />
method => "scp",<br />
incoming => "/opt/packages/incoming/debian/",<br />
};<br />
<br />
$default_host = "openlighting-debian";<br />
</pre><br />
<br />
* Run dupload:<br />
<br />
<pre><br />
dupload ola_0.8.22-1_armel.changes<br />
</pre><br />
<br />
If having more than one dupload config:<br />
<pre><br />
dupload -t openlighting-ubuntu precise32/*changes<br />
</pre></div>Nomis52https://wiki.openlighting.org/index.php?title=OLP_SOC_Ideas_Page&diff=5795OLP SOC Ideas Page2015-01-11T21:26:18Z<p>Nomis52: </p>
<hr />
<div>This page lists some ideas for [http://www.google-melange.com/gsoc/homepage/google/gsoc2014 Google Summer of Code 2014] projects for the [[Open Lighting Project]]. You can use these ideas as a basis for your application, or come up with something different. Please see the Google SOC site for the 2014 timeline. If you would like to discuss any of these ideas, or are thinking of applying to work with us, please send an email to the [https://groups.google.com/forum/?fromgroups#!forum/open-lighting Open Lighting List] introducing yourself.<br />
<br />
Please also read our [https://www.openlighting.org/openlightingproject/get-involved/gsoc/gsoc-information/ GSOC Application Guide].<br />
<br />
== Adding support for more RDM PIDS to the Web UI ==<br />
<br />
Our current WebUI lacks support for a lot of the really cool parameters and features that RDM is capable of. The main task of this project would to add support for RDM sub-devices and Ack Timer. <br />
<br />
This project would include:<br />
* Adding support for RDM sub-devices in the UI and supporting code in the web server back-end <br/><br />
* Adding support for Ack Timer packets in the RDM flow <br/><br />
* Adding support for additional parameter ids or (PIDS).<br />
'''Skills Required''': HTML, Javascript, C++ <br/><br />
'''Estimated Difficulty''': Medium<br />
<br />
== Raspberry Pi UI ==<br />
<br />
The Raspberry Pi is a great platform but lacks a good user interface. With the addition of a small touchscreen, a portable DMX/RDM debugger can be created.<br />
<br />
This project would include:<br />
* Designing, writing and testing the new UI<br />
<br/><br />
'''Skills Required''': Python ? <br/><br />
'''Estimated Difficulty''': Easy<br />
<br />
== RESTful API ==<br />
<br />
The current API that the website uses is a bit old and needs updated to allow full use of OLA's inner working in a general RESTful way. This would allow third parties to easily build new web based apps that could connect to RDM and DMX devices.<br />
<br />
This project would include:<br />
* Writing and testing the new API<br />
* Modifying our current Web app to use the new web api<br />
<br/><br />
'''Skills Required''': C++, Javascript, HTML, JSON <br/><br />
'''Estimated Difficulty''': Easy<br />
<br />
== Web Based Configuration of Preferences ==<br />
<br />
User Preferences for [[OLA]] are stored in text files but the web UI provides no method for changing any preferences beyond port patchings. At the moment the user is required to stop the OLA Daemon, edit the text files and restart if settings are to be changed. This project would involve building a generic preference store and exposing it through the web UI. Changing preferences on the fly is likely to expose bugs in some of the OLA plugins. These will need to be fixed.<br />
<br />
<br />
<br />
'''Skills Required''': C++, Javascript, HTML <br/><br />
'''Estimated Difficulty''': Easy<br />
<br />
== Asynchronous Web Notification of RDM Messages == <br />
<br />
Thanks to sites like GMail and Facebook, users have come to expect asynchronous notification of events in their web browser. [[RDM]] enabled lighting devices can generate events such as ''Over Temperature'' and ''Lamp Faulty'' so it would be nice to alert the users to this. This project would involve work with two Open Source efforts. The student would need to work with [http://www.gnu.org/software/libmicrohttpd/ libmicrohttpd] to add [http://en.wikipedia.org/wiki/WebSocket WebSocket] support (see the [http://lists.gnu.org/archive/html/libmicrohttpd/2012-01/msg00015.html email thread]).<br />
<br />
The second step would involve using WebSockets to deliver events to the browser, and building a UI to notify the user. The [[OLA]] UI is built with [http://code.google.com/closure/ Google Closure].<br />
<br />
<br />
'''Skills Required''': C++, Network Programming, Javascript, HTML, Google Closure<br/><br />
'''Estimated Difficulty''': Medium<br />
<br />
==Port to Android==<br />
<br />
Android is an obvious target for [[OLA]]. Not only does it make perfect sense to use phones & tablets as lighting control interfaces but the Android platform could be used to build embedded lighting control devices. A small amount of this has been done, see [[OLA on Android]]. [[issue:222|Bug #222]] covers this work.<br />
<br />
This project would include:<br />
* Building OLA as a Android Application<br />
* Adding a [[issue:16|Java client]] or wrapping the C++ client with a Java library.<br />
* Writing a frontend in Java to demonstrate the capabilities of OLA. <br />
<br />
<br />
'''Skills Required''': C++, Java, Android <br/><br />
'''Estimated Difficulty''': Hard<br />
<br />
==Port to Windows ==<br />
<br />
This is the most requested 'feature' and would significantly expand the reach of the project especially as we approach v1.0. The current supported method of running OLA on Windows is using VMWare ([[OLA_on_Windows_with_VMWare|instructions]]). This is sub optimal, since it requires the use of non-free software, is challenging for users without Unix command line experience, and doesn't allow Windows applications to communicate with OLA. Work on a Windows port commenced in mid 2011 (see [[Building_OLA_for_Windows|these notes]]), but was postponed due to lack of resources.<br />
<br />
This project would include:<br />
* Refactoring the base classes under [[code:common/network|common/network]] to use the Windows network & event management APIs and ensuring that all unit tests pass. <br />
* Cleaning up various parts of the code which use POSIX APIs (see [[issue:140|issue 140]] for an example)<br />
<br />
A Windows port would enable lighting controller applications like [[QLC]] and [[D::Light]] to move to OLA entirely, and not have to maintain their own plugins.<br />
<br />
<br/><br />
<br />
'''Skills Required''': C++, Windows Network Programming & Windows Event Handling<br/><br />
'''Estimated Difficulty''': Hard<br />
<br />
== Patcher v2 ==<br />
<br />
Patcher v2 is one of the next big projects for [[OLA]] it requires a rewrite of our current daemon to allow users to patch a specific channel:universe to a different channel:universe. It would most likely not be entirely up to the student but would be a small team effort as this touches all major points of our system. This would also require a change in the web interface to possibly allow drag and drop of patching. Depending on the students knowledge they may help with the web interface, web backend or the OLA daemon.<br />
<br />
See [[issue:280|issue 280]] for some additional features and thoughts.<br />
<br />
'''Skills Required''': C++, Javascript, HTML <br/><br />
'''Estimated Difficulty''': Hard</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_LED_Pixels&diff=5791OLA LED Pixels2014-12-31T15:56:18Z<p>Nomis52: </p>
<hr />
<div>[[Image:Lpd8806.jpeg|300px|right]]<br />
<br />
Since March 2013, [[OLA]] contains an [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus SPI] plugin, which allows you to drive strings of LEDs pixels provided your platform has an SPI interface. Using embedded Linux platforms like the [[OLA_Raspberry_Pi | Raspberry Pi]], this allows one to build Pixel strings controllable via any of the [[OLA#Supported_Protocols|supported protocols]] ([[ArtNet]], [[E1.31]], [[OSC]] & more) for less than $100.<br />
<br />
Alternatively if you don't want network control, you can send [[DMX512]] to the LEDs using the Python, C++ or Java client library running on the host itself.<br />
<br />
This page is focused on the Raspberry Pi, but may be applicable to other hardware such as the BeagleBone. If you're using a Raspberry Pi you can save yourself a lot of time by using the pre-built images, see [[OLA_Raspberry_Pi| OLA on the Raspberry Pi]] for details.<br />
<br />
== Host Hardware ==<br />
<br />
The Raspberry Pi contains three SPI interfaces, but only one of these is wired to the 26-pin connector. The interface comes with 3 chip-enable (CE) lines but again only two are connected (pins 24 & 26). With the default mode, pin 24 is pulled low when the /dev/spi0.0 device is used and pin 26 is pulled low when /dev/spi0.1 is used.<br />
<br />
The Pi uses 3.3V logic. You can usually get away with connecting the pins directly to the pixel hardware which uses 5V for testing, but for reliable operation it's best to use a driver circuit to convert the voltage levels from 3.3v to 5v especially if you have a cable run between the Pi and the Pixel string. There is a [https://github.com/hackerspaceshop/RaspberryPI_WS2801_Bridge schematic] available or you can buy a [http://www.hackerspaceshop.com/raspberrypi-ws2801.html kit].<br />
<br />
Here are some timings stats collected from the Pi:<br />
<br />
{| border=1 cellspacing="0"<br />
! SPI Speed !! Number of bytes || time taken for write() !! Time on the wire <br />
|-<br />
|| 1MHz || 75 || 13.5ms || 11.1ms<br />
|-<br />
|| 2MHz || 75 || 8.1ms || 5.6ms<br />
|-<br />
|| 4MHz || 75 || 4.7 ms || 3.0 ms<br />
|-<br />
|| 8MHz || 75 || 3.7ms || 1.4ms<br />
|-<br />
|| 12MHz || 75 || 3.2ms || 0.75 ms<br />
|-<br />
|| 1MHz || 516 || 78.5 ms || 76.15 ms<br />
|-<br />
|| 2MHz || 516 || 40.2 ms || 38.2ms<br />
|-<br />
|| 4MHz || 516 || 21.5 ms || 19.1 ms<br />
|-<br />
|| 8MHz || 516 || 12.2ms || 9.6ms<br />
|-<br />
|| 12MHz || 516 || 7.4ms || 4.83 ms<br />
|-<br />
|}<br />
<br />
It also takes somewhere between 3.6 and 4.6 ms to toggle a GPIO pin using the /sys/class/gpio interface. The importance of these numbers will be clear in a minute. <br />
<br />
<br />
Beyond the Pi, any SPI hardware supported by the Linux kernel should work modulo the timing restrictions. By default OLA looks for devices that match the /dev/spi* .<br />
<br />
== Pixel Hardware ==<br />
<br />
On the pixel side the following is supported:<br />
* LPD8806, e.g. https://www.adafruit.com/products/306. since 0.8.27<br />
* WS2801, e.g. https://www.adafruit.com/products/738, since 0.8.28<br />
<br />
Each of these uses 3 DMX slots per pixel, so you can drive up to 170 pixels from a universe of DMX data.<br />
<br />
== Hardware Setup ==<br />
<br />
The simplest setup is to connect SCLK (pin 23) to the pixel string's clock line and MOSI (pin 19) to the pixel string's DATA line. You'll need a separate power supply for the pixel string, check the pixel specifications but 1A per m is a good rule of thumb. Don't forget to connect the ground on the power supply to a ground pin (e.g. 25) on the Pi.Do not connect the 5V rail of the pixel power supply to the Pi.<br />
<br />
=== Multiplexer ===<br />
<br />
If you want to drive more than one string in parallel you'll need to use a de-multiplexer. For a two-line multiplexer one can use the CE0 and CE1 lines to select the output string. To run more than 2 strings you'll need to use some of the GPIO pins as chip-enables. However these pins are slow (~4ms) which limits the update rate.<br />
<br />
There is a 8 way demultiplexer schematic [https://docs.google.com/file/d/0B7Z8oqKsoX5HWE1qV2hCeDNNOU0/edit?usp=sharing here].<br />
<br />
== OLA SPI Plugin ==<br />
<br />
The [[OLA]] SPI plugin is pretty flexible, the primary limitation is how long it takes to write the data out the SPI interface, and this limits the overall refresh rate. Each SPI interface (/dev/spi*) is represented as an OLA Device. Devices can have multiple 'ports' since each port can consume at most one universe of DMX512 data (170 RGB pixels). Each port can be configured (via RDM) with a start address and personality (pixel type). This allows a combination of various strings lengths & pixel hardware types. <br />
<br />
Each SPI device uses a backend to write the SPI data. Right now there are two types backends available: a software backend which merges the SPI data from one or more ports, and a hardware backend which uses the GPIO pins to control a hardware demultiplexer.<br />
<br />
=== Timing ===<br />
<br />
It all comes down to timing. Consider the following example:<br />
<br />
* 170 LPD8806 pixels per string (results in 516 bytes written)<br />
* Two strings using the built in CE lines to drive a hardware demultipliexer. <br />
* SPI speed of 2Mhz<br />
<br />
Using timing table above, we can see this will take 40.2 ms x 2 = 80ms to update all pixels. That means you'll only be able to do 12 updates per second. Most DMX systems run at 40 updates per second so we'll end up dropping updates. <br />
<br />
If we tried to use GPIO pins rather than the CE ones it gets worse. Consider a second example:<br />
<br />
* 32 WS2801 pixels per string (results in 75 bytes written)<br />
* Four strings using two GPIO lines to drive a hardware demultipliexer. <br />
* SPI speed of 2Mhz<br />
<br />
Now each write requires setting GPIO pins. Worse case both pins will need to change which adds 8ms. The write itself takes 8.1 ms, so that's 16.1 ms per string or 64.4 ms to update all strings. That gives you an update rate of 15 updates per second. Still not close to DMX's 40 updates per second.<br />
<br />
== Software Setup ==<br />
You'll need a suitable [[OLA_Device_Specific_Configuration#SPI|udev config]], so that OLA has permission to talk to your SPI port. There is also some Raspberry Pi specific config (enabling a kernel module) on the same page.<br />
<br />
If you're using the GPIO pins to drive an hardware demultiplexer, you'll need to run the following as root prior to starting olad.<br />
<br />
<pre><br />
for pin in 17 21; do<br />
echo $pin > /sys/class/gpio/export;<br />
chmod a+w /sys/class/gpio/gpio${pin}/value;<br />
chmod a+w /sys/class/gpio/gpio${pin}/direction;<br />
done<br />
</pre><br />
<br />
Once you have OLA running it's a matter of patching an SPI Output port to a universe and then patching the desired input port. This can be done from the OLA web UI or by using ola_patch<br />
.<br />
[[Image:Ola-spi-artnet.png| thumb|center |200px|Example of an ArtNet controlled LED String]]<br />
<br />
== Configuration ==<br />
<br />
The type of LED drivers, operating mode and DMX Start Address are configurable via [[RDM]]. Click on the RDM tab and you'll see the options.<br />
<br />
[[Image:Ola-spi-rdm.png| thumb|center |200px|Using RDM to set the hardware type and DMX start address]]<br />
<br />
<br />
The number of LEDs and SPI speed is set using the ola-spi.conf file.<br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-dmx-address = 1<br />
spidev0.0-personality = 1<br />
spidev0.0-pixel-count = 25<br />
spidev0.0-spi-speed = 100000<br />
spidev0.1-dmx-address = 1<br />
spidev0.1-personality = 2<br />
spidev0.1-pixel-count = 25<br />
spidev0.1-spi-speed = 1000000<br />
</pre><br />
<br />
== Example Configs ==<br />
<br />
=== Single Pixel String ===<br />
<br />
For a simple single-string output we can use the software backend and ignore the CE lines. This config is for 25 WS2801 pixels running at 1Mhz on /dev/spi0.0. From the timing information above this should support about 75 updates / second.<br />
<br />
<pre><br />
base_uid = 7a70:00000100 <br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-pixel-count = 25<br />
spidev0.0-0-personality = 1<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 1<br />
spidev0.0-spi-speed = 1000000<br />
</pre><br />
<br />
=== Two Pixel Strings, using the CE lines ===<br />
<br />
This example is for 25 WS2801 pixels and 32 LPD8806 pixels. Both strings run at 2Mhz and are connected to the spi bus, and we're using the CE chips to de-multiplex. We want to CE lines to be active-high.<br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-personality = 1<br />
spidev0.0-0-pixel-count = 25<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 1<br />
spidev0.0-spi-ce-high = true<br />
spidev0.0-spi-speed = 200000<br />
spidev0.1-0-dmx-address = 1<br />
spidev0.1-0-personality = 1<br />
spidev0.1-0-pixel-count = 25<br />
spidev0.1-backend = software<br />
spidev0.1-ports = 1<br />
spidev0.1-spi-ce-high = true<br />
spidev0.1-spi-speed = 2000000 <br />
</pre><br />
<br />
=== Two Pixel Strings, using a single output ===<br />
<br />
This example is a string of 300 WS2801 pixels. Since this is more than one universe of data, we need to use multiple ports. <br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-personality = 1<br />
spidev0.0-0-pixel-count = 150<br />
spidev0.0-1-dmx-address = 1<br />
spidev0.0-1-personality = 1<br />
spidev0.0-1-pixel-count = 150<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 2<br />
spidev0.0-spi-speed = 1000000<br />
spidev0.0-sync-port = -2<br />
</pre><br />
<br />
SPI data is written when data arrives on the second port (sync-port = -2). See the plugin description for more info.<br />
<br />
== Exported Variables ==<br />
<br />
The SPI plugin exports a number of useful variables. These can be found at http://<ip>:9090/debug. Each is indexed by the device name e.g. /dev/spi0.0 . <br />
<br />
;spi-writes<br />
: Number of writes to each SPI device<br />
; spi-write-errors<br />
: Number of writes that resulted in an error<br />
; spi-drops<br />
: Number of DMX updates that were skipped. The happens if DMX data is arriving faster than it can be written to the SPI bus.<br />
<br />
== Related Links ==<br />
<br />
http://www.solderlab.de/index.php/software/glediator (Pixel Control Software that outputs ArtNet)</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_LED_Pixels&diff=5790OLA LED Pixels2014-12-31T15:55:26Z<p>Nomis52: /* Single Pixel String */</p>
<hr />
<div>[[Image:Lpd8806.jpeg|300px|right]]<br />
<br />
Since March 2013, [[OLA]] contains an [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus SPI] plugin, which allows you to drive strings of LEDs pixels provided your platform has an SPI interface. Using embedded Linux platforms like the [[OLA_Raspberry_Pi | Raspberry Pi]], this allows one to build Pixel strings controllable via any of the [[OLA#Supported_Protocols|supported protocols]] ([[ArtNet]], [[E1.31]], [[OSC]] & more) for less than $100.<br />
<br />
Alternatively if you don't want network control, you can send [[DMX512]] to the LEDs using the Python, C++ or Java client library running on the host itself.<br />
<br />
This page is focused on the Raspberry Pi, but may be applicable to other hardware such as the BeagleBone. If you're using a Raspberry Pi you can save yourself a lot of time by using the pre-built images, see [[OLA_Raspberry_Pi| OLA on the Raspberry Pi]] for details.<br />
<br />
== Host Hardware ==<br />
<br />
The Raspberry Pi contains three SPI interfaces, but only one of these is wired to the 26-pin connector. The interface comes with 3 chip-enable (CE) lines but again only two are connected (pins 24 & 26). With the default mode, pin 24 is pulled low when the /dev/spi0.0 device is used and pin 26 is pulled low when /dev/spi0.1 is used.<br />
<br />
The Pi uses 3.3V logic. You can usually get away with connecting the pins directly to the pixel hardware which uses 5V for testing, but for reliable operation it's best to use a driver circuit to convert the voltage levels from 3.3v to 5v especially if you have a cable run between the Pi and the Pixel string. There is a [https://github.com/hackerspaceshop/RaspberryPI_WS2801_Bridge schematic] available or you can buy a [http://www.hackerspaceshop.com/raspberrypi-ws2801.html kit].<br />
<br />
Here are some timings stats collected from the Pi:<br />
<br />
{| border=1 cellspacing="0"<br />
! SPI Speed !! Number of bytes || time taken for write() !! Time on the wire <br />
|-<br />
|| 1MHz || 75 || 13.5ms || 11.1ms<br />
|-<br />
|| 2MHz || 75 || 8.1ms || 5.6ms<br />
|-<br />
|| 4MHz || 75 || 4.7 ms || 3.0 ms<br />
|-<br />
|| 8MHz || 75 || 3.7ms || 1.4ms<br />
|-<br />
|| 12MHz || 75 || 3.2ms || 0.75 ms<br />
|-<br />
|| 1MHz || 516 || 78.5 ms || 76.15 ms<br />
|-<br />
|| 2MHz || 516 || 40.2 ms || 38.2ms<br />
|-<br />
|| 4MHz || 516 || 21.5 ms || 19.1 ms<br />
|-<br />
|| 8MHz || 516 || 12.2ms || 9.6ms<br />
|-<br />
|| 12MHz || 516 || 7.4ms || 4.83 ms<br />
|-<br />
|}<br />
<br />
It also takes somewhere between 3.6 and 4.6 ms to toggle a GPIO pin using the /sys/class/gpio interface. The importance of these numbers will be clear in a minute. <br />
<br />
<br />
Beyond the Pi, any SPI hardware supported by the Linux kernel should work modulo the timing restrictions. By default OLA looks for devices that match the /dev/spi* .<br />
<br />
== Pixel Hardware ==<br />
<br />
On the pixel side the following is supported:<br />
* LPD8806, e.g. https://www.adafruit.com/products/306. since 0.8.27<br />
* WS2801, e.g. https://www.adafruit.com/products/738, since 0.8.28<br />
<br />
Each of these uses 3 DMX slots per pixel, so you can drive up to 170 pixels from a universe of DMX data.<br />
<br />
== Hardware Setup ==<br />
<br />
The simplest setup is to connect SCLK (pin 23) to the pixel string's clock line and MOSI (pin 19) to the pixel string's DATA line. You'll need a separate power supply for the pixel string, check the pixel specifications but 1A per m is a good rule of thumb. Don't forget to connect the ground on the power supply to a ground pin (e.g. 25) on the Pi.Do not connect the 5V rail of the pixel power supply to the Pi.<br />
<br />
=== Multiplexer ===<br />
<br />
If you want to drive more than one string in parallel you'll need to use a de-multiplexer. For a two-line multiplexer one can use the CE0 and CE1 lines to select the output string. To run more than 2 strings you'll need to use some of the GPIO pins as chip-enables. However these pins are slow (~4ms) which limits the update rate.<br />
<br />
There is a 8 way demultiplexer schematic [https://docs.google.com/file/d/0B7Z8oqKsoX5HWE1qV2hCeDNNOU0/edit?usp=sharing here].<br />
<br />
== OLA SPI Plugin ==<br />
<br />
The [[OLA]] SPI plugin is pretty flexible, the primary limitation is how long it takes to write the data out the SPI interface, and this limits the overall refresh rate. Each SPI interface (/dev/spi*) is represented as an OLA Device. Devices can have multiple 'ports' since each port can consume at most one universe of DMX512 data (170 RGB pixels). Each port can be configured (via RDM) with a start address and personality (pixel type). This allows a combination of various strings lengths & pixel hardware types. <br />
<br />
Each SPI device uses a backend to write the SPI data. Right now there are two types backends available: a software backend which merges the SPI data from one or more ports, and a hardware backend which uses the GPIO pins to control a hardware demultiplexer.<br />
<br />
=== Timing ===<br />
<br />
It all comes down to timing. Consider the following example:<br />
<br />
* 170 LPD8806 pixels per string (results in 516 bytes written)<br />
* Two strings using the built in CE lines to drive a hardware demultipliexer. <br />
* SPI speed of 2Mhz<br />
<br />
Using timing table above, we can see this will take 40.2 ms x 2 = 80ms to update all pixels. That means you'll only be able to do 12 updates per second. Most DMX systems run at 40 updates per second so we'll end up dropping updates. <br />
<br />
If we tried to use GPIO pins rather than the CE ones it gets worse. Consider a second example:<br />
<br />
* 32 WS2801 pixels per string (results in 75 bytes written)<br />
* Four strings using two GPIO lines to drive a hardware demultipliexer. <br />
* SPI speed of 2Mhz<br />
<br />
Now each write requires setting GPIO pins. Worse case both pins will need to change which adds 8ms. The write itself takes 8.1 ms, so that's 16.1 ms per string or 64.4 ms to update all strings. That gives you an update rate of 15 updates per second. Still not close to DMX's 40 updates per second.<br />
<br />
== Software Setup ==<br />
You'll need a suitable [[OLA_Device_Specific_Configuration#SPI|udev config]], so that OLA has permission to talk to your SPI port. There is also some Raspberry Pi specific config (enabling a kernel module) on the same page.<br />
<br />
If you're using the GPIO pins to drive an hardware demultiplexer, you'll need to run the following as root prior to starting olad.<br />
<br />
<pre><br />
for pin in 17 21; do<br />
echo $pin > /sys/class/gpio/export;<br />
chmod a+w /sys/class/gpio/gpio${pin}/value;<br />
chmod a+w /sys/class/gpio/gpio${pin}/direction;<br />
done<br />
</pre><br />
<br />
Once you have OLA running it's a matter of patching an SPI Output port to a universe and then patching the desired input port. This can be done from the OLA web UI or by using ola_patch<br />
.<br />
[[Image:Ola-spi-artnet.png| thumb|center |200px|Example of an ArtNet controlled LED String]]<br />
<br />
== Configuration ==<br />
<br />
The type of LED drivers, operating mode and DMX Start Address are configurable via [[RDM]]. Click on the RDM tab and you'll see the options.<br />
<br />
[[Image:Ola-spi-rdm.png| thumb|center |200px|Using RDM to set the hardware type and DMX start address]]<br />
<br />
<br />
The number of LEDs and SPI speed is set using the ola-spi.conf file.<br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-dmx-address = 1<br />
spidev0.0-personality = 1<br />
spidev0.0-pixel-count = 25<br />
spidev0.0-spi-speed = 100000<br />
spidev0.1-dmx-address = 1<br />
spidev0.1-personality = 2<br />
spidev0.1-pixel-count = 25<br />
spidev0.1-spi-speed = 100000<br />
</pre><br />
<br />
== Example Configs ==<br />
<br />
=== Single Pixel String ===<br />
<br />
For a simple single-string output we can use the software backend and ignore the CE lines. This config is for 25 WS2801 pixels running at 1Mhz on /dev/spi0.0. From the timing information above this should support about 75 updates / second.<br />
<br />
<pre><br />
base_uid = 7a70:00000100 <br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-pixel-count = 25<br />
spidev0.0-0-personality = 1<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 1<br />
spidev0.0-spi-speed = 1000000<br />
</pre><br />
<br />
=== Two Pixel Strings, using the CE lines ===<br />
<br />
This example is for 25 WS2801 pixels and 32 LPD8806 pixels. Both strings run at 2Mhz and are connected to the spi bus, and we're using the CE chips to de-multiplex. We want to CE lines to be active-high.<br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-personality = 1<br />
spidev0.0-0-pixel-count = 25<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 1<br />
spidev0.0-spi-ce-high = true<br />
spidev0.0-spi-speed = 200000<br />
spidev0.1-0-dmx-address = 1<br />
spidev0.1-0-personality = 1<br />
spidev0.1-0-pixel-count = 25<br />
spidev0.1-backend = software<br />
spidev0.1-ports = 1<br />
spidev0.1-spi-ce-high = true<br />
spidev0.1-spi-speed = 200000 <br />
</pre><br />
<br />
=== Two Pixel Strings, using a single output ===<br />
<br />
This example is a string of 300 WS2801 pixels. Since this is more than one universe of data, we need to use multiple ports. <br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-personality = 1<br />
spidev0.0-0-pixel-count = 150<br />
spidev0.0-1-dmx-address = 1<br />
spidev0.0-1-personality = 1<br />
spidev0.0-1-pixel-count = 150<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 2<br />
spidev0.0-spi-speed = 1000000<br />
spidev0.0-sync-port = -2<br />
</pre><br />
<br />
SPI data is written when data arrives on the second port (sync-port = -2). See the plugin description for more info.<br />
<br />
== Exported Variables ==<br />
<br />
The SPI plugin exports a number of useful variables. These can be found at http://<ip>:9090/debug. Each is indexed by the device name e.g. /dev/spi0.0 . <br />
<br />
;spi-writes<br />
: Number of writes to each SPI device<br />
; spi-write-errors<br />
: Number of writes that resulted in an error<br />
; spi-drops<br />
: Number of DMX updates that were skipped. The happens if DMX data is arriving faster than it can be written to the SPI bus.<br />
<br />
== Related Links ==<br />
<br />
http://www.solderlab.de/index.php/software/glediator (Pixel Control Software that outputs ArtNet)</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_LED_Pixels&diff=5789OLA LED Pixels2014-12-31T15:55:16Z<p>Nomis52: /* Two Pixel Strings, using a single output */</p>
<hr />
<div>[[Image:Lpd8806.jpeg|300px|right]]<br />
<br />
Since March 2013, [[OLA]] contains an [http://en.wikipedia.org/wiki/Serial_Peripheral_Interface_Bus SPI] plugin, which allows you to drive strings of LEDs pixels provided your platform has an SPI interface. Using embedded Linux platforms like the [[OLA_Raspberry_Pi | Raspberry Pi]], this allows one to build Pixel strings controllable via any of the [[OLA#Supported_Protocols|supported protocols]] ([[ArtNet]], [[E1.31]], [[OSC]] & more) for less than $100.<br />
<br />
Alternatively if you don't want network control, you can send [[DMX512]] to the LEDs using the Python, C++ or Java client library running on the host itself.<br />
<br />
This page is focused on the Raspberry Pi, but may be applicable to other hardware such as the BeagleBone. If you're using a Raspberry Pi you can save yourself a lot of time by using the pre-built images, see [[OLA_Raspberry_Pi| OLA on the Raspberry Pi]] for details.<br />
<br />
== Host Hardware ==<br />
<br />
The Raspberry Pi contains three SPI interfaces, but only one of these is wired to the 26-pin connector. The interface comes with 3 chip-enable (CE) lines but again only two are connected (pins 24 & 26). With the default mode, pin 24 is pulled low when the /dev/spi0.0 device is used and pin 26 is pulled low when /dev/spi0.1 is used.<br />
<br />
The Pi uses 3.3V logic. You can usually get away with connecting the pins directly to the pixel hardware which uses 5V for testing, but for reliable operation it's best to use a driver circuit to convert the voltage levels from 3.3v to 5v especially if you have a cable run between the Pi and the Pixel string. There is a [https://github.com/hackerspaceshop/RaspberryPI_WS2801_Bridge schematic] available or you can buy a [http://www.hackerspaceshop.com/raspberrypi-ws2801.html kit].<br />
<br />
Here are some timings stats collected from the Pi:<br />
<br />
{| border=1 cellspacing="0"<br />
! SPI Speed !! Number of bytes || time taken for write() !! Time on the wire <br />
|-<br />
|| 1MHz || 75 || 13.5ms || 11.1ms<br />
|-<br />
|| 2MHz || 75 || 8.1ms || 5.6ms<br />
|-<br />
|| 4MHz || 75 || 4.7 ms || 3.0 ms<br />
|-<br />
|| 8MHz || 75 || 3.7ms || 1.4ms<br />
|-<br />
|| 12MHz || 75 || 3.2ms || 0.75 ms<br />
|-<br />
|| 1MHz || 516 || 78.5 ms || 76.15 ms<br />
|-<br />
|| 2MHz || 516 || 40.2 ms || 38.2ms<br />
|-<br />
|| 4MHz || 516 || 21.5 ms || 19.1 ms<br />
|-<br />
|| 8MHz || 516 || 12.2ms || 9.6ms<br />
|-<br />
|| 12MHz || 516 || 7.4ms || 4.83 ms<br />
|-<br />
|}<br />
<br />
It also takes somewhere between 3.6 and 4.6 ms to toggle a GPIO pin using the /sys/class/gpio interface. The importance of these numbers will be clear in a minute. <br />
<br />
<br />
Beyond the Pi, any SPI hardware supported by the Linux kernel should work modulo the timing restrictions. By default OLA looks for devices that match the /dev/spi* .<br />
<br />
== Pixel Hardware ==<br />
<br />
On the pixel side the following is supported:<br />
* LPD8806, e.g. https://www.adafruit.com/products/306. since 0.8.27<br />
* WS2801, e.g. https://www.adafruit.com/products/738, since 0.8.28<br />
<br />
Each of these uses 3 DMX slots per pixel, so you can drive up to 170 pixels from a universe of DMX data.<br />
<br />
== Hardware Setup ==<br />
<br />
The simplest setup is to connect SCLK (pin 23) to the pixel string's clock line and MOSI (pin 19) to the pixel string's DATA line. You'll need a separate power supply for the pixel string, check the pixel specifications but 1A per m is a good rule of thumb. Don't forget to connect the ground on the power supply to a ground pin (e.g. 25) on the Pi.Do not connect the 5V rail of the pixel power supply to the Pi.<br />
<br />
=== Multiplexer ===<br />
<br />
If you want to drive more than one string in parallel you'll need to use a de-multiplexer. For a two-line multiplexer one can use the CE0 and CE1 lines to select the output string. To run more than 2 strings you'll need to use some of the GPIO pins as chip-enables. However these pins are slow (~4ms) which limits the update rate.<br />
<br />
There is a 8 way demultiplexer schematic [https://docs.google.com/file/d/0B7Z8oqKsoX5HWE1qV2hCeDNNOU0/edit?usp=sharing here].<br />
<br />
== OLA SPI Plugin ==<br />
<br />
The [[OLA]] SPI plugin is pretty flexible, the primary limitation is how long it takes to write the data out the SPI interface, and this limits the overall refresh rate. Each SPI interface (/dev/spi*) is represented as an OLA Device. Devices can have multiple 'ports' since each port can consume at most one universe of DMX512 data (170 RGB pixels). Each port can be configured (via RDM) with a start address and personality (pixel type). This allows a combination of various strings lengths & pixel hardware types. <br />
<br />
Each SPI device uses a backend to write the SPI data. Right now there are two types backends available: a software backend which merges the SPI data from one or more ports, and a hardware backend which uses the GPIO pins to control a hardware demultiplexer.<br />
<br />
=== Timing ===<br />
<br />
It all comes down to timing. Consider the following example:<br />
<br />
* 170 LPD8806 pixels per string (results in 516 bytes written)<br />
* Two strings using the built in CE lines to drive a hardware demultipliexer. <br />
* SPI speed of 2Mhz<br />
<br />
Using timing table above, we can see this will take 40.2 ms x 2 = 80ms to update all pixels. That means you'll only be able to do 12 updates per second. Most DMX systems run at 40 updates per second so we'll end up dropping updates. <br />
<br />
If we tried to use GPIO pins rather than the CE ones it gets worse. Consider a second example:<br />
<br />
* 32 WS2801 pixels per string (results in 75 bytes written)<br />
* Four strings using two GPIO lines to drive a hardware demultipliexer. <br />
* SPI speed of 2Mhz<br />
<br />
Now each write requires setting GPIO pins. Worse case both pins will need to change which adds 8ms. The write itself takes 8.1 ms, so that's 16.1 ms per string or 64.4 ms to update all strings. That gives you an update rate of 15 updates per second. Still not close to DMX's 40 updates per second.<br />
<br />
== Software Setup ==<br />
You'll need a suitable [[OLA_Device_Specific_Configuration#SPI|udev config]], so that OLA has permission to talk to your SPI port. There is also some Raspberry Pi specific config (enabling a kernel module) on the same page.<br />
<br />
If you're using the GPIO pins to drive an hardware demultiplexer, you'll need to run the following as root prior to starting olad.<br />
<br />
<pre><br />
for pin in 17 21; do<br />
echo $pin > /sys/class/gpio/export;<br />
chmod a+w /sys/class/gpio/gpio${pin}/value;<br />
chmod a+w /sys/class/gpio/gpio${pin}/direction;<br />
done<br />
</pre><br />
<br />
Once you have OLA running it's a matter of patching an SPI Output port to a universe and then patching the desired input port. This can be done from the OLA web UI or by using ola_patch<br />
.<br />
[[Image:Ola-spi-artnet.png| thumb|center |200px|Example of an ArtNet controlled LED String]]<br />
<br />
== Configuration ==<br />
<br />
The type of LED drivers, operating mode and DMX Start Address are configurable via [[RDM]]. Click on the RDM tab and you'll see the options.<br />
<br />
[[Image:Ola-spi-rdm.png| thumb|center |200px|Using RDM to set the hardware type and DMX start address]]<br />
<br />
<br />
The number of LEDs and SPI speed is set using the ola-spi.conf file.<br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-dmx-address = 1<br />
spidev0.0-personality = 1<br />
spidev0.0-pixel-count = 25<br />
spidev0.0-spi-speed = 100000<br />
spidev0.1-dmx-address = 1<br />
spidev0.1-personality = 2<br />
spidev0.1-pixel-count = 25<br />
spidev0.1-spi-speed = 100000<br />
</pre><br />
<br />
== Example Configs ==<br />
<br />
=== Single Pixel String ===<br />
<br />
For a simple single-string output we can use the software backend and ignore the CE lines. This config is for 25 WS2801 pixels running at 1Mhz on /dev/spi0.0. From the timing information above this should support about 75 updates / second.<br />
<br />
<pre><br />
base_uid = 7a70:00000100 <br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-pixel-count = 25<br />
spidev0.0-0-personality = 1<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 1<br />
spidev0.0-spi-speed = 100000<br />
</pre><br />
<br />
=== Two Pixel Strings, using the CE lines ===<br />
<br />
This example is for 25 WS2801 pixels and 32 LPD8806 pixels. Both strings run at 2Mhz and are connected to the spi bus, and we're using the CE chips to de-multiplex. We want to CE lines to be active-high.<br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-personality = 1<br />
spidev0.0-0-pixel-count = 25<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 1<br />
spidev0.0-spi-ce-high = true<br />
spidev0.0-spi-speed = 200000<br />
spidev0.1-0-dmx-address = 1<br />
spidev0.1-0-personality = 1<br />
spidev0.1-0-pixel-count = 25<br />
spidev0.1-backend = software<br />
spidev0.1-ports = 1<br />
spidev0.1-spi-ce-high = true<br />
spidev0.1-spi-speed = 200000 <br />
</pre><br />
<br />
=== Two Pixel Strings, using a single output ===<br />
<br />
This example is a string of 300 WS2801 pixels. Since this is more than one universe of data, we need to use multiple ports. <br />
<br />
<pre><br />
base_uid = 7a70:00000100<br />
device_prefix = spidev<br />
enabled = true<br />
spidev0.0-0-dmx-address = 1<br />
spidev0.0-0-personality = 1<br />
spidev0.0-0-pixel-count = 150<br />
spidev0.0-1-dmx-address = 1<br />
spidev0.0-1-personality = 1<br />
spidev0.0-1-pixel-count = 150<br />
spidev0.0-backend = software<br />
spidev0.0-ports = 2<br />
spidev0.0-spi-speed = 1000000<br />
spidev0.0-sync-port = -2<br />
</pre><br />
<br />
SPI data is written when data arrives on the second port (sync-port = -2). See the plugin description for more info.<br />
<br />
== Exported Variables ==<br />
<br />
The SPI plugin exports a number of useful variables. These can be found at http://<ip>:9090/debug. Each is indexed by the device name e.g. /dev/spi0.0 . <br />
<br />
;spi-writes<br />
: Number of writes to each SPI device<br />
; spi-write-errors<br />
: Number of writes that resulted in an error<br />
; spi-drops<br />
: Number of DMX updates that were skipped. The happens if DMX data is arriving faster than it can be written to the SPI bus.<br />
<br />
== Related Links ==<br />
<br />
http://www.solderlab.de/index.php/software/glediator (Pixel Control Software that outputs ArtNet)</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Thread_Scheduling&diff=5788OLA Thread Scheduling2014-12-29T04:43:06Z<p>Nomis52: /* Results */</p>
<hr />
<div>Since 0.9.4, OLA provides options to control the thread scheduling algorithms, when supported by the host kernel.<br />
<br />
Besides the default scheduling policy (SCHED_OTHER), OLA supports SCHED_RR and SCHED_FIFO. You can read about the differences on [http://www.linuxjournal.com/article/3910 The Linux Journal]. <br />
<br />
== Configuration ==<br />
<br />
If you're on Linux you need to edit <tt>/etc/security/limits.conf</tt> and add:<br />
<br />
<pre><br />
<username> hard rtprio 99<br />
<username> soft rtprio 50<br />
</pre><br />
<br />
Replace <username> with the user you run olad as.<br />
<br />
== Running OLA ==<br />
<br />
Start olad with <tt>--scheduler-policy</tt> and <tt>--scheduler-priority</tt>. You must provide both flags.<br />
<br />
<pre><br />
$ olad --scheduler-policy fifo --scheduler-priority 10<br />
</pre><br />
<br />
The --scheduler-priority flag must be a value less than or equal to the soft rtprio limit set in <tt>/etc/security/limits.conf</tt>. <br />
<br />
== Results ==<br />
<br />
The test setup was as follows:<br />
* Intel i5-3450, running Debian Wheezy, set to send ArtNet traffic on universe 1<br />
* Raspberry Pi, configured to receive ArtNet traffic and convert to sACN traffic on universe 1.<br />
* Both hosts connect to a netgear 5 port switch. The Pi was connected at 100Mbps, the Debian host at 1Gbps.<br />
<br />
On the Debian host, the traffic was generated with:<br />
<br />
<pre><br />
$ i=0; while :; do echo "$i"; i=$((i+1)); if [ $i == 256 ] ; then i=0; fi ; sleep 0.025; done | ola_streaming_client -u 1<br />
</pre><br />
<br />
And the packets captured with:<br />
<br />
<pre><br />
tcpdump -n '(port 5568 or port 6454) and (dst host 239.255.0.1 or dst host 192.168.3.115)' -c 10000 -s0 -w /tmp/savefile-fifo<br />
</pre><br />
<br />
On the Pi, the control was with no scheduling options. Then the fifo scheduler was enabled with <br />
<br />
<pre><br />
$ olad --scheduler-policy fifo --scheduler-priority 10<br />
</pre><br />
<br />
From the tcpdump, we can find the time between sending the ArtNet packet and receiving the E1.31 packet, and then plot these on a histogram:<br />
<br />
{| class="wikitable"<br />
! Scheduler<br />
! Mean (ms) <br />
! Standard Deviation<br />
! 90 percentile (ms)<br />
! 99 percentile (ms)<br />
! 99.9 percentile (ms)<br />
! Max (ms)<br />
|-<br />
| Control<br />
| 0.880 ms<br />
| 5.64791e-02<br />
| 0.920 ms<br />
| 1.018 ms<br />
| 1.842 ms<br />
| 2.252 ms<br />
|-<br />
| Fifo<br />
| 0.868 ms<br />
| 2.819106e-02<br />
| 0.909 ms<br />
| 0.958 ms<br />
| 1.010 ms<br />
| 1.132 ms<br />
|}<br />
<br />
[[File:Thread-scheduling-control.png]]<br />
<br />
[[File:Thread-scheduling-fifo.png]]</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Thread_Scheduling&diff=5787OLA Thread Scheduling2014-12-29T03:38:48Z<p>Nomis52: </p>
<hr />
<div>Since 0.9.4, OLA provides options to control the thread scheduling algorithms, when supported by the host kernel.<br />
<br />
Besides the default scheduling policy (SCHED_OTHER), OLA supports SCHED_RR and SCHED_FIFO. You can read about the differences on [http://www.linuxjournal.com/article/3910 The Linux Journal]. <br />
<br />
== Configuration ==<br />
<br />
If you're on Linux you need to edit <tt>/etc/security/limits.conf</tt> and add:<br />
<br />
<pre><br />
<username> hard rtprio 99<br />
<username> soft rtprio 50<br />
</pre><br />
<br />
Replace <username> with the user you run olad as.<br />
<br />
== Running OLA ==<br />
<br />
Start olad with <tt>--scheduler-policy</tt> and <tt>--scheduler-priority</tt>. You must provide both flags.<br />
<br />
<pre><br />
$ olad --scheduler-policy fifo --scheduler-priority 10<br />
</pre><br />
<br />
The --scheduler-priority flag must be a value less than or equal to the soft rtprio limit set in <tt>/etc/security/limits.conf</tt>. <br />
<br />
== Results ==<br />
<br />
The test setup was as follows:<br />
* Intel i5-3450, running Debian Wheezy, set to send ArtNet traffic on universe 1<br />
* Raspberry Pi, configured to receive ArtNet traffic and convert to sACN traffic on universe 1.<br />
* Both hosts connect to a netgear 5 port switch. The Pi was connected at 100Mbps, the Debian host at 1Gbps.<br />
<br />
On the Debian host, the traffic was generated with:<br />
<br />
<pre><br />
$ i=0; while :; do echo "$i"; i=$((i+1)); if [ $i == 256 ] ; then i=0; fi ; sleep 0.025; done | ola_streaming_client -u 1<br />
</pre><br />
<br />
And the packets captured with:<br />
<br />
<pre><br />
tcpdump -n '(port 5568 or port 6454) and (dst host 239.255.0.1 or dst host 192.168.3.115)' -c 10000 -s0 -w /tmp/savefile-fifo<br />
</pre><br />
<br />
On the Pi, the control was with no scheduling options. Then the fifo scheduler was enabled with <br />
<br />
<pre><br />
$ olad --scheduler-policy fifo --scheduler-priority 10<br />
</pre><br />
<br />
From the tcpdump, we can find the time between sending the ArtNet packet and receiving the E1.31 packet, and then plot these on a histogram:<br />
<br />
{|<br />
! Scenario<br />
! Mean<br />
! Standard Deviation<br />
! 90% <br />
! 99%<br />
! 99.9 %<br />
! Max<br />
|-<br />
| Control<br />
| 0.0008808826<br />
| 5.64791e-05<br />
| 0.000920000<br />
| 0.001018000<br />
| 0.001842056<br />
| 0.002252<br />
|-<br />
| Fifo<br />
| 0.0008681658<br />
| 2.819106e-05<br />
| 0.000909000<br />
| 0.000958020<br />
| 0.001010026<br />
| 0.001132<br />
|}<br />
<br />
[[File:Thread-scheduling-control.png]]<br />
<br />
[[File:Thread-scheduling-fifo.png]]</div>Nomis52https://wiki.openlighting.org/index.php?title=File:Thread-scheduling-fifo.png&diff=5786File:Thread-scheduling-fifo.png2014-12-29T03:25:48Z<p>Nomis52: </p>
<hr />
<div></div>Nomis52https://wiki.openlighting.org/index.php?title=File:Thread-scheduling-control.png&diff=5785File:Thread-scheduling-control.png2014-12-29T03:25:31Z<p>Nomis52: </p>
<hr />
<div></div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Thread_Scheduling&diff=5784OLA Thread Scheduling2014-12-29T03:24:35Z<p>Nomis52: </p>
<hr />
<div>Since 0.9.4, OLA provides options to control the thread scheduling algorithms, when supported by the host kernel.<br />
<br />
Besides the default scheduling policy (SCHED_OTHER), OLA supports SCHED_RR and SCHED_FIFO. You can read about the differences on [http://www.linuxjournal.com/article/3910 The Linux Journal]. <br />
<br />
== Configuration ==<br />
<br />
If you're on Linux you need to edit <tt>/etc/security/limits.conf</tt> and add:<br />
<br />
<pre><br />
<username> hard rtprio 99<br />
<username> soft rtprio 50<br />
</pre><br />
<br />
Replace <username> with the user you run olad as.<br />
<br />
== Running OLA ==<br />
<br />
Start olad with <tt>--scheduler-policy</tt> and <tt>--scheduler-priority</tt>. You must provide both flags.<br />
<br />
<pre><br />
$ olad --scheduler-policy fifo --scheduler-priority 10<br />
</pre><br />
<br />
The --scheduler-priority flag must be a value less than or equal to the soft rtprio limit set in <tt>/etc/security/limits.conf</tt>. <br />
<br />
== Results ==<br />
<br />
The test setup was as follows:<br />
* Intel i5-3450, running Debian Wheezy, set to send ArtNet traffic on universe 1<br />
* Raspberry Pi, configured to receive ArtNet traffic and convert to sACN traffic on universe 1.<br />
* Both hosts connect to a netgear 5 port switch. The Pi was connected at 100Mbps, the Debian host at 1Gbps.<br />
<br />
On the Debian host, the traffic was generated with:<br />
<br />
<pre><br />
$ i=0; while :; do echo "$i"; i=$((i+1)); if [ $i == 256 ] ; then i=0; fi ; sleep 0.025; done | ola_streaming_client -u 1<br />
</pre><br />
<br />
And the packets captured with:<br />
<br />
<pre><br />
tcpdump -n '(port 5568 or port 6454) and (dst host 239.255.0.1 or dst host 192.168.3.115)' -c 10000 -s0 -w /tmp/savefile-fifo<br />
</pre><br />
<br />
On the Pi, the control was with no scheduling options. Then the fifo scheduler was enabled with <br />
<br />
<pre><br />
$ olad --scheduler-policy fifo --scheduler-priority 10<br />
</pre><br />
<br />
From the tcpdump, we can find the time between sending the ArtNet packet and receiving the E1.31 packet, and then plot these on a histogram:</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Buildbot&diff=5777OLA Buildbot2014-12-28T16:30:11Z<p>Nomis52: </p>
<hr />
<div>We run a [http://buildbot.net/ Buildbot] instance for [[OLA]].<br />
<br />
*Web UI: http://buildbot.openlighting.org<br />
*IRC: OLA-buildbot-ch in #openlighting-build on irc.freenode.org<br />
<br />
We're currently only building ola, but this could be extended to do other projects such as the QT GUI etc.<br />
<br />
== Master Configuration ==<br />
The buildbot master configuration is stored in git at https://github.com/OpenLightingProject/buildbot . It needs checking out, and symlinking to replace master.cfg in the buildbot master's config directory.<br />
<br />
N.B. If the main open-lighting git repository (as opposed to buildbot config) is ever moved or changed, ensure the master's gitpoller-workdir folder is emptied out, or the poller won't work properly.<br />
<br />
= Adding a Slave =<br />
<br />
Buildbot documentation is at http://docs.buildbot.net/current/manual/installation.html#creating-a-buildslave . The steps below should cover everything you need though.<br />
<br />
== Prerequisites & Warning ==<br />
<br />
Slaves execute code directly from the git repo. Even though submits to the git repo are locked down, this is still a possible attack vector for your machine. For this reason it's best to run build slaves within a virtual machine. TODO: link to some VM solutions.<br />
<br />
At the very least you should run the buildslave as a separate user (not root!). Slave passwords aren't stored in the git repo for security, you'll need to get Simon to add new ones.<br />
<br />
The buildbot performs full build & test runs with all the options enabled. Please make sure you have all the necessary libraries installed on your system. You need to be able to complete a <br />
<br />
<pre><br />
autoconf -i<br />
./configure --enable-e133 --enable-rdm-tests --enable-python-libs<br />
make<br />
make check<br />
</pre><br />
<br />
cycle before proceeding. If you have trouble ask on the mailing list.<br />
<br />
If you're running the lint check, you need ccplint.py in your path somewhere, see README.developer for info on how to obtain it.<br />
<br />
Buildbot slaves need to connect to buildmaster.openlighting.org:9989 . Make sure your firewall allows this. No port forwarding for inbound connections is required.<br />
<br />
== Debian / Ubuntu Instructions ==<br />
<br />
This requires wheezy or later. For squeeze you can use the easy_install method below.<br />
<br />
=== Build Slave Installation ===<br />
<br />
<pre><br />
sudo apt-get install buildbot-slave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Create the slave (the package creates the buildbot user automatically for you):<br />
<br />
<pre><br />
sudo -u buildbot buildslave create-slave --usepty=0 /var/lib/buildbot/slaves/ola buildmaster.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Update the slave info, edit the files in /var/lib/buildbot/slaves/ola/info to be relevant to you.<br />
<br />
Add config for the slave into /etc/default/buildslave (you'll need to increase the array id if you've got more than one slave on the same host), e.g.:<br />
<pre><br />
SLAVE_ENABLED[1]=1 # 1-enabled, 0-disabled<br />
SLAVE_NAME[1]="ola" # short name printed on start/stop<br />
SLAVE_USER[1]="buildbot" # user to run slave as<br />
SLAVE_BASEDIR[1]="/var/lib/buildbot/slaves/ola" # basedir to slave (absolute path)<br />
SLAVE_OPTIONS[1]="" # buildbot options<br />
SLAVE_PREFIXCMD[1]="" # prefix command, i.e. nice, linux32, dchroot<br />
</pre><br />
<br />
Start the slave<br />
sudo /etc/init.d/buildslave start<br />
<br />
Check the log if there are any issues, or confirm the slave is registered at http://buildbot.openlighting.org/buildslaves:<br />
tail -f /var/lib/buildbot/slaves/ola/twistd.log<br />
<br />
== FreeBSD Instructions ==<br />
<br />
This was tested on FreeBSD 10.<br />
<br />
=== Build Slave Installation ===<br />
As root:<br />
<pre><br />
pkg install buildbot-slave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Setup a new user:<br />
<br />
<pre><br />
su -<br />
adduser<br />
</pre><br />
Username: ola-build-slave<br />
Use password-based authentication? No<br />
<br />
Setup the slave:<br />
<br />
Switch to the slave user, I did:<br />
<pre><br />
su - #To root<br />
su - ola-build-slave #To slave user<br />
cd ~<br />
</pre><br />
<br />
Export the variables needed for configure on FreeBSD:<br />
<pre><br />
export CPPFLAGS="-I/usr/local/include/"<br />
export LDFLAGS="-L/usr/local/lib/"<br />
</pre><br />
<br />
Setup the slave itself:<br />
<pre><br />
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.<br />
<br />
Then start the slave:<br />
<br />
<pre><br />
/usr/local/bin/buildslave start ola-slave<br />
</pre><br />
<br />
You can look at the logs by running<br />
<br />
<pre><br />
tail -f ola-slave/twistd.log<br />
</pre><br />
<br />
At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.<br />
<br />
Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:<br />
<br />
<pre><br />
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave<br />
</pre><br />
<br />
<br />
== NetBSD Instructions ==<br />
<br />
This was tested on NetBSD 6.<br />
<br />
=== Build Slave Installation ===<br />
As root:<br />
<pre><br />
pkgin install py27-buildbot-slave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Setup a new user:<br />
<br />
<pre><br />
su -<br />
useradd -m ola-build-slave<br />
</pre><br />
Use password-based authentication? No<br />
<br />
Setup the slave:<br />
<br />
Switch to the slave user:<br />
<pre><br />
su - ola-build-slave<br />
cd ~<br />
</pre><br />
<br />
Export the variables needed for git and configure on NetBSD (add these to the .shrc or equivalent for next time):<br />
<pre><br />
export CPPFLAGS="-I/usr/pkg/include/"<br />
export LDFLAGS="-L/usr/pkg/lib/"<br />
export GIT_SSL_NO_VERIFY=true<br />
</pre><br />
<br />
Setup the slave itself:<br />
<pre><br />
/usr/pkg/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.<br />
<br />
Then start the slave:<br />
<br />
<pre><br />
/usr/pkg/bin/buildslave start ola-slave<br />
</pre><br />
<br />
You can look at the logs by running<br />
<br />
<pre><br />
tail -f ola-slave/twistd.log<br />
</pre><br />
<br />
At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.<br />
<br />
Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:<br />
<br />
<pre><br />
@reboot /usr/pkg/bin/buildslave start /home/ola-build-slave/ola-slave<br />
</pre><br />
<br />
== OpenBSD Instructions ==<br />
<br />
This was tested on OpenBSD 5.4.<br />
<br />
=== Build Slave Installation ===<br />
As root:<br />
<pre><br />
pkg_add py-buildslave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Setup a new user:<br />
<br />
<pre><br />
su -<br />
useradd -m ola-build-slave<br />
</pre><br />
<br />
Setup the slave:<br />
<br />
Switch to the slave user:<br />
<pre><br />
su - ola-build-slave<br />
cd ~<br />
</pre><br />
<br />
Export the variables needed for autoconf and configure on OpenBSD (add these to the .profile or equivalent for next time):<br />
<pre><br />
export AUTOCONF_VERSION=2.69<br />
export AUTOMAKE_VERSION=1.13<br />
export CPPFLAGS="-I/usr/local/include/"<br />
export LDFLAGS="-L/usr/local/lib/"<br />
</pre><br />
<br />
Setup the slave itself:<br />
<pre><br />
/usr/local/bin/buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.<br />
<br />
Then start the slave:<br />
<br />
<pre><br />
/usr/local/bin/buildslave start ola-slave<br />
</pre><br />
<br />
You can look at the logs by running<br />
<br />
<pre><br />
tail -f ola-slave/twistd.log<br />
</pre><br />
<br />
At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.<br />
<br />
Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:<br />
<br />
<pre><br />
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave<br />
</pre><br />
<br />
== Other Platforms ==<br />
<br />
=== Build Slave Installation ===<br />
<br />
The easiest way to get started is by using easy_install. You need to have the Python headers available, so on Debian / Ubuntu run:<br />
<br />
<pre><br />
sudo apt-get install python-dev<br />
</pre><br />
<br />
Then install buildbot-slave:<br />
<br />
<pre><br />
easy_install buildbot-slave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Setup a new user:<br />
<br />
<pre><br />
sudo -s <br />
adduser ola-build-slave # use a temp password for now<br />
vi /etc/shadow # delete the password entry<br />
</pre><br />
<br />
Setup the slave:<br />
<br />
<pre><br />
su ola-build-slave<br />
cd ~<br />
buildslave create-slave ola-slave buildmaster.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.<br />
<br />
Then start the slave:<br />
<br />
<pre><br />
buildslave start ola-slave<br />
</pre><br />
<br />
You can look at the logs by running<br />
<br />
<pre><br />
tail -f ola-slave/twistd.log<br />
</pre><br />
<br />
At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.<br />
<br />
Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:<br />
<br />
<pre><br />
@reboot buildbot start /home/ola-build-slave/ola-slave<br />
</pre><br />
<br />
== Enabling the C++ Lint Checker ==<br />
<br />
The lint checker enforces C++ style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.<br />
<br />
Download the cpplint checker and put it in /usr/local/bin<br />
<br />
<pre><br />
wget http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py<br />
sudo cp cpplint.py /usr/local/bin<br />
sudo chmod a+x /usr/local/bin/cpplint.py<br />
</pre><br />
<br />
Finally let Simon or Peter know, or raise an issue, asking them to enable C++ lint for your slave.<br />
<br />
== Enabling the Javascript Lint Checker ==<br />
<br />
The lint checker enforces Javascript style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.<br />
<br />
Install the gjslint checker by following the relevant instructions here (you man need to install python-setuptools to get easy_install on Debian/Ubuntu):<br />
https://developers.google.com/closure/utilities/docs/linter_howto<br />
<br />
Finally let Simon or Peter know, or raise an issue, asking them to enable Javascript lint for your slave.<br />
<br />
== Enabling the heap checker ==<br />
<br />
First we need libunwind:<br />
<br />
<pre><br />
sudo apt-get install libunwind8-dev <br />
</pre><br />
<br />
Then download the latest gperftools from https://code.google.com/p/gperftools/downloads/list .<br />
<br />
<pre><br />
wget ....<br />
tar -zxf gperftools-2.1.tar.gz<br />
cd gperftools-2.1<br />
./configure<br />
make<br />
sudo make install<br />
sudo ldconfig<br />
</pre><br />
Finally let Simon or Peter know, or raise an issue, asking them to enable the heap checker for your slave.</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Buildbot&diff=5776OLA Buildbot2014-12-28T16:28:33Z<p>Nomis52: /* Slave Configuration */</p>
<hr />
<div>We run a [http://buildbot.net/ Buildbot] instance for [[OLA]].<br />
<br />
*Web UI: http://buildbot.openlighting.org<br />
*IRC: OLA-buildbot-ch in #openlighting-build on irc.freenode.org<br />
<br />
We're currently only building ola, but this could be extended to do other projects such as the QT GUI etc.<br />
<br />
== Master Configuration ==<br />
The buildbot master configuration is stored in git at https://github.com/OpenLightingProject/buildbot . It needs checking out, and symlinking to replace master.cfg in the buildbot master's config directory.<br />
<br />
N.B. If the main open-lighting git repository (as opposed to buildbot config) is ever moved or changed, ensure the master's gitpoller-workdir folder is emptied out, or the poller won't work properly.<br />
<br />
= Adding a Slave =<br />
<br />
Buildbot documentation is at http://docs.buildbot.net/current/manual/installation.html#creating-a-buildslave . The steps below should cover everything you need though.<br />
<br />
== Prerequisites & Warning ==<br />
<br />
Slaves execute code directly from the git repo. Even though submits to the git repo are locked down, this is still a possible attack vector for your machine. For this reason it's best to run build slaves within a virtual machine. TODO: link to some VM solutions.<br />
<br />
At the very least you should run the buildslave as a separate user (not root!). Slave passwords aren't stored in the git repo for security, you'll need to get Simon to add new ones.<br />
<br />
The buildbot performs full build & test runs with all the options enabled. Please make sure you have all the necessary libraries installed on your system. You need to be able to complete a <br />
<br />
<pre><br />
autoconf -i<br />
./configure --enable-e133 --enable-rdm-tests --enable-python-libs<br />
make<br />
make check<br />
</pre><br />
<br />
cycle before proceeding. If you have trouble ask on the mailing list.<br />
<br />
If you're running the lint check, you need ccplint.py in your path somewhere, see README.developer for info on how to obtain it.<br />
<br />
Buildbot slaves need to connect to buildbot.openlighting.org:9989 . Make sure your firewall allows this. No port forwarding for inbound connections is required.<br />
<br />
== Debian / Ubuntu Instructions ==<br />
<br />
This requires wheezy or later. For squeeze you can use the easy_install method below.<br />
<br />
=== Build Slave Installation ===<br />
<br />
<pre><br />
sudo apt-get install buildbot-slave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Create the slave (the package creates the buildbot user automatically for you):<br />
<br />
<pre><br />
sudo -u buildbot buildslave create-slave --usepty=0 /var/lib/buildbot/slaves/ola buildmaster.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Update the slave info, edit the files in /var/lib/buildbot/slaves/ola/info to be relevant to you.<br />
<br />
Add config for the slave into /etc/default/buildslave (you'll need to increase the array id if you've got more than one slave on the same host), e.g.:<br />
<pre><br />
SLAVE_ENABLED[1]=1 # 1-enabled, 0-disabled<br />
SLAVE_NAME[1]="ola" # short name printed on start/stop<br />
SLAVE_USER[1]="buildbot" # user to run slave as<br />
SLAVE_BASEDIR[1]="/var/lib/buildbot/slaves/ola" # basedir to slave (absolute path)<br />
SLAVE_OPTIONS[1]="" # buildbot options<br />
SLAVE_PREFIXCMD[1]="" # prefix command, i.e. nice, linux32, dchroot<br />
</pre><br />
<br />
Start the slave<br />
sudo /etc/init.d/buildslave start<br />
<br />
Check the log if there are any issues, or confirm the slave is registered at http://buildbot.openlighting.org/buildslaves:<br />
tail -f /var/lib/buildbot/slaves/ola/twistd.log<br />
<br />
== FreeBSD Instructions ==<br />
<br />
This was tested on FreeBSD 10.<br />
<br />
=== Build Slave Installation ===<br />
As root:<br />
<pre><br />
pkg install buildbot-slave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Setup a new user:<br />
<br />
<pre><br />
su -<br />
adduser<br />
</pre><br />
Username: ola-build-slave<br />
Use password-based authentication? No<br />
<br />
Setup the slave:<br />
<br />
Switch to the slave user, I did:<br />
<pre><br />
su - #To root<br />
su - ola-build-slave #To slave user<br />
cd ~<br />
</pre><br />
<br />
Export the variables needed for configure on FreeBSD:<br />
<pre><br />
export CPPFLAGS="-I/usr/local/include/"<br />
export LDFLAGS="-L/usr/local/lib/"<br />
</pre><br />
<br />
Setup the slave itself:<br />
<pre><br />
/usr/local/bin/buildslave create-slave ola-slave buildbot.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.<br />
<br />
Then start the slave:<br />
<br />
<pre><br />
/usr/local/bin/buildslave start ola-slave<br />
</pre><br />
<br />
You can look at the logs by running<br />
<br />
<pre><br />
tail -f ola-slave/twistd.log<br />
</pre><br />
<br />
At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.<br />
<br />
Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:<br />
<br />
<pre><br />
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave<br />
</pre><br />
<br />
<br />
== NetBSD Instructions ==<br />
<br />
This was tested on NetBSD 6.<br />
<br />
=== Build Slave Installation ===<br />
As root:<br />
<pre><br />
pkgin install py27-buildbot-slave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Setup a new user:<br />
<br />
<pre><br />
su -<br />
useradd -m ola-build-slave<br />
</pre><br />
Use password-based authentication? No<br />
<br />
Setup the slave:<br />
<br />
Switch to the slave user:<br />
<pre><br />
su - ola-build-slave<br />
cd ~<br />
</pre><br />
<br />
Export the variables needed for git and configure on NetBSD (add these to the .shrc or equivalent for next time):<br />
<pre><br />
export CPPFLAGS="-I/usr/pkg/include/"<br />
export LDFLAGS="-L/usr/pkg/lib/"<br />
export GIT_SSL_NO_VERIFY=true<br />
</pre><br />
<br />
Setup the slave itself:<br />
<pre><br />
/usr/pkg/bin/buildslave create-slave ola-slave buildbot.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.<br />
<br />
Then start the slave:<br />
<br />
<pre><br />
/usr/pkg/bin/buildslave start ola-slave<br />
</pre><br />
<br />
You can look at the logs by running<br />
<br />
<pre><br />
tail -f ola-slave/twistd.log<br />
</pre><br />
<br />
At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.<br />
<br />
Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:<br />
<br />
<pre><br />
@reboot /usr/pkg/bin/buildslave start /home/ola-build-slave/ola-slave<br />
</pre><br />
<br />
== OpenBSD Instructions ==<br />
<br />
This was tested on OpenBSD 5.4.<br />
<br />
=== Build Slave Installation ===<br />
As root:<br />
<pre><br />
pkg_add py-buildslave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Setup a new user:<br />
<br />
<pre><br />
su -<br />
useradd -m ola-build-slave<br />
</pre><br />
<br />
Setup the slave:<br />
<br />
Switch to the slave user:<br />
<pre><br />
su - ola-build-slave<br />
cd ~<br />
</pre><br />
<br />
Export the variables needed for autoconf and configure on OpenBSD (add these to the .profile or equivalent for next time):<br />
<pre><br />
export AUTOCONF_VERSION=2.69<br />
export AUTOMAKE_VERSION=1.13<br />
export CPPFLAGS="-I/usr/local/include/"<br />
export LDFLAGS="-L/usr/local/lib/"<br />
</pre><br />
<br />
Setup the slave itself:<br />
<pre><br />
/usr/local/bin/buildslave create-slave ola-slave buildbot.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.<br />
<br />
Then start the slave:<br />
<br />
<pre><br />
/usr/local/bin/buildslave start ola-slave<br />
</pre><br />
<br />
You can look at the logs by running<br />
<br />
<pre><br />
tail -f ola-slave/twistd.log<br />
</pre><br />
<br />
At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.<br />
<br />
Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:<br />
<br />
<pre><br />
@reboot /usr/local/bin/buildslave start /home/ola-build-slave/ola-slave<br />
</pre><br />
<br />
== Other Platforms ==<br />
<br />
=== Build Slave Installation ===<br />
<br />
The easiest way to get started is by using easy_install. You need to have the Python headers available, so on Debian / Ubuntu run:<br />
<br />
<pre><br />
sudo apt-get install python-dev<br />
</pre><br />
<br />
Then install buildbot-slave:<br />
<br />
<pre><br />
easy_install buildbot-slave<br />
</pre><br />
<br />
=== Slave Configuration ===<br />
<br />
Setup a new user:<br />
<br />
<pre><br />
sudo -s <br />
adduser ola-build-slave # use a temp password for now<br />
vi /etc/shadow # delete the password entry<br />
</pre><br />
<br />
Setup the slave:<br />
<br />
<pre><br />
su ola-build-slave<br />
cd ~<br />
buildslave create-slave ola-slave buildbot.openlighting.org:9989 <slave user> <slave password><br />
</pre><br />
<br />
Edit <tt>ola-slave/info/admin</tt> and <tt>ola-slave/info/host</tt> so your slave shows up correctly.<br />
<br />
Then start the slave:<br />
<br />
<pre><br />
buildslave start ola-slave<br />
</pre><br />
<br />
You can look at the logs by running<br />
<br />
<pre><br />
tail -f ola-slave/twistd.log<br />
</pre><br />
<br />
At this point you can go to http://buildbot.openlighting.org/buildslaves and you should see your slave connected. It's probably worth asking someone to kick off a build at this point so we can check your slave is working.<br />
<br />
Finally, if everything looks good, configure your slave to launch on startup by editing the crontab for the ola-build-slave user (crontab -e). Add the following line:<br />
<br />
<pre><br />
@reboot buildbot start /home/ola-build-slave/ola-slave<br />
</pre><br />
<br />
== Enabling the C++ Lint Checker ==<br />
<br />
The lint checker enforces C++ style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.<br />
<br />
Download the cpplint checker and put it in /usr/local/bin<br />
<br />
<pre><br />
wget http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py<br />
sudo cp cpplint.py /usr/local/bin<br />
sudo chmod a+x /usr/local/bin/cpplint.py<br />
</pre><br />
<br />
Finally let Simon or Peter know, or raise an issue, asking them to enable C++ lint for your slave.<br />
<br />
== Enabling the Javascript Lint Checker ==<br />
<br />
The lint checker enforces Javascript style. We only run this once per change but it's good to have multiple lint-enabled hosts in case one is down.<br />
<br />
Install the gjslint checker by following the relevant instructions here (you man need to install python-setuptools to get easy_install on Debian/Ubuntu):<br />
https://developers.google.com/closure/utilities/docs/linter_howto<br />
<br />
Finally let Simon or Peter know, or raise an issue, asking them to enable Javascript lint for your slave.<br />
<br />
== Enabling the heap checker ==<br />
<br />
First we need libunwind:<br />
<br />
<pre><br />
sudo apt-get install libunwind8-dev <br />
</pre><br />
<br />
Then download the latest gperftools from https://code.google.com/p/gperftools/downloads/list .<br />
<br />
<pre><br />
wget ....<br />
tar -zxf gperftools-2.1.tar.gz<br />
cd gperftools-2.1<br />
./configure<br />
make<br />
sudo make install<br />
sudo ldconfig<br />
</pre><br />
Finally let Simon or Peter know, or raise an issue, asking them to enable the heap checker for your slave.</div>Nomis52https://wiki.openlighting.org/index.php?title=OlaOutput_Max_External&diff=5774OlaOutput Max External2014-12-20T17:52:55Z<p>Nomis52: /* Download and Install OLA */</p>
<hr />
<div>=== How to use the OlaOutput Max External ===<br />
<br />
<br />
'''This article describes how to configure OlaOutput on Mac OS X 10.6 (or greater) for use in Cycling 74's Max/MSP/Jitter or Ableton MaxForLive environments. The object is compatible with Max 5 and 6 (both 32-bit and 64-bit versions), and Ableton Live 8 and 9.<br />
'''<br />
<br />
<br />
==Download and Install OLA==<br />
<br />
<br />
*[https://github.com/OpenLightingProject/ola/releases Download the latest build of OLA] and install it. OlaOutput is only compatible with OS X (for now).<br />
<br />
*IMPORTANT: If you are planning on [http://opendmx.net/index.php/OLA_Install_Using_MacPorts installing OLA via MacPorts], you must install OLA with the '''+universal''' option<br />
<br />
*OLA is a separate application from Ableton Live and Max/MSP/Jitter. To use OlaOutput to send DMX, you need to start the OLA daemon first. <br />
'''NOTE:''' Before you do this, make sure any USB devices you wish to use are plugged in and their drivers are installed.<br />
<br />
<br />
*Open Terminal (found in Applications/Utilities), type the following and press enter:<br />
<br />
<code><pre>olad</pre></code><br />
<br />
This starts the OLA daemon.<br />
<br />
==Configure OLA==<br />
<br />
<br />
*OLA has a HTTP web interface for configuration. You can access it at: [http://localhost:9090 http://localhost:9090]<br />
<br />
<br />
*OLA won’t do anything until it’s configured. You need to setup which DMX universe each hardware device will operate on. To do this, select ‘Devices’ from the left-hand menu in the OLA web interface.<br />
<br />
<br />
*Click on the + next to the device you wish to use. You will see a variety of boxes labeled ‘IN’ and ‘OUT’. We want to configure a universe for output, so choose the correct ‘OUT’ box for the port you wish to use and enter a number into it to specify the universe. A universe value of 1 a typical starting value.<br />
<br />
<br />
*Once you’ve done this, click ’Save Changes’ at the bottom of the list.<br />
<br />
<br />
*Click on ‘Universes’ on the left-hand menu. You should now see a list of the universes specified for output, which should include the one you just specified.<br />
<br />
<br />
*Click on the 'Console' link, and use the sliders to test that OLA is controlling your DMX devices<br />
<br />
<br />
==Install and Use OlaOutput in Max/MSP/Jitter==<br />
<br />
<br />
*To install OlaOutput as a Max/MSP external, [http://code.google.com/p/olaoutput/downloads/list download the latest version] and place the files in a folder somewhere on your system. Make a note of this path for the next step.<br />
<br />
<br />
*Load Max/MSP. Choose ''Options>File Preferences…''. Then use the plus button on the lower left to add the path to the folder containing the externals you wish to install. This will tell Max to look in this folder for externals to use. Make sure you keep the files in this place, or Max will be unable to locate them. <br />
<br />
<br />
*Create a new Max patcher, and add an olaoutput object. If Max is unable to find olaoutput, it will log a message to its output window.<br />
<br />
<br />
*The OlaOutput object has 2 inlets. The left inlet is used to send a series of DMX messages using the list structure. The (optional) right inlet is used to set the universe that is the destination for messages. For further details about how to use OlaOutput in Max, consult the ''olaoutput.maxhelp'' file included in the download (you can access this quickly from Max by alt-clicking on the object).<br />
<br />
<br />
*Create a message object in Max with the values <code>128 200 250</code> (separated by spaces). Connect the outlet of this message object to the left inlet of the OlaOutput object.<br />
<br />
<br />
*Lock the patcher, and click on the message object. The above values (128, 200, 250) should be sent out to channels 1, 2, 3 respectively.<br />
<br />
<br />
==Wrapping Up==<br />
<br />
<br />
*Once you’re done, you can shut down olad using the 'stop olad' link on the ‘Home’ page of OLA's web interface. OLA will remember your universe patchings next time you start it up.<br />
<br />
<br />
For additional help and information about OLA, visit the [[OLA| OLA Wiki]] page.<br />
<br />
[[Category:Articles]]</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Mac_Install_From_Tarball&diff=5773OLA Mac Install From Tarball2014-12-20T17:51:38Z<p>Nomis52: /* Download OLA */</p>
<hr />
<div>{{ MacInstallPrep }}<br />
<br />
= Download OLA =<br />
<br />
Download the latest tarball from https://github.com/OpenLightingProject/ola/releases.<br />
<br />
Extract the tarball:<br />
<br />
tar -zxf ola-0.X.Y.tar.gz<br />
cd ola-0.X.Y<br />
<br />
{{ MacOLABuild }}<br />
<br />
= Common Problems =<br />
<br />
See [[Common Problems When Building OLA on Mac]]</div>Nomis52https://wiki.openlighting.org/index.php?title=Using_OLA_with_Xcode&diff=5772Using OLA with Xcode2014-12-20T17:49:49Z<p>Nomis52: </p>
<hr />
<div>You can use OLA to implement your application in Objective-C++, a bridge between Objective-C and C++. This page explains how to integrate OLA client into your program. <br />
<br />
See also: http://www.bennigraf.de/wp-content/uploads/2012/11/writing-scola.pdf<br />
<br />
<br />
==What you'll need==<br />
* Xcode<br />
* [http://www.openlighting.org/ola/mac-install/ OLA for Mac OS X] installed<br />
<br />
== Create a new Project ==<br />
# File -> New Project, from the right under Mac OS X, select 'Application', then in the left panel choose 'Cocoa Application' <br />
# Once the main window pops up, right click the 'main.m' file and select rename. Change the name to 'main.mm' (required for Objective-C++ extensions)<br />
<br />
==Configure your project==<br />
# Select menu: "Project" -> "Edit Project Settings". All settings below are referred in a "Build" tab<br />
# Under 'Search Paths', set "Header Search Paths" to /usr/local/include (Source) or /opt/local/include (MacPorts) , depending on how you installed OLA.<br />
<br />
==Add the required libraries==<br />
# In your project tree, right-click on a group that contain frameworks (e.g. "External Frameworks and Libraries", "Frameworks/Linked Frameworks"), select "Add" -> "Existing Frameworks"<br />
# Select following frameworks:<br />
#* libprotobuf.dylib<br />
#* libola.dylib<br />
#* libolacommon.dylib<br />
<br />
==Example code==<br />
The following code sends value 255 to channel 0 in universe 0. First, it creates a client from a SimpleClient object. Then, it creates a DMX buffer and sets channel 0 to 255. Finally it sends the buffer to a server. <br />
<br />
#import <Cocoa/Cocoa.h> <br />
#import <ola/DmxBuffer.h><br />
#import <ola/SimpleClient.h><br />
<br />
int main(int argc, char *argv[]) {<br />
ola::SimpleClient simpleClient;<br />
if (!simpleClient.Setup()) {<br />
NSLog(@"Client setup failed");<br />
return -1;<br />
}<br />
<br />
ola::OlaClient *client = simpleClient.GetClient();<br />
<br />
ola::DmxBuffer buffer;<br />
buffer.Blackout();<br />
buffer.SetChannel(0, 255);<br />
<br />
unsigned int universe = 0;<br />
if (!client->SendDmx(universe, buffer)) {<br />
NSLog(@"Sending DMX failed");<br />
}<br />
return 0;<br />
// you could also run the main app here<br />
return NSApplicationMain(argc, (const char **) argv);<br />
}<br />
<br />
You can find more information by browsing the source file of [http://linux-lighting.googlecode.com/files/ola-examples-0.6.0.tar.gz DMX example]. For me, the src/ola-client.cpp is quite useful.<br />
<br />
Here is another example that create OlaServer and communicate with a pipe socket.<br />
<br />
#import <Foundation/Foundation.h><br />
#include <errno.h><br />
#import <ola/DmxBuffer.h><br />
#import <ola/OlaClient.h><br />
#import <ola/network/SelectServer.h><br />
#import <ola/network/Socket.h><br />
<br />
using ola::network::PipeSocket;<br />
<br />
// define type for DMX message<br />
typedef unsigned char dmx_t ;<br />
<br />
// maximum number of channels<br />
int MAXCHANNELS=512;<br />
<br />
int main (int argc, const char * argv[]) {<br />
NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];<br />
<br />
// create a server <br />
ola::network::SelectServer server;<br />
<br />
// create a select server <br />
ola::network::SelectServer server;<br />
<br />
// create pipe socket<br />
PipeSocket *socket = new PipeSocket();<br />
if (!socket->Init())<br />
{<br />
NSLog(@"Cannot create pipe socket");<br />
return -1;<br />
}<br />
<br />
// add socket to select server<br />
server.AddSocket(socket, true);<br />
<br />
// create server daemon<br />
// *** see: olad/Olad.cpp for more detail ***<br />
<br />
// get a client<br />
ola::OlaClient client(socket);<br />
if (!client.Setup()) {<br />
NSLog(@"Client setup failed %s", strerror(errno));<br />
return -1;<br />
}<br />
<br />
// prepare data<br />
int channel = 0;<br />
dmx_t *dmx = (dmx_t *)calloc(MAXCHANNELS + 10, sizeof(dmx_t));<br />
dmx[channel] = 255;<br />
ola::DmxBuffer buffer(dmx, MAXCHANNELS);<br />
<br />
<br />
// send DMX message<br />
int universe = 0;<br />
if (!client.SendDmx(universe, buffer)) {<br />
NSLog(@"Sending DMX failed %s", strerror(errno));<br />
}<br />
<br />
// cleanup<br />
free(dmx);<br />
<br />
[pool drain];<br />
return 0;<br />
}</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_Patch_persistency&diff=5771OLA Patch persistency2014-12-20T17:47:01Z<p>Nomis52: /* Patch Persistency */</p>
<hr />
<div>= Patch Persistency =<br />
The patch persistency information is stored in plain text files inside your configuration folder (~/.ola by default, or/var/lib/ola/conf if you're using the Raspberry Pi image.)<br />
<br />
The "universe" information is stored inside "ola-universe.conf"<br />
<br />
The "patch" information is stored inside "ola-port.conf"<br />
<br />
To start with something clean we can delete the "ola-universe.conf" and "ola-port.conf" files and ola will create them again when stopping ola.<br />
<br />
Note : olad only writes it's patch files when it exists. That means that is the computer is crashing or if ola is crashing, the patch is not stored in files (see Issue [https://github.com/OpenLightingProject/ola/issues/125 125] ).<br />
<br />
== Example ==<br />
We are going to patch an ArtNet universe as an input with a DmxKing ultraDMX Micro as an output.<br />
<br />
On this example, I have enabled only the plugins :<br />
* ArtNet<br />
and<br />
* Serial USB<br />
setting all the plugins in the config folder with<br />
enabled = false<br />
except the 2 ones needed witch i have enabled using<br />
enabled = true<br />
<br />
=== Starting ola ===<br />
We are starting olad using either the command<br />
/etc/init.d/olad start<br />
or<br />
olad -l 3<br />
-l 3 : means that we are starting olad with the login level 3<br />
<br />
=== Getting devices info ===<br />
To get the devices info we are using the command<br />
ola_device_info<br />
That is returning :<br />
Device 1: ArtNet [10.0.0.2]<br />
port 0, IN , priority 100, RDM supported<br />
port 1, IN , priority 100, RDM supported<br />
port 2, IN , priority 100, RDM supported<br />
port 3, IN , priority 100, RDM supported<br />
port 0, OUT , RDM supported<br />
port 1, OUT , RDM supported<br />
port 2, OUT , RDM supported<br />
port 3, OUT , RDM supported<br />
Device 2: DMXking.com - ultraDMX Micro<br />
port 0, IN Serial #: 84000775, priority 100<br />
port 0, OUT Serial #: 84000775, RDM supported<br />
<br />
=== Patching the devices ===<br />
First we are patching the ArtNet device using<br />
ola_patch -d 1 -i -p 0 -u 0<br />
That means :<br />
patch device 1 (-d 1) input (-i) port 0 (-p 0) to the universe 0 (-u 0)<br />
(ola is using the output port as the default one, this is why we need to tell it to use the input using -i.<br />
<br />
Then we are patching the ultraDMX micro using<br />
ola_patch -d 2 -p 0 -u 0<br />
<br />
Now the device info is returning<br />
Device 1: ArtNet [10.0.0.2]<br />
port 0, IN ArtNet Universe 0:0:0, priority 100, patched to universe 0, RDM supported<br />
port 1, IN , priority 100, RDM supported<br />
port 2, IN , priority 100, RDM supported<br />
port 3, IN , priority 100, RDM supported<br />
port 0, OUT , RDM supported<br />
port 1, OUT , RDM supported<br />
port 2, OUT , RDM supported<br />
port 3, OUT , RDM supported<br />
Device 2: DMXking.com - ultraDMX Micro<br />
port 0, IN Serial #: 84000775, priority 100<br />
port 0, OUT Serial #: 84000775, patched to universe 0, RDM supported<br />
<br />
=== Resulted files ===<br />
After stopping ola (using "/etc/init.d/olad stop" or "ctrl+c" (if running it directly on the command line))<br />
<br />
The ola-port.conf and ola-universe.conf are filled with the infos.<br />
<br />
==== ola-universe.conf ====<br />
Here is the content of this file<br />
uni_0_merge = LTP<br />
uni_0_name = Universe 0<br />
LTP priority is set by default.<br />
<br />
A default name "Universe 0" was given to the universe 0.<br />
<br />
==== ola-port.conf ====<br />
Here is the content of this file<br />
2-1-I-0 = 0<br />
2-1-I-0_priority_value = 100<br />
2-1-I-1_priority_value = 100<br />
2-1-I-2_priority_value = 100<br />
2-1-I-3_priority_value = 100<br />
5-84000775-I-0_priority_value = 100<br />
5-84000775-O-0 = 0<br />
<br />
What does it mean ?<br />
<br />
First we need to know about the plugins ids.<br />
<br />
To get the plugins infos, we are using<br />
ola_plugin_info<br />
That is returning<br />
Id Plugin Name<br />
--------------------------------------<br />
1 Dummy<br />
2 ArtNet<br />
3 ShowNet<br />
4 ESP Net<br />
5 Serial USB<br />
6 Enttec Open DMX<br />
7 SandNet<br />
8 StageProfi<br />
9 Pathport<br />
11 E1.31 (sACN)<br />
12 USB<br />
13 FTDI USB DMX<br />
14 OSC<br />
--------------------------------------<br />
In this example, we are only using the ArtNet plugin and the Serial USB plugins.<br />
<br />
We can see that the ArtNet has the id 2 and the Serial USB has the id 5.<br />
<br />
The ola-port.conf file is storing the info as<br />
<plugin-id>-<device-id>-<port-id><br />
We can translate the first line as :<br />
<br />
The plugin 2, device 1 and input port 0 is patched to the universe 0.<br />
<br />
The second line is defining the priority level.<br />
<br />
Then we can see that other ports are not patched.<br />
<br />
And then on the sixth line, we can translate it as :<br />
<br />
The plugin 5, device 84000775 (remember ola_device_info values) Input port 0 is not patched.<br />
<br />
And on the 7th line we can see translate it as :<br />
<br />
The plugin 5, device 84000775 Output port 0 is patched to universe 0.</div>Nomis52https://wiki.openlighting.org/index.php?title=OLA_ArtNet_Roadmap&diff=5770OLA ArtNet Roadmap2014-12-20T17:45:52Z<p>Nomis52: /* Multiple ArtNet Devices */</p>
<hr />
<div>This describes proposed changes to the [[OLA]] [[ArtNet]] plugin to make it more usable. Some of the use cases that have been requested include:<br />
<br />
== Use Cases ==<br />
<br />
* Receiving broadcast ArtNet data and unicasting to a static list of destinations<br />
* Converting many universes (10s, 100s?) from ArtNet to E1.31 and visa versa. <br />
* Receiving broadcast ArtNet data on one interface, and then sending using ArtNet2 / ArtNet 3 on another interface.<br />
<br />
Artnet-1 to Artnet-2. There are some media servers that do not support Unicast Art-net at all, and all packets are broadcast. When the number of universes exceeds some threshold ( typically >20 ) many end devices can't cope with the number of packets that are needed to be discarded. You end up with irractic and laggy results. ( end devices typically have low power embedded microcontrollers ). Broacast packets need to received from a console/media server and retransmitted in unicast. Its important to be able to either use the Art-net poll mechanism to auto-populate which universes are required on which devices or to use a 'static' routing system. Because we are listening to an Art-net Speaking console, we need to be listen to a large number of universes.<br />
<br />
A typical device that we would want to listen to could be a GrandMA VPU. It does not support Static assignment of Universes to IP address', and there is a requirement to be able to send more than 4 universes to an Art-net device..<br />
<br />
<br />
== Requirements ==<br />
* Support multiple ArtNet Devices, one per logical network interface.<br />
* Support unicasting data to a static list of IPv4 addresses. <br />
* Support more than 4 ports in both directions<br />
* De-couple the ArtNet universe from the OLA universe number to support any-way patching. i.e. patch ArtNet universe 5 to OLA universe 3.<br />
<br />
<br />
== Proposed Changes==<br />
<br />
=== Investigate Optimizing the Send Path ===<br />
<br />
The [http://man7.org/linux/man-pages/man2/sendmmsg.2.html sendmmsg] syscall was added in Linux 3.0. It allows multiple datagrams to be sent with a single syscall. sendmmsg would allow us to reduce the number of syscalls required for each ArtNet packet when unicasting. This scope of this change is to make the required changes and then benchmark the performance. <br />
<br />
Steps:<br />
* Detect support for sendmmsg in configure.ac<br />
* Add a method to the UDPSocket class to enable a single data message to be sent to many addresses<br />
* Modify the ArtNetNode::SendDMX method to use the new UDPSocket method<br />
<br />
<br />
''with the large number of universes being used, the likely scenario is that most universes will only be used at a single destination, the number of replicated packets probalby is quite low''<br />
<br />
=== Multiple ArtNet Devices ===<br />
<br />
Right now only a single ArtNet Device is created. This should be changed so that OLA creates [https://github.com/OpenLightingProject/ola/blob/master/plugins/artnet/ArtNetPlugin.cpp#L46 one device per logical interface].<br />
<br />
Currently the ArtNetNode object binds to the wildcard address ([https://github.com/OpenLightingProject/ola/blob/master/plugins/artnet/ArtNetNode.cpp#L1596 code]) which means trying to create a second instance will fail.<br />
<br />
We need some research into how broadcast traffic is handled with multiple interfaces. Ideally each instance should bind to the broadcast addresses for the specified logical interface.<br />
<br />
=== Increased Output Ports ===<br />
<br />
This shouldn't be too hard. Only the first 4 ports will be represented in the ArtPollReply responses. We'll need to store the net, subnet and port ids on a per-port basis. Right now the net & sub-net values are the same for all ports in a node.<br />
<br />
=== Increased Input Ports ===<br />
<br />
This is more challenging since it requires multiple IP addresses on the host in order to work correctly (that is, have the ports show up in ArtPollReplies). [[libartnet]] supported the concept of merging node instances, we should do something similar in OLA. It may be challenging to work out the corner cases when this interacts with the multi-device change.</div>Nomis52https://wiki.openlighting.org/index.php?title=Logic_RDM_Sniffer&diff=5769Logic RDM Sniffer2014-12-20T17:43:44Z<p>Nomis52: /* OLA Sniffer */</p>
<hr />
<div>[[Image:Saleae-logic.jpg|thumb|200px|right|Saleae Logic]]<br />
[[Image:Logic-sniffer.jpg|thumb|200px|right|The Logic as a 2 line DMX/RDM sniffer]]<br />
<br />
The [http://www.saleae.com/logic Saleae Logic] makes an excellent [[DMX]] / [[RDM]] sniffer. With the Logic and a small amount of hardware you can build a sniffer for a fraction of the price of commercial units.<br />
<br />
<br />
== Parts ==<br />
* A Logic or Logic 16, but see the note below.<br />
* 485 driver circuit<br />
* XLR connectors.<br />
<br />
== Electrical ==<br />
<br />
You need some hardware to convert from the differential 485 levels to a signal which the logic can understand.<br />
<br />
At the basic level you only need an RS-485 receiver like the Maxim MAX485 or Linear Technology LT1785 to translate from the DMX/RDM differential levels to a TTL level that the Saleae Logic understands.<br />
[[File:RDMSnifferSchematic.jpg|thumb|center|400px|alt=Example Circuit]]<br />
<br />
Connecting this circuit to the Logic is fairly simple. Power the board with a MicroUSB Cable or from the +5V, and COM pins on the TTL connector. Then attach the Logic's grey Ground wire to the COM pin on the sniffer circuit, pull the DIR pin low to put the board in RX mode and connect your Logic's channel 1 (generally it's the black cable) to the RX pin. Finally Connect a DXM/RDM source to the board and make sure the green LED is flickering to show data is receiving on the TTL side.<br />
<br />
For more information check [[RDM Sniffer Board]]<br />
== Software ==<br />
<br />
=== Saleae Logic ===<br />
<br />
[[Image:Saleae-dmx.png|thumb|200px|right|The Logic App decoding DMX]]<br />
<br />
Saleae provides the [http://www.saleae.com/downloads Logic App] which works on Windows, Mac and Linux. The application has a plugin to decode DMX, but it doesn't understand RDM data. The tool is best for analyzing the signal timing rather than the high level messages.<br />
<br />
=== OLA Sniffer ===<br />
<br />
OLA has a text-based DMX/RDM sniffer that works with the Logic (it could easily be extended to work with the Logic 16). It can be found in [https://github.com/OpenLightingProject/ola/tree/master/tools/logic tools/logic] directory of the OLA sources.<br />
<br />
Limitations:<br />
* the sniffer doesn't understand DUB responses yet since it looks for breaks.<br />
* it may struggle with signal timings that are at the edge of the E1.11 standard. If you experience problems with the sniffer please email the [http://groups.google.com/forum/#!forum/open-lighting Open Lighting Mailing List]</div>Nomis52