Modification to PGN Proposed - DC Load Command - 0x1FFBC
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
Tuesday, May 13, 2008 | 18:22pm
Please Sign in to View
Log in to view member-only content.
If you believe you are receiving this message in error contact us at memberservices@rvia.org.
David Tenney Member for 17 years
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 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.
Martin Perlot Member for 2 months 2 weeks
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.