Does the EMCY code's timestamp has enough margin compared to when FAULT is entered by the drive?

[d-loret]

I'm realizing that this line that compares the timestamp of the EMCY error with when the drive entered the FAULT state may be dependent on how fast the driver's execution cycle is. This is because fault_time is not exactly when the drive entered FAULT, but when the driver detected the drive entered FAULT.

So I am wondering whether the EMCY code is generated with enough delay to be properly handled by the aforementioned line.

[alex-brinkman]

In order to trigger that FAULT transition in the first place, PDO data communicating the state change is received and handed by the JSD driver (relevant snipped included below). At the same time, the pthread conditional is signaled to wake up the SDO thread to check if there is a new error code.

Though, I suppose temporally we should set the fault_time BEFORE the signal but it's probably not going to harm anything in practice... (@alex-brinkman TODO)

    // promotes timely checking of the EMCY code
    if(state->pub.actual_state_machine_state == JSD_EGD_STATE_MACHINE_STATE_FAULT){

      jsd_sdo_signal_emcy_check(self); // Originally here

      state->new_reset = false; // clear any potentially ongoing reset request
      state->fault_time = jsd_time_get_time_sec();

       jsd_sdo_signal_emcy_check(self); // Probably better if the SDO wakeup occurs after the PDO fault_time is set here

    }

Similar to how we handle the PDO data, the SOEM ecx_mbxreceive function checks if theres a new emergency and timestamps the error when its pushed onto the SOEM error queue (NOT the time of the fault on the slave or anything fancy)

So I think temporally we should be fine here.