anthony_d

5 Months later, I've used the aircraft without problems just by making sure my prop levers weren't set to cutoff when the aircraft was loaded. However since then I've now gotten into aircraft development myself (RW Designs Twin Otter), so I've learned a thing or two about datarefs. The problem dataref is this one: sim/cockpit2/engine/actuators/prop_rotation_speed_rad_sec[0] / [1]. Now this seems to read the position of the prop levers upon aircraft load only, and then this value is frozen for the rest of the flight with no possibility for a regular user to change it. It seems it can either be one of two values: - The value of the prop levers upon startup - A value prescribed by script on the first frame. On any other aircraft, this dataref will freely change with the prop handle position. But not here, and the consequence of the dataref being close to zero (because of *any* detectable noise on the prop handle), is that the engine doesn't start. Do this test: 1. Load the aircraft up cold and dark. 2. Set the dataref "prop_rotation_speed_rad_sec[0]" to zero, using dataref editor. 3. Attempt to start engine 1 via the usual procedure. I'm confident now that you'll be able to reproduce the problem of engines not being able to ignite.

If the aircraft is loaded with a very low prop value baked in (less than 20), then that aircraft engine will never start. This is 100% reproducible. No I can't reproduce the scenario without hardware. That doesn't mean the problem is my hardware. Why should noise on the condition lever be baked into the prop value when the aircraft is loaded? That's a problem with what your code does in response the hardware input. Speculating here, the prop values are probably taking a (very small) change in hardware input as an override to the default prop values. But it's certainly seems daft that hardware inputs that are inherently dynamic have an influence on values that remain static for the rest of the flight. I suggest you try it with your own hardware inputs for the prop lever. The original poster also suffered failed engine starts, so there is potentially at least one other person out there. And it has certainly been a historical problem that I've read about in these forums. You've previously talked about manipulators being updated in version 1.5.2, which I understand are interfaces in the virtual cockpit, not the hardware. Therefore I'm not so confident in your statement regarding it being a moot point. I have every expectation that this problem will persist into 1.5.2 unless the problem is acknowledged beforehand.

The end of a failed start is when I pull back the condition lever to the cut off position after I've waited about 15 seconds or so. That will switch off the starter (which I can hear winding down) and I therefore consider that to be an aborted starting sequence. I've looked a general data outputs for propeller and mixture settings, and only the mixture value changes (0 to 1) between the cutoff and start lever positions. I haven't looked at datarefs at all. In my line of work, I'm dealing with 4-20mA analogue inputs into logic, but then I have full access to see what logical behaviours are attached to the input so I can fully see what's going on. So yes, I do like to analyse things down to a point where there is a pathway towards implementing a proven solution. I'm guessing only you can see what's going on in your logic. I've measured the noise on the condition lever and it's around 1% of total travel range. That doesn't seem like a troublesome amount..... With the Saab, all I can see is, once I've got one start failure on my engine, I can attempt to restart that engine as many times as I want and it simply won't start (regardless of what I've tried, hardware disconnection or not, depowering the aircraft or not, standby fuel pump override or not). That tells me that something in the logic has latched, but what that something is I can't tell. If I knew how it got latched, and how it could be unlatched then I guess we've figured out a solution. It can't be random noise, otherwise the chances are I'd be able to start the engine on the next attempt, and I'd be able to replicate it with the right jiggle of the virtual cockpit condition levers. OK. For now I have a workaround, so I'll just have to live with half a quadrant and just virtual cockpit those condition levers. Edit1: I found something My observation is that the propeller setting is always constant no matter what the condition lever position is. In the above instance engine 2 started fine, but engine 1 didn't. As you can see, engine 1 has a different propeller setting. Normally it needs to be 1395, but in this instance it isn't and it's stuck. I'll investigate some more, but I think I'm onto something. Edit 2: OK Everytime I load the aircraft, a successful engine start can always be predicted if the prop value is 1395.6. I've loaded up the aircraft 8 times, and three times the prop value for one engine has ended up being very low, and predictably the engine didn't start. So this is a problem that happens when the aircraft is loaded at the beginning. I'll investigate some more as to what causes these erroneous prop values. Edit 3: If I load the aircraft with prop levers away from the cut off position, then the chances are that either: Prop value is 1395.6 or Prop value is greater than 275 (start position, or higher) Basically the higher the condition lever position, the greater the initial prop value. A prop value of 275 or greater is sufficient to get the engines started. So the takeaway from this investigation is: make sure the aircraft is loaded with the condition levers not in the cutoff position, then you can get the aircraft engines started everytime. So Gregory: I suppose I was right and you were right. The only question for you is why are these prop values in a bistable fixed state either to 1395.6 or a value dependant on the condition lever once the aircraft has loaded? I would suggest as a solution: Fix the prop values to 1395.6 during startup or..... Make the prop value a dynamic variable with condition lever position. Either implementation will solve this problem without need for a workaround. Regards Anthony

It's not in the middle, It's actually after the end of a failed start once I've pulled the lever to cutoff before I try again without the hardware. But anyway.... Shouldn't engine start only consider the position of the condition levers - regardless of whether they are set by hardware, or by manipulation of the levers in the virtual cockpit? It shouldn't matter one bit whether hardware was disconnected during a flight session at all, except to freeze the existing position. I say "shouldn't", but obviously that isn't your thinking, and that difference between "shouldn't" and "doesn't" is something that only you can see. My understanding of the start logic is as such: - Condition Levers interlock the Start L/R switch from cranking the engine and charging the ignitors unless in the start position (not even a little bit outside the start position) - Start L/R will crank the engine and charge the ignitors once interlock is removed. - Condition Lever will introduce fuel into engine once cranking initiated for any lever position above the cutoff position. Fuel will subsequently ignite. Even with some noise in the condition levers, it would have to be considerable before fuel starvation becomes an issue. I simply haven't observed noise of such amplitude. My way of thinking about this logic is that it cannot correlate at all with the observations that I'm making, which suggests that the prop lever inputs from my throttle quadrant are triggering something quite erroneous in your code. No, I'll try tonight. I doubt it'll work however as there's no mention of this in the manual. If it does work, then the question then becomes where is this mentioned in the manual? There's only the cooldown interval that was discussed earlier, which as you say is bypassed with the use of the GPU.

If this remark about noise is correct, then whenever I have a failed ignition then I should be able to simply unplug the throttle quadrant and then restart the engine successfully. That will eliminate any such noise from the equation. Unfortunately this is not so. Once the engine has failed to ignite, it can't be successfully restarted until I have actually reloaded the aircraft. Furthermore, once the engine has started, I have to pull the condition lever back from the quite a distance before the engine is starved of fuel (literally just above the cutoff detent). The degree of lever movement for fuel starvation lies far outside any noise amplitude. In fact any throttle noise (and there is very little) is completely absorbed by the software detent for the start position. I still think there's some odd logic going on here. Sure enough, it's tied to the throttle quadrant being plugged in in the first place, but it lingers after the hardware has been unplugged.

OK. I think we're getting somewhere. Yes I'd say maybe 75% of the time the engines would start. But there was seemingly no rhyme or reason as to whether the engines started or not. It's purely a roll of the dice. I dialled down my procedure down to Batteries On, Condition Levers to Start and then Start L/R. I introduced no further steps and it was pure luck as to whether the engines started or not. Now your comment regarding hardware has got me thinking about my throttle quadrant, and about a particular paragraph in page 38 of the systems manual: So I wander if this logic is somehow tied into the condition lever. The condition lever will be brought into the start position, and then sometimes fall out a little bit due to my throttle quadrant having a physical detent that is just below the software detent for the start position. The result is a bit of jitter (which I bring under control prior to starting the engine). If every time it goes in and out of the start position that it triggers a cooling off period, that could explain it. I don't think the above logic shouldn be like this, as I'd have thought the cooling off logic should actually be tied to the Start switch. It makes no sense for the cooling interval logic to be tied to the condition lever start position. Afterall the battery is still being used to crank the engine and run the ignitors, and the cooling off period is used to protect the battery. But I wander if there's some odd logic here...…. Nothing else seems to explain the seeming randomness of the situation. I've had this problem in X-Plane 10, and now X-Plane 11 and the only common thread between the two simulators is my CH Throttle Quadrant. The plugins shared no commonality whatsoever. For now I've demapped my condition levers from the throttle quadrant, so I'll do some more testing tonight. Edit 1: More testing. I reloaded the aircraft, and rebooted the computer, and each time I had a successful start. I've done ten start attempts so far, so that's 20 engine starts and not one single start failure. So this is all done without the condition levers being mapped to the throttle quadrant. I'll now see if I can mimic a start failure based on my previous hunch. Edit 2: I tried to simulate the condition lever jumping in and out of the start position prior to start L/R. I couldn't replicate my hunch. I'm really at a loss as to why my throttle quadrant is giving me this grief. But at least I've managed to demonstrate a strong correlation between engine start failures, and condition levers being mapped to the CH Throttle Quadrant.

Just to be belt and braces about this. I updated my test copy of X-Plane and installed the LES into that copy. No other plugins installed. I reloaded the aircraft until I found an instance where the right engine didn't ignite. It cranked upto 40% RPM, but it didn't ignite, just like before. You can see in the picture above that the right engine is cranking, condition lever in start position, and "R IGN" light is annunciated. All the conditions for lighting the engine are there. I even made sure there was fuel in the tanks! Tried with manual and auto start procedures, exactly as described earlier. GizmoLog.txt Log.txt

Right. Plugins disabled, all except gizmo64. Reloaded the plane and the right engine fails to ignite. It's a manual start this time, but I'm sure it'll be the same result as the autostart. It'll crank the engine, but it doesn't ignite. Edit: Tried the autostart once the engines had stopped, and it fails on the right engine as expected. It cranks, but it does not ignite. I have only one idea what you mean by "hardware". If you're referring to my Brunner yoke, I disabled the plugin for that as well. Otherwise I'm not sure what you're meaning by "hardware". Log files attached again. Log.txt GizmoLog.txt

I know, but it is a problem, and it's probably the same root cause that affects both engine start methods. Since I was going to raise a post regardless, I thought I would tack my remarks on to this active topic. In fact I'm having problems again with manual start right now, so let's try the auto start procedure instead...… Gizmo Menu --> Auto Start --> Begin Autostart Steps 1-7 complete Step 8 Monitor Left Engine Start: In Progress. Observation: No engine cranking, Condition Levers Set to Cutoff. So lets sort that out. OK So condition Lever is now set to "start". Quite how step 5 (Move left condition lever to "Start") could compute a "complete" remark, when it's mapped to my throttle quadrant is something worthy of attention. OK. So it's stuck on Step 8. Let's hit the "X" in top right hand corner and try again. Attempt 2: Gizmo Menu --> Auto Start --> Begin AutoStart Steps 1-7 complete Step 8 Monitor Left Engine Start: In Progress. Observation: Engine cranking at 40% RPM, no ignition. Waiting for a minute ……. no change. Aborting Auto Start. So there you have it. The auto start failed on the same problem that I was having with the manual start. The engine was cranking, but it was not igniting. Log.txt GizmoLog.txt

I'll chime in here. I recently started using version 1.51 of this aircraft after a long period of inactivity (only just saved up enough money in FSEconomy to buy one!) If I go through the following basic sequence: - L & R Batteries ON - Ground Power Connected, external power ON - L, ESS and R Avion ON - COND Levers: START At this point I should be able to start my engines by moving the START switch to the L position for left engine or the R position for the right engine. Maybe 75% of the time the engines will crank, and ignite. However that 25% of the time, the engines will crank with eng RPM settling at 20%. There is no ignition. At this stage there is nothing I can do to get the engine started, except to reload the aircraft. I can abort the ignition, and try again to no avail. Not even a gizmo rebootbutton solves this problem. I've had this problem in X-Plane 10 with earlier versions of the aircraft, but it's carried through to X-Plane 11 in version 1.51 of this aircraft. I seem to remember earlier discussions on this topic suggesting that the authors of the aircraft couldn't reproduce this problem. I've attached log file for my current x-plane session. One additional remark, I notice that during engine ignition that it seems to ignite far too soon during the start sequence. The exhaust gas temperature gauge goes off the high end of the scale for a good 8+ seconds or so. I think that needs to be tweaked in the start sequence. Running X-Plane 11.41 Log.txt GizmoLog.txt

I just downloaded version 1.5 and last night I spend 90minutes trying to figure out why my engines weren't starting. Procedure used in summary: - Battery On - Ext Power connected, battery switched on - Throttle: Ground Idle - Props: Start - Start Lever: Left At this point my left engine should begin cranking, but that wasn't happening. This morning I had a eureka moment: I unplugged my CH throttle quadrant. repeated the above procedure and I get the engines started as expected. When I replugged the CH quadrant, the problem seems to be that the prop lever has to be **exactly** on the Start Detent - not *ever so* slightly above or below. This is actually very difficult because the CH-Quadrant has a physical detent that is located ever so slightly below the start detent. I retried with the Quadrant accounting for this, applying constant pressure to the levers to stop them falling into the physical detent. I could crank the engines, but once the essential busses were back online, the engines shutdown again. For now, the answer would be to not use the CH throttle quadrant.

This seems to be fixed for me in Beta 6. One of those glitches that's come and gone....

Hello Goram & Theo, I've been having an interesting ride during the x-plane beta testing phase. Some issues with the DC3 have come and gone. Now that Beta 6 is upon us, one issue looks likely to stick: 1. Load up the DC-3, cold and dark. 2. Notice the cooling fan sound. According to TKyler, in this post: http://forum.avsim.net/topic/381668-x-plane-1010-b6-released/#entry2437035 the avionics cooling fan 'bug' running on a dead bus "requires authors to go back and comply" I understand a further DC-3 revision is due, is this something that can be captured? Hopefully LR can fix the dancing engine gauges when engines are off. ----------------------- A couple of other things, not related to 10.10: 1. Gear down results in "landing gear unlocked" lighting up. This light is also active on a dead bus. I understand it should be green when landing gear is lockup up or down, and red when in transit. 2. Inner marker beacon lamp is (or appears to be) illiuminated on a dead bus. 3. Any chance of having click-drag manipulators for the radios and autopiliot knobs? They are quite hard to use with track IR. Barometer on altimeter is much nicer to use by comparison. Regards Anthony

Hello, One of the things in 10.10 that's been done by Laminar is to stop electric flaps operating on a dead bus. However on the CRJ the flaps were still working in the cold and dark state. So... I opened up planemaker and ticked the highlighted box So afterwards flaps don't operate on a dead bus (as should be the case)! Any chance you can catch this for the next update? --------------------- Hydraulics One of the things I've been investigating is to see how the hydraulics system hangs together. Test: 1. In flight, turn off hydraulic pumps 1, 3A & 3B. Leaving just pump 2 running. 2a. Operate landing gear - landing gear shouldn't move but it does. b. Roll the plane. Left aileron shouldn't move but it does. You can repeat the tests symetrically if you wish (and do more tests with brakes etc..), but the above test suggests that the hydraulic system only consists of one universal hydrailic circuit with 6 pumps, rather than three separate hydraulic circuits in x-plane. Is this a bug with the CRJ, or a limitation in x-plane that hasn't been highlighted? The hydraulics description in your manual isn't highlighted red, which suggests it should work as described. This isn't new for 10.10

Hello Goram Goran / Theo Don't mind if I jump in here? I've also discovered an autopilot related issue. I'm pretty sure this is related to the 10.10 Beta, and as such I've reported it on the LR bug report page. However I thought I'd bring it to your attention, since you might be able to engage with LR about it in more detail: ------------------------- In 10.10 B4 When I engage the autopilot, it maintains present attitude. However as soon as I adjust the pitch knob, the aircraft pitches up very steeply until the stall warning disconnects the autopilot. No matter what I try, I can't bring the pitch setpoint back down. When I try re-engage the autopilot the DC3 pitches up steeply straight away. This behaviour wasn't observed in 10.05r1. It worked as expected. ------------------------ On a side note, does the Sperry autopilot announce "Ding-a-ling-a-ling: Caution" when disconnected? Such a feature does sound a bit ahead of it's time for a 1940's autopilot !