DC Component Driver Status
Thu, 2021-01-21 19:06 — VonLindsey
Clayton Lorenz of Spyder Controls Group is proposing addition of DC Component Driver Status 6 message to support full driver status through the DC Component Driver messages. This allows for a common status message from generic drivers including high side, low side, breakers, half and full bridge drivers.
| Attachment | Size |
|---|---|
| DC Component Driver status amendments.docx | 23.58 KB |
| DC Component Driver status amendments Rev 2 - 2021.03.26.docx | 23.71 KB |
The revisions do not address
The revisions do not address my objection to DC_COMPONENT_DRIVER_6.
Some elements of DC_COMPONENT_DRIVER_6 are acceptable, as they are inherent properties shared by (some) DC Drivers. In this category is "PWM Duty" and "Driver Pulsing", although I suggest adding some description to these to better indicate the relationship between the two. (e.g. does a value of 0 in Driver Pulsing mean that the driver is entirely off? Can Pulsing be 1 and PWM Duty be 0?)
Some elements could be made acceptable if they are rewritten to only reference the properties of the driver, and not the application. For example, references to "forward" and "up" are descriptions of a DC Motor, Window Shade, or such. A driver is only "High" or "Low". Note that this can be essential for troubleshooting . . . by conflating the driver with the application it is connected to, we make it more confusing when troubleshooting a miswired application. In this category is "Driver Direction" and "Command Timeout". (There are other sorts of timeouts other than a Command Timeout. For example, a watchdog (at its simplest) is a DC driver with a timeout that is reset when an input is pulsed to it.)
Some elements need further definition in the context of a DC Driver. It is not at all clear what a "Lock" or "Override" are - what events trigger a change in their status and what is their impact on driver behavior. Again, these should be defined in terms either of properties inherent in the design of a DC Driver, or in terms of other specific RV-C data items.
Finally, several elements reference elements that are nowhere else defined in the protocol and are not inherent properties of a driver. In this category are Delay Remaining and Duration Remaining. (Granted, a time-delay relay is a DC Driver for which a delay is an inherent property, but these fields aren't structured or scaled appropriately for that purpose.) These appear to be leftovers from the companion submission and without that submission they have no meaning.
The original submission
The original submission proposed changed to three DGNs: DC_COMPONENT_DRIVER_STATUS_1, DC_COMPONENT_DRIVER_STATUS_2, and DC_COMPONENT_DRIVER_STATUS_6. For reference and clarity, I am summarizing their current status: DC_COMPONENT_DRIVER_STATUS_1 is now being addressed here rv-c.com/node/608; DC_COMPONENT_DRIVER_STATUS_2 as corrected has not had objections for 30 days; and DC_COMPONENT_DRIVER_STATUS_6 is still being discussed with objections.
Two comments on this: 1)
Two comments on this:
1) DC_COMPONENT_DRIVER_STATUS_1 changes are not the same in these two submissions. Only the changes highlighted in red are under consideration. Hence the two submissions can be summarized as follows:
Reason for Shutdown: 6 = Over Temperature, 7 = Hardware Disabled, 8 = Driver Fault.
2) DC_COMPONENT_DRIVER_STATUS_6 only had the standing objection of the broadcast rate, and we agreed to the suggested change, so to my knowledge there is nothing else that needs to be resolved here.
You did address my concerns
You did address my concerns but the post from Sat, 2021-04-24 13:26 indicates there is still an open objection.
DC_COMPONENT_DRIVER_STATUS_2,
DC_COMPONENT_DRIVER_STATUS_2, Under Current field: the value 3 is already reserved for not available so this change is redundant.
No concern with the comment.
No concern with the comment. The administrator can defiantly can remove anything that is redundant.
Regarding
Regarding DC_COMPONENT_DRIVER_STATUS_6, this DGN only has relevance if its companion submission (http://www.rv-c.com/node/598) is also approved. That submission has received an objection, and therefore I object to this DGN as well.
Regarding DC_COMPONENT_DRIVER_STATUS_1, the same is true. A driver is either Off or On, period. Whether the software behind the driver is in a manual or automatic state is a function of that application (e.g. awning, charger, etc..), and should be reported in the DGNs relevant to that device.
Regarding DC_COMPONENT_DRIVER_STATUS_2, these appear to be fine.
DC_COMPONENT_DRIVER_STATUS_1
DC_COMPONENT_DRIVER_STATUS_1
It is huge difference if a driver is on because of a driver level override being active and it just being on. Would you like to see this elsewhere? The information must be conveyed, so if you would prefer this as a separate section under DC_COMPONENT_DRIVER_STATUS_6 that could be easily changed.
DC_COMPONENT_DRIVER_STATUS_6
Nothing in this addition requires changes in the command structure to be considered relevant. Why wouldn’t it be alright to broadcast the direction the direction the driver is being driven? Or if it is pulsing? Or if it is on but will automatically shut off within a certain period?
Fundamentally the submitter did not originate the DC Component Driver Status, but now that is has been created, we simply want to include a few more details to it that were lacking in DC_COMPONENT_DRIVER_STATUS_1 through DC_COMPONENT_DRIVER_STATUS_5.
If there is a typo, let’s work together to correct it. If there is a misuse of a data type, units, etc., lets fix them. But beyond that, this is all simple information that can be broadcast from a driver, which isn’t in the spec yet, so why not add it in? If there are additional features anyone thinks of, we have space in bytes 6 and 7 to include them!
DC_COMPONENT_DRIVER_STATUS_6.
DC_COMPONENT_DRIVER_STATUS_6. I disagree with the objector, I think this DGN does provide useful information that does not appear in any of the other DC_COMPONENT_DRIVER_STATUS messages. I would suggest that the Broadcast rate be changed to On Request. As this DGN contains timers with a resolution of seconds, On Change would increase network traffic unnecessarily.
Generally I agree, but I
Generally I agree, but I think it would be appropriate to broadcast on change of something like driver direction or a change in the PWM duty so I left it in. Perhaps a note could be made indicating that for delay and duration they shouldn't broadcast on change?
Can you give an example of
Can you give an example of when the direction or duty cycle would change? If it is in response to a command over RV-C, there would already be a response transmitted. If the device is more complicated and has controls on it that would enable changing the direction or duty cycle, should those controls be considered RV-C components and make their request over the network? That would make it clear to all other RV-C devices as to why the direction changed.
I agree that the other data
I agree that the other data fields would change as a result of an incoming command so this change to the normal broadcast gap isn't an issue on our end.
DC_COMPONENT_DRIVER_STATUS_1:
DC_COMPONENT_DRIVER_STATUS_1:Output Status. I agree with the objector. Typically, two bit fields represent the values OFF, ON, ERROR, and N/A. I would not object to this information being included elsewhere - perhaps in the STATUS_6 DGN.
I agree with this
I agree with this improvement. It has been moved to Status 6 and should be reposted with this change shortly.