Your workaround doesn't work for me 00 if I put in a hard altitude of 234 at FIROP the FMC says "ALT CONSTRAINT DRUZZ"

Input format s/b 00234. Entering 234 means FL234 which is above the altitude contraint at DRUZZ.

Well if you would have signed your name as per the rules than your posts wouldnt have been deleted

Yea, great way to run a business -- "follow our rules on an obscure link in our customer forum! Or else!"I just don't know why they're so fixated on this kind of stuff. It's going to destroy their potential.(signed)Gabriel Keewaydin--Gabe Keewaydin

How are you connecting the STAR segment to the approach segment in the FMS to produce this result? (Where the 234 restriction at FIROP affects preceding waypoints)?There is no direct linkage between the final waypoint of the ELDEE5 STAR, and any of the IAFs of the RNAV19 approach at KDCA. The STAR routing terminates at SABBI (well south of KDCA) - where it is "depart SABBI heading 192 degrees for vectors to the final approach course". Unless given further descent clearance after ELDEE, one would expect to maintain 8000 feet to SABBI.In IFR R/W ops with RWY 19 in use, ATC would most likely issue vectors for a right turn back to the north after SABBI, direct to the RNAV19 IAF at AML at 8000, thence the rest of the approach as published.The point being that one should not tie the final STAR waypoint (SABBI) directly to the approach IAF (AML) in the FMS prior to arriving at SABBI, as this could certainly produce an unpredictable results in the LEGS page of the FMS (insofar as speed/altitude restrictions for preceding waypoints), since the Navigraph database correctly lists the terminating STAR waypoint SABBI as (VECTORS)

It doesn't matter. Put in RNAV 19. In r/w you'll never go down to SABBI, you'd be vectored north after DMALL or KASDY. But it doesn't matter. The problem is way before that, on the ELDEE5 arrival itself. Notice REVUE is at 15000, then CAPSS is at FL279 and POOCH after that back down to 11000. And when you fly it in VNAV mode, with 8,000 dialed in way before T/D, it misses all the restrictions. That's the bug and it's easily repeatable. And PMDG can delete this thread and ban me for reporting this, as they've threatened above, but it won't fix the bug. It's actually probably really simple to fix.(Signed) Gabriel Keewaydin--Gabe Keewaydin

Yea, great way to run a business -- "follow our rules on an obscure link in our customer forum! Or else!"I just don't know why they're so fixated on this kind of stuff. It's going to destroy their potential.(signed)Gabriel Keewaydin--Gabe Keewaydin

They not fixated, they been giving plenty of warning that they be deleting threads with out names, people are just ignoring these warning. If people would read the rules before they post than there be no problems of deleting threads

rules are rules just sign your name

They not fixated, they been giving plenty of warning that they be deleting threads with out names, people are just ignoring these warning. If people would read the rules before they post than there be no problems of deleting threads

What rules? There's no 'rules' link or sticky post if you click on the PMDG support forum link, like how most people probably get here. You have to dig way down to find all these 'rules,' and personally I think it drives people away and is not good for PMDG's business.(signed) Gabriel Keewaydin--Gabe Keewaydin

What rules? There's no 'rules' link or sticky post if you click on the PMDG support forum link, like how most people probably get here. You have to dig way down to find all these 'rules,' and personally I think it drives people away and is not good for PMDG's business.(signed) Gabriel Keewaydin--Gabe Keewaydin

lol than you cant be reading too good than since when you first log on the pmdg forum have a look at the bottom there are 3 pinned sections one of them being signing your names have a look next time you be suprised on what your able to find

lol than you cant be reading too good than since when you first log on the pmdg forum have a look at the bottom there are 3 pinned sections one of them being signing your names have a look next time you be suprised on what your able to find

I sign my name 3 times! Yet my threads get deleted for not signing my 'name'I don't know how I can sign it any more! Should I do it four times? Five?!Why is PMDG so fixated on forum name signing, instead of growing their product and making customers happy?! We are all on their side and want to make this product grow! I just wish they'd realize this, instead of deleting our threads for reporting simple bugs. We're on the same side, guys!(signed) Gabriel Keewaydin--Gabe Keeywaydin

The name policy is not up for negotiation - there are multiple very good reasons for it.I'm looking into this VNAV thing right now seeing if I can replicate it... this part of the code hasn't been touched in a long time, I don't understand how a bug like this could have gotten past us...

I had a similar situation today. I was flying to KSAN using the LYNDI2 STAR. All the fixes and restrictions were accurate, however, the TOD was off and I had to nose dive to get to my proper altitudes.

This is one of the STARs I used a ton during testing... #####.

EDIT:Nevermind, I just reproduced it. Did you leave out the part where you were selecting an approach? That's what caused it here - without the approach it's correct, as soon as I selected RNAV 19 with AML transition it went to the messed up version.This is why every time something like this gets reported we ask for EXACT steps for reproducing it. You may think some part of it isn't important, but it often is! Thanks though, we'll figure out what's happening.

Hi.I have been messing with same issue for a long time, opened several topics, no luck so far. I wasn't the only one. I use real charts at work and cross check filed route in NGs FMC with real ones I dispatch. Well, most of the time NGX won't follow the profile even if the route and LEGS page are ideal and taken from real world fligth plan. Definitely there is something going on with profile within PMDG and it needs to be tested more deeply. Some people say it is not big deal, well, it is a big deal. You can fix this problem when you are on the ground, but when ATC swap your arrival several times for traffic and you do not have FO, you have no time to check the whole STAR, all alts and speeds and everything.Save flight.

I think I know what's causing it now - replicated at KSAN as well.For now try to make sure there is no discontinuity between the STAR and the approach - I think the issue has something to do with that. Won't know for sure until I talk to Vangelis tomorrow.

Hi Ryan,I can tell you that I did both 1 & 2 and I can duplicate this. However, it looks by the number of pages in your legs that didn't select the RNAV19 approach?Sorry, this really isn't that big a deal, I'm just curious about what causes it.Also, try just creating a KLAX to KORD route with just the BENKY1 arrival with either no selected approach or the RNAV09L approach (I think just about any RNAV appch works too at KORD since they all have an AT OR ABOVE restriction right before the RWXX leg). Set your cruise alt to say FL370, then manually enter the FL240 restriction at BDF in the LEGS and look at the subsequent waypoint altitudes. Pretty common route--surprised more haven't seen this unless everyone is setting ILS approach which does NOT cause an issue since it does not have an AT OR ABOVE restriction in the legs right before RWXX.Thanks!Edit: I posted this after you already caught the missing approach...thanks again for looking at this Ryan.

Looks entirely normal to me.Questions:1. Are you using any pre-SP1 panel states or saved flights?2. Have you tried doing a completely clean install of the airplane + SP1?

Ryan,I tried duplicating Gabe's scenario and got exactly the same result - BUT - only when selecting the RNAV19 approach with the AML transition immediately after SABBI, the last waypoint in the ELDEE5 STAR.I first entered the route only as far as SHAAR, with a cruise altitude of 33000 feet - no problems. (Departing from 28L at KCMH BTW).I then selected the ELDEE5 STAR from the KDCA ARR page and hit EXEC. This added all of the ELDEE5 waypoints. Again, no problems - the hard constraints at DRUZZ, REVUE, POOCH and ELDEE were correctly shown, as were the Above constraints at PUGEE and WZRRD. Intermediate waypoints with no specific constraints (CAPPS, DARIC) showed logical values. It did show a continued descent after ELDEE, ending up around 6000 feet at SABBI. In reality, an aircraft on this arrival would be expected to maintain 8000 feet to SABBI unless cleared to descend by ATC, since the last specific hard constraint was 8000 feet at ELDEE.Things go pear-shaped, however, when selecting the RNAV 19 approach with the AML transition after SABBI. It is at this point that the non-constrained waypoints (going all the way back to ESL) suddenly change to obviously incorrect values. DARIC, which prior to adding the approach showed a soft crossing altitude of around 9000 feet, suddenly showed FL 260 - very similar results to what Gabe reported.I do wonder if this is basically a Navigraph problem... IF I repeat the above scenario - entering just the STAR - then select JUST runway 19 (not RNAV19), then add all the waypoints and altitude constraints that make up the RNAV19 approach manually... everything works fine. NOTE, I entered the approach altitude constraints as hard AT constraints for all waypoints after HIXIT, not AT or ABOVE (xxxA) constraints as defined in the Navigraph version of the approachDefinitely not a case of the FMS blowing up with more than 6 constraints, because when I entered and defined the RNAV 19 approach manually, I had over 10 hard constraints and it caused no problems.