Fixes Quick Stop transition in EPD driver

[d-loret]

EPD driver requested an Enable Operation's state machine transition inadvertently during Quick Stop Active.

The firmware in Platinum drives should ignore such request if Quick Stop Option Code is set to 2. However, some drives do not follow the documented behavior and transition into Enabled Operation from Quick Stop Active. As a consequence of this, if there is a brake configured in the drive, the brake will remain engaged after the Quick Stop.

Test Plan: Tested on Safety and non-Safety Platinum drives connected to motors. The test consisted on sending one profiled position command, and sending a second one after completion of the first. Now the state machine does not transition to Enabled Operation from Quick Stop Active, and the motor's brake is engaged and disengaged properly.

[preston-rogers]

Hey Daniel, whenever you're back, you are referring to how this state transition should not be possible if the quick stop option code is not 5 or 6?

Additionally, by "brake will remain engaged" do you mean the brake will not be keeping the rotor fixed?

[d-loret]

Hey Daniel, whenever you're back, you are referring to how this state transition should not be possible if the quick stop option code is not 5 or 6?

Additionally, by "brake will remain engaged" do you mean the brake will not be keeping the rotor fixed?

Yes, transition 16 should not be possible with the code we are using (2).

By "brake will remain engage" I meant that if you try to re-enable the actuator, the brake will not open anymore (i.e. tries to keep the rotor from moving).

[preston-rogers]

Basic question, but do we have a state diagram that outlines the interaction between "JSD_EPD_STATE_MACHINE" states and "JSD_ELMO_STATE_MACHINE_STATE" states?

[d-loret]

Reference in

[d-loret]

Basic question, but do we have a state diagram that outlines the interaction between "JSD_EPD_STATE_MACHINE" states and "JSD_ELMO_STATE_MACHINE_STATE" states?

I am not sure what you mean by "JSD_EPD_STATE_MACHINE," do you mean jsd_epd_state_machine_controlword_t?

There is the actual state of the state machine in the drive which is referred in the code by the enumeration type jsd_elmo_state_machine_state_t (JSD_ELMO_STATE_MACHINE_STATE_*). This state is kept by the drive itself and we query it in each execution cycle of JSD.

And there is the controlword which is a variable in the Object Dictionary of the drive used, among a few other things, to trigger the transitions of the state machine in the drive. The driver here uses the controlword to tell the drive what transition we want.

You can read more about it in the documentation of the drive. Check section 4.2 Device Control Objects in the Platinum Administrator Guide.

[preston-rogers]

Hey Daniel, when the SW bit 12 is 1 and it says "previous set-point still processed; set-point buffer is not available," I'd like some clarification. By "previous set-point still processed" does this mean that the drive has yet to reach the previous set-point? As in, the buffer for set-points in the drive is only of size one and we need to wait until the statusword bit 12 is 0 again to send the next set-point?

[d-loret]

Hey Daniel, when the SW bit 12 is 1 and it says "previous set-point still processed; set-point buffer is not available," I'd like some clarification. By "previous set-point still processed" does this mean that the drive has yet to reach the previous set-point? As in, the buffer for set-points in the drive is only of size one and we need to wait until the statusword bit 12 is 0 again to send the next set-point?

The drive supports different modes for profiled position. The modes differ on how they process new set-points. There is a "buffer mode" in which set-points are queued and processed one by one. We are not using this mode. In the mode we are using, set-points are followed immediately. That's why we also set the "request immediate change" bit: https://github.com/nasa-jpl/jsd/blob/master/src/jsd_epd.c#L1170-L1171