[PFC.dll - Saving individual config options]

Yes, I agree that having such user facilities centralized is the best way to go.

Okaytry PFC 1.994 and FSUIPC 3.537, both now available above.

Be aware that if you assign PFC axes in FSUIPC you need to disable those same ones in the PFC options (uncheck the enabling checkbox for each). The FSUIPC assignments do not override thse in PFC, unlike the Button assignments.

Regards,

Pete

Wow! I was did not think you were going to tend to this so soon. I will give it a try either tonight or tomorrow night and will report back.

Thanks.

-michael

[PFC.dll - Saving individual config options]

Actually, thinking about it, it might be better to make PFC.DLL route the axes through to FSUIPC and let you assign them and configure them there (see the Interim release details for FSUIPC 3.536). I already do this for more advanced button programming -- I'd rather all the similar additional user facilities in my products be grouped in one place. I'll look at it that way -- keep an eye on future FSUIPC releases.

Pete

Yes, I agree that having such user facilities centralized is the best way to go.

Thanks.

-michael

[PFC.dll - Saving individual config options]

Only the throttle quadrant is expected to change according to aircraft type. The main flight controls are not aircraft-specific!

Pete,

That is the change I am requesting. If one can assign a throttle quadrant config to a specific aircraft, why not also save the flight control response curve that has been set for that aircraft?

-michael

[PFC.dll - Saving individual config options]

Okay. The response curve number is saved in the INI file. It's part of the first number in lines like:

Elevator=341,1,0,16,56,68,116,255

Rudder=357,2,0,28,49,60,97,255

Here I can see Elevator is using curve #5 and Rudder #6. It's in bits 4-7.

Pete

Pete,

Ok, I see that under the pfc.ini section [FlightControls], a single response curve is saved and therefore applies regardless of the aircraft selected.

I would like to configure different response curves specific to "Jet 2-engined" and "User Config 2" that I have assigned to LDS 767 and PMDG 747 respectively. Its a nuisance to have to reset the curve each time a/c are changed. If you could put it in at some point it would be appreciated. :)

Thanks.

-michael

[PFC.dll - Saving individual config options]

What is "expo" please?

Hello Pete,

Expo := exponential. I'm not sure what term you use to describe the non-linear response for flight control axis, but they look to me like the application of an exponential mathematical function that translates linear h/w axis movement into non-linear actual control response.

The use of the abbreviated term 'expo' is a habit from my Radio Control flying days - we would apply an exponential function to "soften" control response around neutral for more precise control of the aircraft in hi-speed flight.

Can you also tell me what version of PFC.DLL you are using? It maybe something already fixed. If not the latest, available above, perhaps you could try that first, please (1.993).

I am using 1.993. Let me double-check tonight, perhaps I made additional changes to the response curves *after* assigning the TQ configuration to specific aircraft.

I'll get back to you.

Thanks.

-michael

[PFC.dll - Saving individual config options]

Pete,

Now that I am enjoying using my 2-engine jet throttle quad to fly different aircraft, I noticed that the flight control response is not being saved individiually for each config. I am using the 2-engine config to fly the LDS 767. I have the flight controls tailored with some expo in both aileron and elevator.

For the PMDG 747, I use Config 2 and no expo on aileron and 1 click on elevator.

Each time I fly, pfc.dll properly selects the correct config, but I have to manually reset the expo each time I change a/c.

Please consider saving the flight control response settings when a config is saved for a specific aircraft.

Thanks.

-michael

[Strange PFC Yoke Aileron Behavior]

Hi Michael,

Found it! A very old error for sure. Please try the attached PFC DLL version 1.993. If this is okay for you too I will put it up with the Interim releases at the top of the Forum.

Thanks for your help,

Pete

Pete,

Glad to report that I can not reproduce the error with 1.993. Thanks for the quick turnaround.

-michael

[Strange PFC Yoke Aileron Behavior]

Hi Michael,

Found it!

Pete

Good man!

A very old error for sure. Please try the attached PFC DLL version 1.993. If this is okay for you too I will put it up with the Interim releases at the top of the Forum.

Thanks for your help

Pete

Thank you. I know how these strange issues can eat at you and it's impossible to rest until you solve them! ;-)

I will test it tonight and get back to you tomorrow.

-michael

[Strange PFC Yoke Aileron Behavior]

Please watch the "input" value for the aileron, the first figure under the little "RVS" checkbox. Does that undergo similar sudden changes? If so, then it is definitely something on the hardware side, as that is reflecting the raw input.

Pete

Pete,

We can eliminate hardware as an issue. I checked the raw input value as I deflected the yoke. As the raw input value progressed from 85 to 97, the 'scaled output' went full negative. At one point I was able to hold the yoke steady with a raw input value of 87, and the scaled output remained locked on full negative.

But, then the really interesting part ...

The above test was made with a response curve. When I set the response to linear, I could not reproduce the problem. I then made a single click on the response curve and was able to reproduce the problem. I then made a second click on the response curve and was not able to reproduce the problem. After a series of tests on the response curve, I can only reproduce the problem if I make a single click to the response curve from the linear setting.

The tests were run with pfc.dll v1.992.

-michael

[Strange PFC Yoke Aileron Behavior]

I will also try it with zero slope.

And no filtering, just in case, please.

Regards,

Pete

Will do.

-michael

[Strange PFC Yoke Aileron Behavior]

I definitely need your PFC.INI so I can check with the same options and selections. Tell me also:

1) which user config in your setup you are selecting

2) using Throttles R12, R34 or just forward thrust 12, 34?

3) Flitering on or off?

4) Slope selected or flat?

Pete

1. I tried it with several user configs: 1, 2, 3, 15.

2. Just forward thrust 12 and 34.

3. Filtering is on.

4. Slope is selected - about 2 clicks.

You say that the little dot on the Slope depiction zooms off the wrong side, but that is manipulated by the driver. Please watch the "input" value for the aileron, the first figure under the little "RVS" checkbox. Does that undergo similar sudden changes? If so, then it is definitely something on the hardware side, as that is reflecting the raw input.

Let me know these things, then we'll try logging to get hard data.

Pete

Ah yes. Good point. I will check the actual values to see what is happening with the raw input.

I will also try it with zero slope.

BTW: I initially suspected h/w (and have not ruled it out :-) ). I had to return the yoke to PFC 3 months after I purchased it to have them address an intermittent problem with the left/left rocker randomly triggering input on the other rocker switches. Since I use that rocker for trim, I was getting all kinds of random actions occurring during a flight when manually flying - very frustrating to say the least. I used the "test" page to document what was happening (thanks Pete!). Since then, the h/w has performed flawlessly.

I will make a visual check of the board in the TQ Console and also pull the board at the base of the yoke - PFC had me do that when I first reported the left/left rocker issue.

I attach PFC DLL 1.992, just to be sure we are using the same version. Please do the tests with this from now on. (Note that the Version Info on this build says 1.991 -- there's no difference, both were internal builds on the same day).

Pete

Very good. It will be a long day for me, I wont get to test this until about 11PM tonight. Look for it tomorrow.

Thanks.

-michael

[Strange PFC Yoke Aileron Behavior]

Could you Zip up and send me the PFC.INI file from the FS Modules folder, please? (petedowson@btconnect.com). I'll try checking this out tomorrow -- if I can't reproduce it here I may ask you to do some tests for me with different options.

Thanks,

Pete

Will do so when I get home tonight.

-michael

[Strange PFC Yoke Aileron Behavior]

So you are possibly deducing that it is related to the mapping of the throttles, independent of the aircraft itself? Can you verify that with, for instance, the default 747? Is it only since you purchased the PMDG 747 that you have been mapping the throttles linke this?

Oh, could you try the current "official issue" PFC.DLL (from http://www.schiratti.com/dowson) just in case it is some problem introduced over the last year or so. Thanks.

Regards

Pete

Pete,

I verified that the behavior exists independent of aircraft. I just ran a series of tests with pfc.dll v1.989 and v1.92, using the default 777, default 747, and the LDS 767. The behavior existed in all tests.

And yes, prior to acquiring the 747 I never tried mapping throttles in this manner. I figured I would give it a try to see how I like it before investing in the 4-engine throttle quad.

Thanks for the help. Let me know if I can help further at this time.

-michael

[Strange PFC Yoke Aileron Behavior]

Pete,

I hope you can help me troubleshoot this strange behavior ...

I have the PFC Jet Yoke, Rudder Pedals and use the 2 engine jet throttle quad. The PFC h/w is connected to my FS host via a USB-to-serial interface. I'm using PFC.dll v1.989.

I've been flying this setup for 2+ years with 767PIC and LDS 767 and have experienced no issues.

I recently purchased the PMDG 747. After the install I configured the pfc driver to use the 2 engine throttle quad to control the 4 engines. I enabled a user config, assigned the left throttle as throttle 1+2 and the right throttle as throttle 3+4. I also enabled the spoiler and thrust reverse levers. I closed down the pfc configuration utility and double checked my assignments by observing throttle, reverser and spoiler movement. All looks good.

I then get the aircraft airborne and initiate an easy right turn. The a/c violently rolled left, and then began to roll right. This behavior repeated everytime I would initiate a right roll. So, I ended the flight, restarted, and double-checked all my settings. When observing the aileron movement on the Flight Controls page, I noticed that as I slowly and continously input right aileron, the "dot" on the response curve would drop full negative and then return to the plotted curve. When inputing left aileron, all is fine. All is fine for up/down elevator, left/right rudder, brakes, etc. ONLY with right aileron to I get this sudden full down (negative) deflection. And it occurs at the same point in the deflection.

I decided to start over from scratch. First, I loaded the LDS 767 using the 2 engine throttle quadrant config. I repeated the test of control movements that I described above. Everything worked as it should. I ended that flight and started the PMDG 747, still using the 2 engine throttle quadrant config. Repeated the test again, everything worked just fine.

I then selected a user config, but did not make any assignments. I checked control throws and everything was fine. I then assigned throttle 1 to engine 1+2 and throttle 2 to engine 3+4. When I checked control throws, the full negative deflection behavior reappeared.

I'm not sure where to go from here. I have started from a clean FS9 start, using clean (archived) versions of pfc.ini, and regardless of user config I use to assign the controls, I get the same behavior. Do you have any ideas on what might be going on; is there some data that I can log to help explain what might be going on????

I'm stumped????!!!!!

Thanks.

-michael

[Major problem with LDS 767 A/T and PFC hardware.]

In that case, instead of using the FSUIPC throttle disconnection option, you might try disconnecting the PFC throttles only. If you check the PFC DLL User Guide, you'll find a section entitled

Application program axis handling

You'll see that you can disconnect selected PFC axes by setting bits in FSUIPC offset 3BC8. You can either set and clear these bits direct from a program, or do it by programming a button in FSUIPC and using the Offset Word controls to set, clear or toggle bits.

Once again, I never thought to look! Ok - will take a look.

If you can give me information on how to detect A/T engaged state in the LDS 767 I can look into doing this automatically in the PFC driver, but it will now have to await my return from holiday, first week in April.

Basically, via the dll provided by LVLD, you provide a pointer to a STRUCT that is populated with all internal state information.

Perhaps I should just request permission from LDS to allow me to provide you with the SDK??? (I'm aware of the past issues ...)

Maybe you still need to retain the action of A/T disconnection on significant throttle movement? Isn't that what they are really trying to emulate? It seems that they really have a bit of a bug in allowing minor fluttering to disengage the speed modes. I could do that.

Honestly, in my experience to-date with the LDS767 I have no problems with minor throttle movements/control jitter and the a/t.

The significant problem occurs on takeoff after manually positioning the throttles at ~70%N1 and then engaging THR/N1 on the MCP. There is a short period during which the two seem to fit each other, and then it settles out.

I actually complicate this because I routinely practice manually advancing the throttles to the full open position while the a/t takes over (which I believe is also the case for real world ops: although the throttles are motorized the pilot does keep his hands on them while they are automatically positioned!)

I would say this boils down to having a solution that is more eloquent than the current work-around.

Perhaps others do have jitter issues.

-michael

[Major problem with LDS 767 A/T and PFC hardware.]

Well, as I said in another thread, I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we do later find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically.

Regards

Pete

Pete,

FYI: Good news and not so good news. Using the LDS 767 SDK I developed a routine to determine the autothrottle state and then ENABLE/DISABLE manual throttle input as appropriate using the THROTTLES_ON and THROTTLES_OFF custom controls in FSUIPC 3.47.

Unfortunately, those custom controls are also disabling the LDS 767 autothrottle inputs! I would not have suspected such to occur.

Will continue to investigate ...

-michael

[PFC.DLL problem troubleshooting]

I'm running XP Pro, FS9.1, FSUIPC, Autosave, WideFS, Aerosoft MCP747, Ultimate Traffic.

Nothing there any different to what I'm running. Could you send me your PFC.INI file just in case it's some combination of options? petedowson@btconnect.com.

Thanks,

Pete

Sure. It will be very late tonight before I get home to do so.

-michael

[PFC.DLL problem troubleshooting]

I don't have a registered version of fsuipc so I cannot reprogram the keys to the autopilot but I can get by with the Z key or the mouse.

The Z key operates the Level D767 A/P??

Pete

Yes, it does. Let me explain. The default LVLD keymaps have the Z key as the A/P ON/OFF toggle. There are three other keys that are mapped to CMD L, CMD C, CMD R (Left, Center, Right A/Ps).

What I did was assign the PFC A/P Button to Keypress 'Z'. The result is this:

(a) If the LVLD A/P is OFF: then the A/P is turned ON and the Center A/P is ENGAGED. I do not know why the Center a/p is engaged - I would have thought if anything that the Left would have been. (??)

(b) If the LVLD A/P is ON and any one of the three A/Ps are ENGAGED: then the A/P is turned OFF and consequently the ENABLED A/P is disabled. At this point, an A/P disconnect warning is displayed and remains displayed. A second press of the A/P button is necessary to clear the warning. This puts the A/P state back in the state described in (a).

Note: LVLD support mentioned that in programming a button to toggle the a/p we would need to press it twice to completely disengage and turn off the a/p. LVLD support also mentioned a A/P 'soft' disconnect custom control. By default it is not mapped to any key. I did not have the time to try that out to see what functionality it provides. If it is purely a disconnect function that I would prefer staying with the current settings since they allow me to turn ON and ENGAGE as well as Disengage/turn OFF the A/P.

-michael

[Major problem with LDS 767 A/T and PFC hardware.]

Unfortunately, there were no change in any of the monitored locations. It seems LVLD is manipulating values internally. They have provided an SDK to access such variables - sounds like a project for one of us to tackle.

Well, as I said in another thread, I've added new controls in FSUIPC 3.47 (hopefully released tomorrow) for "Throttles off", "Throttles on" and "Throttles toggle", so at the worst you can manually disconnect the throttles when engaging A/T modes -- or even program them on the same switch if you are able to use a switch for the 767. If we do later find a method for the PFC.DLL to detect the A/T modes then I can use the same controls automatically.

Regards

Pete

Thanks Pete - your assistance is very much appreciated. I'll get on with it and see what materializes.

-michael

[Major problem with LDS 767 A/T and PFC hardware.]

Please monitor these locations (FSUIPC's Logging page, right-hand side):

310A type U8

07DC type U32

07E4 type U32

0810 type U32

If you check the "AdvDisplay" option, below, the 4 values will show in real time on the FS screen. Let me know what happens when you engage autothrottle and disengage it. Try both Airspeed and Mach hold.

Regards,

Pete

Pete,

Unfortunately, there were no change in any of the monitored locations. It seems LVLD is manipulating values internally. They have provided an SDK to access such variables - sounds like a project for one of us to tackle.

Thanks for your help!

-michael

[PFC Jet Yoke A/P Disengage Command]

Hi Michael,

I think you can assign a key press or an FS control to that button using the FSUIPC button page. What you program there will override the settings in PFC.dll. I have programmed all the GPS buttons on the Digital Avionics to operate the FS internal GPS.

HTH

Frank

Pete/Frank -

Thanks - it works! I am able to toggle the LVLD A/P via the disengage button on the PFC Yoke.

Thanks again.

-michael

[PFC.DLL problem troubleshooting]

I stumbled across this thread and tried out the 1.912 and 1.913 versions of PFC.dll. The strange thing is that with either of these builds I am unable to perform flight control axis calibration - the calibration screen is non-responsive to flight control inputs. I reverted back to the current 1.90 version and the ability to calibrate works just fine.

Odd. That's not been changed. What about the throttles?

I'm not sure how I can help at present. What operating system FS version, other things running, and so on? I really wouldn't know where to begin.

I'll be trying to make another interim release next week, but then that's it till late April.

Pete

Pete,

Oh no - do not spend time on this as it's not a show stopper since all my controls are already calibrated! :wink: I just wanted to let you know that I did detect this and perhaps others that have downloaded it can check to see if they get the same results.

The throttle quad (throttles, speed brake, reverse thrust) show no response either. Yet, when I exit the display and go back into FS, everything works just fine.

I'm running XP Pro, FS9.1, FSUIPC, Autosave, WideFS, Aerosoft MCP747, Ultimate Traffic.

-michael

[PFC.DLL problem troubleshooting]

I have made some improvements in the serial port handling in PFC.DLL, but there are also large changes for other things and I've not yet finished those nor documentated them. However, you may like to try the attached version 1.912 to see if it helps.

Regards,

Pete

Pete,

I stumbled across this thread and tried out the 1.912 and 1.913 versions of PFC.dll. The strange thing is that with either of these builds I am unable to perform flight control axis calibration - the calibration screen is non-responsive to flight control inputs. I reverted back to the current 1.90 version and the ability to calibrate works just fine.

-michael

[Major problem with LDS 767 A/T and PFC hardware.]

The critical part is:

... if a means is provided to ascertain if the LDS A/T is engaged.

You tell me how I can detect that, and the throttle disconnection is easy.

Check that monitored locations for me first. Then I'm stuck. If the modes are entirely contained in the aircraft's own code then the only thing I can think of is to have another programmable button to specifically disconnect or reconnect the throttles.

Regards,

Pete

I'll check into it and get back to you - thanks.

-michael

[PFC Jet Yoke A/P Disengage Command]

if there is the possibility of modifying PFC.dll for inherent support of Level D I would be glad to research the "signature" components that would allow PFC.dll to recognize the existence of Level D.

I fear it will be much more complex than that. The current stuff in PFC.DLL for 767PIC is a real mish mash, trying to cope with the original (pre 1.3) version and the later update simultaneously.

If the Level D team is more or less the same as the 767PIC team then really I don't want anything to do with them.

Pete

Yes, I was aware of some of the past issues and it really is an unfortunate situation. However, lines must be drawn where they must be drawn and I do respect and understand your position.

Let's hope that the workaround you offered (reprogramming keys via FSUIPC) will suffice.

Thanks.

-michael