PFC Flight Controls

[dfournie]

Pete,

I've had this happen a few times now over the last couple of weeks on 2 dfferent computers: FS2004 starts up fine, PFC yoke/throttle passes connections checks and operates OK in FS2004. After a situation reset or two, the controls stop operating the aircraft flight controls. The PFC dialog menu still shows the proper inputs being received from roll, pitch, rudders, and throttle with no corresponding action in the FS2004 aircraft. I am using 1.92/registered FSUIPC 3.50. I have been trying feverishly to find the circumstances to recreate the problem on a consistent basis, but can't. To get it working again takes a complete exit from FS2004 and a restart of the program. It has done this on 2 different computers each with different USB-to-serial converters, and after switching to a standard RS-232 port, even on that one. It happens maybe once out of every 20 FS2004 sessions.

[Pete Dowson]

After a situation reset or two, the controls stop operating the aircraft flight controls. The PFC dialog menu still shows the proper inputs being received from roll, pitch, rudders, and throttle with no corresponding action in the FS2004 aircraft.

How odd. It sounds like the hook into FS to allow PFC.DLL to scan the inputs at regular intervals is being destroyed. Do you have any other complex add-ins?

I am using 1.92/registered FSUIPC 3.50.

It might be worth your while trying the latest PFC driver, which has a whole raft of improvments -- 1.989 in the top Announcement above. It only hasn't got into a General Release state yet because I'm well behing with the documentation, and I'm still developing some of the 737NG cockpit parts of it.

To get it working again takes a complete exit from FS2004 and a restart of the program.

Have you tried doing a PFC.DLL restart instead? You can assign a Hot Key for that in FSUIPC's Hot Keys page (of course you need a user registration for that).

It has done this on 2 different computers each with different USB-to-serial converters, and after switching to a standard RS-232 port, even on that one.

Since you are still seeing the controls in the PFC calibration and (presumably) Test screens, it cannot be related to the lnikage to the controls or the serial ports. It must be something internal to FS which is destroying the frame-based scanning.

I use PFC.DLL on two separate (complex) systems all the time and have never seen this problem, so there's something odd going on. Perhaps I will ned to know a little more about what you have installed in FS, please?

And try the latest version. If it happens again and you are FSUIPC user-registered, see if the PFC restart hotkey helps. If it doesn't happen again then maybe some of the changes I've made over the last year or whatever have fixed it. Let me know.

Regards,

Pete

[dfournie]

I was experimenting with the autopilot feedback facility and turning off the roll and pitch inputs from the yoke to FS when the autopilot was connected. When the autopilot disconnects I am setting the appropriate control axis flags back to regain roll and pitch input. I thought this may have been the culprit - that for some reason the control flags were still set to disable yoke input. Even after completely removing my application from the mix, I still saw the problem described above.

I am now waiting for it to occur again so I can perform the PFC hot key restart. That should fix the problem.

[dfournie]

Pete,

I have enabled the feature in my registered FSUIPC to reset the PFC flight controls through a keyboard Shift-C.

I do not however, see any FSUIPC offsets available to be used to perform this same type of reset.

Is this possible? Did I miss it in the documentation? I've looked through both the PFC docs, and FSUIPC docs.

[Pete Dowson]

I have enabled the feature in my registered FSUIPC to reset the PFC flight controls through a keyboard Shift-C.

There isn't such a feature that I know of. Do you mean the Hot Key option to restart the PFC driver, PFC.DLL? All that does is close down the COM port and re-open it, basically similar to restarting FS as far as the PFC controller sees. I don't think it is really needed any more. It was added when there was some suspicion of problems with serial port drivers for Win98 and Me.

The only way to reset the PFC hardware is to pull the power and power it up again. What sort of problems are you having that needs such a thing?

I do not however, see any FSUIPC offsets available to be used to perform this same type of reset.

What for? What are you trying to do?

Pete

[dfournie]

I'm using the Hot Key function to restart the PFC driver. I've mapped it to Shift-C on the keyboard and it fixes the problem I have been seeing with unresponsive flight controls. I would suggest the feature to perform the Hot Key PFC driver restart be left in, as it appears to cure the problems I've been having.

What I'm looking for is an FSUIPC offset that could perform the same function as the PFC Driver Hot Key restart. Perhaps a location that needs a value written to it to perform the same thing as my pressing the key command assigned to the PFC Driver restart on my system. Can I write a keystroke (through my application) to a particular offset to accomplish this?

[Pete Dowson]

I'm using the Hot Key function to restart the PFC driver. I've mapped it to Shift-C on the keyboard and it fixes the problem I have been seeing with unresponsive flight controls. I would suggest the feature to perform the Hot Key PFC driver restart be left in, as it appears to cure the problems I've been having.

First of all, did you update to PFC.DLL 1.989 as I advised? There have been a lot of changes. Also, I don't believe you have yet stated what operating system you are using.

As far as the restart facility is concerned, I wasn't planning to take it out, but it is a sort of last-ditch thing. Really the reason for the problem should be determined and fixed. The fact that a COMMs restart fixes it indicates that my first guess (that the PFC driver was losing its calls from FS) was wrong.

When that restart facility was first put in it was to help someone whose set up was becoming non-responsive after a long period: 8-12 hours or so. Long-haul flights in real-time. We never actually got to the bottom of it, but I've actually re-written the lower level routines a couple of times since then and it didn't recur as far as I know. Maybe he re-installed his operating system or upgraded to WinXP.

Checking the PFC DLL documentation, you'll see this in the History (version 1.70):

The ‘restart’ facility is operated automatically if no data is received from the PFC device within a specific time, defaulting to 3 seconds. The idea of this is to attempt automatic recovery from stoppages in COM port operation on some systems. So far, it seems these may be related to the Intel ICH5/ICH5R chipset, though this is simply based on the only similarities between the two machines on which it is known to have happened.

The automatic restart is only implemented on Win2K/XP and is controlled by the AutoRestartTime parameter. If you are using WinXP (which I would advise in any case) then maybe you should be using this? The automatic restart actually does an identical thing to the facility you are wanting to use, but it doesn't work on Win98/Me.

Can I write a keystroke (through my application) to a particular offset to accomplish this?

Yes. Offsets 3200-320B, as documented. It's a bit complicated, as you need to send KEYDOWN messages for each key press, in the correct order, then KEYUP messages in the reverse order. You may find it easier just to toggle a virtual button bit (see offset 3340 ff) and then program that button in FSUIPC to send the keystroke for you. I know it sounds rather round-about, but it works and is pretty easy to do, not to say more flexible as you can re-program the virtual buttons any time and using all the power of the FSUIPC button programming option.

But before you do anything, please do try the latest version of the DLL. I have had no instances of control response dying for a very long time.

Regards,

Pete