For developing a "not fast" RDM proxy hardware, use ACK_timer or other method? - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · September 29th, 2025

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.

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
RDM 1.37-5 Schema "different_pid" used in QUEUED_MESSAGE not part of Schema	Qasi_	RDM Interpretation Questions	3	September 18th, 2024 07:54 PM
DMXter4 says "not responding"	dj41354	RDM General Implementation Discussion	11	November 27th, 2015 06:59 AM
New PID "Slot Labels"	este_	RDM General Implementation Discussion	5	August 14th, 2014 09:26 AM
New PID "CURVE DEFINITION"	este_	RDM General Implementation Discussion	0	July 13th, 2014 03:16 PM
Refreshing "parameter_description" ?	theguenni	RDM General Implementation Discussion	0	February 29th, 2012 02:36 PM

September 29th, 2025	#6
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	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.