DEFAULT_SLOT_VALUE

[berntd]

Hello,

I assume the value of a slot is the dmx level.

We can retrieve the default value for a slot.
How do we retrieve the current value of a slot?

Kind regards
Bernt

[sblair]

There is no mechanism for retrieving the current value of a slot. Only the default value for use in setting defaults for the controller. It is meant to be used in conjunction with the SLOT_ID information to assist a controller that doesn't have a library.

[ericthegeek]

DEFAULT_SLOT_VALUE is used to get the standard idle values for a device (good values to send when it's doing nothing else). For example, on a moving light, this would be pan and tilt at 50%, intensity at zero, Color at open-white, gobo rotation off, etc.

Generally the manufacturer for a responder will know what values are good to use for defaults.

> How do we retrieve the current value of a slot?

There's no standard way to get the current value. Generally, it's assumed that the RDM controller is also sending the Null-Start-Code DMX, so it should know what level it is sending.

Generally dimmers and relay don't need to support DEFAULT_SLOT_VALUE. It's really intended for more complicated devices where zero isn't necessarily what you want the console to send by default.

[berntd]

All true for simple devices BUT if a device also has faders, can play and mix scenes and chases and the output levels are acually a combination of all the differnt inputs, then seing what the slot final output level is becomes really useful, especially if this is to be mimic'd somewhere else.

Kind regards
Bernt

[sblair]

I believe we had discussed it early on, and it works if eveything is static, but once you have a chase or fade running than it would be almost useless as trying to get real-time feedback would quickly bog things down.

As Eric mentioned, we typically expect that most DMX values would be coming from the controller itself although other scenarios are possible as you mentioned.

[ericthegeek]

What you're describing is beyond the scope of RDM. RDM is intended to provide simple configuration and management of fixtures, with control provided by traditional Null-Start-Code DMX.

If you're looking for a complex interconnected system with multiple controllers and everyone knowing what everyone else is doing, you're better off with something like ACN. ACN and SDT offer this kind of global knowledge and a reliable many-to-many multicast communications.

RDM maintains the traditional DMX model of a single control source with multiple controlled destinations.

[berntd]

Originally Posted by ericthegeek

What you're describing is beyond the scope of RDM. RDM is intended to provide simple configuration and management of fixtures, with control provided by traditional Null-Start-Code DMX.

If you're looking for a complex interconnected system with multiple controllers and everyone knowing what everyone else is doing, you're better off with something like ACN. ACN and SDT offer this kind of global knowledge and a reliable many-to-many multicast communications.

RDM maintains the traditional DMX model of a single control source with multiple controlled destinations.

No, I didn't mean muticastor anthng that fancy.
1 single device, 1 controller but device has built in control for the outputsvia whatever means.
Ok, I didn't expect the info as realtime either but if I see for example that channel n appears to be solid on or off or somewhin, it would be great to see if its output level is actually that or if the channel has popped or maybe the lamp.

Kind regards
Bernt

[ericthegeek]

If a channel is blown, or the lamp is out, that's a perfect application for status messages. If you look at the ESTA RDM Additional Messages website, you'll see there's already an extra status message there for STS_LOAD_FAILURE

http://www.esta.org/tsp/working_grou...RDMextras.html

If you want to report actual levels, you could advertise a sensor for each output that gives the real level. Sensors are pretty widely supported, but rather low bandwidth. The DMXter updates sensor levels once a second, not sure about other controllers.

With everything you're trying to do, I'd encourage you to attend one of the RDM plugfests. You'll find there are a lot of knowledgeable people around, and lots of different equipment to test with.

[berntd]

Originally Posted by ericthegeek

With everything you're trying to do, I'd encourage you to attend one of the RDM plugfests. You'll find there are a lot of knowledgeable people around, and lots of different equipment to test with.

Agreed but unfortunately not my decision :-(

Regards
Bernt

[sblair]

Agreed but unfortunately not my decision :-(

Bernt,

Let me know if there is anyone that will be at LDI that I can discuss it with. We've had a number of new people attend the last plugfest and they all found it was incredibly valuable for them to the point they were all planning on attending the next one in January as well.

I'll do what I can to help make the case for it.

Scott

[ericthegeek]

Another alternative is find someone who is going, and ask them to bring your gear along with them. There are people who travel from the UK, Germany, Sweden, and others.

Or, you can ship it to Scott or I, along with a list of specific things you'd like checked. We'll do our best to test it and report back to you. No guarantees of course, but we'll do the best we can.

Or, if you have a dealer or rep in the Dallas area, have them bring a unit to the plugfest.

[berntd]

Originally Posted by ericthegeek

Another alternative is find someone who is going, and ask them to bring your gear along with them. There are people who travel from the UK, Germany, Sweden, and others.

Or, you can ship it to Scott or I, along with a list of specific things you'd like checked. We'll do our best to test it and report back to you. No guarantees of course, but we'll do the best we can.

Or, if you have a dealer or rep in the Dallas area, have them bring a unit to the plugfest.

Thanks for all the kind words and suggestions.

Regards
Bernt

[zano_villa]

Hello,

In DEFAULT_SLOT_VALUE response, do I have to take into account actual personality with its footprint?
In other words, different responses depending on actual personality?

Thank you

[ericthegeek]

Originally Posted by zano_villa

In DEFAULT_SLOT_VALUE response, do I have to take into account actual personality with its footprint?

In other words, different responses depending on actual personality?

Yes, the DEFAULT_SLOT_VALUE response will be different depending on which DMX_PERSONALITY is currently active.


Many standard PIDs will have different responses depending on the current personality. In general, I recommend that controllers forget everything they know about a responder and re-query it any time they change the personality (or when they receive a queued message telling them that the personality has been changed via some other means).