Reformat the data to mat file for the analysis: data_rotator.mat

Linear Encoder Fault:

Linear Encode 1 Value:

We can see the significant fluctuation. This happens for the linear encoder 2 as well.

Compared with this, the motor encoder 1 and 2 looks smooth:

Compared with the above data, I have a data at 10/19/2022 (DM-35339) that shows the linear encoder data should be smooth:

The code to check the linear encoder fault is:

void actuator_check_linear_encoder_fault(actuator_t *actuator) {

    uint32_t linearEncFault = 0;

    // This is only reset by the clearError command from GUI or DDS

    linearEncFault |= (drive_get_copley_status(actuator->drive[1], 0) & 0x20);

    linearEncFault |= (drive_get_copley_status(actuator->drive[1], 1) & 0x20);

    if (linearEncFault) {

        gLinearEncFault = 1;

    }

}

Copley drive status reads the following memory object:

The 0x20 means the bit 5 here:

I think we could bypass the error checking at actuator_update() for the linear encoder fault. We can put this bypass option to the configuration file.

I think it might be dangerous to bypass this because it looks like the reading values of linear encoders are not smooth. The fluctuation of linear encoder values will give the Simulink model wrong idea of trajectory generator for the feedback values (and the result is unpredictable). It is noted that the execution frequency of trajectory generator is 4000 Hz.

Please help to review this ticket based on the data analysis in the comment. If you want me to implement the code to bypass the error checking, please issue me another ticket instead. But you could see I would not recommend to bypass this as I explained in the comment. Thanks!

Hi Te-Wei, thank you very much for confirming that we can bypass the Linear Encoder Fault.

However, I agree that we should avoid doing so since it can be dangerous. Let's leave the system as it is now and find out a better solution for the FRACAS-130 ticket. 

Ticket approved!