For developing a "not fast" RDM proxy hardware, use ACK_timer or other method?

[yxj-ae86]

HI, RPMer, I am a RDM rookie.
Right now we are developing a RDM proxy, a power line communication hardware which convert RDM/DMX512 to PLC two-way.
There is one PLC proxy connects to the RDM master and a PLC-RDM/DMX node connects to RDM/DMX light.

We have finished DMX512 part, but when face RDM, its timing is critical that our PLC module can not meet the requirements. And we have two choice:

1. One is using ACK-timer or Queued message, but RDM OG in this forum have said that this maybe not a good choice for not all RDM master support this.
2. Use asynchronous communication or "cheated communication" : when RDM master send some control/set message, PLC proxy replied it instantly, and then transmit the messages to the remote PLC-RDM/DMX node; when RDM master wanna read some info from RDM/DMX light, and PLC proxy also reply it instantly from its "on-chip RAM's data" which is collected periodically.

Which one is a better choice, or, other suggestions is also thankful.

Thanks in advance.

[sblair]

Welcome to the RDM forums.

Depending on the design of your product I would suggest you'll have the best user experience by periodically caching the information that may be requested so that it is available to immediately reply via RDM. If you do choose to use the ACK_TIMER method then I would definitely recommend supporting QUEUED_MESSAGE also.

Scott

[yxj-ae86]

Thanks for you reply.

Best user experience, do you mean response time? And if choose ACK_TIMER+QUEUED_MESSAGE, only add about 50-100ms, I think it is acceptable.

Our concern is that whether mainstream RDM controller support ACK_TIMER+QUEUED_MESSAGE, if most of them support it, I prefer ACK_TIMER+QUEUED_MESSAGE, because caching information from slaves during DMX512's transmission interval is not so easy done by PLC(power line communication). But if ACK_TIMER+QUEUED_MESSAGE is not common in RDK controller, caching solution is a better and only way to go.

[ericthegeek]

Do you want to support any standard RDM Responder at the far end of the PLC communication?

As in:
RDM controller -> RS485 -> PLC node -> power line -> PLC node -> RS485 -> Any standard RDM responder

Or are you only trying to support your own lights over PLC?

As in:
RDM controller -> RS485 -> PLC node -> power line -> Your own equipment with integrated PLC

[yxj-ae86]

Do you want to support any standard RDM Responder at the far end of the PLC communication?
--RE: Yes, we want to support standard RDM responder at the end of PLC communication.

As in:
RDM controller -> RS485 -> PLC node -> power line -> PLC node -> RS485 -> Any standard RDM responder
--RE: Currently we want support this one.

Or are you only trying to support your own lights over PLC?

As in:
RDM controller -> RS485 -> PLC node -> power line -> Your own equipment with integrated PLC
--RE: this is not our plan.

[ericthegeek]

To support standard RDM responders at the far end, you basically have to treat the PLC bridge(s) like a managed proxy. The controller-facing bridge responds to discovery on behalf of the the far-end devices, and uses ACK_TIMER for everything else.


It's been a while since we've discussed proxies and ACT_TIMER on this forum. Fortunately, ACK_TIMER is now much more widely supported in controllers than it was year ago.




Scott and I have different views on this topic, but generally I don't like for proxies to cache information. Any time you cache data, you then have to worry about cache coherency and aging. When you cache something like, say, DMX address, how long is the cached data valid for? 100ms? 1 second? 1 minute? 10 minutes? Do you have to flush the cache any time the personality changes?


Also, there's a risk that the proxy will keep providing cached data when the actual responder has gone offline (crashed, or lost power).


The proxy does have to cache discovery information, and may be able to cache some read-only PIDs, but IMO it's not worth the hassle.

[yxj-ae86]

To support standard RDM responders at the far end, you basically have to treat the PLC bridge(s) like a managed proxy. The controller-facing bridge responds to discovery on behalf of the the far-end devices, and uses ACK_TIMER for everything else.


It's been a while since we've discussed proxies and ACT_TIMER on this forum. Fortunately, ACK_TIMER is now much more widely supported in controllers than it was year ago.




Scott and I have different views on this topic, but generally I don't like for proxies to cache information. Any time you cache data, you then have to worry about cache coherency and aging. When you cache something like, say, DMX address, how long is the cached data valid for? 100ms? 1 second? 1 minute? 10 minutes? Do you have to flush the cache any time the personality changes?


Also, there's a risk that the proxy will keep providing cached data when the actual responder has gone offline (crashed, or lost power).


The proxy does have to cache discovery information, and may be able to cache some read-only PIDs, but IMO it's not worth the hassle.

Thanks very much for so detailed reply.
I have a similar opinion, it is difficult to balance the caching period and response realtime ability. And yes, your post about ACK_TIMER is a few years ago, and you have said that many wireless RDM proxy use ACK_TIMER, so I prefer this way.

[yxj-ae86]

To support standard RDM responders at the far end, you basically have to treat the PLC bridge(s) like a managed proxy. The controller-facing bridge responds to discovery on behalf of the the far-end devices, and uses ACK_TIMER for everything else.


It's been a while since we've discussed proxies and ACT_TIMER on this forum. Fortunately, ACK_TIMER is now much more widely supported in controllers than it was year ago.




Scott and I have different views on this topic, but generally I don't like for proxies to cache information. Any time you cache data, you then have to worry about cache coherency and aging. When you cache something like, say, DMX address, how long is the cached data valid for? 100ms? 1 second? 1 minute? 10 minutes? Do you have to flush the cache any time the personality changes?


Also, there's a risk that the proxy will keep providing cached data when the actual responder has gone offline (crashed, or lost power).


The proxy does have to cache discovery information, and may be able to cache some read-only PIDs, but IMO it's not worth the hassle.

For RDM protocol 6.3 Response Type Field Values, when command class is DISCOVERY_COMMAND_RESPONSE, it does not support ACK_TIMER, so we need combine two ways: caching + ACK_TIMER to fully support RDM by PLC? For discovery part, caching first and reply command instantly, for GET/SET command, use ACK_TIMER+QUEUED_MESSAGE?

[yxj-ae86]

For RDM protocol 6.3 Response Type Field Values, when command class is DISCOVERY_COMMAND_RESPONSE, it does not support ACK_TIMER, so we need combine two ways: caching + ACK_TIMER to fully support RDM by PLC? For discovery part, caching first and reply command instantly, for GET/SET command, use ACK_TIMER+QUEUED_MESSAGE?

You have mentioned the answer, but I have missed them:

The proxy does have to cache discovery information, and may be able to cache some read-only PIDs, but IMO it's not worth the hassle.

OK, no problem now.
Thanks for all.

[ericthegeek]

That's right. The proxy needs to keep track of what responders are present on the far side of the high-latency link, and then send that information to the Controller.


The proxy must respond to Discover Unique Branch, Mute, and Unmute on behalf of the responders. It's also a good idea to support the PROXIED_DEVICES and PROXIED_DEVICE_COUNT PIDs to speed up discovery.

[yxj-ae86]

That's right. The proxy needs to keep track of what responders are present on the far side of the high-latency link, and then send that information to the Controller.


The proxy must respond to Discover Unique Branch, Mute, and Unmute on behalf of the responders. It's also a good idea to support the PROXIED_DEVICES and PROXIED_DEVICE_COUNT PIDs to speed up discovery.

Got it, thank you so much