Quote:
Originally Posted by 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.
|
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?