[DM-22103] Please uncomment some logging statements in the MT Rotator cRIO - Jira

XML

Word

Printable

Details

Type: Improvement
Status: Done
Resolution: Done
Fix Version/s: None
Component/s: ts_main_telescope
Labels:
- HexRot
- MainTelescope

Story Points:
0
Epic Link:
Develop and Test the Hexapod and Rotator Software Phase 1
Sprint:
TSSW Sprint - Mar 30 - Apr 13
Team:
Telescope and Site

Description

Please enable the logging statements at lines 400, 403 and 408 in rotator/targetx2/commanding.c: the commented-out syslog calls in:

                // select who can command the rotator: GUI (default/0) or DDS (1)

                case CMDSOURCE:

                    if (isOffline(state1) && isPublishOnly(offlineSubstate1))

                        syslog(LOG_ERR, "command not allowed in Offline/PublishOnly state");

                        gCommandSourceDDS = 0;

                        break;

                    if (cmdMsg.param1 > 0.5)

                       if (gCmdDDSServerConnected == 1)

                          //syslog(LOG_NOTICE, "Command source now == DDS");

                          gCommandSourceDDS = 1;

                       //else syslog(LOG_NOTICE, "Not connected to DDS Cmd socket");

                    else

                       //syslog(LOG_NOTICE, "Command source now == GUI");

                       gCommandSourceDDS = 0;

                    break;

Please also look for and enable similar messages in the hexapod commanding.c

This will help us diagnose when the rotator or hexapod cRIO decides to ignore commands from the CSC.

Note that any command from the "GUI", which is what we call the Engineering User Interface (EUI), will reset gCommandSourceDDS to 0, making the CSC unable to command the cRIO. That is based on different code in rotator/targetx2/cmdClientSocket.c:

              // IF DDS was in control, a cmd from GUI will revert to GUI control

              if (gCommandSourceDDS)

                   ////printf("Command source==GUI\n");

                 gCommandSourceDDS = 0;

This looks like a bug or misfeature to me (unless it also changes the state to Offline/PublishOnly, which I strongly doubt).

I would expect the CSC to always be able to control the rotator except in Offline/PublishOnly mode.

This task will try to understand the logging mechanism and log the useful information. This will be helpful for the following debug.

Attachments

Issue Links

relates to

DM-24361 Allow the Connection Message in the MT Hexapod PXI Controller

Done

Activity

Ascending order - Click to sort in descending order

Russell Owen created issue - 05/Nov/19 4:28 PM

Te-Wei Tsai made changes - 12/Mar/20 11:59 PM

Field	Original Value	New Value
Epic Link		~~DM-21931~~ [ 425242 ]

Te-Wei Tsai made changes - 12/Mar/20 11:59 PM

End date		27/Mar/20
Sprint		TSSW Sprint - Mar 16 - Mar 30 [ 1006 ]
Start date		16/Mar/20
Story Points		3
Description	Please enable the logging statements at lines 400, 403 and 408 in rotator/targetx2/commanding.c: the commented-out syslog calls in: {code} // select who can command the rotator: GUI (default/0) or DDS (1) case CMDSOURCE: if (isOffline(state1) && isPublishOnly(offlineSubstate1)) { syslog(LOG_ERR, "command not allowed in Offline/PublishOnly state"); gCommandSourceDDS = 0; break; } if (cmdMsg.param1 > 0.5) { if (gCmdDDSServerConnected == 1) { //syslog(LOG_NOTICE, "Command source now == DDS"); gCommandSourceDDS = 1; } //else syslog(LOG_NOTICE, "Not connected to DDS Cmd socket"); } else { //syslog(LOG_NOTICE, "Command source now == GUI"); gCommandSourceDDS = 0; } break; {code} Please also look for and enable similar messages in the hexapod commanding.c This will help us diagnose when the rotator or hexapod cRIO decides to ignore commands from the CSC. Note that any command from the "GUI", which is what we call the Engineering User Interface (EUI), will reset gCommandSourceDDS to 0, making the CSC unable to command the cRIO. That is based on different code in rotator/targetx2/cmdClientSocket.c: {code} // IF DDS was in control, a cmd from GUI will revert to GUI control if (gCommandSourceDDS) { ////printf("Command source==GUI\n"); gCommandSourceDDS = 0; } {code} This looks like a bug or misfeature to me (unless it also changes the state to Offline/PublishOnly, which I strongly doubt). I would expect the CSC to always be able to control the rotator except in Offline/PublishOnly mode.	Please enable the logging statements at lines 400, 403 and 408 in rotator/targetx2/commanding.c: the commented-out syslog calls in: {code} // select who can command the rotator: GUI (default/0) or DDS (1) case CMDSOURCE: if (isOffline(state1) && isPublishOnly(offlineSubstate1)) { syslog(LOG_ERR, "command not allowed in Offline/PublishOnly state"); gCommandSourceDDS = 0; break; } if (cmdMsg.param1 > 0.5) { if (gCmdDDSServerConnected == 1) { //syslog(LOG_NOTICE, "Command source now == DDS"); gCommandSourceDDS = 1; } //else syslog(LOG_NOTICE, "Not connected to DDS Cmd socket"); } else { //syslog(LOG_NOTICE, "Command source now == GUI"); gCommandSourceDDS = 0; } break; {code} Please also look for and enable similar messages in the hexapod commanding.c This will help us diagnose when the rotator or hexapod cRIO decides to ignore commands from the CSC. Note that any command from the "GUI", which is what we call the Engineering User Interface (EUI), will reset gCommandSourceDDS to 0, making the CSC unable to command the cRIO. That is based on different code in rotator/targetx2/cmdClientSocket.c: {code} // IF DDS was in control, a cmd from GUI will revert to GUI control if (gCommandSourceDDS) { ////printf("Command source==GUI\n"); gCommandSourceDDS = 0; } {code} This looks like a bug or misfeature to me (unless it also changes the state to Offline/PublishOnly, which I strongly doubt). I would expect the CSC to always be able to control the rotator except in Offline/PublishOnly mode. * This task will try to understand the logging mechanism and log the useful information.
Labels		HexRot MainTelescope

Te-Wei Tsai made changes - 13/Mar/20 12:04 AM

Description

Please enable the logging statements at lines 400, 403 and 408 in rotator/targetx2/commanding.c: the commented-out syslog calls in:
{code} // select who can command the rotator: GUI (default/0) or DDS (1)
                case CMDSOURCE:
                    if (isOffline(state1) && isPublishOnly(offlineSubstate1))
                    {
                        syslog(LOG_ERR, "command not allowed in Offline/PublishOnly state");
                        gCommandSourceDDS = 0;
                        break;
                    }
                    if (cmdMsg.param1 > 0.5)
                    {
                       if (gCmdDDSServerConnected == 1)
                       {
                          //syslog(LOG_NOTICE, "Command source now == DDS");
                          gCommandSourceDDS = 1;
                       }
                       //else syslog(LOG_NOTICE, "Not connected to DDS Cmd socket");
                    }
                    else
                    {
                       //syslog(LOG_NOTICE, "Command source now == GUI");
                       gCommandSourceDDS = 0;
                    }
                    break;
{code}
Please also look for and enable similar messages in the hexapod commanding.c

This will help us diagnose when the rotator or hexapod cRIO decides to ignore commands from the CSC.

Note that any command from the "GUI", which is what we call the Engineering User Interface (EUI), will reset gCommandSourceDDS to 0, making the CSC unable to command the cRIO. That is based on different code in rotator/targetx2/cmdClientSocket.c:
{code} // IF DDS was in control, a cmd from GUI will revert to GUI control
              if (gCommandSourceDDS)
              {
                   ////printf("Command source==GUI\n");
                 gCommandSourceDDS = 0;
              }
{code}
This looks like a bug or misfeature to me (unless it also changes the state to Offline/PublishOnly, which I strongly doubt).

I would expect the CSC to always be able to control the rotator except in Offline/PublishOnly mode.

* This task will try to understand the logging mechanism and log the useful information.

Please enable the logging statements at lines 400, 403 and 408 in rotator/targetx2/commanding.c: the commented-out syslog calls in:
{code} // select who can command the rotator: GUI (default/0) or DDS (1)
                case CMDSOURCE:
                    if (isOffline(state1) && isPublishOnly(offlineSubstate1))
                    {
                        syslog(LOG_ERR, "command not allowed in Offline/PublishOnly state");
                        gCommandSourceDDS = 0;
                        break;
                    }
                    if (cmdMsg.param1 > 0.5)
                    {
                       if (gCmdDDSServerConnected == 1)
                       {
                          //syslog(LOG_NOTICE, "Command source now == DDS");
                          gCommandSourceDDS = 1;
                       }
                       //else syslog(LOG_NOTICE, "Not connected to DDS Cmd socket");
                    }
                    else
                    {
                       //syslog(LOG_NOTICE, "Command source now == GUI");
                       gCommandSourceDDS = 0;
                    }
                    break;
{code}
Please also look for and enable similar messages in the hexapod commanding.c

This will help us diagnose when the rotator or hexapod cRIO decides to ignore commands from the CSC.

Note that any command from the "GUI", which is what we call the Engineering User Interface (EUI), will reset gCommandSourceDDS to 0, making the CSC unable to command the cRIO. That is based on different code in rotator/targetx2/cmdClientSocket.c:
{code} // IF DDS was in control, a cmd from GUI will revert to GUI control
              if (gCommandSourceDDS)
              {
                   ////printf("Command source==GUI\n");
                 gCommandSourceDDS = 0;
              }
{code}
This looks like a bug or misfeature to me (unless it also changes the state to Offline/PublishOnly, which I strongly doubt).

I would expect the CSC to always be able to control the rotator except in Offline/PublishOnly mode.
* This task will try to understand the logging mechanism and log the useful information. This will be helpful for the following debug.

Te-Wei Tsai made changes - 24/Mar/20 10:11 PM

Story Points

Te-Wei Tsai made changes - 30/Mar/20 3:49 PM

Sprint

TSSW Sprint - Mar 16 - Mar 30 [ 1006 ]

TSSW Sprint - Mar 30 - Apr 13 [ 1009 ]

Te-Wei Tsai made changes - 06/Apr/20 3:39 PM

Story Points

Te-Wei Tsai made changes - 06/Apr/20 3:39 PM

Status

To Do [ 10001 ]

In Progress [ 3 ]

Te-Wei Tsai made changes - 06/Apr/20 3:49 PM

Link

This issue relates to ~~DM-24361~~ [ ~~DM-24361~~ ]

Te-Wei Tsai made changes - 06/Apr/20 4:00 PM

Reviewers		Russell Owen [ rowen ]
Status	In Progress [ 3 ]	In Review [ 10004 ]

Russell Owen made changes - 06/Apr/20 11:25 PM

Status

In Review [ 10004 ]

Reviewed [ 10101 ]

Te-Wei Tsai made changes - 06/Apr/20 11:31 PM

Resolution		Done [ 10000 ]
Status	Reviewed [ 10101 ]	Done [ 10002 ]

People

Assignee:: Te-Wei Tsai

Reporter:: Russell Owen

Reviewers:: Russell Owen

Watchers:: Russell Owen, Te-Wei Tsai

Votes:: 0 Vote for this issue

Watchers:: 2 Start watching this issue

Dates

Created:: 05/Nov/19 4:28 PM

Updated:: 06/Apr/20 11:31 PM

Resolved:: 06/Apr/20 11:31 PM

Start date:: 16/Mar/20

End date:: 27/Mar/20

Jenkins

No builds found.

Data Management

Details

Description

Attachments

Issue Links

Activity

People

Dates

Jenkins