E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDMnet (BSR E1.33) Draft Standard General Discussion

RDMnet (BSR E1.33) Draft Standard General Discussion General Discussion and questions concerning the draft E1.33 standard.

Reply
 
Thread Tools Search this Thread Display Modes
Old May 14th, 2012   #1
SeanSill
Task Group Member
 
Join Date: Aug 2011
Location: Lancaster, PA
Posts: 25
Default E120 Transaction Numbers over E133

I don't recall the task group talking about how E1.20 transaction numbers (TN) work over E1.33 so I decided to talk about this here. The current path we are taking in E133 is trying to let the gateways just take a E1.20 message from E133 and send it over the E1.20 link. The problem occurs when multiple controllers are communicating to the same gateway. The E1.20 TN could jump from 1 to 200 to 3 to 5 to 201, etc which for most responders is probably not a problem but I suspect it might be for proxies and other E1.20 devices that might multiplex messages some manner.

One way to solve it would be to just mandate that the E1.20 TN is a value of 0 over an E133 network, because the E133 controller is already tracking the E133 sequence number which is 32 bit. This renders the E1.20 TN redundant on the E133 network. The gateway would then locally track its own TN number per port.

Comments? Criticisms? Snide Remarks?
SeanSill is offline   Reply With Quote
Old May 14th, 2012   #2
pkleissler
Task Group Member
 
Join Date: Oct 2008
Location: NJ
Posts: 19
Send a message via Skype™ to pkleissler
Default

My proxy does the same thing. It takes what comes in and passes it as is. This way I do not need to map my TN with a specific source UID + TN combo. I currently have the case where there is Art-Net, GetSet Ethernet and another controller via RS-485 issuing RDM messages at the same time working this way without issue.

I would also like to advocate against a mandate. As I use the sourceUID + TN as a method of determining a duplicate message within my proxy system.

Paul
pkleissler is offline   Reply With Quote
Old May 14th, 2012   #3
SeanSill
Task Group Member
 
Join Date: Aug 2011
Location: Lancaster, PA
Posts: 25
Default

Paul, It would still work for you since the E133 layer has a 32bit sequence number you could use to track. As an example you could still use the lower byte of the sequence number as the TN for your records.

I bring it up because the gateway is using it's own UID in the source UID field in the E120 packet as we talked about in one of the last meetings. Where proxies might break is when E133 controller A send TN of 1 and E133 controller B sends TN of 1 to a specific gateway. That gateway would then use it's own UID and your proxy would see two messages with the same TN number from the same UID. We decided to have the gateway use its UID in the packet because the process to deal with multiple source IDs from a responder or proxy point of view is undefined in E1.20 or I couldn't find anything on it.

So if we keep the standard where the gateway is using its own UID then we need to translate and track TN numbers in the gateway. That either needs to be stated or we need to fix it somehow.
SeanSill is offline   Reply With Quote
Old May 14th, 2012   #4
pkleissler
Task Group Member
 
Join Date: Oct 2008
Location: NJ
Posts: 19
Send a message via Skype™ to pkleissler
Default

I agree that I can make it work, but I don't agree that we need to put something into the standard that has no benefit other than to make more work to implement.

1.20 was written with source and destination addressing, implying that the source can be from anyone. In fact a responder has to assume that, or else it can never talk in the first place. Forcing a single source UID on the 485 side has no real benefit but has the drawback of not allowing diagnostic tools to see what 1.33 controller has sent the message in the first place.

TN is all about the controller, the standard says that the responder has to set it in accordance with the packet they are responding to. Making no requirement that it needs to check it for proper incrementing. Thus from a responder point of view, the TN can be out of order as it would be from multiple controllers. Since responders are already designed this way, why fix something that isn't broke?

1.33 should not be used to change the behavior of 1.20. 1.20 allows random TN and multiple sources UIDs by design or accident. Responders only have to work correctly within the confines of 1.20, adding additional requirements past that to 1.33 gateways is not necessary. Having a gateway use it's UID exclusively and locally generated TNs should be a should and not a shall

Paul
pkleissler is offline   Reply With Quote
Old May 14th, 2012   #5
SeanSill
Task Group Member
 
Join Date: Aug 2011
Location: Lancaster, PA
Posts: 25
Default

We need to make it a point to bring this up at the next meeting.

Quote:
Originally Posted by pkleissler View Post

1.33 should not be used to change the behavior of 1.20. 1.20 allows random TN and multiple sources UIDs by design or accident. Responders only have to work correctly within the confines of 1.20, adding additional requirements past that to 1.33 gateways is not necessary. Having a gateway use it's UID exclusively and locally generated TNs should be a should and not a shall
I completely agree.
SeanSill is offline   Reply With Quote
Old May 14th, 2012   #6
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 355
Default

This was discussed in earlier task group meetings. We considered the pros and cons of having the gateway rewrite the packets to keep the Transaction Numbers consistent vs. passing the packets As-Is from IP to 485.

The same questions also arise with regards to the Source UID's in the packet. Should the gateway rewrite the Source UID so that the responder always sees the same Source UID, or pass the UID along unmodified.

In both cases, we decided it was better to keep the packets as-is and that the gateway should *not* rewrite any portion of the packet.

This decision was based in large part on experience with real-world systems. There are many systems today that have packets sent from multiple sources that do not coordinate their transaction numbers. No one was aware of any ill effects from this behavior.

Many systems using Art-Net's RDM implementation exhibit discontinuous transaction numbers. I believe Paul's proxy does the same.


The possibility of this occurring was discussed even before E1.37 was started. During the development of E1.20, several people suggested that the responder should un-mute itself whenever the controller's UID changed. We decided against this because in the case of an RDM merger, you could expect to see packets from multiple controllers with different UIDs and TNs interleaved on the same 485 line. E1.37 is essentially the same thing as an RDM merger and raises the same issues.
ericthegeek is offline   Reply With Quote
Old May 14th, 2012   #7
nomis52
Task Group Member
 
Join Date: May 2010
Location: San Franciscio
Posts: 57
Default

Quote:
Originally Posted by ericthegeek View Post
In both cases, we decided it was better to keep the packets as-is and that the gateway should *not* rewrite any portion of the packet.
Um, that's not how I remember it. In fact I was under the impression that the gateways would be required to rewrite the source UID and TN and then recalculate the checksum.


Quote:
Originally Posted by ericthegeek View Post
This decision was based in large part on experience with real-world systems. There are many systems today that have packets sent from multiple sources that do not coordinate their transaction numbers. No one was aware of any ill effects from this behavior.

Many systems using Art-Net's RDM implementation exhibit discontinuous transaction numbers. I believe Paul's proxy does the same.
What systems are these? I haven't seen anyone do multi-controller using ArtNet, and when I spoke with the AL guys they said they haven't done it.


Simon
nomis52 is offline   Reply With Quote
Old May 14th, 2012   #8
pkleissler
Task Group Member
 
Join Date: Oct 2008
Location: NJ
Posts: 19
Send a message via Skype™ to pkleissler
Default

I can't speak for multi controller Art-Net, but I am doing multi-controller with Art-Net, GetSet and Enttec in the lab.

Paul
pkleissler is offline   Reply With Quote
Old May 15th, 2012   #9
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 355
Default

Quote:
Originally Posted by nomis52 View Post
What systems are these? I haven't seen anyone do multi-controller using ArtNet, and when I spoke with the AL guys they said they haven't done it.
I'll have to go back and check some packet captures to be certain, but IIRC the transaction number is not coordinated between the ongoing discovery packets that are generated by the AL Art-Net node itself and the packets that come via Ethernet.
ericthegeek is offline   Reply With Quote
Old May 15th, 2012   #10
ericthegeek
Task Group Member
 
Join Date: Aug 2008
Posts: 355
Default

Attached is a packet dump of the RDM traffic generated by an AL-500x Art-Net node. The Transaction Number column is highlighted in yellow.

Notice that the discovery packets generated by the node itself (with the Transaction Number in red) have Transaction numbers that are not coordinated with the Transaction Number for packets that come from the Ethernet input.

System Details:
DMX Workshop V4.113
AL-500x Node Firmware V1.021
1x Labpack Responder
Attached Files
File Type: pdf packets.pdf (28.0 KB, 511 views)
ericthegeek is offline   Reply With Quote
Reply

Bookmarks

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -6. The time now is 09:23 PM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.