recently installed saab340 and it gives me problems with automatic engine start

[olsiymeraj]

hello everyone, I recently installed LES SAAB340 and I always have problems when starting the automatic start of the engines.  the plane then does not respond well to the commands and I have to start all over again without results.

[Cameron]

You have not been specific enough to explain what problems you experience.

[olsiymeraj]

hello everyone, I recently installed LES SAAB340 and I always have problems when starting the automatic start of the engines.  the plane then does not respond well to the commands and I have to start all over again without results.  so I can't make an automatic start of the engines to leave, I tried to install the plane several times but without success.  I use mac os.  Has anyone had my same problem by chance?  With 733 IXEG or TOLISS and others I have no problems of any kind, I don't understand.

[Goran_M]

Like Cameron said, you're not being very clear.  Which commands are not responding? 

[anthony_d]

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

Edited January 3, 2020 by anthony_d

[JGregory]

3 hours ago, anthony_d said:

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

The OP stated he was having issues with Auto-Start.  You are doing a manual start and did not even mention if you tried Auto-Start.  

[anthony_d]

2 hours ago, JGregory said:

The OP stated he was having issues with Auto-Start.  You are doing a manual start and did not even mention if you tried Auto-Start.   

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

Edited January 3, 2020 by anthony_d

[JGregory]

You system is running several plugins, has a fair amount of custom scenery with plugins, and you are using hardware.  The easiest way to START diagnosing this is to either remove the plugins and hardware, or download the X-Plane demo, and then try the autostart.  If that works then you will need to determine which plugin or hardware is conflicting.

[anthony_d]

20 hours ago, JGregory said:

The easiest way to START diagnosing this is to either remove the plugins and hardware, or download the X-Plane demo, and then try the autostart.

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

Edited January 4, 2020 by anthony_d

[anthony_d]

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

Edited January 4, 2020 by anthony_d

[JGregory]

4 hours ago, anthony_d said:

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".

Right, "hardware", as in yokes, throttles, pedals, etc. You mentioned in one of your posts that you had the condition levers "mapped" to your throttle quadrant.   As an example, the last log you sent shows you have something mapped to prop and mixture.  You need to disconnect ALL your hardware to do a proper test.  

BTW.. when doing tests with plugins, it is not enough to just "disable" a plugin, you need to remove it from the plugins folder entirely.  I see that you mentioned you had a test copy of XP where only Gizmo was installed... that's the correct way to test.

 

47 minutes ago, anthony_d said:

I reloaded the aircraft until I found an instance where the right engine didn't ignite.

Does that mean there were instances where the engine did start ??

Edited January 4, 2020 by JGregory

[anthony_d]

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:

Quote

Starter is limited to 2 start attempts (i.e., unsuccessful start), with a 3 minute cooling   period between first and second attempt, then a 25 minute cooling period before each   subsequent start attempt. • Start; 3 minutes cooling; Start; 25 minutes cooling

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.

Edited January 5, 2020 by anthony_d

[JGregory]

3 hours ago, anthony_d said:

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.

Anthony,

It sounds like you've discovered the problem.  At this point I think it's safe to say the aircraft is performing as expected.  

Your logic regarding the condition levers being tied into the battery temp logic is not correct.  You can test this by using the GPU for your starts and continuing to use your hardware for the condition levers...this eliminates the battery temp restriction on multiple starts.   My guess is that you will continue to have the same failed starts because, as you have discovered, the issue appears to be in your hardware (noise) mapped to the condition levers. Without reading the code, I believe that if our engine logic does not find the condition levers in the "START" detent then you may get failed starts (probably due to fuel starvation), especially if the CL is below the START detent.

Cleaning the hardware may eliminate some of the noise.  In addition, you may try re-calibrating the hardware in X-Plane.

[anthony_d]

On 1/5/2020 at 3:21 PM, JGregory said:

 My guess is that you will continue to have the same failed starts because, as you have discovered, the issue appears to be in your hardware (noise) mapped to the condition levers.  Without reading the code, I believe that if our engine logic does not find the condition levers in the "START" detent then you may get failed starts (probably due to fuel starvation), especially if the CL is below the START detent

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.

Edited January 7, 2020 by anthony_d

[JGregory]

1 hour ago, anthony_d said:

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.

I'm fairly sure that our code does not take into consideration the user disconnecting their hardware in the middle of an engine start, so I'm not surprised by what you've found.  

 

Quote

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.

Not sure an aircraft reload is necessary.   Have you tried to power off the entire aircraft after a failed start?

[anthony_d]

1 hour ago, JGregory said:

I'm fairly sure that our code does not take into consideration the user disconnecting their hardware in the middle of an engine start, so I'm not surprised by what you've found.  

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.

 

1 hour ago, JGregory said:

Not sure an aircraft reload is necessary.   Have you tried to power off the entire aircraft after a failed start?

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.

Edited January 7, 2020 by anthony_d

[JGregory]

3 hours ago, anthony_d said:

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....

Huh? What constitutes the "end" of a failed start to you ?  If the starter is still running then I would not consider it the "end" of a failed start.  And... once the starter is running it will only stop running at a pre-determined N1 (or loss of elect power), not the position off the Condition Lever. 

 

3 hours ago, anthony_d said:

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.

Are you certain about that ?  Have you observed the joystick Datarefs to see what happens to them when you disco your hardware?  It's possible that the act of disconnecting itself introduces a temporary noise/spike.. who knows!  I don't think you should assume it doesn't.

 

3 hours ago, anthony_d said:

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.

It's not quite that simple.

 

3 hours ago, anthony_d said:

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.

I used the term "noise" as one example of a potential problem.  The bigger picture was that your hardware was not behaving in some manner and that was causing the engine start failure.  

 

3 hours ago, anthony_d said:

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.

We are simply taking the values from your hardware (assigned as Prop) as an input of the condition levers (position).  If the failed start ONLY happens when you have hardware connected then that tells me the hardware is causing a problem.  I have no way of knowing exactly what that problem is since I don't have your hardware.

 

it's starting to feel like you may be over analyzing this.  And, we are basically "beating a dead horse" here anyway.  The next update is not that far off and all of the manipulator logic has been re-written, including the Power Levers and Condition Levers. So, even if we found an issue that is currently affecting v1.51 we would not be issuing a patch for it anyway.

 

Edited January 7, 2020 by JGregory

[anthony_d]

3 hours ago, JGregory said:

Huh? What constitutes the "end" of a failed start to you ?  If the starter is still running then I would not consider it the "end" of a failed start.

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.

3 hours ago, JGregory said:

Have you observed the joystick Datarefs to see what happens to them when you disco your hardware?

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. 

 

3 hours ago, JGregory said:

The next update is not that far off and all of the manipulator logic has been re-written, including the Power Levers and 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

Edited January 7, 2020 by anthony_d

[JGregory]

2 hours ago, anthony_d said:

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

We do not use the prop data out values as you think we do.

I really don't have any more time to keep going back-and-forth about this...

The question still remains...

1.If you disconnect your hardware, can you consistently reproduce the scenario where you get a failed auto-start?  If not, then your assumptions are not correct and the problem is hardware related.    

and...

2. You should also consider that we are not getting any other complaints or bug reports about this and you are not the only user of the Saab that is using hardware to control the condition levers.  

Based on these two points the problem would be more than likely isolated to your system (hardware) and not a Saab related issue.

But again,  I think this is all a moot point as we will not be patching v1.51 anyway and the new update is not that far off.

[anthony_d]

 

13 hours ago, JGregory said:

We do not use the prop data out values as you think we do.

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.  

 

13 hours ago, JGregory said:

1.If you disconnect your hardware, can you consistently reproduce the scenario where you get a failed auto-start?  If not, then your assumptions are not correct and the problem is hardware related.    

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.  

13 hours ago, JGregory said:

2. You should also consider that we are not getting any other complaints or bug reports about this and you are not the only user of the Saab that is using hardware to control the condition levers.  

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. 

 

13 hours ago, JGregory said:

But again,  I think this is all a moot point as we will not be patching v1.51 anyway and the new update is not that far off.

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.

Edited January 8, 2020 by anthony_d

[JGregory]

14 hours ago, anthony_d said:

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.

It's a moot point with regard to 1.5.1.  I guess we will find out if your expectations were right or wrong when the update gets released. 

[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.
 

Quote

Have you observed the joystick Datarefs

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.  
 

[JGregory]

4 hours ago, anthony_d said:

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.  
 

Anthony,

While I appreciate your attempt at diagnosing the problem, these facts still remain the same....

1. The engine/prop code in the Saab is very complex.  We override the throttles and the props.  Therefore, observing the Dataref you mentioned above is not applicable and really does not provide any diagnostic value. 

2. The next update (yes, I know it's taking longer than expected) has all new manipulators and logic for most of the systems.  As previously stated, we are no longer "patching" 1.5.1.  So, whatever answers/conclusions you've arrived at are not going to be addressed or applicable to the next update.

Given these two facts alone, I suggest that you not put any further effort into diagnosing an old version that will not be patched and whose code is changing drastically in the next update.  When the new update is released I hope you will try it out and let us know how it works for you.   If you are still having problems we will be happy to work on diagnosing them against the new systems logic.  

FYI... none of our internal testing of the update is producing any kind of issues with the engines not starting, with or without hardware.

Edited June 9, 2020 by JGregory