PMDG 737NGX Toe Brakes stopped working P3Dv4

[FatherDane]

Hello

I have the latest version of FSUIPC installed (5.15).  My sim has Opencockpits 737 rudder pedals. everything has been working fine up to a few days ago when I discovered the toe brakes were no longer working.

I first checked that the wiring was all right (it is) and I performed a new calibration thinking that would solve the problem, but it hasn't  The calibration is correct but for some reason the toe brakes are inoperable in the sim.  I've checked everything, and even ran P3Dv4 repair, and PMDG repair from the installation packages, but although FSUIPC shows that the physical Opencockpits pedals are properly connected and functioning, the toe brakes on the pedals do not seem to be connecting to the sim.  The rudder works, but not the toe brakes.  It there any reason you can think of why the toe brakes should have stopped working in the sim?  I push the toe brakes and absolutely nothing happens.  I also checked to see if there was a fault in the PMDG failure settings, but that it clear.

I have a suspicion that it is something very simple that my thick brain is overlooking, so could you put me out of my misery, please?

Many thanks

Father Dane 

[Pete Dowson]

5 hours ago, FatherDane said:

I have the latest version of FSUIPC installed (5.15).  My sim has Opencockpits 737 rudder pedals. everything has been working fine up to a few days ago when I discovered the toe brakes were no longer working.

Where are they assigned: P3D or FSUIPC? In FSUIPC assignments can you see the values changing then they are selected for assignment (whether you do assign or not)? Have you checked with any default aircraft at all?

Pete

 

 

[FatherDane]

I have no default aircraft - only scenarios that I have assigned with the one aircraft I use: PMDG 737NGX and the Ryanair livery.

The brake assignments are all made via FSUIPC and are disabled in P3D.  The values do change when I go into the FSUIPC settings so I know FSUIPC "sees" the action.

As an aside, it's possible the brake issue could be a bit more widespread as I assigned FS-Brakes to a button as a stop-gap measure and when I use it, it's as though there are no brakes at all.  I also notice that auto-brake seems to have little or no effect and finally, the hand brake appears very reluctant.  There is a screen in the 737 … the lower DU where engine and system values are monitored … and I note that after a landing, the brake temperature now remains zero which is very unusual as there is always some temperature increase registered even on one of my more perfect landings. :)

Does this help?

Thanks for taking the time

Father Dane

[Pete Dowson]

25 minutes ago, FatherDane said:

I have no default aircraft

Deleting all the supplied aircraft is a bad idea. most PMDG advice is to load a default aircraft as default before sleecting a scenario with a PMDG aircraft.

26 minutes ago, FatherDane said:

As an aside, it's possible the brake issue could be a bit more widespread as I assigned FS-Brakes to a button as a stop-gap measure and when I use it, it's as though there are no brakes at all.  I also notice that auto-brake seems to have little or no effect and finally, the hand brake appears very reluctant. 

I think this is now a question for the PMDG forum as it is obviously a problem with the aircraft.

Pete

 

[FatherDane]

Hello Again

Sorry, I goofed and I need to clarify.  First, I do have a default aircraft - it is one of the standard ones in P3D that I never use, but remember people saying that unless you have it, P3D has a habit of crashing to the desktop.  I had simply forgotten about it as I never used it.

Second, I did discover one problem: that when I performed a "repair" from both P3Dv4 and PMDG, I forgot to put in the [SDK] EnableDataBroadcast=1 in the 737NGX_Options.ini file.

I did and then went back into the sim to see what difference it made - and it did, of course.

I now have fully function brakes with the button I added to activate FS Brakes when pressed.  The parking brake also works.  The differential brakes still have a problem and don't work as they did before.  If I apply them, the effect is so slight as to be negligible.  I went into FSUIPC to try and calibrate them again, and I notice something I had not seen before: where before, the preview box that shows the values, had a whole number in one and a -number in the other, the calibration seems confused as to whether there is a -values of not.  I could do it twice and get a different value each time.  I suspect the is the visible evidence of what the problem might be - but I'm not smart enough to know what that problem is.  Does this help you to determine the possible cause?

The 737 yoke assembly uses the same controller card as the 737 pedals (which also includes the toe brakes) No other axis appears affected other than the differential left and right brakes. Since I can have brakes via the button programmed as an FS function for Brakes, the issue is not with PMDG I think, but with the way the hardware is trying to talk to the software (the toe brakes to FSUIPC).

Have you encountered this anomaly before?  Is there a corrupt file somewhere that needs deleting and re-installing?

Many thanks

Father Dane

[Pete Dowson]

2 hours ago, FatherDane said:

I went into FSUIPC to try and calibrate them again, and I notice something I had not seen before: where before, the preview box that shows the values, had a whole number in one and a -number in the other, the calibration seems confused as to whether there is a -values of not.  I could do it twice and get a different value each time.  I suspect the is the visible evidence of what the problem might be - but I'm not smart enough to know what that problem is.  Does this help you to determine the possible cause?

"Preview" box? In the calibration screen?

On the left it has an IN value (before calibration) and an OUT value (after calibration).

Most joystick axes have a range of something like -16380 to + 16380.   That's fine for ailerons, evelators, and rudders, as they go left and right or up and down as well as having a neutal centre. But brakes only run from neutrol (off or 0) to full pressure (16383).

Proper calibration maps your unput value to the output values required.

2 hours ago, FatherDane said:

Have you encountered this anomaly before? 

I really don't have any idea of what you regard as an "anomaly".

Did you be sure to disable controllers in P3D? did you check things with a default aircraft?

Pete

 

[FatherDane]

Ah yes, the "preview boxes" I referred to were the axes range values.  It's just that the values in the IN and OUT value boxes show a different range of values each time I try to calibrate the toe brakes.  One time they are all positive numbers another time I see the numbers prefixed with a "-" minus - this is what I refer to as an anomaly (something that deviates from what is standard, normal, or expected) and this was not what I expected.  I know something is not working as it should.

I have attached the INI file for you to look over - the specific controller is: 1=USBAXESV2.0 and the specific lines for the axes are

LeftBrake=-15230,16383/16
RightBrake=-14938,16139/16

And yes, the controllers are disabled in P3D.

As I said, I don't understand why everything was working perfectly up until a few days ago and since then, this particular function has not worked.  That's why I wondered if there is a corrupt file somewhere (like a DLL file) that needs to be deleted or overwritten with something else.

Sorry to trouble you with this but I am out of ideas.

Father Dane 

FSUIPC5.ini

[Pete Dowson]

4 minutes ago, FatherDane said:

Ah yes, the "preview boxes" I referred to were the axes range values.

Not the range values, One in, one out.

5 minutes ago, FatherDane said:

.  It's just that the values in the IN and OUT value boxes show a different range of values each time I try to calibrate the toe brakes

Of course! They'll change all the same according to the axis position! and your calibration!

6 minutes ago, FatherDane said:

LeftBrake=-15230,16383/16
RightBrake=-14938,16139/16

Those look fine.  That sort of range from minimum to maximum is quite normal, especially if that allows a little dead area in case you push them inadvertently during rudder operation. I think the /16 [art just means that they are reversed (the "REV" checkbox) always necessary for brakes.

Sorry, but I think you need to look elswhere. Check with a default aircraft, as i keep telling you, so you can determine if it's a PMDG problem.

Pete

 

[FatherDane]

I understand.  Yes the REV is ticked. And yes I understand the values will change as I move the pedals - but the values are changing without any input from me and before I even try to move the pedals and calibrate. That's what I mean by changing values - and an anomaly.

But as you suggest, I will now approach PMDG to see if they have an answer.  If not, then it will mean a complete wipe of the computer with a full and clean installation as that is the only other alternative to fixing this: get rid of everything and simply start again.  It's a time consuming process, but so is trying to track down one single malfunction in a million processes, and at some point, that may be the more economical route.

Thank you for trying though - it is really appreciated.

Father Dane

[Pete Dowson]

4 hours ago, FatherDane said:

but the values are changing without any input from me and before I even try to move the pedals and calibrate.

If they are changing by small amounts up and down, that's called jitter, and is caused by dirty controls or poor power. If the changes are more violent then it will either be a very bad faulty unit, a bad connection, or interference.

The "IN" value merely relays the value being received from Windows DirectInput. Check also the values seen on the assignments tab -- where you assigned these axes. They will correspond. And if they are changing all the time you'd have to use the "ignore" button to allow you to assign any other axes, as they would be seen first.

4 hours ago, FatherDane said:

But as you suggest, I will now approach PMDG to see if they have an answer. 

I actually suggested you first check the action in a default aircraft. Really, if the inputs from the troes brakes are so wild then there's nothing PMDG could do.

So, why haven't you at least tested with a default aircraft first? That's always the main step in deciding where the problem lies. (Though if your inputs are playing up I doubt there's an other source but hardware).

Pete

 

[FatherDane]

Hello

I just experimented with a Mooney Bravo (one of the P3DV4 models they offer) and with an imported 737 from FSX.  Then I also tried with another PMDG model 737 other that the Ryanair model I generally use.  All other axes controls are working such as the yoke and rudder etc, as does the hand brake, as well as the button I assigned to use as a brake, but the toe brakes are inoperable in every sim aircraft model l tried. I tried calibrating them again and still nothing happens.  (And I do believe it is jitter that is causing the values to change now that you point it out).

However, there is an obvious physical connection between the hardware toe brakes and FSUIPC otherwise there would be no values appearing or changing in the FSUIPC  at all.  The values are just not transmitting to the aircraft - whichever aircraft model that it.

The rudder pedals are working normally and I mention this because the controller card is the same for both the rudder as for the toe brakes and also for the yoke as well.

I wrote to PMDG but so far no reply.  As this affects sim models other than PMDG, I'm wondering now if this is something for Lockheed?  There has been no P3D update for some little while that might be seen as a cause for such a disconnect, nor has there been other sim updates either, so I am baffled as to why this one FSUIPC function doesn't connect with any of the sim models.  As far as I can see, all the other FSUIPC functions are operating as normal.

Is there another value I could put in somewhere?  I know this is one of the axes, but is there a work-around?  What sort of test would you run to try and make a connection?  I wondered earlier if there might be a corrupt file somewhere.  You are the one who knows how FSUIPC connects with the sim and what files are used or accessed: is there a file somewhere that could possibly be preventing the sim connection?

So do you recommend me contacting Lockheed Martin on this, or should I take the plunge and simply wipe it all out and perform a clean installation from the OS on up?  It's a bit drastic and time consuming but it appears there is a tiny needle somewhere in a very large haystack.

Best wishes

Father Dane

[Pete Dowson]

3 hours ago, FatherDane said:

However, there is an obvious physical connection between the hardware toe brakes and FSUIPC otherwise there would be no values appearing or changing in the FSUIPC  at all.  The values are just not transmitting to the aircraft - whichever aircraft model that it.

What are they assigned to, exactly.

3 hours ago, FatherDane said:

I wrote to PMDG but so far no reply.  As this affects sim models other than PMDG, I'm wondering now if this is something for Lockheed? 

If you use P3D assignments instead (temporarily re-enabling controllers) do they then work okay? If so, L-M won't be interested.

3 hours ago, FatherDane said:

Is there another value I could put in somewhere?

No really. You could log the axis controls in FSUIPC logging.  Maybe they are getting trapped or inhibited somewhere.  Also, in the FSUIPC Logging Tab, right-hand side, enter the offset 341A and select type U8. Then chek "normal log" below. This will log a byte in FSUIPC used to stop toe brakes operating -- used by programs wishing to simulate failures -- eg by overheating in the case of the brakes, It has bits used as follows:

0 Left brake (“Axis Left Brake Set”)
1 Right Brake (“Axis Right Brake Set”)
2 Flaps
3 Spoilers

So and odd value, for example, would stop Left Brake working.

3 hours ago, FatherDane said:

So do you recommend me contacting Lockheed Martin on this, or should I take the plunge and simply wipe it all out and perform a clean installation from the OS on up?

Neither, yet.

Pete

 

[FatherDane]

Hello

Since I am in the miracle business, I am declaring a miracle has happened.

First of all and to answer the first question, the toe brake axes are assigned to left brake and right brake

After starting P3Dv4, I chose a PMDG 737 aircraft.  I went into FSUIPC and ticked the AXES box and selected NEW LOG FILE. Then I entered the offset 341A in all four boxes on the right with U8.  Then I went into the calibration panel and re-calibrated the left and right differential brakes - and I noted that this time, the values were not jittery and it entered smoothly.  Exiting I went through a start up so I could test the brakes and after moving, that is when I discovered a miracle had happened: the toe brake now work as they used to do.

I have attached all the log files for you to look at.  The toe brakes are attached to this controller: USBAXESV2.0

Now, since the brakes are working once again, do I do anything with the LOG page?  Should I remove any values or at least disable the additional logging?  What should I do about those settings?

Whatever the problem was, it has certainly been corrected.  You, sir, are a genius!

Gratefully

Father Dane

 

 

FSUIPC5 Install.log

FSUIPC5.1.log

FSUIPC5.log

[Pete Dowson]

1 hour ago, FatherDane said:

Now, since the brakes are working once again, do I do anything with the LOG page?  Should I remove any values or at least disable the additional logging?  What should I do about those settings?

You don't need any logging if things are working. I would be more interested in what you did differently to make things work.

BTW you shouldn't have an "FSUIPC5.1.Log". you must have pressed "New Log" to start a new file. you never need to do that unless you are after a clean start. Normally the full log from the start is more useful.

Also, I don't see how the Installer log is relevant.

The FSUIPC logs just show everything is ok.

Pete

 

 

[FatherDane]

As to what I did, well, only what I wrote above - I added those values - the 341A and U8  into the LOG boxes.  After that, it worked!

I will disable the new logging but leave the values as the same.  As to sending you too many logs - I thought it better to be generous rather than stingy :)  I wouldn't know what is relevant or not to a programmer such as yourself.

Once again, thank you for sorting me out.  You really are a genius.

Father Dane