P3D v4 Controlling RPM or N1

[danridz]

Hello again

I'm making a control gauge for a certain B1900D addon, thanks to Doug and my typo being spotted through debugging (which incidentally doesn't work anymore! something about mshtml.dll exception)

Using Bjoern's tip, I've adjusted the Corrected FF while the starter is active, and this works as planned.

When the engines shut down, the RPM (which i believe is unsettable?) spools down VERY slowly - in fact they stop in around 42 seconds (over 10 since n1 indication has stopped), I'm not sure if this is controlled or a specific in the .air file.

I am wondering how they do this, whether it's the .air or externally controlled.

I was also wondering if I could spin the props on startup in a similar manner, I've tried reading the combustion state from execute_calculator_code:

execute_calculator_code("(A:GENERAL ENG COMBUSTION:1, Bool)",&engine1_combustion,NULL,NULL);

As my debug isn't working anymore I cannot check this value

The basic stupid idea was to manually increment a variable and write it to TURB ENG N1:1 until combustion occurred, but nothing really happens.

If it's not possible then it's no problem! Just was interested to see if it could be done, or if my descent in to madness has finally occurred!

 

[Heretic]

The range of controllable engine variables is very limited. I think the only ones I've managed to control via XMLTools are:
- Fuel flow (only tested on turboprops)
- N2 (only tested on a jet)
- EGT (only tested on a jet)

N1 (and therefor prop RPM) can't be controlled because it's a direct function of N2 (gas generator RPM). It would be interesting which piston engine related variables can be controlled, but I haven't done any research into that direction yet.

Normally, the best way to implement slow startups is with a ton of XML code, some custom sounds, prop model visibilities, but these all depend on the avilability of the model source file.

 

[taguilo]

Hi,

For the B1900, you can control CN1 (you must use and display this, not N1) , Corrected Fuel Flow (as per Bjoern method), and ITT, though this last one has no secondary effect and can be faked by custom data.

And besides, for any free spooling turboprop, you need to custom manage prop lever position for an accurate simulation of prop RPM at any stage of flight (startup, inflight and shutdown).

Tom

 

[danridz]

Thanks Bjoern and Tom

Much appreciated! As a progress update of sorts...

I am controlling CN1 all the way through till the starters are disengaged which then (for now) hands back control to the sim, I've got a nice CN1 spool up for before combustion, as per the sim limitation there is no animation until ignition, as the prop rpm won't increase until that happens. Regardless, controlling the CN1 after combustion is working well via writing at a 18Hz rate rather than 6Hz, at 6Hz the sim was taking over, just need to keep tweaking it until I get a realistic enough effect.

Once thats done, then I will need to accordingly fake ITT as that goes rather high until CN1 is high enough

A positive step regardless!

 

[Roy Holmes]

Just to clarify a point or two.
The corrrected values (CN1, CN2 etc) are what both the sim and you can control, not the actual values (N1, N2) etc which are computed from the corrected ones for display in turbojets and turbofans.
Corrected means that the values are what they would be at sea level ISA conditions. Conversely, not corrected means the values are what they should be for the current altitude and Mach number.
In a 2 or more stage turbojet or turbofan CN2 is varied by throttle (or directly by user code control) and CN1 follows according to the values used in Record 1502, in an old single stage turbine they are, obviously, the same (which should be reflected in 1502).

In a turbo prop, usually, CN2 runs at 100% except when at ground idle when it will be somewhat less. CN1 varies as required to generate the amount of torque used to maintain CN2 at 100% as prop pitch is changed automatically through throttle adjustment (in this case "throttle" is a misnomer, it is really a "power lever"). The prop RPM is directly proportional to CN2. 100% prop RPM happens at 100% CN2

In a helo turbine the rotor RPM is also the same percentage wise as CN2 and CN1 varies according to the torque requirements necessary to maintain 100% Rotor RPM, according to flight conditions and collective lever position.

As Tom said, in turboprops and helo turbines if there is a display of gas generator revs it should be CN1 not N1.
Roy

 

[Heretic]

Now I see why I didn't have much luck with the other RPM-related variables. I didn't write to the corrected ones, which would make most sense as they're updated directly from the FDE engine.

Why writing to N2 succeeds, however, is a bit of a mystery.

 

[danridz]

Thanks Roy, this B1900D is using Corrected N1 for the respective instrument, and actual N1 isn't far behind according to FSInterrogate. Regardless, i'm only adjusting the visual startup and as soon as the CN1 is high enough, I disengage the starter if it isn't already done. As a result flight dynamics are not affected - luckily!

On another note, I know that Prop RPM:index is marked in the SDK as settable, though through SimConnect it isn't (I have tested and read this somewhere), it doesn't matter even if it's written every frame, I assume the facility was never actually added.

Through alternative methods however, basic setting operation is working, a caveat is the sim is still fighting for control (and doing well!), so lots of tweaking and delving will be required to gain a positive result, but just thought it was an interesting find. In the below video, i'm setting it to 300 rpm, and as the engines are OFF the sim is (at a much higher rate), trying to decrease the value (I presume this rate is defined in the .air file)

 

[Heretic]

You can mitigate the fighting somewhat by limiting your framerate.

Some time ago, I've talked to Tom regarding variable updates and "holding" values set by XMLTools between XML gauge refreshes to eliminate the needle flickering. Maybe a future version of XMLTools is able to pull this off.

 

[danridz]

Sorry for the bump, but I've made a breakthrough! (Early testing and proof of concept )

Ignore ITT and TRQ, as well as the low introduction of Fuel. This is just testing that the modification works as planned. The long road of tweaking for the desired effect begins!
Once I've got the desired effect in full swing, I will move onto cleaning up the code, then working on ITT etc. This will also allow me to use an external FDE to control models without their source files.

Basically this involves the FSUIPC method of internally messing with the simulator, all I have done is stop the sim writing (but still calculating) to the Prop RPM variable, once I'm done controlling it, I give control back to the simulator. I'm hoping my method should work in 4.2 without hassle, but depends on module changes.

I plan to make an interface that allows this to be controlled by another gauge, or program. I haven't tested if this means SimConnect now works for it.

 

[Heretic]

Nice work.

Not sure how many capabilities FSUIPC has regarding user interfacing. There's the Simwindow or what it's called, but it's always rendered as an extra window and can't be opened and closed by the user at will.
If this is only meant for startup, you can make the window appear when RPM is below 20% and offer to toggle the startup fix or close the window and make the window auto-close after engine spoolup.

If your solution requires a registered FSUIPC, however, it might limit the range of users that can use it, so going for a SimConnect-based gauge might be the most sensible option.

 

[danridz]

It doesn’t require FSUIPC at all or even Simconnect, so it’s just a matter of providing an interface to the variables.

I’m working on matching as many as I can, with the aim of an External FDE without Simconnect. These variables are all read/writeable instantly, but I will add some protections where possible too.

So far it seems stable and fast. I’m very happy with the progress, has been irritating to debug! So far it’s tailor made in c++ logic, though I’m looking at an external file to make it editable without messing around recompiling and reloading the aircraft.

 

[Heretic]

Now I'm confused. I always thought that SimConnect or FSUIPC is the only way to control FSX'/P3D's internal variables from an external tool.

An external configuration file is a very good idea.

 

[danridz]

That's correct. I've essentially made another FSUIPC. With the exception that it's done as a gauge. It also works in a regular c++ external program.
I'm directly grabbing all the variables, and having to map them myself. I'm having to reference the Simulation Variables SDK to get the right units (ITT caught me out being Rankines )
For a public "all bases covered" release, it will probably be a .dll, and I'd provide a way of communicating with it externally (be it a program or a c++ gauge). Still weighing that part up.

 

[n4gix]

Well, I hope you don't run into the same issues that have haunted Pete for literally decades. Every time the sim changes, all of the offsets he's carefully sussed out change, and he has it all to do again.

 

[danridz]

I will have to no doubt! I’m holding out on 4.2 until everything is ported aircraft wise...

Then will see if it works...

 

[WarpD]

Lockheed-Martin does not want hacks with v4. Even Pete Dowson is honoring that request with his FSUIPC. If there is something you want access to that there is currently not access to, you need to discuss it with Lockheed-Martin. I think they're getting tired of developers doing the hacks that then become complaint points with every update to the core sim. So... I strongly urge you to reconsider your approach... as it may become a bigger issue.

 

[danridz]

I'll try and contact them again, they haven't replied to any previous requests. If they can't come to a solution, then I can still use this for solely personal use of course.

 

[Heretic]

But SimConnect gauges should still be good, right?

 

[danridz]

Not in my implementation it seems. Well I’ll keep looking, it serves my needs. It’s only providing a pointer to the variable in memory, that’s all it does at the moment. The one little hack it does is instantly reversible, put it through quite extensive testing. Anyways if they can give me the same level of access to variables then I’ll be happy.