DC Component Driver Command
Clayton Lorenz of Spyder Controls Group:
Proposes amendment of DC Component Driver Command to support full driver control through the DC Component Driver messages. This allows for a common command message for generic drivers including high side, low side, breakers, half and full bridge drivers that is extendable as new driver types or modes are required.
The DC Component Driver Command provides a common command interface to generic DC Drivers, including high and low side drivers, breakers, half and full bridge drivers. This can be used for multichannel driver devices where the types of loads being driven are not specified. When the specific load type is known and a there is a DGN specific to the load type, such as AWING_COMMAND, it is recommended to support that DGN. Although it is acceptable to also support control of the driver using the DC Component Driver Command.
The DC Component Driver Command can be used for driving loads or groups of loads that do not have defined DGN control methods. For instance, if used to control seat adjustment motors and seat heaters, the Device Instance would select the seat location as driver, passenger, etc, and the driver index would select the specific adjustment motor (position adjust, height adjust, tilt, etc), fan, or electric heater element in the seat controller.
| Attachment | Size |
|---|---|
| DC Component Driver Command amendment.docx | 22.42 KB |
This is not materially
This is not materially different than the previous submission on this topic, and suffers from the same problematic ambiguity. Rather that rehash that problem, I would like to suggest a method of making this concept workable.
The author is motivated by the desire to have a common interface to a variety of devices - which makes life easier for programmers and hopefully reduces the number of bugs. The RV-C protocol provides us with an example of a similar situation and an effective way to manage it. The AC_POINT DGNs provide a common means of describing AC power, and are applied to Generator, Inverter, Transfer Switch, and Generic AC Point. The first byte - the Instance - changes for each application (for example, for the transfer switch the Instance identifies the Leg and whether it's the input or the output being described.) The remaining seven bytes are identical for each application. But note that each application has its own set of DGNs.
We can use the same trick here. Simple take the last SIX bytes in this DGN (and the corresponding status DGNs) and consider them a "template", in the same way that the AC_POINT formats are a template for describing AC power. Then, as developers have applications for specific uses - such as the Seat described by the author - new DGN numbers are assigned and the first TWO bytes are described by the submitter. The submission would describe the instancing scheme (which usually would match the scheme used for the device, but variations are possible) and the functions addressed in the second byte.
In the Seat example, Byte 0 would be the seat instance as already described in a recent submission. Byte 1 would be explicitly described, something like.
1 = Foot Rest Motor
2 = Main Tilt Motor
3 = Back Tilt Motor
4 = Forward Position Motor
5 = Head Rest Motor
6 = Heat
and so on.
A further requirement would be that the value in Byte 1 MUST be defined in the protocol. We cannot have one manufacturer using 7 for Massage Motor and another manufacturer using 7 for Cooling Fan. Of course, adding functions to these DGNs should be a trivial submission - like submitting SPNs. It is hard to imagine a RV-C device with more than 250 possible motors/switches requiring independent control.
There is one significant downside to this scheme. Should we go ahead and begin creating DGNs for devices that already exist, we will have two alternative methods of control for the same device. For example, you may be able to control an awning with AWNING_COMMAND and AWNING_DC_COMPONENT_DRIVER_COMMAND. If we allow this, we have to be very careful in our requirements. For example, do we require vendors to support both control mechanisms? Do we require both status messages to be broadcast in response? How do timing requirements translate to the new commands (e.g. the requirement for slide rooms to stop promptly when the message streams ends)?
There is a lot here to unpack. I think we can solve the narrow technical problems by applying the "template" strategy. But the broader problems need more discussion.
-