Modification to PGN Proposed - DC Load Command - 0x1FFBC
Tue, 2008-05-13 22:22 — Anonymous
Proposed:
Addition to the current PGN (0x1FFBC) definition using currently reserved bytes of the command to further specify control of a module.
Edit:
- Command Byte 3: Interlock has been explained as a bitmap
- Command Byte 4: “Set Level” has been changed from 0xFF to 0x00. Also, the commands have been listed and explained in a separate table which is referenced.
Edit 2:
- "Priority" added to byte 3, bits 4 to 7.
- "Command" in byte 4 now referenced to unified and centralized command table located in AC LOAD COMMAND
- Momentary duration now changed to 0.1s
| Attachment | Size |
|---|---|
| DC Load Command EDIT.doc | 51.5 KB |
| DC_Load_Command_v2.doc | 42.5 KB |
David
David Bailey
Conditionally,
Byte 0 We should not use 255 for information. Use 254 for all loads in indicated groups. (We probably need to set a conference call on grouping so we all implement it the same.)
Bytes 1,2,3 OK
Byte 4 Command table, use the same table a DC Dimmer.
Byte 5,6,7 looks OK
Now, how are you proposing including the rest of the infromation in the existing DC_LOAD_STATUS like priority, delay, demand current, present current?
Engineering at Spyder
Engineering at Spyder Controls Corp.
In Byte 0, we understand 255 as “no data”, which implies that a group would them need to be defined in order for the message to be relevant. This could be clarified by re-wording the definition that was grandfathered in from the original DC Load PGN.
On the command table for byte 4, many of the DC Dimmer commands do not apply to a DC load (ramp commands, etc). So the DC table was developed as a ‘sub-set’ of the DC Dimmer commands.
This looks Ok. My comments
This looks Ok. My comments here duplicate the DC_DIMMER_COMMAND comments.
- "Interlock" needs to be explained.
- 0xFF is not a good choice for a command. I suggest 0 for "Set Level".
- The commands need to be more thoroughly explained.