Jump to content
The simFlight Network Forums

Proprtional brakes


Recommended Posts

Hi Pete. I hope i have not missed a thread about this, if so my apologies.

Is it possible to make both toe brakes work off the on brake axis. I have a registered FSUIPC and FS2004. CH Pedals

My problem is that I am unable to use the right toe break pedal without great difficulty due to a dissability and would like to assign proportional brakes to the left pedal only if possible

Thanks in anticipation

Dave Lidgley

Link to comment
Share on other sites

Is it possible to make both toe brakes work off the on brake axis. I have a registered FSUIPC and FS2004. CH Pedals

My problem is that I am unable to use the right toe break pedal without great difficulty due to a dissability and would like to assign proportional brakes to the left pedal only if possible

The ordinary "brakes" control (BRAKES) would do that -- operating left and right brakes simultaneously, but unfortunately it isn't recognised by FS2004 as an axis control, only a button control (it's the '.' key). So the only way would mean a change to FSUIPC to allow a nominated axis, such as AXIS_BRAKE_LEFT to operate both left and right -- in the same way as I already map Throttle 1, and so on, to other engine throttles.

This isn't difficult to do, but unfortunately you ask at a bad time. Just last week I managed to finish up a number of important changes and get FSUIPC 3.47 out. I now have less than a week to tidy up some other things before my wife and I go on holiday.

I may be able to look at this in April if you've not found another solution by then. Ask Bob Church if he knows of a ready-made solution already available (http://www.stickworks.com). Otherwise, get back to me, say mid-April, please.

Regards,

Pete

Link to comment
Share on other sites

Hi Dave,

Another solution would be a small gauge that reads the value of the Left Brake, and continuously (that is: only if the Left brake value changes) sets the Right Brake to the same position.

If you contact me by Email at rc.barendregt@planet.nl , I'm willing to make that gauge (in XML) for you..

Question for PETE:

If the brakes pedals are calibrated via FSUIPC, does FSUIPC still use the old-style brake setting (via your own algoritm) or directly the FS AXIS_LEFT_BRAKE_SET and AXIS_RIGHT_BRAKE_SET events ??

Rob Barendregt

Link to comment
Share on other sites

Question for PETE:

If the brakes pedals are calibrated via FSUIPC, does FSUIPC still use the old-style brake setting (via your own algoritm) or directly the FS AXIS_LEFT_BRAKE_SET and AXIS_RIGHT_BRAKE_SET events ??

The former. FSUIPC has always performed proportional braking its own way -- this dates from FS2000 where there were no proportional braking facilities in FS. And I prefer the slower release of pressure my algorithm gives. Seems more realistic. :wink:

It takes either 65721 (BRAKES_RIGHT) or 66388 (AXIS_BRAKE_RIGHT_SET) for right brakes, and either 65720 (BRAKES_LEFT) or 66387 (AXIS_BRAKE_LEFT_SET) for left brakes.

But it also takes 65588 (BRAKES) as both brakes and operates them together, so you could simply convert the 66387 input into 65588 and leave the rest to FSUIPC. That's probably what I would do.

This isn't possible if you are using the gauge event interception, though, as it doesn't seem to allow changes, so your method would then be best. But I'm not sure at present if that interception occurs AFTER the control has been through the WM_COMMAND message process or before -- it would make a difference because you'd not want the right brake copy altered by FSUIPC calibration twice. You could calibrate only left, though, and leave the right, or both, so I suppose it is solvable.

Experimentation would show the best way. The axis logging facilities in FSUIPC may help too -- they occur not in the WM_COMMAND stage but the gauge interception.

Regards,

Pete

Link to comment
Share on other sites

Ok, that clear.

Actually, I just read it again, and it isn't! There's some nonsense in it! Sorry.

IF the brakes are calibrated in FSUIPC, then those controls are not getting through at all -- FSUIPC will be absorbing them in the process of making its own braking. This is okay, and what I said holds true, IF and only if the gauge event intercept occurs BEFORE the WM_COMMAND posting, which I think is highly unlikely.

Basically, I suspect that with FSUIPC doing the braking you cannot do what you need to do via gauge even intercepts, only by WM_COMMAND intercepts like FSUIPC. But then the problem arises about who sees it first.

Actually, if your code is in a gauge you will hook the FS window after FSUIPC so you will see the WM_COMMANDs first. But if this is in XML I don't suppose you'll be doing that sort of stuff?

I think, in the end, your best bet would be to do what you say and tell the user not to calibrate brakes in FSUIPC at all.

Regards,

Pete

Link to comment
Share on other sites

Hi Dave,

Another solution would be a small gauge that reads the value of the Left Brake, and continuously (that is: only if the Left brake value changes) sets the Right Brake to the same position.

If you contact me by Email at rc.barendregt@planet.nl , I'm willing to make that gauge (in XML) for you..

Rob Barendregt

Rob & Dave

I could do a module to perform this function. It wouldn't have to be installed in each panel. It would simply go in the FS Modules folder and would load automatically with FS.

Doug

Link to comment
Share on other sites

HI to all

Many thanks to you all for you solutions.

I took a look at the CHCM program but that was way past me.

Thanks to Rob for his offer of a guage and to Doug for the offer of a module which I think sounds to be the best solution for me.

Regards

Dave

Link to comment
Share on other sites

Basically, I suspect that with FSUIPC doing the braking you cannot do what you need to do via gauge even intercepts, only by WM_COMMAND intercepts like FSUIPC. But then the problem arises about who sees it first.

Hi Pete,

Actually I wouldn't have been using event monitoring for someting like this; I would just be reading the value of LeftBrake, and if it has changed since the previous read, command the RightBrake with the same value.

Using the event monitoring is a very usefull function, but only if know exactly which events you need to intercept. As you just illustrated :-)

But it's irrelevant now, since Doug's (my favorite competitor :lol: ) "module" implementation is easier (no gauge installation per aircraft).

However, your explanation DID make another thing clear about FSUIPC that puzzled me.

As you may know or not, FS2004 will DISABLE the standard key/button brake functions (AllBrakes, LeftBrake, RightBrake) if it detects an event

AXIS_LEFT_BRAKE_SET or AXIS_RIGHT_BRAKE_SET, as generated by toebrake pedals or from a gauge.

Don't ask me why, but it does !!

But now it's finally clear to me why this "problem" does NOT occur if one uses the toebrakes calibration function of FSUIPC :-)

Cheers, Rob

Link to comment
Share on other sites

As you may know or not, FS2004 will DISABLE the standard key/button brake functions (AllBrakes, LeftBrake, RightBrake) if it detects an event

AXIS_LEFT_BRAKE_SET or AXIS_RIGHT_BRAKE_SET, as generated by toebrake pedals or from a gauge.

Ah, no. I never knew thatprobably because I've never really used those new axis controls.

Don't ask me why, but it does !!

Does seem a little odd -- but, then, the button actions operate like my implementation. Of course, they would, really, because that's what I copied way back in FS2000, imitating the effect C00 and C01 had on FS98 (those were the Global offsets changed by F11/F12). I don't think the FS2002/FS2004 AXIS controls for brakes have the slower pressure release.

Regards,

Pete

Link to comment
Share on other sites

I don't think the FS2002/FS2004 AXIS controls for brakes have the slower pressure release.

You're right, they don't. The BrakesPosition value instantaneously and lineairly follows the Axis value.

Remains the question what a realistic "pressure release" is.

I don't fly aircraft in real life, so I can't really judge.

But what I notice when I have calibrated my toepedals with FSUIPC: if I give full brake pressure, and slowly let the pedals come up again, the brake pressure remains 100% untill I have fully released the brake pedal, after which the pressure returns to 0 in a few steps.

Is this how it is supposed to work, and how brakes work in real aircraft ??

(I mean: that you have to fully release the brake before any pressure is released)

Regards, Rob

Link to comment
Share on other sites

But what I notice when I have calibrated my toepedals with FSUIPC: if I give full brake pressure, and slowly let the pedals come up again, the brake pressure remains 100% untill I have fully released the brake pedal, after which the pressure returns to 0 in a few steps.

Assuming your pedals are analogue axes not just on/off switches, then what you describe was certainly a long-standing bug -- it was fixed in 3.201 as descibed in this paragraph of the History document:

Finally, the FSUIPC proportional toe brakes are now proportionally effective on pressure release, as well as application. It seems that, ever since the braking facilities were added several years ago, FSUIPC has always held the highest pressure attained during application until the brakes are fully released, and then it lets them off over a second or two.

Regards,

Pete

Link to comment
Share on other sites

then what you describe was certainly a long-standing bug -- it was fixed in 3.201 ....

Mea Culpa :-)

What I described came from my "Notes"list I maintain, and was observed in FS2002 with FSUIPC 2.97. But since you mentioned in a previous post that your braking system was still the same as made for FS2000 (based on FS98 behaviour) I assumed this wasn't changed in 3.* as well.

Shows again.. Never makes assumptions, always check the facts :lol:

Regards, Rob

Link to comment
Share on other sites

... since you mentioned in a previous post that your braking system was still the same as made for FS2000 (based on FS98 behaviour) I assumed this wasn't changed in 3.* as well.

Ah, I see. It is actually the same as what it was supposed to do, ever since it was first implemented. The bug wasn't actually intended ( :roll:), and, oddly, wasn't even reported to me for the life of FS2000 and FS2002 put together! I actually fixed it within a few days of it being reported! I assume folks just assumed it was supposed to be like that. :?

For most of that time the only proportional brakes I had were linked to my GA28R cockpit device and driven, correctly, by the Aerosoft driver that came with it. When I eventually got some PFC pedals with proportional brakes I was driving them via my PFC.DLL driver, again which worked okay.

So my only source of information about behaviour with, for example, the CH USB pedals, was (and still is) by reports, though once receiving one I could reproduce this by assigning other axes, on an ordinary joystick, to brakes. That's how I tested the fix.

Regards,

Pete

Link to comment
Share on other sites

.... oddly, wasn't even reported to me for the life of FS2000 and FS2002 put together! I actually fixed it within a few days of it being reported! I assume folks just assumed it was supposed to be like that. :?

You are probably right about that.

In fact the only reason I noticed it, was because I made a Brake Pressure gauge for FS2002 and (during testing) found this peculiar behaviour. But never bothered to give it a followup, since I found it a non-issue. The only reason I mentioned it now, was (being a technical person) tried to fully understand how it worked. Which I do now ...

Case closed :-)

Have a good holliday ...

Regards, Rob

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.