A recent SDK update added descriptions of a number of automatic flap handling
variables available in the flight_model.cfg file. One of these variables is
flaps-position-inhibit.N. The description says that it is a comma-delimited
table identifying conditions that if all are true will inhibit that flap
setting from being selected by the flap lever. (The words the description uses
says, “will inhibit the flaps settings from affecting the flaps ,” which
doesn’t make a whole lot of sense.) However, it is not working in this manner.
Example: This variable is used in the Asobo A320NEO for specifying the
conditions under which moving the flap lever to the first flap position will
result in CONF 1 (slats only) vs CONF 1+F (slats + flaps). The line in the cfg
file is: “flaps-position-inhibit.1 = air, increasing.” If implemented
correctly, this would inhibit selection of CONF 1+F if the airplane is in the
air AND you were increasing the flap handle position (that is going from flaps
up to flaps 1). If the airplane is on the ground, the inhibit should not have
any effect, and therefore, you should get CONF 1+F regardless of whether you
were selecting flaps 1 starting from the flaps up handle position or the flaps
2 handle position. However, it is currently working in the same manner as it
is meant to work in the air – if going from the flaps up handle position to
the flaps 1 position, you get only CONF 1. Only if going from the flaps 2
handle position to the flaps 1 position do you get CONF 1+F. From this, I
thought maybe it had been incorrectly implemented as an “OR” set of
conditions. This would mean, however, that whenever the airplane is in the
air, it should never allow CONF 1+F to be set. However, it does allow this to
occur if going from the flaps 2 handle position to the flaps 1 handle
position. It even allows this to happen if the only condition is “air,” which
should prevent the trailing edge flap from deploying at any time while in the
air. It also works the same way (giving CONF 1 when going from flaps up to
lever position 1 and giving CONF 1+F when going from flap lever position 2 to
flap lever position 1) when in the air with the inhibit condition being “air,
decreasing,” (In this case, moving the flap lever from flaps up to flap lever
position 1 should result in CONF 1+F and going from flap lever position 2
to flap lever position 1 should result in CONF 1.) I haven’t checked any
of the other similar flap conditional variables described in this section of
the SDK, but this one does not appear to be working properly. Addendum: The
SDK has these variables in a new optional section entitled [FLAPS]. In
contrast, the Asobo A320NEO flight_model.cfg file has the inhibit example I
referred to in one of the [FLAPS.N] sections. To model the A320NEO flap/slat
system, I don’t know how you could put it in a generic [FLAPS] section. Seems
to me it has to go in a specific [FLAPS.N] section.
Hello! Referring to this: “Addendum: The SDK has these variables in a new
optional section entitled [FLAPS]. In contrast, the Asobo A320NEO
flight_model.cfg file has the inhibit example I referred to in one of the
[FLAPS.N] sections. To model the A320NEO flap/slat system, I don’t know how
you could put it in a generic [FLAPS] section. Seems to me it has to go in a
specific [FLAPS.N] section.” The documentation is actually wrong I’m afraid,
and there is only the [FLAPS.N] section. There was a miss-communication about
the parameters in the [FLAPS] section of the current documentation. The docs
say that the N value for the parameters target a particular flaps however,
they actually target a particular flaps position and as such should indeed
be defined for each [FLAPS.N] section. The next update will resolve this issue
and sorry for any inconvenience this may have caused.
Hello. On the behaviour of the parameter itself, we can confirm it applies a
OR logic between conditions. We have taken your feedback into account and will
review how this can be improved to choose between AND and OR logic. Thanks for
reporting this. Regards, Sylvain
Hello @donstim This has been done in SU8. You will now have a or and
and version of the parameter.
