Transcript LX-Networks101 - Pathway Connectivity

Lighting Networks 101
DMX
Digital Multiplex Protocol
or
ANSI E1.11 – 2004
USITT DMX512-A
Asynchronous Serial Data Transmission
Standard for Controlling Lighting Equipment
and Accessories
Proper DMX Layout
Daisy Chain the signal path
Console
Fixture
or dimmer
Fixture
Fixture
or dimmer or dimmer
DMX Troubleshooting
“T” or “Y” connections change the
cable impedance causing reflection
Fixture
or dimmer
Console
DMX Mixed Layout
Opto-splitter/Repeater
Console
Merger
Console
Each DMX leg out of a repeater
is its own electrical entity
Repeaters can be daisy-chained
DMX Troubleshooting (2)
Signal path must be terminated
with 120 ohm resistor
Console
Terminator
switch or plug
on final fixture
Fixture
or dimmer
Fixture
Fixture
or dimmer or dimmer
Failure to terminate causes signal reflection
back up the cable and intermittent problems
DMX Cable

Low capacitance required to maintain wave
form

Belden 9842, 9729, 9829

ProPlex, Showplex

Cat5, Cat5e, Cat6

Not microphone cable

What they say about barb wire isn’t true
Wave Form
Proper square/digital wave form
Sawtooth wave form – likely caused
by capacitance in the cable or slewrating in the transceiver
Wave form overlay (typically caused
by reflection)
Multiple overlays are possible
DMX Data Packet
High
Start Code
44uS
Slot 1
(lvl=0)
Slot 2
(lvl=0)
also
44uS
1 start bit (low)
Mark-after-break 8uS
2 stop bits (high)
Break 88uS
Idle time can
follow stop bits
DMX Data Frame
Line Idle - high
2 Stop Bits
- high
1
0
0
1
1
0
1
0
8 Data Bits high or low
1 Start bit
- low
Single Data Frame
11 bits altogether
44uS transmission time
RDM
Remote Device Management
or
ANSI E1.20 - 2006
RDM
Remote Device Management
Over DMX512-A Networks
Why RDM?
Because DMX isn't enough anymore
Too much gear
 Too many universes
 Too much paperwork
 Too many places for things to go wrong
 Not easy to fix things on the fly

How RDM Works





Does not make legacy DMX-only gear
obsolete
Uses a packet structure, like DMX
RDM messages are interleaved or inserted
between regular DMX packets
DMX does not need to be present for RDM
messages to be sent
Requires all devices be transmitters as well
as receivers
RDM Packet Structure
Start Code
Hex CC: indicates RDM Packet
Sub-Start Code
Hex 01: basically for future use
Message Length
Number of slots used by message
Destination UID
UID of intended recipient
Source UID
Transaction #
Port ID/Response
Type
Message Count
Sub-device
Message Data
Checksum
Not sure why: only one controller allowed
Used to match query and response
Identifies controller's sending port and
responder's type of message
Incremented by responder – tells
controller number of queued msgs
IDs device within responder ie dimmer
within the rack
Payload! At last!
16-bit checksum of all above fields
RDM Message Block
Command Class
Parameter ID
(PID)
Parameter Data
Length
Get, Set or Discovery
i.e.: Network Mgmt, Status,
Sensors, DMX512 Set-up, others,
or manufacturer specific
Number of slots used by next part of
message (can be zero)
- responder needs to know when
check sum begins
Format depends on the PID
Parameter Data
New Rules for System Design
No more than 4 in-line devices between a
responder and the controller
 In-line devices include opto-splitters,
mergers, repeaters, anything that
reprocesses the signal
 In-line devices must be bi-directional




Timing changes to DMX E1.11
Break time extended to 132uS
Each in-line device to reduce break by 22uS
Legacy Equipment
DMX distribution gear developed prior to 2000
will likely need to be replaced

no provision for bi-directional signal

end gear will depend on manufacturer
 as purchasers you should be demanding
support for older gear
 DMX-over-Ethernet likely will be okay
 currently no programming consoles with RDM

RDM and Pathway
Support for firmware upload over RDM
 DMX/RDM over Ethernet via Pathport
 In-line Devices:
 DMX Repeater Pro
 Bi-directional opto-splitter
 Can also act as a controller
 eDIN 1009 RDM opto-splitter
 Responder Devices:
 EDIN 1003 DMX to Contact Output
 eDIN 1004 DMX-to-Analog
 eDIN 1006 Analog-to-DMX
 eDIN 1008 DMX LED Driver

ACN
ANSI E1.17 – 2006
Architecture for Control Networks
Remaining Problems
- sheer size of lighting installations (think LED)
causing infrastructure problems
- cost of wire and connectors for DMX/RDM
- management tools not covered by RDM
- multiple universe management
- distribution management (merge, priority)
- everything still mapped to 512 channels
- maybe the answer is... Ethernet?
Ethernet Advantages
- Cheap wiring and distribution gear
- available everywhere
- 10 Mbit = 40 universes at 250 baud
(we get back to this one)
- flexibility of star wiring
- cheap (did I mention cheap?)
Proprietary Protocols
(again)
Strand Shownet
ETC Net1
ETC Net2
ArtNet
Pathport
....and less often
AVAB
Compulite
Enttec
Colornet
KiNet
... and none can talk to each other
DMX-over-Ethernet
Advantages

signal management
- merging, splitting, priority switching
unlimited outputs (dependent on network
architecture)


up to 128 universes of input (typical 2008)
number of fully active universes varies from
protocol to protocol but typically 12 - 15

Ethernet Limitations

finicky installations

sensitive to electrical interference

not robust (compared to Belden/XLR)

100m cable runs versus 500m for DMX
Enter ACN
media agnostic – use whatever cable
you want

intended as a generic language to
control devices


allows for plug and play
Alphabet Soup (1)
CID – Component IDentifier
DDL – Device Description Language
DMP – Device Management Protocol
SDT – Session Data Transport
RLP – Root Layer Protocol
Three letter acronyms – not just for
audio anymore
Alphabet Soup (2)
CID – Component IDentifier
- unique identifier for each device on system
DDL – Device Description Language
- an XML file describing device properties and
associated ‘behaviours’
- controller can pick and choose what it wants
depending on sophistication and need
Alphabet Soup (3)
DMP – Device Management Protocol
- how to get and set properties of the device
SDT – Session Data Transport
- heart of ACN
- allows efficient, reliable (error-checking)
data transmission to one, a few or all devices on
the network, depending on need
- created specifically with the typically
assymmetric lighting data flow in mind
ACN Overview
- information not bound by 512 data slots
- formatted or configured according to need
- device reports native resolution
- end devices can report abilities, parameters to
the controller
- no searching for libraries anymore
- configuration using terms that make sense to
the user
- devices not limited to lighting equipment
How Will it Fit Together?
- Ethernet backbone carrying ACN signals
- some devices such as media servers, dimmer
banks and LED drivers will sit natively on the
network
- gateway nodes will provide ACN-RDM control
over configurable devices
- gateway nodes will provide ACN-DMX control
over legacy and 'dumb' gear
What’s on the shelf now?
- DMX, obviously
- RDM, increasingly
- streaming ACN Ethernet protocol is
available as Net3 (ETC), sACN (Pathway)
and soon others (MA Lighting, Pharos)
- in the near term (5 years or less) sACN will
replace the proprietary protocols
- openACN group working on open source
code modules (www.openacn.org)
Ethernet Design Tips (1)
- structured wiring
- IDC termination
- TIA/EIA-568 certification
- Cat5e vs Cat6
-STP and conduit
- observe cable lengths
- max 90m for copper
- copper versus fibre
Ethernet Design Tips (2)
- Power-over-Ethernet (802.3af)
- device classes and sufficient power
- switches vs routers
- current lack of Etherner protocol converters
Troubleshooting (1)
- managed vs unmanaged switches
- bad things, maybe:
- broadcast storm control
- IGMP packet sniffing
- multicast filtering
- spanning tree protocol
Troubleshooting (2)
- maximum traffic for 10Mb devices
- 24 universes for broadcast protocols
- traffic patterns
- Ethernet component reliability issues
- RJ45 vs Ethercon vs XLR
- segregated traffic
-VLANS
- media converters