PM MCP problem

[BrunoBL]

Hi Pete,

I am using a registered FSUIPC 3.411 and WideFS 6.41, and I am having a bit of trouble with PM MCP (demo version). After a few email exchanges with Jonathan and Enrico, PM suggested that I post this here.

I am scratch-building a 737 MCP. For test purposes I initially used only the default FS2004 737, and assigned the MCP functions (via FSUIPC dialog facilities) to the default (not PM) 737 autopilot functions. Everything worked fine except, of course, the more involved MCP logic such as LVL CHG which Microsoft did not implement on its autopilot. So far, so good: my hardware panel exactly replicates the default 737 autopilot panel.

Being satisfied that my wiring and connections were OK, I decided to use PM's MCP to control my panel and changed my assigments accordingly (from default Microsoft autopilot to PM MCP commands). This is when the strange MCP behavior started. All MCP push buttons (N1, VOR/LOC, etc) work as expected, but the rotary switches "stick" once they are moved. That is, if I touch a rotary switch then its value keeps increasing (or decreasing) forever until I change direction again with the rotary switch. It then changes forever in this new direction, etc.

At first both Jonathan and Enrico thought that this was a keyboard encoder problem (I am using Hagstrom) but I completely removed the encoder, deleted FSUIPC.INI, restarted everything and reassigned the rotary functions (PM MCP SPD INC and DEC, for example) to two joystick buttons and, indeed, the problem persisted.

So far I have detected the following: If I run the PM MCP demo in the same machine as FS2004, then I have no problem whatsoever (with or without the keyboard encoder). With the MCP demo in a remote computer, I can command PM MCP SPD INC or DEC via that PC's keyboard, but if I touch an INC or DEC joystick button the problem reappears (in effect disabling even the keyboard command). My original MCP rotary swithes were not assigned to joystick buttons but rather to keypresses (via the Hagstrom encoder), but PM suggested that I change them to joystick buttons instead. I did (I am actually pressing buttons on a real joystick for the tests), but that did not fix the problem, so I presume the trouble is not encoder-related, or even keypress-related.

The network seems to be OK, I routinely run PM Glass Cockpit in the remote PC with no problem at all.

I am about to give up and settle for running the MCP software locally in the FS2004 machine (which I would very much rather avoid).

Have you seen anything like this? Do you have an idea of what may be wrong?

Best regards,

Bruno.

[Pete Dowson]

I am using a registered FSUIPC 3.411 and WideFS 6.41

One thing to check before anything else. You say you are using WideFS 6.41, but are you absolutely certain you are using both WideClient and WideServer 6.41? If you've just changed the Server and not the Client then this may be the problem -- the "WriteLocalDirect=No" parameter is used in WideClient 6.40 which was found to give strange problems like this, which was why it was scrapped in 6.401.

Also, I assume you've not changed any of the default WideFs performance related parameters in their INI files?

So far I have detected the following: If I run the PM MCP demo in the same machine as FS2004, then I have no problem whatsoever (with or without the keyboard encoder). With the MCP demo in a remote computer, I can command PM MCP SPD INC or DEC via that PC's keyboard

This certainly sounds like the problem is an older WideClient.

I have just this moment programmed two buttons in FSUIPC, operated on a remote PC, to the PM MCP SPD INC and PM MCP SPD DEC controls, and they work fine. My PM MCP is running on the same PC as FS, unlike yours.

So, I also tried running FS on another PC and having WideFS linked to the PM MCP on my erstwhile FS PC. I've programmed joystick buttons on the now-FS PC and on the now-only MCP PC, and in both cases they worked flawlessly.

I don't think it is either FSUIPC or WideFS. I hate to do this, but if it is not some simple error you've made, like not updating WideClient, or changing some of the performance parameters, I think it is back to Project Magenta support -- I don't know what restrictions or differences the "Demo" versions of PM make, but possibly there's a problem with them? There have been problems with the FSUIPC offsets interface into PM from time to time, maybe the Demo is build on a version with such problems?

BTW If you want to check the operation of WideFS/FSUIPC in commanding PM, simply use the FSUIPC Monitor facility -- on the Logging page. You'll need this information from PM's documents page (pm FSUIPC offsets):

offset 5418

MCP/FCU Knobs/Selectors S00-31 (Read/Write)

DH- Bit0 (10)

DH+ Bit1 (10)

HDG- Bit2 (1)

HDG+ Bit3 (1)

HDG- Bit4 (10)

HDG+ Bit5 (10)

ALT- Bit6 (100)

ALT+ Bit7 (100)

ALT- Bit8 (1000)

ALT+ Bit9 (1000)

SPD- Bit10 (1) (mach .01)

SPD+ Bit11 (1) (mach .01)

SPD- Bit12 (10) (mach .01)

SPD+ Bit13 (10) (mach .01)

VS- Bit14 (100)

VS+ Bit15 (100)

CRS- Bit16 (1)

CRS+ Bit17 (1)

QNH- Bit18 (0.01/1 depending on mode)

QNH+ Bit19 (0.01/1 depending on mode)

CRNG- Bit20 (Captain ND range -)

CRNG+ Bit21 (Captain ND range +)

CNDM- Bit22 (Captain ND mode -)

CNDM- Bit23 (Captain ND mode +)

FRNG- Bit24 (F/O ND range -)

FRNG+ Bit25 (F/O ND range +)

FNDM- Bit26 (F/O ND mode -)

FNDM- Bit27 (F/O ND mode +)

For external programs, set to one, when it applies, reset to 0 by the MCP.

If you set FSUIPC to monitor offset 5418 as a U32, in Hex, and have it display to the adv display on screen (the easiest in this case) you will see, for example:

Press PM MCP SPD INC: 5418 changes from 0x0 to 0x800 (bit 11) momentarily, then back to 0x0 -- this is FSUIPC setting the bit and PM's MCP clearing it when it has incremented the Speed.

Maybe there is a bug in the Demo version which is causing the bit not to be cleared. However, that wouldn't explain why you get it working okay when pressing a button on the FS PC. Version 6.40 of WideClient may do, though.

There's no difference as far as FSUIPC button programing is concerned where the button is coming from.

I am about to give up and settle for running the MCP software locally in the FS2004 machine (which I would very much rather avoid).

Well, it isn't solving the original problem, but I must say that I run the PM MCP in the FS PC because I believe that gives the best performance -- the autopilot control needs the quickest feedback, and even the slight amount of latency you get across a network could be a little damaging. With a P4 with hyperthreading as the FS PC FS itself seems to be only using 50% of the capacity in any case.

Have you seen anything like this? Do you have an idea of what may be wrong?

No, but then I'm using current releases of PM modules.

Regards,

Pete

[BrunoBL]

Pete,

This is the beauty of talking to who knows. You've pretty much seen it all. No matter what mistakes your users keep repeating (this one at least!), there is a good chance you've either seen it before or have the resources to infer what the problem is.

Just as you predicted, despite updating WideServer in the FS machine I failed to update WideClient on one of the four machines in my network. Exactly the one in which I tried running PM's MCP demo! To further complicate diagnosis, PM Glass Cockpit (runs in that machine too) did not complain or misbehave in any way, so I only noticed something wrong when trying the demo program. All is running fine now.

Thanks again for the great software and great support.

Best regards,

Bruno.