6.50 DC Component Driver Status 1
Thu, 2021-03-11 23:11 — VonLindsey
Clayton Lorenz of Spyder Controls proposes the addition of two additional shutdown reasons to Table 6.50.1b
Byte Bit Name Data Type Unit Value Definition
7 - Reason for Shutdown uint8 - 7= Safety input not active
8= Driver Fault
| Attachment | Size |
|---|---|
| Driver Status 1 Amendment - 2021.03.11.docx | 15.3 KB |
| Driver Status 1 Amendment Rev 2 - 2021.03.26.docx | 15.27 KB |
The comment from Friday,
The comment from Friday, March 12, 2021 asserts that the submitter has a fundamental misunderstanding of how the shutdown reason for a safety status should be implemented.
Unfortunately, the submitter disagrees with this assertion, as it is a completely legitimate reason for a driver being shut down, and it is also completely legitimate to want to convey the reason over the network. The basis for the objection is a misunderstanding by the objector of the level at which a safety input is applied or how it is used in certain applications. The awning example only applies to one DSA, and hence is far too ridged for capturing how DC Driver status applies to the other DSAs that are available.
As we are all well aware, there is no assumption that every feature from every DGN in the RV-C spec is applicable in every application. The same is true with this, and for modules where this is not applicable this index value can be omitted at the discretion of the developer. But that is not a valid argument for disallowing it in legitimate use cases.
This is not conflicting with existing safety information; it is supplemental and essential to fully understand why the driver is in the current state it is in in many applications. We politely request that the objection be withdrawn as it is in no conflict with existing content and fundamentally gives added information where this feature is applicable.
I will happily retract my
I will happily retract my objection if the submitter can provide an application document or specification sheet from a FET, Relay, DC Driver or similar driver which includes reference to a "Safety Input", and that resetting the driver will clear this condition. This particular field describes the physical condition of the driver - not the status of the software that controls it.
The status of any safety input belongs somewhere else - and in every case mentioned so far, there is already a place for it.
A breaker panel. Each breaker
A breaker panel. Each breaker driver is a “standalone” device – it enables as soon as there is power, it does not need any network communication to function, it is not related to any other intelligent device in a network to be told anything about the safety inputs or anything else for that matter. The safety inputs run directly to the driver. This is not the only driver level safety, but it should suffice to show that this is not an optional, wish list, addition. The spec needs to support this to match current technology and development.
There are plenty of driver
There are plenty of driver ICs that include an ENABLE input. I can imagine an RV-C device that incorporates one of those drivers and brings that signal out on a connector - perhaps as an E-stop. As the driver is universal, it wouldn't necessarily be tied to a higher level function like AWNING. If that input is not configurable and when ASSERTED (or NEGATED) disables the driver, it would make sense for that to be reported in the DC_COMPONENT_DRIVER_STATUS_1 message. Nothing in the system has commanded the driver to be OFF. Perhaps the field could be renamed "Hardware disabled" or something similar.
I agree with the label
I agree with the label change. We will resubmit the document with this clarification in it to call this “Hardware Disabled”.
This is acceptable.
This is acceptable.
DC Component Driver Status 1
DC Component Driver Status 1 is also discussed here: rv-c.com/node/597. There is a change requested and agreed to not reflected in the above attachment but made to the attachment in the other topic: specifically, removing the addition to Output Status. I don't want that to be missed.
Similar to the reply in the
Similar to the reply in the other thread, only the changes highlighted in red are under consideration.
Understood. My point was the
Understood. My point was the the above attachment still shows "10b - On, Override active (such as a manual override switch)" as a valid value for Output Status and I didn't want that to mistakenly make its way into the specifications.
It seems as though there is a
It seems as though there is a misunderstanding here. Driver Fault is Ok, but Safety Input is inappropriate.
The Shutdown Status and Reason for Shutdown are intimately tied to the DC_COMPONENT_DRIVER_COMMAND. These data indicate when and why it might be necessary to reset the driver. The existing examples include over-voltage and over-current conditions. Other possibilities based on app-docs that I've read include over-temperature and backfeed. "Driver Fault" is a reasonable catch-all term. But the safety input is a different thing altogether.
If a driver is in a shutdown condition, the DC_COMPONENT_DRIVER_STATUS_1 DGN should be populated as follows:
Output Status = Off
Desired Status = On (At least, at first. The status might be turned off after the shutdown has occurred)
Shutdown Status = Disabled
Reason for Shutdown = As appropriate, e.g. Short Circuit
If a driver is turned off due to a safety interlock (for example, the unit drives an awning motor, and the awning requires a park brake signal), then the DC_COMPONENT_DRIVER_STATUS_1 DGN should be populated as follows:
Output Status = Off
Desired Status = Off
Shutdown Status = Ok
Reason for Shutdown = 0
Note that the Desired Status is, unambiguously, OFF! The driver is not in an error condition, so the Reason for Shutdown does not apply (and should be 0.) If the driver requires a manual reset, sending DC_COMPONENT_DRIVER_COMMAND will not have an effect.
The status of the safety input should be indicated in the status DGN for the actual device being driven - e.g. AWNING_STATUS. If the submitter desires to duplicate this information in the DC_DRIVER DGNs, it should be in its own data field. And frankly, a strong justification should be included in such a submission as duplicating data fields is a recipe for miscommunication. That always something we should avoid, particularly when the datum is safety related.
Perhaps some additional verbiage in the DGN description would help others who are navigating this DGN.