Compatibility Problem with New PFC Drivers and pmSystems

[FredK]

Hi -

I have the PFC jetliner console and yoke.

I just updated to the most recent PFC drivers, including FSUIPC. Specifically, I went from old PFC 1.90/FSUIPC 3.50 to new PFC 2.02/FSUIPC 3.71 for FS9. I also installed the new PFC/FSUIPC drivers for FSX from the Pete Dowson website.

In both case (FS9 and FSX) I found an incompatibility with PMSystems. PMSystems lighting control functions are confounded/inoperable and when PMSystems is running some functions on the jet console do not operate (for example, brake on/off switch). Backlighting for my CPFlight MCP also becomes inoperable. If I close PMSystems everything goes back to functioning normally.

I tried rolling back drivers individually (FSUIPC, PFCdll, PMSystems) to pinpoint the problem. I found the problem to be with the latest PFCdll (both the 2.00 and 2.02). If I roll back to PFC1.90dll all is OK for FS9. Obviously there is no option to roll back for FSX.

Any insights on this would be much appreciated.

Thanks,

Fred

[Pete Dowson]

PMSystems lighting control functions are confounded/inoperable

PFC drives the 6 pack indicators in the same way as pmSystems 737 Logic, via offset 5530. These only affect the sixpacks, Fire and Master Caution indicators. The whole point of the change for 2.01 to 2.02 was to make the bit assignments compatible with the current assignments in PMS's SysVar.txt.

The PMSystems functions in the PFC driver are pretty much restricted to those things handled by pmSystems logic when it is running. They've been driven in PFC.DLL now for nearly two years. This isn't a recent thing. These include:

Offset 5530 for six pack, fire and master caution

Offset 560F for APU

Offsets 5642 and 5643 for lighting

Offset 5645 for Strobe

Offset 5610-13 for the starters

Offset 5664 for pitot heat

Offset 5657 for wing and engine de-icing

Offset 5628 for the master battery

Offset 561A for fuel cutoff/idle

Offset 579B for the Parking Brake

when PMSystems is running some functions on the jet console do not operate (for example, brake on/off switch).

As above you mean?

When I do a bit more work the Autobrake will go through pmSystems too, but I've not done that yet.

It sounds very much like you are using PMSystems logic which isn't doing what it should. Can you tell me what you are using? If you have a custom written logic for your setup then we can sort out some small changes to make it work. What aircraft are you simulating?

Backlighting for my CPFlight MCP also becomes inoperable.

Backlighting? How does PMSystems relate to backlighting? Sorry, you will need to be more specific.

Do you know how any of your kit works, or are you simply using stuff programmed by someone else? If you know, please get down to the detail of what offsets do what.

I've put a lot of work in over the past two years to make the PFC stuff work properly with pmSystems, and I'm pretty sure all the offsets are used correctly. Can you please look to see why your pmSystems isn't using the standard SYSVAR.TXT defined values?

Regards

Pete

[FredK]

Hi Pete -

Thanks for the response, but am still scratching my head on this.

Let me be sure I'm clear about the problem.....I am getting a corruption in pmSystems if I use the updated PFC.dll. Likewise some switch functions on the jet console will not operate with pmSystems running. If I revert back to the earlier PFC.dll all is OK.

I've switched the PFC.dlls back and forth a number of times to be sure and the behavior is consistent each time.

To answer your questions.....I am flying the 737NG. Behavior described will happen using the MSFS default model. I am using the standard unedited sysvar.txt supplied with pmSystems (most recent release). What I mean by backlighting on my CPFlight MCP is that the "NAV" light switch on the PFC console normally will switch that on/off.

Since the sysvar.txt is unedited and remains common in both cases (updated and non-updated PFC.dll), I can't see how it could be related. I am using SIMBOARDS as a hardware interface and I'm sure there is some special internal logic there, but what I'm seeing happens independent of the hardware and SIMBOARD software running and certainly with no changes in any of the pmSystems files.

Manifestations of the problem: The updated PFC.dll works fine as long as pmSystems is not running. As soon as PMsystems is interfaced (without the hardware and SIMBOARD software running to be sure) it will cause the parking brake switch and NAV light switch on the PFC console not to function (perhaps some others, I have not checked everything). Also, the light switches in the PMsystems overhead will not function - for example, if I throw the landing light switch the landing lights will flick on but then flick off, including the switch itself. Also, I find that I cannot perform an engine restart in pmSystems. An initial start from a cold and dark cockpit works, but after shutdown the engine start switches on the pmSystems screen flick back-and-forth randomly. Not possible to perform a restart after that.

But if I put back the old PFC.dll (version 1.90 about a year old is the previous and latest I have) everything functions perfectly!

Your quick response was much appreciated.

Very best regards,

Fred

[Pete Dowson]

Let me be sure I'm clear about the problem.....I am getting a corruption in pmSystems if I use the updated PFC.dll. Likewise some switch functions on the jet console will not operate with pmSystems running. If I revert back to the earlier PFC.dll all is OK.

A "corruption"?

I thought I explained all this. Did you not understand anything in my last reply?

The difference between the two versions you are using is that I've added "pmSystems awareness" to the PFC driver, so that, if pmSystems is running, the switches that pmSystems controls are routed through pmSystems instead of going direct to FS.

This is the whole purpose of pmSystems -- to handle the subsystems of an aircraft. It can only do that properly if the switches it needs to control are routed through it.

I have no idea what you mean by "corruption", but it sounds like your pmSystems logfic is not using the SYSVARs for the purpose they are assigned in the SYSVAR.TXT. Possibly you have made your own specific pmSystems system?

That's is why I asked, and also listed the SysVar offsets I am affecting.

To answer your questions.....I am flying the 737NG. Behavior described will happen using the MSFS default model. I am using the standard unedited sysvar.txt supplied with pmSystems (most recent release).

And what logic file? The standard 737 one supplied by Enrico or the system enriched one supplied by Thomas Richter? Maybe there's some differences which adversely affect the systems. I must admit that I've been using Thomas's excellent 737 logic files for the last 18 months or so. However, I thought these weren't too far removed from Enrico's, especially in basic things like lights, starters and brakes.

What I mean by backlighting on my CPFlight MCP is that the "NAV" light switch on the PFC console normally will switch that on/off.

Hmm.. I wonder how that is arranged? Naturally, for pmSystems, the NAV light switch operates the NAV light bit in pmSystems. If your pmSystems logic does not handle the lights at all, that may explain that. Or possibly it is just that, before the lights would work without the Battery switch in pmSystems being on, and the relevant electrical subsystem energised? Possibly it is because the correct overhead procedures are needed that the confusion is arising?

Since the sysvar.txt is unedited and remains common in both cases (updated and non-updated PFC.dll), I can't see how it could be related.

Er. I think you profoundly misunderstand something here. SYSVAR.TXT doesn't actually DO anything. It simply defines which offsets and which bits are used for which functions. It is the logic files for the particular aircraft which defines what happens as a result.

Manifestations of the problem: The updated PFC.dll works fine as long as pmSystems is not running. As soon as PMsystems is interfaced (without the hardware and SIMBOARD software running to be sure) it will cause the parking brake switch and NAV light switch on the PFC console not to function (perhaps some others, I have not checked everything).

I am not sure why you insist on repeating yourself so many times. I heard you the first time and actually did give a detailed response in my earlier reply.

But if I put back the old PFC.dll (version 1.90 about a year old is the previous and latest I have) everything functions perfectly!

I know that too and I did explain why. You do not seem to understand much if any of what I have said! :-( :-(

Look, if you want to stick with what PFC.DLL used to do and not make the subsystems work correctly with the PFC switches, I'll add an option into PFC and PFCFSX to totally ignore pmSystems and have nothing whatsoever to do with it, just like version 1.90 did. I honestly don't think that is the right way forward, as the whole point of pmSystems is to force correct procedures in relation to the assorted subsystems, but I cannot see any other way if you do not understand this. By having PFC do its thing always directly to FS, pmSystems cannot influence those aspects of aircraft operation as it is being by-passed.

Look for an update within the next few days. You may need to change an option to make the driver ignore pmSystems.

Pete

[FredK]

Hi Pete -

Again, your prompt attention to this is remarkable and very much apprecated.

To answer your question.....I am using the standard pmsys737.txt logic supplied with pmSystems. Nothing is modifed. I will track down the Richter version to see if that makes any difference.

In any event I will watch for your update. (I did try to add the PMsixpack entry in the PFCini but that had no effect =yes or no).

Thanks again.

Very best regards,

Fred

[Pete Dowson]

I am using the standard pmsys737.txt logic supplied with pmSystems. Nothing is modifed.

Hmm. Sounds like Enrico's version is ignoring the relevant SYSVAR variable settings. That's a bit sad.

Easy enough to fix, though, if you don't want those subsystems handled. You just need to add logic to copy the pmSystems SYSVAR offset changes back to the FS offsets. I would have thought he would do that by default for variables he is not handling. I may need to tackle him about that after Christmas, but it is not a good time now. Sorry.

Meanwhile I'll add the option to bypass pmSystems altogether, as I said.

In any event I will watch for your update. (I did try to add the PMsixpack entry in the PFCini but that had no effect =yes or no).

If you don't have a pair of sixpack annunciators it wouldn't have made any difference in any case. If you did have, the added PFC treatment is simply a superset of Enrico's defaults, but the extras would depend upon parts of the pmSystems logic which are only in Thomas's files in any case.

Regards

Pete

[Pete Dowson]

In any event I will watch for your update. (I did try to add the PMsixpack entry in the PFCini but that had no effect =yes or no).

If you don't have six-pack annunciators being driven by pmSystems that won't make any difference. I only mentioned it as I wasn't sure how your backlighting was controlled.

Versions 2.03 and 4.03 are now available in the Announcements above. The option to disable PFC's cooperation with pmSystems is on the first options page. It defaults to being enabled as it has been that way on all interim versions now for 18 months or so.

Regards

Pete

[FredK]

Hi Pete -

Everything is working fine again for both FS9 and FSX with the 2.03/4.03 drivers you posted today.

Your speedy attention to my problem is very much appreciated.

Very Best Wishes for the Holiday Season!

Fred