PMDG 777 CDU data

[Jason Fayre]

Hello,

A friend of mine told me that the newest PMDG 777 update now supports CDU screen data, same as the 737 and 747 do.

I don't see any reference to this in the latest FSUIPC 6 777 document. Can anyone confirm that this support is in fact in this aircraft and if fSUIPC will support it?

We need CDU data for software we are writing.

Thanks!

 

[John Dowson]

 

15 hours ago, Jason Fayre said:

A friend of mine told me that the newest PMDG 777 update now supports CDU screen data, same as the 737 and 747 do.

Has the SDK been updated for this? When was this update released? Could you send me the header file and I'll check it against the one we are using, to see if an update is needed. Thanks,

John

[Jason Fayre]

I'll get it and send it over. There are two of us developing the a-on, and it's the other developer that has this aircraft.

What is the best way to get the file to you? 

 

[John Dowson]

36 minutes ago, Jason Fayre said:

What is the best way to get the file to you? 

You can just attach it here.

[Jason Fayre]

File is attached.

PMDG_777X_SDK.h

[John Dowson]

Can you try the attached version please - its untested as I don't have any PMDG aircraft: FSUIPC6.dll

 

[Jason Fayre]

Are the offsets for accessing the CDU the same as in the 747 and 737?

 

[John Dowson]

2 minutes ago, Jason Fayre said:

Are the offsets for accessing the CDU the same as in the 747 and 737?

Yes

[Jason Fayre]

In an initial test, the CDU data is working.

Any idea if other things in the FSUIPC offsets for this aircraft need to be updated? I'm not sure what else was changed in the SDK.

 

 

[John Dowson]

5 minutes ago, Jason Fayre said:

Any idea if other things in the FSUIPC offsets for this aircraft need to be updated? I'm not sure what else was changed in the SDK.

There i the following additional data in the PMDG_777X_Data data structure.

Quote

    // Additional variables
    //------------------------------------------
    
    bool            ENG_StartValve[2];                    // true: valve open
    float            AIR_DuctPress[2];                    // PSI
    float            FUEL_QtyCenter;                        // LBS
    float            FUEL_QtyLeft;                        // LBS
    float            FUEL_QtyRight;                        // LBS
    float            FUEL_QtyAux;                        // LBS
    bool            IRS_aligned;                        // at least one IRU is aligned
    unsigned char   AircraftModel;                        // 1: -200  2: -200ER  3: -300  4: -200LR  5: 777F  6: -300ER
    bool            WeightInKg;                            // false: LBS  true: KG
    bool            GPWS_V1CallEnabled;                    // GPWS V1 call-out option enabled
    bool            GroundConnAvailable;                // can connect/disconnect ground air/electrics

    unsigned char    FMC_TakeoffFlaps;                    // degrees, 0 if not set
    unsigned char    FMC_V1;                                // knots, 0 if not set
    unsigned char    FMC_VR;                                // knots, 0 if not set
    unsigned char    FMC_V2;                                // knots, 0 if not set
    unsigned char    FMC_LandingFlaps;                    // degrees, 0 if not set
    unsigned char    FMC_LandingVREF;                    // knots, 0 if not set
    unsigned short  FMC_CruiseAlt;                        // ft, 0 if not set
    short            FMC_LandingAltitude;                // ft; -32767 if not available
    unsigned short  FMC_TransitionAlt;                    // ft
    unsigned short  FMC_TransitionLevel;                // ft
    bool            FMC_PerfInputComplete;
    float            FMC_DistanceToTOD;                    // nm; 0.0 if passed, negative if n/a
    float            FMC_DistanceToDest;                    // nm; negative if n/a
    char            FMC_flightNumber[9];
 

This is now written to the 2nd PMDG data offset area, from 0x6C00

[John Dowson]

@Jason Fayre There was a minor problem in the previous dll I posted - 737NGX offsets were disabled. This has been corrected in the attached version.

Also, I'm not sure the packing for the general data offsets is correct. Could you check the general 777 data is correct from offset 0x6420 as well as the new data from 0x6C00. If it doesn't look correct, I will need to adjust the packing in the header.

FSUIPC6.dll

Thanks,

John

[Jason Fayre]

Hi John,

Thanks for this. We have just started working with the 777, so not sure how easy it will be to check these offsets.

We use Paul Henty's FSUIPC .net library, so I'm wondering if he will need to do some work on his end as well.

 

[Luke Kolin]

If Jason doesn't get to it today, I'll take a peek after I go to get shot. What exactly is new? I have a document dated November 2016 that has all this. I'm pretty certain it all works correctly; I do a sanity check on the flight number IIRC.

Cheers!

[John Dowson]

34 minutes ago, Luke Kolin said:

What exactly is new? I have a document dated November 2016 that has all this. I'm pretty certain it all works correctly; I do a sanity check on the flight number IIRC.

But, with this update, that document is now out-of-date and I need to update. I would just like to check this is still working for the latest 777 update. Once that is confirmed, I will update the documentation.

I would like to know if the (old) 777 data area is still ok (i.e. has the correct spacing for the different data points) and if the new data segment (from 6C00) is also spaced correctly.

Luke - if you could check this, that would be great.
Attached is another dll with the structure packing changed to 4 bytes, as was previously. I would like to know if the data in the PMDG offset area conforms to this version or the previous (or maybe both!). : FSUIPC6.dll
 

Thanks,

John

[Luke Kolin]

The most recent DLL in this thread looks good, both for the equipment code (0x6CID) and tail code (0x6C3C). I suppose I can check the door status as well to validate the padding on the other blocks but I think that will be good too. The earlier DLL did _not_ work.

FWIW I got some differing messages regarding LUA shutdown handlers like we discussed earlier. I don't believe it's at all related and doesn't seem to harm anything, but I am enclosing in case it triggers a eureka moment on your end.

Cheers

FSUIPC6.log FSUIPC6_prev.log

[John Dowson]

8 minutes ago, Luke Kolin said:

The most recent DLL in this thread looks good, both for the equipment code (0x6CID) and tail code (0x6C3C). I suppose I can check the door status as well to validate the padding on the other blocks but I think that will be good too. The earlier DLL did _not_ work.

Ok, that's exactly what I needed to know, thanks. I don't think there is any need for further checks - if they are in the correct position, so should be the rest of the data.

10 minutes ago, Luke Kolin said:

FWIW I got some differing messages regarding LUA shutdown handlers like we discussed earlier. I don't believe it's at all related and doesn't seem to harm anything, but I am enclosing in case it triggers a eureka moment on your end.

No, they both look fine, just different timings.... The 6.1.1.d one does look a bit strange though, as it looks to be trying to kill the DevCom thread prematurely, before its given time for any luas to close rgus down themselves - although this seems to happen later, which is strange!
One thing you could do to make the log a bit easier to understand would be to also activate logging for 'Extras'. As well as a few extra log messages, this also adds the thread id sending the message, so its a bit easier to understand which thread each message is coming from. Just FYI.

Cheers,

John

[Jason Fayre]

Thanks everyone! Any idea when this will make it into a release? I want to check with Paul Henty in case he needs to update anything.

 

[John Dowson]

2 minutes ago, Jason Fayre said:

Thanks everyone! Any idea when this will make it into a release?

I can release once I've updated the documentation. I'll take a look at this next week, so maybe release later next week, but I don't think there is any need to rush (as the updated dll is available).

4 minutes ago, Jason Fayre said:

I want to check with Paul Henty in case he needs to update anything.

Ok. Maybe @Paul Henty could advise if an update for this would be needed for his .net client dll, and if so we can coinside the releases.

[Paul Henty]

15 hours ago, John Dowson said:

Ok. Maybe @Paul Henty could advise if an update for this would be needed for his .net client dll, and if so we can coinside the releases.

I don't think there are any updates required. @Jason Fayre seems to have the 777 CDU working from my dll.

Like Luke, I'm a confused as to what has changed with the offsets you mentioned. Those offsets from 0x6C00 were in the Sept 2015 777x offsets list and so are already included in my dll. They don't look to have changed from 2015.

Paul

[John Dowson]

23 minutes ago, Paul Henty said:

Like Luke, I'm a confused as to what has changed with the offsets you mentioned. Those offsets from 0x6C00 were in the Sept 2015 777x offsets list and so are already included in my dll. They don't look to have changed from 2015.

Yes, sorry, there was previously data populated in the offset are starting at 0x6C00. However, this now has additional data which will be added at the end. This is the following:

Quote

    // More additional variables
    //------------------------------------------
    bool            AIR_AltnVentSw_ON;
    bool            AIR_annunAltnVentFAULT;
    unsigned char   AIR_CargoTemp_MainDeckFwd_Sel;        // 0: C ... 60: W
    unsigned char   AIR_CargoTemp_MainDeckAft_Sel;        // 0: C ... 60: W
    unsigned char   AIR_CargoTemp_LowerFwd_Sel;            // 0: C ... 60: W
    unsigned char   AIR_CargoTemp_LowerAft_Sel;            // 0: C ... 60: W  67: HEAT H  70: HEAT OFF  73: HEAT L
    bool            AIR_MainDeckFlowSw_NORM;            // M/D FLOW  true: NORM  false: HIGH
    bool            ELEC_annunAPU_GEN_OFF;
    bool            ELEC_annunBattery_OFF;
    bool            FCTL_PrimFltComputersSw_AUTO;        // true: AUTO  false: DISC
    bool            FCTL_annunPrimFltComputersDISC;
    bool            FIRE_EngineHandleIlluminated[2];
    bool            FIRE_APUHandleIlluminated;
    bool            FIRE_EngineHandleIsUnlocked[2];
    bool            FIRE_APUHandleIsUnlocked;
    bool            FIRE_annunMainDeckCargoFire;
    bool            FIRE_annunCargoDEPR;                // DEPR light in DEPR/DISCH guarded switch
    bool            GPWS_RunwayOvrdSw_OVRD;

    unsigned short    COMM_ReceiverSwitches[3];            // array: 0=capt, 1=F/O, 2=observer.  Bit mask for selected receivers with bits indicating: 0=VHFL 1=VHFC 2=VHFR 3=FLT 4=CAB 5=PA 6=HFL 7=HFR 8=SAT1 9=SAT2 10=SPKR 11=VOR/ADF 12=APP

    bool            WheelChocksSet;
    bool            APURunning;
 

I need to update the documentation and add those.

Also, of course, the CDU data is now available for the 777, so I need to add that to the document.

I'll take a look at this over the weekend and release with the updated documentation sometime next week.

John

[Paul Henty]

Okay - I'll add these new offsets to my DLL.

Paul

[John Dowson]

Here is the updated PMDG 777X document: Offset Mapping for PMDG 777X.pdf

[John Dowson]

22 hours ago, John Dowson said:

Here is the updated PMDG 777X document: 

There was an error in that version. Please find the corrected version attached:. 

Could someone check the data at offset 6C53 (COMM_ReceiverSwitches[3]) is correct as this would verify that we have the correct packing.

Thanks.

Offset Mapping for PMDG 777X.pdf

[John Dowson]

Sorry, thats also wrong! Attached is hopefully correct, and COMM_ReceiverSwitches[0] should be at offset 0x6C58.

Offset Mapping for PMDG 777X.pdf

[John Dowson]

Found another issue - FIRE_EngineHandleIlluminated and FIRE_APUHandleIsUnlocked are arrays of 2 bools not just single bools. Updated document attached, and the offset to check for COMM_ReceiverSwitches[0] is 0x6C5A.

Offset Mapping for PMDG 777X.pdf