Steering using steering axis, not rudder [was in topic FSUIPC FSLABS A320 P3Dv4]

[vadriver]

13 hours ago, Pete Dowson said:

Why does the nose wheel turn with rudder deflection in any case, if the rudder is for handling hight airspeeds? .

runway steering at low speeds (using limited pedal controlled nosewheel steering) is required as the rudder is ineffective for direction control until 30 or 40kts.... but then as you wrote, becomes effective at higher speed is the dominant / more effective control with bigger rudder deflections than 7^o possible (& shortly after pedal & tiller nosewheel steering is disconnected as oleo pressure comes off the nosegear). The 7^o limit is controlled via the nosegear hydraulics etc. somehow (in the real).

using the tiller at these lower speed is not only a tad dangerous but with the PF's one hand on yoke, the other on throttle, the only z axis option is your feet (& not all 2 pilot aircraft have a tiller on the starboard side).

16 hours ago, Pete Dowson said:

Is that a universal limit, applicable to all aircraft? Because I would have thought that was a function of the add-on aircraft design, not a built-in simulator imposition. A 7 degree steering limit certainly sounds wrong for, say, a 737, which can turn on taxiways in not much more than its own length.

7^o roughly speaking for cat C & above aircraft ...... which use the tiller with about 70-80^o deflection on taxiways / lineup / turnbacks etc.

 

16 hours ago, Pete Dowson said:

Have you tested that guess?

sort of ......... with P3D43 steering (66818) set / rudder (65696) set with the ngx, I see diminished nosewheel deflection with speed) but increased rudder control and deflection (thru the pedals), it's just that at low speed the pedal steer deflects the nosewheel towards 70^o (ie not limited to 7^o).

cheers john

ps ..pete / thomas, thank you both for your thoughts in the above

[Pete Dowson]

7 hours ago, vadriver said:

it's just that at low speed the pedal steer deflects the nosewheel towards 70^o (ie not limited to 7^o).

That's a shame. I'm sure the aircraft designer's could sort that out. The only way I can think of dealing with it externally to P3D or aircraft code is to continually re-write the rudder deflection setting via SimConnect, much as the FSUIPC "magic battery" option does for the battery voltage.  I suppose I might be able to intercept rudder axis controls and alter the parameter, but I'm not sure that will work with all aircraft. PMDG oes tend to do their own interception for example.

But your original complaint was not being able to observe the animation of the rudder when doing the pre-flight checks. Going back to what you said:

" In FSX & now P3D43, I've preferred to use "fsuipc direct to" for assigning a tiller (twist) axis on a LPro3D & the rudder to (Saitek) pedals along with MaxSteerSpeed=-60 .... but lament the "nuisance" of not seeing the correct animations inside (LDu Sys) & outside the aircraft for a controls check before taxi (turning the tiller moves the rudder !!)."

I realise I still don't fully understand the problem. The MaxSteerSpeed facility operates when FSUIPC blends its Direct Tiller input with the rudder input. and as you say, both use the rudder. So you should be able to do your rudder movement check on the ground (but using the tiller axis movement).

Now the problem seems to have morphed into being one about a 7 degree limit rather than about the animation. Or is it both? If the 7 degree limit is somehow imposed, then FSUIPC's own Tiller won't be any use because, as you say, you need up to 70 degrees. Does the sim's built-in Steering axis use the rudder too?

With the FSUIPC blending facility perhaps I could not limit the Rudder Axis input when the Ground speed is zero (say) or the Parking Brake is on, so you could perform rudder checks before starting to taxi out. Would that work for you? Using the FSUIPC steering, though, since it uses the rudder for steering, there's no way to limit the latter to 7 degrees and have any useful steering when taxiing.

Pete

 

 

[vadriver]

Pete

Thanks again for your notes.

• To clarify, my original "lament" is solely the fact that in the NGX the animations (not the effect) on the ngx responding to fsuipc direct tiller / rudder axis are incorrect .... & that I thus can't check the rudder moves with pedal input (including that my pedals are in working order). MaxSpeedSet is as intended & observed to limit pedal nosewheel steer.
• But having noted the inclusion in P3D43 of "steering (tiller steer) set" / "rudder ( nosewheel steer / rudder control) set" axis' and setting those with fsuipc to sim, the NGX animations are correct but I need to be careful that I don't oversteer with pedal nosewheel steering at modest speed until the rudder takes over.

If I recollect correctly, Aerosoft's "workaround" with their FSX Airbus (using the throttle #3 axis as a tiller axis somehow) gives correct animations & pedal nws limits when appropriate.  (?) I have no direct knowledge of the FSL or other PMDG etc. aircraft. I have asked PMDG for their advice in this.

In the meantime, apart from thinking there needs to be 3 axis, tiller nws, pedal nws & rudder (aerodynamic) control .... with appropriate blending & limits, the remaining question becomes whether one can / could set a key to toggle the tiller axis off & on for the controls check.

 

 

[Pete Dowson]

1 hour ago, vadriver said:

the remaining question becomes whether one can / could set a key to toggle the tiller axis off & on for the controls check.

I will implement a check on Ground Speed being 0 ( or less than a parameter value which you can set), and if so then NOT limit the rudder. So there would be a lower GS limit on the blending as well as the higher one (MaxSteerSpeed).

I think that will be sufficient. and better than having to switch anything off and on with an assigned button or key.

I don’t see a need to stop the tiller. You don’t want to use that for the rudder check in any case, surely? Just leave it alone for the check.

Pete

 

[Pete Dowson]

Interim release 5.132c includes a new parameter alongside MaxSteerSpeed: "RudderBlendLowest". This gives a ground speed below which the rudder input is used fully with no tiller use. The parameter defaults to 1 knot, so the aircraft needs to be stationary (or very close to stationary).

Pete

 

[vadriver]

pete

many thanks for the 5.132c release ....... did a startup, taxi & a few RTO's with fsuipc tiller / rudder direct (MSS Q0,30,0,60) ....... cockpit animations, controls check, limited pedal nws & rudder control blend spot on.

but as you forecast, tiller nws during taxi (moving) still deflects the rudder ..... but whose watching (though i'll set RBL=5/10 to see whatever) !!

i'll give your update a mention at the pmdg forum ... I'm sure there'll be more than a few use / appreciate it.

cheers john

[Pete Dowson]

6 hours ago, vadriver said:

but as you forecast, tiller nws during taxi (moving) still deflects the rudder

But whilst taxiing, surely you should be in the cockpit looking where you are going?

Pete

 

[vadriver]

21 hours ago, Pete Dowson said:

But whilst taxiing, surely you should be in the cockpit looking where you are going?

of course pete ....... it's those curious PATC controllers that keep asking if I'm ready to go ??

john

ps .... finally found the attached about the airbus320 etc. it will be interesting to see what aerosoft offer this week on their P3DV4 release, given P3D4's inclusion of a "steering set" axis assignment.

nws.pdf

rudder.pdf

Edited July 8, 2018 by vadriver
xtra

[bcarson]

Pete:

I am somewhat confused on the effect of this new parameter on Tiller operation.
I am running P3DV4.3, with the 5.132c FSUIPC update. I have the rudder axis' calibrated and assigned via FSUIPC to Rudder and the tiller assigned as FSUIPC tiller(not the simconnect tiller)

Starting with the 5.132C I have noticed an anomaly with the tiller operation. When I push back, and then apply small amount of thrust, still at a very slow taxi speed, the tiller is not responding. However, if I turn the tiller full right and then full left before taxi(or even slightly after starting the taxi) then I have full tiller control.  I understand the blending upper limit, but want to know if the new parameter negates the blending at extremely low speed(eg < 1 with the default)  Should I not be able to use the tiller prior to exceeding 1 kt or am I mis-understanding the operation now.

 

[Pete Dowson]

35 minutes ago, bcarson said:

When I push back, and then apply small amount of thrust, still at a very slow taxi speed, the tiller is not responding. However, if I turn the tiller full right and then full left before taxi(or even slightly after starting the taxi) then I have full tiller control

That sounds like your axis "going to sleep". Check that you don't have power management enabled on any of the USB devices listed in the Windows Device manager.

35 minutes ago, bcarson said:

I understand the blending upper limit, but want to know if the new parameter negates the blending at extremely low speed(eg < 1 with the default)  Should I not be able to use the tiller prior to exceeding 1 kt

The parameter is certainly LESS THAN, not less than or equal to, so the Rudder, only, is operational at less than 1 knot groundspeed -- i.e a speed surely only just perceptible, and certainly not a speed at which you could steer?

HOWEVER, your question made me look at the code for this, and I see that the parameter it uses is wrongly calculated in any case!  I'm re-checking this, as it must have surely have become apparent during testing, but it looks like it is using 1 meter/sec, not 1 knot, as the limit, which makes it nearly 2 knots (1.94). I'll fix that for the upcoming release 5.14 this weekend.

If that is a problem, set the parameter to 0 and do without the new facility.

But turning the tiller full left and right won't make any difference to this whatsoever, so that is certainly down to something else on your system. The < 1 knot check just takes only the rudder input to the sim's rudder control, ignoring the tiller altogether.

Pete

 

[vadriver]

On ‎8‎/‎2‎/‎2018 at 5:14 AM, Pete Dowson said:

it looks like it is using 1 meter/sec, not 1 knot, as the limit, which makes it nearly 2 knots (1.94). I'll fix that for the upcoming release 5.14 this weekend.

pete

I believe you are correct in that, but I thought it of minimal consequence.

for all, I think we need to in the first instance mention what "aircraft" one is talking of (they are all subtly different in the real & in the sim) & to remember the tiller is for nosewheel steering (not rudder input) but that the pedals are for both nosewheel steering & rudder control (the later essentially above 40kts) .... and that fsupic's blend of pedal use has nothing to do with tiller deflection and that the blend limit solely stops pedal nosewheel steering (but allows rudder deflection for a controls check) at <1 or 2kts (no sim allows this without a feature such as pete's yet also appropriately blends pedal rudder/pedal nws in takeoff/landing) ....... @ 5kts, pedal nosewheel steering is a maximum of 7^o but the tiller allows 80^o.

that's as best I know it ...cheers to all

john

 

[vadriver]

pete

just did a flight in the ngx / fsuipc 5.14 (RBL=1) ..... all's well control wise & as expected except I don't see any animations on the lower DU during controls check.

will do some more tests & report.

cheers

john

PS .... further "tests" confirm, the animations in the cockpit are as they were before RBL (ie tiller shows movement, not the rudder, during controls check).

Edited August 22, 2018 by vadriver
more notes

[vadriver]

Pete

Further to the above, I have been reading your "advanced user guide" & have successfully set and used the P3DV4 rudder set (65696) with a 0.2 scale to limit noswheel & rudder control to about a 15^o deflection.

But now I would like to set a condition similar to those mentioned p24 of that guide for buttons to allow axis full defection either at low speed similar to the RBL & / or a simple button toggle that in effect replaces the axis assignment in full or sets a 0.95 scale for example.

I couldn't find an example to follow re format/syntax for an axis though found offsets reading ground speed in the your SDK.

Your advice / thoughts appreciated.

John

[Pete Dowson]

On 8/22/2018 at 8:02 AM, vadriver said:

further "tests" confirm, the animations in the cockpit are as they were before RBL (ie tiller shows movement, not the rudder, during controls check)

I don't understand what the NGX is reading. Can you log the rudder control and position offset s please? Logging tab, right hand side, offsets 0BBA (control position) and 0BBC (rudder position), both type S16. Then we can see what is actually being set and whether it is acted upon.

Can you also confirm that you had the tsteering tiller and the rudder both assigned in FSUIPC "direct" and both calibrated? The "RBL" facility won't be operating otherwise.

3 hours ago, vadriver said:

But now I would like to set a condition similar to those mentioned p24 of that guide for buttons to allow axis full defection either at low speed similar to the RBL & / or a simple button toggle that in effect replaces the axis assignment in full or sets a 0.95 scale for example.

There's currently no way to change the assignment without using a Lua plug-in which receives the input value and routes it to which ever control or offset is appropriate at the time. In that case you'd not assign to the rudder but either to the Lua plug-in, or to "Luavalue" with the plug-in name, if it is permanently loaded and event driven by "event.param".

Pete

 

[vadriver]

pete

thanks ..... time is an issue at the moment though it does not stop this "novice" pondering how to use a Lua to change the calibration (scaling) of the same axis.

Should be able to do the ngx logging mid week.

john

[vadriver]

pete

attached the ngx logging + profiles for the direct & sim options ideas.

it seems I should be able to write a speed contolled lua based on offset 3110 if I can come to grips with the ipcwrite syntax for 2 different axis scales !

john

FSUIPC5sim.log

b737sim.ini

FSUIPC5direct.log

b737direct.ini

& to mention, in each 2 abandoned take-offs from the same runway in opposite directions after a controls check & some tiller steering for the turnback & off the runway after the 2nd.

[Pete Dowson]

3 hours ago, vadriver said:

attached the ngx logging + profiles for the direct & sim options ideas

I'm not sure what  the logs relate to exactly, but "FSUIPC5sim.log" shows rudder deflection in the P3D4 values, for both the cintrol input and the deflection, though the max percent deflection appears to be less than 9% in each direction. 

But in this case FSUIPC is not really involved in the rudder or steering operations as you have them both assigned to the FS controls.

In the FSUIPC5direct.log you are getting full (well over 98%) deflection in both control input and deflection. 

So, FSUIPC is operating correctly. If the indicator on the Lower DU is not showing the deflection then it is the doing of the NGX..

3 hours ago, vadriver said:

it seems I should be able to write a speed contolled lua based on offset 3110 if I can come to grips with the ipcwrite syntax for 2 different axis scales !

What problems do you have with ipc.write functions? There's not much syntacx in the one function: just select the right function for the value number type (ipc.writeSD for a signed DWORD, which is what you want), offset 0x3114 for the value of the rudder, then 0x3110 for the control number (obtained from the List of Controls document. If you want to use the FSUIPC "direct" controls, the numbers for those are listed on page 35 of the Advanced guide.

It's the writing to 3110 which triggers the action, so always set the parameter in 3114 first.

Pete

 

[vadriver]

19 hours ago, Pete Dowson said:

In the FSUIPC5direct.log you are getting full (well over 98%) deflection in both control input and deflection. 

I'm guessing that was when I used the tiller particularly towards the end of the log.

 

19 hours ago, Pete Dowson said:

If the indicator on the Lower DU is not showing the deflection then it is the doing of the NGX..

When you released 5.123c, full deflection was seen on the lower DU, but not with 5.14 when you adjusted the speed calc (as I mentioned last week) (?)

 

19 hours ago, Pete Dowson said:

offset 0x3114 for the value of the rudder, then 0x3110 for the control number

I could not find reference in your SDK etc. of the 3114 offset ...... but I've tried to no avail simply the attached as a starter (in Auto, Assigned etc.)

rudderscale.zip

 

thanks john

[Pete Dowson]

6 hours ago, vadriver said:

When you released 5.123c, full deflection was seen on the lower DU, but not with 5.14 when you adjusted the speed calc (as I mentioned last week) (?)

Well, it does on the ProSim Lower DU during control checks. If you had it showing with 5.123C but not 5.14 then that is completely inexplicable. Currently both tiller and rudder give full operation at groundspeeds less than  RudderBlendLowest if both are assigned Direct and Calibrated.  The fact that the tiller does is an error which I will fix.

If you want 5.14 to behave like 5.123c in this matter just set RudderBlendLowest=0, which will disable the new facility altogether. However, I believe that with 5.123C you must have been assigning to the sim controls, not direct. I don't use PMDG aircraft, but I know some of their actions depend on seeing certain controls, and those won't be seen if you use FSUIPC Calibration.

7 hours ago, vadriver said:

I could not find reference in your SDK etc. of the 3114 offset

Look at the dentry for 3110:

3110   8

Operates a facility to send any ‘controls’ to Flight simulator.
This works with all versions of FS & CFS. Write all 8 bytes for
controls which use a value (axes and all _SET controls), but just
4 will do for ‘button’ types.

This is really two 32-bit integers. The first contains the Control
number (normally 65536 upwards), as seen in my FS Controls
lists. The second integer is used for the parameter, such as the
scaled axis value, where this is appropriate. Always write all 8
bytes in one IPC block if a parameter is used, as FSUIPC will
fire the control when you write to 3110.

See that it is 8 bytes -- 2 x 4. 4 bytes is 32 bits.

The recommendation here is to write the 8 bytes as one block, but that is not so easy in Lua if you are a beginner. The Offsets document is really aimed at programmers writing programs to interface to FSUIPC. 

This is why I described gfor you exactly what do to. You didn't need to look up 3110 or 3114.

7 hours ago, vadriver said:

I've tried to no avail simply the attached as a starter

The ZIP for a 3 line file is a bit cumbersome, isn't it? Why not just paste, thus:

    rudscale=ipc.writeSD(0x3114, 0.5)
    ipc.writeSD=(0x3110, 65696, rudscale)
end

Lots of odd things about this. First what is the "end" the end of? If you only want those two lines executed, just have those two lines. end is used to bracket a chunk like a function or a conditional or a loop.

You are trying to write 0.5 to 3114. 0.5 will be set as 0 because the 32-bit number is an integer (rudders go from -16384 to 16383, as surely you've seen during claibration?). Controls either don't use a parameter, or take an integer.

What do you expect "rudscale=" to do? You are writing not reading. 

In the second line, what to you expect rudscale to do as the third parameter?  The function doesn't use 3 parameters!

Pete

 

[Pete Dowson]

I've fixed a bug in the new RudderBlendLowest option.

FSUIPC 5.141e is now available in the Download Links subforum.

Pete

 

[vadriver]

13 hours ago, Pete Dowson said:

FSUIPC 5.141e is now available

pete

thanks ...... DU animations now showing correctly.

john

[vadriver]

On ‎8‎/‎29‎/‎2018 at 7:29 PM, Pete Dowson said:

Lots of odd things about this.

pete

yes, you were correct. what was needed was....

ipc.writeSD(0x3114, 10000)
ipc.writeSD(0x3110, 65696)

But then I felt defeated after succeeding with that script only to find it was a fixed position input to the rudder not the change of the axis range I was looking for (my so called rudscale) & then not finding an offset that might (with FSInterrogate2std) ie changing for example as speed varies "11=ER,256,F,65696,0,0,0,*0.9" to "11=ER,256,F,65696,0,0,0,*0.2"

whichever, if there was a way, it would only be of likely value if a user found his aircraft had "conflicts" with your "direct to" / mgs / rbl such as those who don't have a separate tiller but would like to use their one & only twist axis for "pedal nosewheel steer" with varying deflections (70^o <15kts, 7^o otherwise).

again thanks for your time & 5.141e.

john 

 

[Pete Dowson]

8 hours ago, vadriver said:

ipc.writeSD(0x3114, 10000)
ipc.writeSD(0x3110, 65696)

But then I felt defeated after succeeding with that script only to find it was a fixed position input to the rudder not the change of the axis range I was looking for

Of course! You are merely setting it to 10000.  To scale it you'd need to READ the input value, multiply it by your scaling factor, then write it back. I thought that was what to meant by "scaling"!???

If the script is assigned to the axis you want scaled, you receive its value as a parameter, so you simply multiply it and use that instead of your 10000. Just make the multiplcation conditional on speed.

Pete

 

[vadriver]

On ‎9‎/‎4‎/‎2018 at 7:42 PM, Pete Dowson said:

If the script is assigned to the axis you want scaled, you receive its value as a parameter

Pete

I continue to struggle to find the "correct" script" for my little idea ....... but 7 years ago you wrote " (i.e a simple newval = (ipcParam - 16384) / 8 ), then sends it on as the parameter ...." at axis range.

Is this the way forward for me, say "newval = ipcParam / 8 and written by 3114 for 3110 as above.

Hope it is, John.

[Pete Dowson]

6 hours ago, vadriver said:

I continue to struggle to find the "correct" script" for my little idea ....... but 7 years ago you wrote " (i.e a simple newval = (ipcParam - 16384) / 8 ), then sends it on as the parameter ...." at axis range.

Is this the way forward for me, say "newval = ipcParam / 8 and written by 3114 for 3110 as above.

Sorry, this is rather out of context. Can you show what you have tried in your "struggle"?

Pete