Welcome, Guest. Please Login or Register
Simufly.com
  News:
Welcome to the SIMUFLY.COM Discussion Forums!
  HomeHelpSearchLoginRegister
 
Bug in InsAutopilotControlState logic (Read 494 times)
w6kd
Forum Member
*
Offline



Posts: 4
Santiago de Chile
Gender: male
Bug in InsAutopilotControlState logic
Jun 10th, 2007, 3:50pm
 
Hi;

 I'm writing an HSI that displays CIVA data, and have run into a problem.

 I use the NavModeTriple gauge to select INS units, and I display the data from the selected unit using a scan of the InsAutopilotControlState values for each of the three INSs.  I discovered that if I select an INS to control the autopilot with one of the switches on the NavModeTriple gauge, and then select another INS without first turning off the one that is on, both InsAutopilotControlState values are set to one at the same time, even though only the last one selected is actually controlling the autopilot.  If I turn the currently selected switch off first, it'll set the control state back to zero.

Regards

Bob Scott
ATP IMEL Gulfstream II-III-IV-V
Santiago de Chile
Back to top
 
 
View Profile   IP Logged
Marco Ravanello
Forum Administrator
*****
Offline



Posts: 309

Gender: male
Re: Bug in InsAutopilotControlState logic
Reply #1 - Jun 11th, 2007, 9:04am
 
Bob,

Would you show me the piece of code where you manage which ins is active on the A/P? I'd like to check it.
If you don't want to post it here in the forum you could send it to ins_A_T_simufly.com

Marco
Back to top
 
 
View Profile   IP Logged
w6kd
Forum Member
*
Offline



Posts: 4
Santiago de Chile
Gender: male
Re: Bug in InsAutopilotControlState logic
Reply #2 - Jun 11th, 2007, 10:56pm
 
Marco;

 I've already replaced the code...but during the debugging I wrote a short segment that displays (via FSUIPC offsets) the values returned from InsAutopilotControlState in real time (in the ADVDISPLAY window) each time the gauge is executed.  essentially:

int INS1State, INS2State, INS3State;

INS1State = InsAutopilotControlState(INS_Unit_1);
INS2State = InsAutopilotControlState(INS_Unit_2);
INS3State = InsAutopilotControlState(INS_Unit_3);

IPC_Test = FSUIPC_Write(0x6D10, 4, &INS1State, &dwResult);
IPC_Test = FSUIPC_Write(0x6D14, 4, &INS2State, &dwResult);
IPC_Test = FSUIPC_Write(0x6D18, 4, &INS3State, &dwResult);
FSUIPC_Process(&dwResult);


With the CIVA NavModeTriple gauge, I turned on the #1 INS.  I saw this on the display:

6D10 = 0x1
6D14 = 0x0
6D18 = 0x0

Then I selected the #2 INS (without turning off the #1 INS first).  The #1 INS switch returned to off, but this is what I saw on the display:

6D10 = 0x1
6D14 = 0x1
6D18 = 0x0

Then I selected the #3 INS.  The #2 switch went to off, and the display said:

6D10 = 0x1
6D14 = 0x1
6D18 = 0x1

In this case all three INSs are reporting that they are connected via the InsAutopilotControlState call.

If I turn the switch off manually, the state returns to zero as it should.

What I did to solve my problem was to write a new NavModeTriple gauge that explicitly turns off the other INS units before turning on the selected one...this keeps the state values returned by the InsAutopilotControlState call in synch with the actual state.

Regards

Bob Scott
ATP IMEL Gulfstream II-III-IV-V
Santiago de Chile
Back to top
 
« Last Edit: Jun 11th, 2007, 10:59pm by w6kd »  
View Profile   IP Logged
Marco Ravanello
Forum Administrator
*****
Offline



Posts: 309

Gender: male
Re: Bug in InsAutopilotControlState logic
Reply #3 - Jun 12th, 2007, 8:33am
 
Bob,

I'll check this evening at home, thanks a lot for the example. I'll report back tomorrow.

Regards
Marco
Back to top
 
 
View Profile   IP Logged
Marco Ravanello
Forum Administrator
*****
Offline



Posts: 309

Gender: male
Re: Bug in InsAutopilotControlState logic
Reply #4 - Jun 15th, 2007, 11:12pm
 
Bob,

I confirm you that it's a bug, already filed as #0021. It's limited to the SDK layer, it does not influence the INS itself which correctly excludes any other currently active INS unit, so it's not critical, but it is still a bug which will be corrected in the next release.

I'm just waiting to collect some problems then I'll produce version 1.51.
V1.51 is anyway planned to be released around the end of august/mid September.

Thanks for discovering and reporting it, I really appreciate that!

Kind regard
Marco
Back to top
 
« Last Edit: Jun 15th, 2007, 11:17pm by Marco Ravanello »  
View Profile   IP Logged