Power Group : DC Source
Mon, 2020-02-24 21:50 — Martin Perlot
From the Power Group,
This submission includes a considerable number of edits intended to improve comprehension, as well a several test profiles. In addition, new DGNs are proposed which allow device to communicate which DC Sources they are attached to. This will allow more sophisticated monitoring and coordination of devices on the network.
Test profiles in this section are prefaced with a 01, rather than a proper DSA. These tests may apply to a variety of devices, and in practice this prefix will be replaced by the DSA of the actual device. It is left to the Administrator to note this properly in the final document.
| Attachment | Size |
|---|---|
| 6_5 DC SOURCE- 021920bT.docx | 101.2 KB |
Define Default Tx rate for
Define Default Tx rate for new DC-SOURCE-CONNECTION-xxx messages
Change:
DC_SOURCE_CONNECTION_STATUS (6.5.20)
Change Default Rate from On-request to 5000mS
Justification:
OnRequest required all nodes to keep two tables in memory:
- Table of nodes which associate themselves with a DC-Instance of interest
- Table of nodes which have not reported their DC-Instance association
Though this could be accomplished by a multi-bit table, having nodes self-announce their association could reduce internal memory down to a single 256bit table. It is also more consistent with the existing behavior of messages this DC_SOURCE_CONNECTION-xxx is intended to replace. The present on-request complicates code in that each node will need to recognize the arrival of a new device, send a request and track its reply. Reception of a periodic broadcast message simplifies this.
Would like to see a conversation on this point, to keep only on-request,
Alarms are not included in
Alarms are not included in the test profile(s). I think this is essential to document so it is clear when the alarms should be sent.
For the solar controller section I added the following to the required response column. If the error is triggered by some condition that is met then it should be documented in the reporting section and if it is triggered by a command it should be in the command and response section.
Reports GENERIC_ALARM_STATUS with instance 102 (Solar charge controller over temperature)
All alarms in your alarm table should appear at least once in the profiles.
Clarification of use of
Clarification of use of 'Instance' and 'Set Priority' in DC_SOURCE_CONFIGURATION_COMMAND_3
Change:
DC_SOURCE_CONFIGURATION_COMMAND_3
Change byte 0 'Instance' to 'Set Device Instance'
Change byte 1 'Set Priority' to 'Set DC Priority'
Justification:
At present it is not clear what values 'Instance' and 'Priority' refer to. The intention of this new command is to allow for a given device to be configuration as to its 'Device instance' (Which is relevant to the DSA), and the DC Source Priority (which is relevant to any DC_SOURCE_xx messages the device may send out in the future).
Conversation:
In many ways it seems these two fields should actually be part of the devices DSA messages, not here. However, in doing a spot check, it seems there is no existing way to assign a 'Device Instance' to some devices, and likewise for the DC Source Priority to be used (if such messages are indeed sent out by a given device). And there is a level of synergy assigning the DC Instance and the DC Priority using this command. Does anyone have any feelings on this topic, that it should be broken out and placed into the individual DSA messages?
Bytes 0 & 1 combined are used to uniquely identify a specific device w/o using its CAN address. Instance is a very overused word, and in the present for there is opportunity for confusion. Purpose of this change is to provide clarity that the 'instance' in this case is the 'Device' instance as defined and used by th
Clarification of use of
Clarification of use of 'Instance' in DC_SOURCE_CONNECTION_STATUS
Change:
DC_SOURCE_CONNECTION_STATUS (6.5.20)
Change byte 0 'Instance' to 'Device Instance'
Justification:
Bytes 0 & 1 combined are used to uniquely identify a specific device w/o using its CAN address. Instance is a very overused word, and in the present for there is opportunity for confusion. Purpose of this change is to provide clarity that the 'instance' in this case is the 'Device' instance as defined and used by the DSA, as opposed to the 'DC Source Instance'.