Commands conflict with current VESC FW

[Peemouse]

Hi @DieBieEngineering,

Since VESC FW3.62, a 0x50rd command has been added.
This conflicts with yourCOMM_STORE_BMS_CONF = 50

Even worse, the 0x51st COMM_GET_BMS_CELLS often used by third party devices may lead to probably brick a VESC if not issued to the correct CAN_ID (0x51st command VESC side is COMM_WRITE_NEW_APP_DATA_LZO introduced in VESC FW 3.63).

What do you think about that ?
Should the COMM_STORE_BMS_CONF be shifted to let's say 0x70 or even maybe 0xA0 to add another gap ?

[DieBieEngineering]

Thanks for pointing out, I'll update it in the next release. Danny

…

On Wed, Mar 18, 2020, 11:08 Peemouse ***@***.***> wrote: Hi @DieBieEngineering <https://github.com/DieBieEngineering>, Since VESC FW3.62, a 0x50rd command <https://github.com/vedderb/bldc/blob/e1c859c894bf88b082e589234dc8c78125b9fb8e/datatypes.h#L754> has been added. This conflicts with yourCOMM_STORE_BMS_CONF = 50 Even worse, the 0x51st COMM_GET_BMS_CELLS often used by third party devices may lead to probably brick a VESC if not issued to the correct CAN_ID (0x51st command VESC side is COMM_WRITE_NEW_APP_DATA_LZO introduced in VESC FW 3.63). What do you think about that ? Should the COMM_STORE_BMS_CONF be shifted to let's say 0x70 or even maybe 0xA0 to add another gap ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#7>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACQ75HRMV3MWU5F5UFCEMCDRICMQDANCNFSM4LONWZSQ> .