Starting Engines on a A400M using FSUIPC4 offsets

[YokeM]

(sorry for the bad english, I´m not a native)

Hello Pete,

 

I´m writing a programm which should be able to to handle the contolls and enviromental settings of the cargo A400M from Roland Laborie.

FSUIPC is a great interface which makes communication from and to FSX really easy.

 

While I was able to get the enviromental data I was looking for out of FSX, starting the engines is another matter.

I can pull the parking brake, but while attemting to set the Engine lever to RUN I came into the problem of simply not finding the right offset

or maybe I´m putting the wrong variable into the right offset.

 

As of now I can imagin that I´m doing something wrong somewhere. Whats the right offset for this lever and what variables have to be put into it?

 

regards

YokeM

[Pete Dowson]

While I was able to get the enviromental data I was looking for out of FSX, starting the engines is another matter.

I can pull the parking brake, but while attemting to set the Engine lever to RUN I came into the problem of simply not finding the right offset

or maybe I´m putting the wrong variable into the right offset.

 

I'm afraid I cannot advise about things like that for an add-on aircraft.  I don't even know whether an "A400M" is a jet, prop, or what -- the starting procedure is different even for each default aircraft type, and can be even more different for an add-on aircraft.

 

First, you need to know how to start the engines with the usual methods -- keyboard and/or mouse. Perhaps you do, and if so, describe it here? You could also use the FSUIPC logging facilities, especially "event" logging, to see what might be going on internally. But be aware that add-on aircraft may not use FS events and may not be susceptible to the documented FSUIPC offsets.

 

Pete

[YokeM]

Hey Pete,

 

thanks for your answer :-)

I almost assumed that duo to the "A400M" beeing a add-on aircraft it will be harder to get an interface for it but I still hope it can be addressed through FSUIPC-routines.

 

I know the starting sequence it is as follows for automatic engines startup:

 

1 - Parking brake on.
2 - Throttle levers 1-2-3-4 Mini. // I´m ingoring this in the logging process. It is for safety reasons and of no real effect on the overall process.
3 - APU START on.
4 - APU MASTER SW. on.
5 - Rotary button ignition.
6 - Engine 1 lever RUN , wait for the stabilization of engine before the starting of engine 2.
7 - Engine 2 lever RUN , wait for the stabilization of engine before the starting of engine 3.
8 - Engine 3 lever RUN , wait for the stabilization of engine before the starting of engine 4.
9 - Engine 4 lever RUN .

 

[Continuation log requested by user]
Running inside Prepar3D v2 on Windows 7
Module base=561B0000
   415103 LogOptions changed, now 20000000 00000001

 

// This a loop that happens every second
   415119 *** EVENT: Cntrl= 65794 (0x00010102), Param= 0 (0x00000000) PAUSE_ON
   415571 *** EVENT: Cntrl= 65962 (0x000101aa), Param= 4 (0x00000004) FUEL_SELECTOR_SET
   415571 *** EVENT: Cntrl= 66576 (0x00010410), Param= 5 (0x00000005) FUEL_SELECTOR_4_SET
   415571 *** EVENT: Cntrl= 66523 (0x000103db), Param= 2 (0x00000002) FUEL_SELECTOR_2_SET
   415571 *** EVENT: Cntrl= 66568 (0x00010408), Param= 3 (0x00000003) FUEL_SELECTOR_3_SET
   415571 *** EVENT: Cntrl= 66886 (0x00010546), Param= 0 (0x00000000) BLEED_AIR_SOURCE_CONTROL_SET

// loop end
 
   418176 *** EVENT: Cntrl= 65561 (0x00010019), Param= 0 (0x00000000) PAUSE_TOGGLE  
   419767 *** EVENT: Cntrl= 65752 (0x000100d8), Param= 0 (0x00000000) PARKING_BRAKES   // Step 1
   427801 *** EVENT: Cntrl= 66704 (0x00010490), Param= 0 (0x00000000) APU_STARTER         // Step 3
   431623 *** EVENT: Cntrl= 66706 (0x00010492), Param= 1 (0x00000001) APU_GENERATOR_SWITCH_TOGGLE  // Step 4

 

// Here should stand an ingnition starter event as described in step 5. The eventlog didn´t show anything like that. Without it the engines won´t start.

 

     // Step 6 - 9
   435570 *** EVENT: Cntrl= 66300 (0x000102fc), Param= 1 (0x00000001) TOGGLE_STARTER1
   438566 *** EVENT: Cntrl= 66301 (0x000102fd), Param= 1 (0x00000001) TOGGLE_STARTER2  
   439580 *** EVENT: Cntrl= 66302 (0x000102fe), Param= 1 (0x00000001) TOGGLE_STARTER3 
   441592 *** EVENT: Cntrl= 66494 (0x000103be), Param= 1 (0x00000001) TOGGLE_FUEL_VALVE_ENG1
   441592 *** EVENT: Cntrl= 66303 (0x000102ff), Param= 1 (0x00000001) TOGGLE_STARTER4
   444587 *** EVENT: Cntrl= 66495 (0x000103bf), Param= 1 (0x00000001) TOGGLE_FUEL_VALVE_ENG2
   445617 *** EVENT: Cntrl= 66496 (0x000103c0), Param= 1 (0x00000001) TOGGLE_FUEL_VALVE_ENG3
   447629 *** EVENT: Cntrl= 66497 (0x000103c1), Param= 1 (0x00000001) TOGGLE_FUEL_VALVE_ENG4  
   455429 *** EVENT: Cntrl= 65561 (0x00010019), Param= 0 (0x00000000) PAUSE_TOGGLE

[Pete Dowson]

I almost assumed that duo to the "A400M" beeing a add-on aircraft it will be harder to get an interface for it but I still hope it can be addressed through FSUIPC-routines.

 

 

Maybe, maybe not. At least it looks like you have most of the controls you need there then. The loop which happens every second is probably just to make sure certain things are set certain ways, and will be automnomous in any case so you can ignore that. A lot of these add-ons seems to waste a lot of processing that way when they only need to check if it has changed first.

 

On the part where you say

 

// Here should stand an ingnition starter event as described in step 5. The eventlog didn´t show anything like that. Without it the engines won´t start.

 

That looks like something internal to their code. I can only suggest you investigate the possibility of use local panel variables, or mouse macros. One or the other might just possibly be useful (not both). If neither then I'm afraid I've no idea.

 

Are you getting any help from the add-=on makers? They'd really know all this better than someone like myself who knows little about any add-on aircraft. All i can do is point to the tools available.

 

Pete

[YokeM]

Maybe, maybe not. At least it looks like you have most of the controls you need there then. The loop which happens every second is probably just to make sure certain things are set certain ways, and will be automnomous in any case so you can ignore that. A lot of these add-ons seems to waste a lot of processing that way when they only need to check if it has changed first.

 

Ok thank you. If I understood correctly, every event that can be displayed by the FSUIPC-logger can be addressed be an FSUIPC-offset and I just have to find the right one? Or do I have to use SimConnect to address them?

 

 

That looks like something internal to their code. I can only suggest you investigate the possibility of use local panel variables, or mouse macros. One or the other might just possibly be useful (not both). If neither then I'm afraid I've no idea.

 

Are you getting any help from the add-=on makers? They'd really know all this better than someone like myself who knows little about any add-on aircraft. All i can do is point to the tools available.

 

Pete

 

Thank you. Using macros would have been the way to go if I couldn´t adress some of the panels via FSUIPC or SimConnect. If they aren´t shown in the event-logger, does that mean that SimConnect can´t address them too? I didn´t want to use SimConnect since your tool (which uses SimConnect I imagin) made my life really easy in regards of interfacing.

 

I´m not getting any help from the add-on makers right now, but it´s a good idea to ask them.

Edited November 3, 2014 by YokeM

[Pete Dowson]

Ok thank you. If I understood correctly, every event that can be displayed by the FSUIPC-logger can be addressed be an FSUIPC-offset and I just have to find the right one? Or do I have to use SimConnect to address them?

 

You are misunderstanding. Offsets hold data, sometimes input data sometimes output data. They are no "events". Events are actions, and initiated by controls with a control number and a parameter. Controls are assigned. You CAN send controls via offsets -- see offset 3110. The names and control numbers you saw in the log relate to the controls/events you need to use. FSUIPC sends some controls via SmConnect, and some directly to FS's wnindow. It varies according to function.

 

Using macros would have been the way to go if I couldn´t adress some of the panels via FSUIPC or SimConnect. If they aren´t shown in the event-logger, does that mean that SimConnect can´t address them too?

 

It varies enormously. Add-on writers implement things which aren't, in their opinion, simulated properly or at all in FS. For those aspects, SimConnect doesn't help because it is just an interface into the simulator which they are programming around because of those shortfalls. Do you see? Maybe, underneath, the add-on code does use built-in FS actions, but being effectively made part of FS (loaded as one of its gauges, for example) it doesn't need always to use controls as such.

 

Mouse macros in FSUIPC only operate on Gauges which are written in C/C++ to strict rules laid down in one of Microsoft's SDKs. Even most of FS's default aircraft don't supportthem.

 

More and more aircraft these days use Local Variables instead. This is especially true of XML gauges.

 

Pete

[YokeM]

Hello Pete,

 

sorry for my late reply. Work hit hard before christmas and now for the first time in a while, I´m able to give this little project of mine some time.

 

As far as I can see, the creator of the simualtion model has used xml-gauges. They are inside the model-folder, but packed inside a rar file. I don´t know if P3D uses this packed files or gets them from somewhere else.

 

Is there any way to see how this gauges are changed during the simulation or change them without clicking manualy on a panel in P3D?

[Pete Dowson]

Hello Pete,

 

sorry for my late reply. Work hit hard before christmas and now for the first time in a while, I´m able to give this little project of mine some time.

 

As far as I can see, the creator of the simualtion model has used xml-gauges. They are inside the model-folder, but packed inside a rar file. I don´t know if P3D uses this packed files or gets them from somewhere else.

 

Is there any way to see how this gauges are changed during the simulation or change them without clicking manualy on a panel in P3D?

 

Just log the L:Vars (local panel variables) to see if you can find one you can use. You can list them using the add-on FSUIPC contorl provided, or you can use the supplied Lua plug-in for logging them live as they change, on screen.

 

Pete

[YokeM]

Thanks Pete, I can log them now. I tried to change them via my programm, using the offset 3110 but the change didn´t happen in P3D. Is there another way to change these or did I do something wrong?

 

Here is what I did:

 

 

FsuipcProxy* fsuipcProxy = new FsuipcProxy;
    int n = 65923, p = -16383;
    if (!FSUIPC_Write(0x3110, 8, &n, &fsuipcProxy->dwResult))
    {
        cout << "Fehler" << endl;
    }

    if (!FSUIPC_Write(0x3110, 8, &p, &fsuipcProxy->dwResult))
    {
        cout << "Fehler" << endl;
    }

    FSUIPC_Process(&fsuipcProxy->dwResult);

[Pete Dowson]

Thanks Pete, I can log them now. I tried to change them via my programm, using the offset 3110 but the change didn´t happen in P3D. Is there another way to change these or did I do something wrong?

 

Offset 3110 is for sending controls -- ones having a number and a parameter. "L:Vars" have names. You can only send them either by using Macros, or by Lua plug-ins. There's no place in the control number system for names.

 

You seem to have changed the subject completely since your last message I replied to, above!

 

You code seems to be trying to send control 65923, which is the axis control "Prop pitch1 Set". Not sure why you'd send that. It needs a parameter to tell the prop #1 what pitch value to set.

 

You appear to be addressing variable n, a 32-bit (== 4 byte)  value as an 8 byte value. What do you think that will do? If you are trying to send the control and the parameter in one Write, you need a structure. If you don't understand structures just set the parameter first (3114) then the control.

 

Pete

[YokeM]

The fact, that I didn´t even formulate my question understandable is a good indicator to how little I know about your software and P3D. Sorry about that, I will take some more time to learn more about both.

 

I´m trying to operate the controls in the A400M-model without having to klick on them inside of P3D.

e.g.: If I click on a button in my software, the parking brake in the simulation should be put to "ON". Or the "Prop pitch 1" should be set to the given parameter.. Etc, etc....

 

In "offset status" is written:

 

3110: Operates  a  facility  to  send  any  ‘controls’  to  Flight  simulator.
This  works  with  all  versions  of  FS  &  CFS.  Write  all  8  bytes  for
controls  which  use  a  value  (axes  and  all  _SET  controls),  but  just
4 will do for ‘button’ types.
This  is  really  two  32-bit  integers.  The  first  contains  the  Control
number  (normally  65536  upwards),  as  seen  in  my  FS  Controls
lists.  The  second  integer  is  used  for  the  parameter,  such  as  the
scaled  axis  value,  where  this  is  appropriate.  Always  write  all  8
bytes  in  one  IPC  block  if  a  parameter  is  used,  as  FSUIPC  will
fire the control when you write to 3110.
Since version 3.40, FSUIPC-added controls (other than the offset
ones) can be used via these  offsets too. See the  Advanced User’s
Guide for a current list.

 

So I thought I have to send a 8 byte control, even if I only use a 4 Byte integer as value.

Here I´m tying to set the "Prop pitch 1" which I adressed in "n" to the parameter given in "p". This should put them into "Mini" or "RUN" (16383).

It seems that I don´t understand structures enough to use them in here.

Also what do you mean I should the parameter first? I Thought you need to have the control first, then the parameter. What do you mean with "3114"? If thats an offset, I can´t find it.

 

Can you give me an example to how you would set "Prop pitch 1" to the value of 16383?

[Pete Dowson]

I´m trying to operate the controls in the A400M-model without having to klick on them inside of P3D.

e.g.: If I click on a button in my software, the parking brake in the simulation should be put to "ON". Or the "Prop pitch 1" should be set to the given parameter.. Etc, etc....

 

Yes, I understood that from way back. But you said this:

 

Using macros would have been the way to go if I couldn´t adress some of the panels via FSUIPC or SimConnect. If they aren´t shown in the event-logger, does that mean that SimConnect can´t address them too?

 

From this I understood you to mean that you had tried using the normal controls and that, because this aircraft "does its own thing", you couldn't operate everything you needed that way, and were about to resort to mouse macros. I then replied saying mouse macros may not work with many aircraft and explained why. You said that the gauges were written in XML which confirmed that mouse macros would not work, so I suggested that local panel variables might (L:Vars), and that if you logged these you might find ones which would do what you wanted.

 

 If I click on a button in my software, the parking brake in the simulation should be put to "ON". Or the "Prop pitch 1" should be set to the given parameter.. Etc, etc....

 

And are those examples of where your aircraft does not obey the normal FS controls? It would be very unusual. Even the more sophisticated aircraft normally use the standard Parking Brake and Prop Pitch controls!

 

In "offset status" is written:

 

Why on Earth include my own documentation in your message? !!!!

 

So I thought I have to send a 8 byte control, even if I only use a 4 Byte integer as value.

 

 

Yes. You can send 8 bytes, but your "&n" is the address of a 4-byte value!!!

 

Sorry, but if you are programming you need to learn programming. To send 8 bytes containing 2 4-byte values you'd need a structure or an array, for example:

 

int n[2];

n[0] = 65923;

n[1] = -16384;

FSUIPC_Write(0x3110, 8, &n[0], &fsuipcProxy->dwResult);

 

or, using structures:

 

struct 

{   int control;

    int parameter;

} n;

 

n.control = 65923;

n.parameter = -16384;

FSUIPC_Write(0x3110, 8, &n, &fsuipcProxy->dwResult);

 

However all of this pre-supposes that your aircraft does, after all, obey normal FS controls, so how did the subject get onto other things like macros?

 

BTW I'm not a good teacher (not enough patience nor time), so won't be trying to tech you programming any further than this! ;-)

 

An easy alternative, if you don't understand arrays or structures, would be to set the parameter in one Write and the control in the next write, then do the Process call. In any case, FSUIPC doesn't do anything when you write the parameter, only when you write the control.

 

Pete