This was first seen for the M2 Hexapod. Today I confirmed for the Camera Hexapod.

Question for Te-Wei Tsai: what happens if the low-level controller receives an incomplete command? Can it successfully ignore that and process new commands correctly? I am not sure it is even possible for my code to send an incomplete command, but it has an "await" for sending data that I'd like to be able to interrupt.

The low-level controller code will ignore the illegal commands and process the new ones. However, this might depend on the condition of "incomplete" command here. If some information is lost in the network packet, this might be a problem.

The defined application status is in the following. Most items are high-level and I am not sure why do we need the data of each actuator. For example, why do we need 6 actuator report the "AppStatus_GuiConnected"?

typedef enum {

    // Many compilers assign the first element in an enumerated type to the

    // value 0.

    AppStatus_InvalidFirst = 0,

    // Following error

    AppStatus_FollowError = 1,

    // Move complete (not in motion)

    AppStatus_MoveComplete = 2,

    // GUI connected

    AppStatus_GuiConnected = 4,

    // Relative move mode

    AppStatus_RelativeMoveMode = 8,

    // Synchronous mode

    AppStatus_SyncMode = 16,

    // Last command exceeds range

    AppStatus_LastCmdExceedRange = 32,

    // Safety interlock open

    AppStatus_InterlockOpen = 64,

    // Extend limit switch

    AppStatus_ExtendLimitSwitch = 128,

    // Retract limit switch

    AppStatus_RetractLimitSwitch = 256,

    // Ethercat problem (fault state)

    AppStatus_EthercatProb = 512,

    // 1=DDS is commanding, 0=eGUI is commanding

    AppStatus_CommandByDds = 1024,

    // Motion timeout (one or more struts not settling, or command values did

    // not change)

    AppStatus_MotionTimeout = 2048,

    // DDS is connected

    AppStatus_ConnectedDds = 4096,

    // Drive fault

    AppStatus_FaultDrive = 8192,

    // Simulink fault

    AppStatus_FaultSmlnk = 16384,

} AppStatus;

Actually, I think this application status should not be an array but a single element. This modification will affect the reading of stream data in EUI part.

Interesting! So information I thought was per-actuator is actually higher-level information that combines data from all actuators.

Here is the per-actuator information I would like to have, if practical:

• Forward limit switch (L2 limit) active
• Reverse limit switch (L2 limit) active
• Forward kill switch (L3 limit) active (does the system have L3 limits and if so, can it tell the difference between the forward and reverse L3 limits?)
• Reverse kill switch (L3 limit) active
• In position (if this is unavailable then I may want to change the MTHexapod XML)
• Drive enabled (i.e. amplifier on, not in fault state, not "out of closed loop")
• Actuator moving

Refactored the GUI for the changed data structure. Reorganize the vis.

The details of Copley drive code can be found at: All-CANopen_Programmers_Manual-Manual.pdf.

For the information of limit switch, we could check the input_pin_states. The code is 0x219A. The key is to check the pins "6, 7, 8" and "16, 17, 18).

PS. The pin state here also contains the information of interlock. The details can follow: DM-28434.

For the implementation of low-level controller, the code is:
1. https://github.com/lsst-ts/ts_hexapod_controller/blob/develop/src/utility.c#L42-L44
2. https://github.com/lsst-ts/ts_hexapod_controller/blob/develop/src/drives/drive.c#L459-L464

It looks like the copley_fault_status_register (or 0x1002) gives more information (page 61 in All-CANopen_Programmers_Manual-Manual.pdf ). The bit value in use in EUI now is:

List the interested bit value of 0x1002 in the following:
Bit 9: Positive limit switch active
Bit 10: Negative limit switch active
Bit 27: In motion (I guess this can be seen as the "Actuator moving")

I do not find something called the "kill switch".

The status_word (or 0x6041) has some information (page 60):
Bit 10: Target Reached (I guess this can be seen as "In position")
Bit 14: Set when the amplifier is performing a move and cleared when the trajectory finishes (I guess this can be seen as "Drive enabled")

The related EUI image is here:

Please help to review:
1. https://github.com/lsst-ts/ts_hexapod_controller/pull/10
2. https://github.com/lsst-ts/ts_hexapod_gui/pull/6

Please ignore the LabVIEW jenkins failed test. There is the problem of CTIO Jenkins now. Contact the people there to fix it already.

Thanks!

Reviewed on github.