Details
-
Type:
Improvement
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: ts_main_telescope
-
Labels:
-
Story Points:0
-
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