Remove 6.18.20 & .21
Mon, 2021-07-12 22:10 — RV-C Admin
Proposed:
Deprecation of GENERATOR_DC_CONFIGURATION_STATUS_5 and GENERATOR_DC_CONFIGURATION_COMMAND_5.
Justification:
Table 6.18.20b, doesn't make much sense. Byte 2 may be “Priority', in which case it duplicates data in GENERATOR_DC_STATUS_2, or it may be “Absorption Time”, in which case it duplicates GENERATOR_DC_CONFIGURATION_STATUS_4 – but with absurd scaling.
Please see attached for proposed deprecation/removal.
| Attachment | Size |
|---|---|
| Section 6.18.20_.21 Removal 070821.docx | 19.9 KB |
DISCUSSION: There is a
DISCUSSION:
There is a collating error in these PGNs, the original submission was:
Byte Bit Name Data type Unit Value description
0 - Instance uint8 -
1 - DC Source Instance uint8 - DC Source generator is associated with.
2 - DC Generator priority uint8 - Priority of DC Generator. See b
With the primary purpose to allow association of the DC Generator with its attached DC SOURCE INSTANCE. (Byte 1 & 2 are repeated to meet the goal of all messages begin fully self-sufficient). However, it does appear this is a direct replication of DC_GENERATOR_STATUS_2. More so, in late discussion to the spec, DC Source association was generalized using : DC_SOURCE_CONNECTION_STATUS message.
Is it possible to retire / remove a DNG once the spec is published? As opposed to Depreciate it?
This is really up to Von.
This is really up to Von.
Personally, I would mark section 6.18.20 with the text "GENERATOR_DC_CONFIGURATION_STATUS_5 has been removed from the protocol and DGN 1FDD5h deprecated." Same with 6.18.21, and I'd mark those rows in Table 7.7 as deprecated. I always erred on the side of deleting as little as possible, but in this case the DGN is so incoherent that I'd pull the table out completely and just leave a message for future generations so that no one comes along and defines a new DGN called GENERATOR_DC_CONFIGURATION_STATUS_5 or using 1FDD5h.
I would not disagree with you
I would not disagree with you on this point, given the miss-edits in the PGN and how it clearly is not correct, nor published as intended -- one would either remove the whole thing, or correct it and then deprecate it...