OpenDMX.net - Recent changes [en]

ArtNet, RDM and Packet Interleaving

2010-09-06T22:57:02Z

← Older revision		Revision as of 22:57, 6 September 2010
(2 intermediate revisions not shown)
Line 34:		Line 34:
	=== Send a single RDM command at once ===		=== Send a single RDM command at once ===

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

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

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

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

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

ArtNet, RDM and Packet Interleaving

2010-09-06T17:43:24Z

← Older revision		Revision as of 17:43, 6 September 2010
Line 4:		Line 4:


-	[[Image:ArtNetRDMSequence.png]]	+	[[Image:ArtNetRDMSequence.png\|center]]


	== The Potential Problem ==		== The Potential Problem ==

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

	''To receive the remaining data, the controller should continue to send GET_COMMANDS for the same PID. The responder shall send subsequent blocks of data with a response type of RESPONSE_TYPE_ACK_OVERFLOW until the remaining data can fit in a single message. The responder shall set the response type to RESPONSE_TYPE_ACK on the final response message in the sequence, to indicate completion of the data transfer. ''		''To receive the remaining data, the controller should continue to send GET_COMMANDS for the same PID. The responder shall send subsequent blocks of data with a response type of RESPONSE_TYPE_ACK_OVERFLOW until the remaining data can fit in a single message. The responder shall set the response type to RESPONSE_TYPE_ACK on the final response message in the sequence, to indicate completion of the data transfer. ''
Line 17:		Line 15:
	Assuming that PID A causes an ACK_OVERFLOW, the sequence now looks like this:		Assuming that PID A causes an ACK_OVERFLOW, the sequence now looks like this:

-	[[Image:ArtNetRDMOverflowSequence.png]]	+	[[Image:ArtNetRDMOverflowSequence.png\|center]]

	But the standard also states:		But the standard also states:
Line 25:		Line 23:
	So any RDM packet interleaved between the two ''GET PID A' commands in the above example will cause the transfer to abort.		So any RDM packet interleaved between the two ''GET PID A' commands in the above example will cause the transfer to abort.

		+	[[Image:ArtNetRDMOverflowResetSequence.png\|center]]
		+
		+	'''Note''': The [http://www.goddarddesign.com/rdm_lab_pack.html Labpack] has a bug where it will not abort the transfer so this continues to work. This is present in version 0x20009
		+
		+
		+	== Possible Solutions ==
		+
		+	There are two cases i) the single controller case ii) the multi-controller case. Nothing in the existing protocol can solve the latter, so it's out of scope for the rest of the discussion.
		+
		+	=== Send a single RDM command at once ===
		+
		+	This is obviously the most reliable but has the drawback of requiring a full round trip between the controller and responder for each message. Testing with a [[Net-Lynx]] showed an average response time of 7ms as seen on the controller when the RTT was 1.3ms. This solution also has the desirable property of not over-running the ArtNet node's buffers.
		+
		+	=== Send multiple packets at once ===
		+
		+	This appears to be what [[DMX Workshop]] does and has the potential to break ack_overflow sequences.
		+
		+	=== Send multiple packets at once and back off when an ACK_OVERFLOW is received ===
		+
		+	Similar to the above, this sends multiple packets at once but stops sending other packets when an ACK_OVERFLOW is received until the sequence completes (or a timeout occurs). This reduces the chance of an aborted transfer, but doesn't eliminate it.
		+
		+	=== Send multiple packets at once, serialize commands expected to generate ACK_OVERFLOWS and back off when an ACK_OVERFLOW is received ===
		+
		+	Of the PIDs described in E1.20, the following have the potential to generate an ACK_OVERFLOW:
		+
		+	* PROXIED_DEVICES
		+	* STATUS_MESSAGES
		+	* SUPPORTED_PARAMETERS
		+	* LANGUAGE_CAPABILITIES
		+	* SLOT_INFO
		+	* DEFAULT_SLOT_VALUE

-	* Note that the ~~[http://www~~.~~goddarddesign.com/rdm_lab_pack.html Labpack] has a bug where~~ it ~~will not abort~~ the ~~transfer so this continues to work~~. ~~This is present in version 0x20009~~	+	When the Controller sends any of these PIDs it can wait to see if an ACK_OVERFLOW occurs before sending any other RDM commands. Of course this doesn't solve the problem for manufacturer specific PIDs, instead it relies on the back off mechanism above.

	== References ==		== References ==

File:ArtNetRDMOverflowResetSequence.png

2010-09-06T17:20:43Z

uploaded "[[File:ArtNetRDMOverflowResetSequence.png]]"

New page

File:ArtNetRDMOverflowSequence.png

2010-09-06T17:18:44Z

uploaded a new version of "[[File:ArtNetRDMOverflowSequence.png]]"

New page

ArtNet, RDM and Packet Interleaving

2010-09-06T17:12:25Z

Created page with '== RDM over Artnet == ArtNet nodes behave as pass-through devices for non-discovery RDM data. The normal sequence of RDM commands looks like this: [[Image:ArtNetRDMSeq…'

New page

== RDM over Artnet ==

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

[[Image:ArtNetRDMSequence.png]]

== The Potential Problem ==

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

From the standard:

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

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

[[Image:ArtNetRDMOverflowSequence.png]]

But the standard also states:

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

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

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

== References ==

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

File:ArtNetRDMOverflowSequence.png

2010-09-06T17:01:35Z

uploaded "[[File:ArtNetRDMOverflowSequence.png]]"

New page

File:ArtNetRDMSequence.png

2010-09-06T16:57:23Z

uploaded a new version of "[[File:ArtNetRDMSequence.png]]"

New page

File:ArtNetRDMSequence.png

2010-09-06T16:51:32Z

uploaded "[[File:ArtNetRDMSequence.png]]"

New page

RDM with OLA

2010-09-06T16:38:06Z

← Older revision		Revision as of 16:38, 6 September 2010
Line 101:		Line 101:

	If you have a copy of DMXWorkshop, you can experiment with RDM over ArtNet by patching an ArtNet Input Port to the same universe as the Dummy Plugin. You can then discover the Dummy Device using DMXWorkshop and configure it's start address over the LAN.		If you have a copy of DMXWorkshop, you can experiment with RDM over ArtNet by patching an ArtNet Input Port to the same universe as the Dummy Plugin. You can then discover the Dummy Device using DMXWorkshop and configure it's start address over the LAN.
		+
		+	Note that the design of the RDM-over-ArtNet protocol has a significant limitation, see [[ArtNet, RDM and Packet Interleaving]]

	== Useful Tricks ==		== Useful Tricks ==

Open Lighting Architecture

2010-09-05T18:00:05Z

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

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

File:Llad home.png

2010-09-03T05:42:15Z

uploaded a new version of "[[File:Llad home.png]]"

New page

Open Lighting Architecture

2010-09-03T05:41:55Z

← Older revision		Revision as of 05:41, 3 September 2010
Line 2:		Line 2:
	Link: http://code.google.com/p/linux-lighting/ <br>		Link: http://code.google.com/p/linux-lighting/ <br>
	{{Features\|free=yes\|tx=yes\|rx=yes\|linux=yes\|osx=yes\|http=yes\|rdm=yes}}		{{Features\|free=yes\|tx=yes\|rx=yes\|linux=yes\|osx=yes\|http=yes\|rdm=yes}}
		+	[[Image:Llad_home.png\|300px\|right]]


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

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

File:Llad home.png

2010-09-03T05:38:03Z

uploaded a new version of "[[File:Llad home.png]]"

New page

← Older revision		Revision as of 05:41, 3 September 2010
Line 2:		Line 2:
	Link: http://code.google.com/p/linux-lighting/ <br>		Link: http://code.google.com/p/linux-lighting/ <br>
	{{Features\|free=yes\|tx=yes\|rx=yes\|linux=yes\|osx=yes\|http=yes\|rdm=yes}}		{{Features\|free=yes\|tx=yes\|rx=yes\|linux=yes\|osx=yes\|http=yes\|rdm=yes}}
		+	[[Image:Llad_home.png\|300px\|right]]


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

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