Jump to content

Will C

  • Posts

  • Joined

  • Last visited

Everything posted by Will C

  1. Mine only has files that go back to the last time I used PFPX (a week ago), 16.6 Mb in total. Just for what that's worth. But thanks for the tip, I'll check it from time to time.
  2. Never mind, I think I can answer my own question. The ISA deviation isn't given so that you can change your flight while enroute, instead it's given so that you can feed it into your FMC (or equivalent) before you take off. PFPX will calculate the performance according to given parameters, but for your FMC to calculate performance, you need to pass those same parameters to the FMC. Hence the OFP includes wind and temperature data. Obviously most FMCs get their flight plan data downloaded through something like ACARS, but you could still enter everything manually, and if you do enter all the data manually, then you'd need to enter the weather manually too, and that includes the temperature at the flight planned altitude.
  3. Hi all, I'm trying to learn more about flight operations. What is the relevance of including the ISA deviation on each leg in the OFP? (I'm asking because some of the OFP templates I've been looking at have the ISA deviation listed at each waypoint in the Navigation Log.) Prior to departure, I'm aware that the temperature at various altitudes is important for performance calculations, so PFPX certainly takes it into consideration. But once the flight has been dispatched, I don't see the advantage of putting the ISA deviation on every leg of the OFP. It would seem to only be relevant if performance numbers were varying from predicted. (If the performance numbers were spot-on, then I doubt a flight crew would ask for a different altitude just because the OFP's temperature was two degrees warmer that the SAT measured by the aircraft.) But assume the performance is off a bit, the aircraft is using more fuel than predicted, so you want to find a more economical altitude. That would usually depend on the winds more than the temperature, but let's say for the sake of argument that we're in completely still air. Specific fuel consumption drops as temperature drops, so you'd want to climb higher if able, and the only thing arguing against a higher altitude (remember we're disregarding winds here) is a temperature inversion or else the plateau you see at the tropopause. But giving the ISA deviation for a particular waypoint doesn't rule in or rule out a temperature inversion, and the ISA is corrected for altitude, so the deviation alone doesn't tell you where the tropopause begins. Another argument for the ISA deviation might be that you could tell if your flight plan is crossing isotherms. Fine, that may be interesting information to have, but PFPX has already calculated the optimum route, and besides, the ISA deviation is only given on along-route waypoints, not throughout the atmosphere, so it's not like the pilots could use the ISA deviation information on the OFP to pick a parallel track that has better performance. What am I missing? How might knowing each waypoint's ISA deviation influence operations once airborne? Thanks.
  4. Hi Stephen, Thanks for your help but I think we may be able to consider this closed. I read more posts by searching the forum under "Not Responding" and I found a thread where a user was reporting a different problem that led to seeing "Not Responding," but what caught my attention was the fact that he said the flag would disappear after a while. So I decided to wait it out. Here's what I found: PFPX wasn't getting stuck in an infinite loop, it was just taking a long time to come back to life. I started a flight plan from KORD to VNKT, using the correct UTC date, and put in the bare minimum data to compute the flight, and then pressed "Compute" and waited... Sure enough, after about 15 seconds I saw "Not Responding" but after just over a minute, PFPX came back to life and computed the flight. When I saw "Not Responding" I assumed it was stuck for good, but that's not the case. I ran exactly the same test using today's date in the computer, which was yesterday in UTC. This time, I did not see "Not Responding," and the flight computed after about 20 seconds. So here are my takeaways: (A) My problem was that I wasn't waiting long enough. (B) Computing a flight with the correct UTC date takes significantly longer. (More weather data available to parse?) (C) Seeing "Not Responding" doesn't mean PFPX won't reanimate itself if you're sufficiently patient.
  5. I'm having trouble computing flights when the departure date on my computer doesn't match the UTC date. For example, I was sitting at my computer at 20:00 tonight (Feb 1) to plan a flight that will leave in an hour (21:00 on Feb 1). However, we are UTC-6 here, so I'm doing my flight planning at 2:00 UTC on Feb 2, and planning a flight that will leave at 3:00 UTC on Feb 2. Since my computer is on Feb 1, but the departure date is Feb 2 (UTC), I get issues... Setting Feb 2 as the departure date leads to PFPX locking and saying "Not responding," and I have to shut it down and restart. But if I leave everything about the flight the same and change the departure date to Feb 1, then the flight computes, but now the weather forecasts don't synch because Feb 1 is the correct (local) date but already yesterday in UTC. Has this been seen before? Anything I'm doing to cause this problem, and anything I can do to fix it? Thanks.
  6. Automatic alternate selection not working either, a downstream effect from TAFs not loading?
  7. I see there are some interesting section types in PFPX: TankerGain TankerLoss TankerNotAvial TankerSavingsGain TankerSavingsLoss It's clear to me how to enter, say, 1000 lbs of fuel in the fuel ladder for tankering, but I don't see how to use those section headers in PFPX. Presumably each would get (by way of example): <&TankerGain_Begin> and <&TankerGain_End And then there would be relevant content within the section. It looks like possibly a way to show the cost savings, by tankering differing amounts of fuel. I'm sure it's too much to ask for a tutorial on what to place within the section delimiters, but is there an OFP template that uses them that I could have a look at? I was looking through the OFP templates that come with PFPX and I couldn't see any that put these sections to use. Thanks.
  8. Aha! Delay "from" is time after your scheduled departure time, and delay "to" is time after your scheduled arrival time. That makes sense. Stephen, thanks for your help. I edited my original post to add another question. If you have a moment, could you please take a look at Question 3 above? Thanks again.
  9. Here are some easy ones, I hope. 1. On the Costs tab, there is an entry for "Fuel Price MPM." What does MPM stand for? 2. How are "Delay from" and "Delay to" intended to be used? I certainly understand the concept of factoring in cost for delays, but I'm not sure what is meant here by "from" and "to." 3. I entered values for all the cost-related data that I could find within PFPX. Then I looked up all the cost-related variables for an OFP, and here's what I get (with the names of the variables): DELAYCOST: 0 FLIGHT HOUR COST: 359179 FUEL BURN COST: 558814 PAX COST: 0 ROUTE COST: 0 TOTAL COST: 917993 WEAR AND TEAR COST: 0 BLOCK HOUR COST: 0 I think understand FlightHourCost, FuelBurnCost, and TotalCost. But can anyone shed light on the other variables, and why they might be at 0? Thanks. (Edited to add question #3) (Edited again, now I understand DelayCost, so you can disregard that.)
  10. Another thing to think about... if you start planning a flight and then come back to finish it later, the scheduled departure time (which was fixed when you started planning the flight) may become out of synch with the freshly-downloaded live wind data. So you may also want to check to make sure your PFPX fight-planned departure time is still in the near future, and not in the past.
  11. Sorry to hear about the lack of future development. As is, the program is still quite usable (and enjoyable). So I have the same question others have posted -- will data subscriptions still be available after the current ones expire?
  12. I figured it out... My destination was close to the end of the speed restriction, so the TOD was reached about the time the 0.86 was cancelled. Moving the end of the speed restriction farther back from the TOD gets the cancellation to show up on the OFP.
  13. Okay, never mind... I planned an entirely different route and now I see: *** CRUISE AT CI 180 *** ... at the end of the speed restriction. So the <&SpeedChange> section tags seem to be working fine. I'll go back and see if I can figure out why it didn't show up on the original route.
  14. Let's say I plan a route that has a constant speed from NUMBR to KETID. I see the following on the OFP: And the relevant section in the OFP is this: <&SpeedChange_Begin>*** CRUISE AT <&Speed> ***<&SpeedChange_End> The issue is that when I get to KETID, there's no indication in the OFP that I'm able to resume ECON speed or whatever the new speed is. Can the <&SpeedChange> section be called more than once in one OFP? If so, I can't figure out where to put the second call. Or is that not the right way to display the end of a speed restriction? Thanks.
  15. When entering oceanic space, I see the following checks from the PFPX default OFP: [ ] LR NAV ACCUR CHECK [ ] RSVM ALTIMETER CHECK [ ] COMPASSS HDG CHECK [ ] HF CHECK I understand the middle two, but what are pilots supposed to check with the first (LR NAV) and the last (HF)? I can guess that LR NAV means to check the accuracy of the long-range navigation equipment, and HF means high-frequency radio, but what would that mean in practice? I imagine this will be dependent on the aircraft being flown. Would this typically mean cross-checking the GPS and the IRS, if the aircraft has that equipment? Is there any maximum error tolerance? And the PFPX OFP has blanks for CPT, STBY, and F/O... again, on an aircraft with L and R GPS, and L, R, and C IRS, does that really fit here (five navigation data sources)? Also, with HF, is that just checking that the HF radio is sending and receiving properly, or is there a tolerance check that's expected? Sorry for beginner's questions... Thanks.
  16. Also, just in case anyone finds it helpful... to switch from ISA deviation to outside air temperature in the existing flight plan template of your choice: 1. Back up the template you want to change. 2. In your template file, locate the data field <&ISADev> and replace it with <&OAT>. Note that <ISADev> may have a number inside it, like this: <ISADev:3>. To preserve formatting, carry that number into <&OAT>, like this: <&OAT:3>. Pay attention to capitalization. And make sure not to change the number of leading and following spaces, or else the formatting will change. 3. Re-select your template within PFPX. You should then be good to go. Note that neither of these data fields are listed in the Flight Plan Template Guide 2.0, which makes them something to think about if there is ever a Guide 3.0.
  17. Thanks, that's helpful. I remember a real-life dispatcher once said (on another aviation forum) that the real-life professional flight-planning software sometimes got too zealous about changing altitudes up and down to "chase tailwinds." He said that he tended to smooth things out into orderly step climbs, since that was what was most compatible with ATC clearances anyway.
  18. Thank you Andrej, that seems to work. Can you (or someone else) check my workflow and let me know if I'm doing this in the best way? 1. "Compute" the flight. 2. Check the OFP, note that the altitude needs fixing (Init Alt = 17999 feet, there is a descent immediately after departure, etc.). 3. Note the preferred initial cruise altitude (FL310). 4. Note the first waypoint past the altitude issues (e.g. CGT). 5. Hit Re-Plan. 6. Go to Advanced > Speed/Altitude/Holding, enter initial waypoint under "From," enter first waypoint past the altitude issues under "To", and enter the preferred initial cruise altitude under "Fixed Altitude/FL." For this flight, this pane now looks like the illustration below: 7. Hit "Compute" again. 8. Now the problematic section has been smoothed over, and the aircraft climbs to the initial cruise altitude without issues, and continues to climb on schedule without further manual inputs, see below (compare this illustration to the one in the original post): Operationally, this solves my problem. But I'm wondering if this is the best workflow? Is there a more efficient or a more preferred way to get to the same result? Thanks.
  19. I'm sure this is an easy fix, but I can't find it. As you can see, PFPX wants the aircraft to climb to just below 20,000 feet for a microsecond (actually it's 4 minutes), then descend back down to 16,000 feet for another microsecond, and then climb up to FL310. On the OFP, the initial cruise altitude (the value of <&InitCruiseAlt>) is 17,999 feet. Clearly odd. To fix this, first I put in a Min Alt/FL of FL250 and hit Compute again, but I get the same result: 4 minutes of level cruise at 17,999 feet followed by a descent. So then I next looked for a way to edit only the altitudes in the advanced route editor and I'm not seeing it. One thing I noticed were that the initial waypoints were on a low-altitude Victor airway. So I hit the button that said Upper Airways, and still got the same result. Then I removed the airways between the initial waypoints and made each waypoint just DCT to the next. Still the same result. Any suggestions? Thanks for your help.
  20. Thanks Stephen. I also read somewhere that by choosing alternates strategically, you can often find airports such that ETP ADD=0. Reducing ETP ADD to zero serves two purposes: one is to maximize payload, and the other to avoid an unsightly gap in the OFP's fuel ladder... 🙂
  21. UPDATE: Resolved. I think I had a nesting error with the section tabs. That said, <&TimeEllapsed> does seem to reset to zero when you divert at the end of the main route, perhaps because the initial point of the alternate route is an airport. But it is incrementing properly to show cumulative time since departing the destination airport, and the planned time matches the predicted time. Which is another way of saying that <&TimeEllapsed> at the end of the diversion matches <&Altn1Time>. Good to go!
  22. The data field <&TimeEllapsed> seems to reset after the destination. The problem is that I have a "Diversion" NavLog (for the route from the destination to the alternate) that is working correctly in other respects, except that the <&TimeEllapsed> is no longer a cumulative counter recording the time elapsed from takeoff. Instead, on the diversion NavLog, <&TimeEllapsed> shows only the time from one leg to the next. By way of example, the final four legs of the main route (origin to destination) count up cumulatively, like this: 12:30, 12:45, 13:05, 13:27. But after diverting, <&TimeEllapsed> only shows values like this between legs: 5, 5, 5, 5, where each leg is hypothetically 5 minutes from the previous one. In other words, it resets to only show just the time from the previous leg, not the cumulative time elapsed since takeoff. Everything works well in the main trip NavLog, and in the re-dispatch NavLog; it's only the diversion NavLog from destination to the alternate that is giving me this behavior. I'm using <&TimeEllapsed> for each of the three NavLogs above. Should I be using a different data field for the cumulative trip time from takeoff to the alternate? Or is there a better way? I should add that I copied and pasted the data fields for the three NavLogs (trip, re-dispatch, and diversion) so they look identical except for their section headers. And every data field works as expected, except <&TimeEllapsed> for the diversion. Thanks.
  23. The Flight Plan Template Guide allows for <&EROPSFuel> with data type "weight," but there is no corresponding <&EROPSTime> with data type "time." Thus there's a missing line in the endurance column of the fuel summary chart. If I read the Fuel Policy section correctly, <&EROPSFuel> corresponds to EDTO Reserve Fuel and it would make sense to me that this would be expressed as endurance, along with the other fuel types. Can anyone shed any light on this? Thanks.
  • Create New...