Does controller need it's UID and support any PIDs?

[alvangee]

Probably it's a noob question, but couldn't find any mentions on this topic.
There's a list of required parameters and a whole lot of discussions on how responders should operate.

But if it's a controller, is it required that it has it's own UID, responds to Discovery commands and supports any of the PIDs?

Now I have Enttec MK2 controllers and I can see that they respond to Discovery with their own UID, but to any other PID request they send ACK_TIMER. Not sure why ACK_TIMER though, it seems more appropriate to send NACK with the reason NR_UNKNOW_PID to tell that PID is not supported.

[hamish]

It's responders that respond, not the controller.
It may be that your controller is behaving as a responder.
Responders will respond with ACK_TIMER if they require additional time
to process the response.

Originally Posted by alvangee

Probably it's a noob question, but couldn't find any mentions on this topic.
There's a list of required parameters and a whole lot of discussions on how responders should operate.

But if it's a controller, is it required that it has it's own UID, responds to Discovery commands and supports any of the PIDs?

Now I have Enttec MK2 controllers and I can see that they respond to Discovery with their own UID, but to any other PID request they send ACK_TIMER. Not sure why ACK_TIMER though, it seems more appropriate to send NACK with the reason NR_UNKNOW_PID to tell that PID is not supported.

[alvangee]

Originally Posted by hamish

Responders will respond with ACK_TIMER if they require additional time
to process the response.

Exactly. That's why I'm surprised with ACK_TIMER from controller. And it's not in "responder" mode.

It's responders that respond, not controllers

Does this mean that controller doesn't have to have it's own UID and respond even to Discovery requests?

[hamish]

A controller has it's own UID, used in all commands to responders. Responses to the controller are addressed to the controller by it's UID.

There's nothing, that I'm aware of in the standard, to prevent a controller acting as a responder on receipt of a command.

[ericthegeek]

I'm a bit confused. Can you give more details about your setup and how things are connected? What controller are you using and what's wired to what?

There can only be one controller, and it doesn't need to discover itself or respond to any PIDs (It already knows everything about itself)

The Enttec USB boxes can be configured to run as an RDM Controller, or as an RDM responder (but they can't do both simultaneously). It sounds like yours might be configured to act as a responder. The ACK Timer behavior is common for USB-attached RDM Responders since the host computer can't guarantee it will respond within the 2ms response window.

I've only used the older Enttec USB boxes and you had to explicitly configure them to be a controller or a responder. It's possible that the newer NK2 units can auto-switch.

[alvangee]

Eric, I have a net with our own Controller (i.e. hardware and firmware was developed by our company, not third-party), couple of our own responders and Enttec Mk2. All of them are connected to one DMX/RDM bus. Enttec Mk2 works as a Controller via Enttec's PC program.

When I perform discovery with my Controller it finds both responders and Enttec Mk2's UID, so Mk2 responds to Discovery requests. I can't set Mk2 to be responder even if I want as I did not purchase license for their Responder PC program. When I request with my Controller any PIDs (for example, Manufacturer Label, Device Info) from Mk2 it responds with ACK_TIMER.

Again, it's not Mk2's behavior I am worrying about. Since I am using Enttec as a reference (assuming that it is widely accepted in community DMX/RDM developer), I wonder if our own Controller should behave similar and whether I need to make my own Controller respond to any requests including Discovery?

[ericthegeek]

That is a very strange behavior from the Enttec USB Box. I have no idea why that is happening. Might be worth an email to Enttec to ask, they are typically pretty responsive.

No, your controller does not have to respond to discovery or to any other PIDs. In fact, I would say that it should *not* respond to them. Controllers send GET, SET, and DISCOVERY requests. They should never send GET_RESPONSE, SET_RESPONSE, or DISCOVERY_RESPONSE packets.


Corner Case: You could hypothetically build a system that has a controller and one or more responders bolted inside the same chassis. To the outside world, this would look like both a controller and a responder.

[alvangee]

Thanks for clarifications!