To make it exclusive operation. no previous request should be pending when a new operation is requested. So only one state machine is running at a time. otherwise, while chamber fill is in progress, anyone can request drain and both requests will be handled. even through new code run only one state machine at a time, this will ensure that only one request is submitted to drybicart
This was a concern reported by Sean and proposed for restructuring into a single state machine.
I recommend DenaliMessage or LeahiMessage, as CanMessage is generic, whereas Leahi/Denali indicate that the protocol is also implemented in the message we are sending. I'm not sure why the name was changed, as it is a lot of change. Also, there is no CAN Message. There is a CAN Frame and a Leahi/Denali Message.
This doesn't look like a valid substate. We should have an enum for valid substates. In default case, we should trigger a s/w fault and also set the state to a valid state (idle or something like that).
What is this variable? If that is the rejection reason ID: 1, I don't think we should use it this way? We need to find the reason message/text for the rejection by the rejection ID. If that is the only case, let me know where it is used and why only one case was tested, rather than testing the rest. The entire rejection system needs to be tested in a separate test suite if we have not already done so.
