P3D V3 FMC memory leak back?

[kevinh 409]

That is a good laugh. I always considered Boeing the Gold Standard. But I guess both developers and manufactures have problems from time to time.

Boeing don't program the FMC. They specify what it should do then get the selected FMC supplier to produce it and then deal with any bugs and issues. No matter who writes it, whereever there is software there are software issues and bugs.

 

Maybe it is is not as easy as we think it is to program software for an FMC ;-)

Now there's a thought.

[pcubine 143]

 

 

Boeing don't program the FMC.

I did not figure they did. I don't imagine they build the own coffee brewer, seats, instruments, lavatories, seat belts, wings, etc. They are the contractor and most of the actual fabrication is sublet to hundreds of XYZ companies. They just assemble the various products from XYZ companies. However, to the flying public it is still a Boeing product. When the plane turns right instead of left, they are going to blame Boeing not the sub-contractor.

[kevinh 409]

I did not figure they did. I don't imagine they build the own coffee brewer, seats, instruments, lavatories, seat belts, wings, etc. They are the contractor and most of the actual fabrication is sublet to hundreds of XYZ companies. They just assemble the various products from XYZ companies. However, to the flying public it is still a Boeing product. When the plane turns right instead of left, they are going to blame Boeing not the sub-contractor.

I doubt most travellers bother about whether it's a Boeing they are flying in or not. If the plane turns left not right they will blame the pilot. Even if the FMC was at fault it is the pilot's responsibility to program it correctly and know what the known limitations of it are.

 

The idea that Boeing is the gold standard was put in doubt by the 787 with its production problems, delays and battery fires. Not knocking Boeing but they are no different to their competition.

[Boeing or not going 578]

I doubt most travellers bother about whether it's a Boeing they are flying in or not. If the plane turns left not right they will blame the pilot. Even if the FMC was at fault it is the pilot's responsibility to program it correctly and know what the known limitations of it are.

 

The idea that Boeing is the gold standard was put in doubt by the 787 with its production problems, delays and battery fires. Not knocking Boeing but they are no different to their competition.

Technically the delays were caused by contractors Boeing used. - David Lee

[kevinh 409]

Technically the delays were caused by contractors Boeing used. - David Lee

The components weren't just contracted out. Large assemblies were designed and produced by risk sharing partners. Boeing were responsible for managing the program, including supplier delays. The problems really began when they started to put the prototype together. It was a long and painful process getting things right.

 

Airbus had similar production problems, with the A380 wiring. They both build fine aircraft but neither is better than the other.

[downscc 1,327]

 

 

Airbus had similar production problems, with the A380 wiring.

 

One of my books on the 777 noted that the wiring problem was because not everyone was using the same version CAD and when it came time to merge work they ran into dimensional problems. Boeing did enforce configuration management and although there were many challenges this was not one of them.  I remember this because I came from the an engineering environment where different versions of the same CAD could cause problems, let alone different CAD platforms.

 

We have a topic creep happening but I couldn't help but chime in on behalf of Boeing. Not blushing at all here LOL.

[Boeing or not going 578]

According to my non scientific research, my vas issues have either disappeared or lessened due to following this:

 

http://www.fsdeveloper.com/wiki/index.php?title=Missing_textures

[SCENERY]// To show alerts or areas, set to = 1 // To hide alerts or areas, set to = 0 // Alert for missing texturesShowMissingTextureAlert=1

After adding the missing texture prompt line, I found the PMDG 777, and 737, are looking for files that do not exist. Adding those files, without file extension names since those are the files the airplanes are looking for, strangely, has helped lessen my vas footprint of the PMDG 777 and 737. I can fly TaxiGate VHHH to FlyTampa OMDB and use 100% custom traffic filling up my skies and do not get any OOM errors in fsx acceleration! Not even using p3d that dumps scenery to help vas.

 

I had submitted a ticket to PMDG showing my findings and they dismissed me maybe not understanding my findings or thinking I am being too nosey questioning experts, but the airplane constantly looking for files that do not exist is a problem according to the developers of fsx.

 

These are the files I created using dummy textures in the fsx\texture folder since they prompted me on loading the 737 and 777 that they are not found by fsx:

 

$NGXCABINLIGHT

$GAUGEFIFTEEN

$FLAPSTCLLIGHT

$MLGHB

$WINGLIGHT

 

There could be a problem with my pmdg installation, and have not had time to uninstall and re-install to see if I still get the missing texture prompt on selecting the 737 or 777. I have only had time to complete my custom Ai traffic and get some long haul flights in this month and had no oom errors and not even beeping from fsupic telling me vas is critical! But this has helped me, and maybe it can help someone else. - David Lee

[CaptKornDog 284]

Does that also address the VAS leak when selecting certain approaches in the FMS, described above?

 

(Seems to me, they shouldn't be related at least.)

[Boeing or not going 578]

Does that also address the VAS leak when selecting certain approaches in the FMS, described above?

 

(Seems to me, they shouldn't be related at least.)

I have no idea probably not but it may help the leak not totally taking your vas - David Lee

[xkoote 57]

Got nipped by the OOM bug today. First flight on 1605 from VHHH to OMDB. Started hearing pings and went to the PC. VAS was over 3 Gb and selecting a visual approach iso the ILS12L seemed to start lowering the VAS again. But P3D never recovered and went black screen on me with only 2.3 Gb on the VAS meter. Anyway. It seems a LOT of time has gone by without someone publicly acknowledging that this is something being worked on. I fly long range only and of my last 10 flights I think more than half were duds. Is it worth opening another ticket for the same thing that's been going on for months?

[CaptKornDog 284]

 

 

Is it worth opening another ticket for the same thing that's been going on for months?

 

Probably couldn't hurt if you are able to provide as much detail as possible, especially steps to reproduce it.

[denthibbe 18]

I did not read the entire thread (although I've been following it since last November), but I can say that not only approach procedures containing 'intercept radial XXX to FIX' do bring the VAS leak.

Also SID's containing it will OOM after 10-11 hours flight after a long and steady VAS leak.

As an example try KDFW-VHHH out of either 17C-17R-18L-18R via LOWGN7 SID (do not enter any arrival/approach procedure for VHHH). Same VAS leak will be observed.

 

I had no problem not entering approach into FMC before T/D (that was the first workaround advised by PMDG), but not being able to use any SID containing that intercept radial to fix thingy is another problem far less ignorable than the first one.

 

just my 2 cents,

Happy flying!

[CaptKornDog 284]

I did not read the entire thread (although I've been following it since last November), but I can say that not only approach procedures containing 'intercept radial XXX to FIX' do bring the VAS leak.

Also SID's containing it will OOM after 10-11 hours flight after a long and steady VAS leak.

As an example try KDFW-VHHH out of either 17C-17R-18L-18R via LOWGN7 SID (do not enter any arrival/approach procedure for VHHH). Same VAS leak will be observed.

 

I had no problem not entering approach into FMC before T/D (that was the first workaround advised by PMDG), but not being able to use any SID containing that intercept radial to fix thingy is another problem far less ignorable than the first one.

 

just my 2 cents,

Happy flying!

I would also post that information in a help desk ticket.

[PinkPony 171]

Got nipped by the OOM bug today. First flight on 1605 from VHHH to OMDB. Started hearing pings and went to the PC. VAS was over 3 Gb and selecting a visual approach iso the ILS12L seemed to start lowering the VAS again. But P3D never recovered and went black screen on me with only 2.3 Gb on the VAS meter. Anyway. It seems a LOT of time has gone by without someone publicly acknowledging that this is something being worked on. I fly long range only and of my last 10 flights I think more than half were duds. Is it worth opening another ticket for the same thing that's been going on for months?

Xander,

 

99% of my B777 flying orginitates from DXB and ends at DXB. Over the pst 3 months alone, I have have completed countless flights from back to DXB ranging from 6 hour rountrips to LIRF to ~16hr DXB-DFW and back.

 

You didnt mention your simulator, but I am on P3D 3.2.2 and I have had no VAS issues going into either ILS12L (the landing runway during east ops) and ILS30L (the landing runway duing the far more common west ops).

 

Are you using FSX?

 

Note: Back when I may using FSX, (may it rot in hell) I had to manually disably the Flytampa OMDB city portion of their coty. Otherwise a flight from any addon scenery airport, to Flytampa's OMDB would always end in a OOM. No such issues EVER with P3D.

 

The only guaranteed OOM approaches I have come across so far: are ILS16L at KSEA, ILS07R ILS25L/R at VHHH, and ILS28L/R at KSFO.

 

I urge all of you with new findings to submit tickets, as that is the only proper channel to report potential bugs to PMDG, and it certainly can only provide more positive information for them to eventually identify a cause and solution.

 

In the meantime, simply remove the entire missed approach code from the offending ILS approach and you will have no issues. (or the portion that is at fault which Kyle mentioned a few posts back).

 

Definitely not a viable permaenent solution, but one that will prevent this annoying leak for happening as long as it exists in the B777s code.

[pcubine 143]

 

 

Also SID's containing it will OOM after 10-11 hours flight after a long and steady VAS leak.

As an example try KDFW-VHHH out of either 17C-17R-18L-18R via LOWGN7 SID (do not enter any arrival/approach procedure for VHHH). Same VAS leak will be observed.

As some people would say, this is a game changer and if true and I have no reason to doubt it, I would urge you as Kyle Weber said to submit a ticket to PMDG tech support with the details as described in your post here. A tech support ticket will be seen, will be I the system, and replied to. On this forum PMDG might see it and they might not.