# The MTHexapod low-level controller appears to only publish application status for the first actuator

XMLWordPrintable

#### Details

• Type: Story
• Status: Done
• Resolution: Done
• Fix Version/s: None
• Component/s:
• Labels:
• Story Points:
1
• Sprint:
TSSW Sprint - Apr 12 - Apr 26
• Team:
Telescope and Site
• Urgent?:
No

#### Description

The summit EFD shows that application status is only nonzero for the first actuator (field applicationStatus0 of logevent_controllerState. Fields 1-5 are all zero.

I suspect the problem is in the low-level controller because I checked the values when using the internal simulator and found nonzero data for all elements of the array.

#### Attachments

1. 0x1002_InUse.png
33 kB
2. All-CANopen_Programmers_Manual-Manual.pdf
2.90 MB
3. statusWordEui.png
37 kB

#### Activity

Hide
Holger Drass added a comment -

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

Show
Holger Drass added a comment - This was first seen for the M2 Hexapod. Today I confirmed for the Camera Hexapod.
Hide
Russell Owen added a comment -

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.

Show
Russell Owen added a comment - 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.
Hide
Te-Wei Tsai added a comment -

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.

Show
Te-Wei Tsai added a comment - 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.
Hide
Te-Wei Tsai added a comment - - edited

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.

Show
Te-Wei Tsai added a comment - - edited 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.
Hide
Russell Owen added a comment - - edited

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
Show
Russell Owen added a comment - - edited 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
Hide
Te-Wei Tsai added a comment -

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

Show
Te-Wei Tsai added a comment - Refactored the GUI for the changed data structure. Reorganize the vis.
Hide
Te-Wei Tsai added a comment -

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

Show
Te-Wei Tsai added a comment - The details of Copley drive code can be found at:  All-CANopen_Programmers_Manual-Manual.pdf .
Hide
Te-Wei Tsai added a comment - - edited

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".

Show
Te-Wei Tsai added a comment - - edited 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".
Hide
Te-Wei Tsai added a comment - - edited

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:

Show
Te-Wei Tsai added a comment - - edited 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:
Hide
Te-Wei Tsai added a comment -

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!

Show
Te-Wei Tsai added a comment - 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!
Hide
Russell Owen added a comment -

Reviewed on github.

Show
Russell Owen added a comment - Reviewed on github.

#### People

Assignee:
Te-Wei Tsai
Reporter:
Russell Owen
Reviewers:
Russell Owen
Watchers:
Andy Clements, Bo Xin [X] (Inactive), Brian Stalder, Holger Drass, Russell Owen, Te-Wei Tsai
0 Vote for this issue
Watchers:
6 Start watching this issue

#### Dates

Created:
Updated:
Resolved:
Start date:
End date:

#### Jenkins

No builds found.