GF MCP with PM using FSUIPC

[CBB]

Hi Pete

I hope you can help with the following as I have tried GF but not had any response so far and remember that you use the GF MCP and there may be a workaround with FSUIPC

I have had this issue for some time now and looks like I have boiled it down to a GF problem, as I ran a flight without the GF MCP (just with PM MCP software graphic) and all was fine. I have tested the problem with GF v1.93, 1.95, 2.02 and 2.03 and all have the same issue.

I run the GF FSDEVFSX.exe before a flight (the so-called data bridge). I did not (and never do) run the GFconfig.exe before the flight, the latter has the MCP always set to “Project magenta. The ascent is absolutely fine but problems start on the descent. When I turn the alt knob to a lower alt, the VS did not light up and I then engaged Lvlchg and all ok. Or the VS lit up after I turn the descent knob but I pressed Lvlchg which extinguished the VS and all was ok. Problem starts when VS lights up, I do not extinguish it by pressing Lvlchg and continue reducing the altitude via the Alt knob. In this case the Alt spins up to 50000 of its own free will or goes to 0000. To take control again I have to extinguish the VS display by pressing Lvlchg (and that is difficult to engage, needing several presses) and then reduce the alt. At this stage the whole MCP may freeze and cannot be disengaged.

When I do the same without GF hardware the V/S never lights up and I don't have the above problem. So this seems like a problem with the VS within GF causing a conflict, I have read that V/S has been recently introduced.

If there is not a quick fix within GF, is there a way around this by-passing the GF software and just assigning to PM commands within FSUIPC, I see the PM commands are all there within FSUIPC, but then how do I avoid this causing a conflict with the MCP having been assigned within GFConfig.exe to PM with the above troubles?

Hardware/Software spec:

Server spec

CPU Intel E8600

Motherboard XFX 790i Ultra

Graphics BFG GTX 280 OC

Memory 4GB DDR3 1600

HD 300GB Velociraptor

O/S Vista Basic 64 bit

I have the 3GB switch enabled

Server contents

• FSX + SP1 + SP2 – settings are around medium (water is 1x and very low cars/ships/airport vehicles) and frame rates set at unlimited (I get frames rates of 40+ although at a very detailed airport (eg Heathrow) down to 20)

• FSUIPC 4.703 and WideFS 6.8.6

• Project Magenta MCP 490B and PMsounds

• Goflight Software 2.03 (to work the buttons and switches on the Goflight hardware below incl Goflight MCP)

• Weather – Active Sky Evolution SP2

• ATC - Radar Contact 4

• Scenery - Ground Env Xtreme and Ultimate Terrain X and FSGenesis World Terrain Mesh

• Traffic X

• Airplane – Project Opensky Continental 737-900

Control hardware connected to Server

• Goflight MCP, throttle quadrant and Airliner system

• PFC yoke and pedals

Client 1

Project Magenta Glass Cockpit (PFD) 490A

Client 2

Project Magenta Glass Cockpit (EICAS) 490A

Client 3

Project Magenta CDU 490 – connected to flyengravity CDU hardware

Client 4

Project Magenta PMSystems 182

3 DOF platform software (Motionforsimulators FAST program)

Edited August 24, 2011 by CBB

[CBB]

In the meantime I saw that there may be a workaround using FSUIPC buttons and GFdisplay.lua. I got all the MCPPro buttons programmed for PM in FSUIPC and put GFDisplay.lua is in my modules folder. I read that the GF MCP driver needs to be deleted to avoid conflicts, so I deleted GFMCP2k2.dll and GFMCP2k4.dll and the ifly and Leveld dll's but I left the PM dll. I think leaving the PM dll was wrong because I continued to get the problem above withe the Vs locking everything up (ie some sort of conflict), so I guess I need to delete that too. I am just not sure at present how I get the PM display to show up on the MCPPro (just dashes at the moment), it looks like it is within the MCPpro part of the gfd library but I am being very slow and can't work out how to find that, I'll keep trying until someone shows me the light

[CBB]

I'm completely stuck on finding a Lua that will display the Project Magenta MCP values on the GF MCPpro, the clearest option to me seems the old GFdisplay130 software that Steveo38 developed,a lthough I understand that Pete no longer supports this. Other problem with it is that it does not seem to cater for lighting up the Vnav, LNAV, N1, LvlChg nor V/s lights, not sure why given the MCP Pro has these and PM must have had them at the time. I think I may be able to add that bit in the programming. Unless anyone can point me to a Lua or a better course, I'll try that. I'll also try contacting Steve.

[Pete Dowson]

I hope you can help with the following as I have tried GF but not had any response so far and remember that you use the GF MCP and there may be a workaround with FSUIPC

No, I don't use any GF equipment. All my stuff is PFC except the overhead which is Cockpitsonic. I do, however, have some GF stuff here which was supplied for testing. The GF MCPPro sits here unused at present.

I have had this issue for some time now and looks like I have boiled it down to a GF problem, as I ran a flight without the GF MCP (just with PM MCP software graphic) and all was fine. I have tested the problem with GF v1.93, 1.95, 2.02 and 2.03 and all have the same issue.

Ah. I've never used the GF software at all, only the interface, GFDev.DLL, which FSUIPC and WideClient use to talk to the GF units.

If there is not a quick fix within GF, is there a way around this by-passing the GF software and just assigning to PM commands within FSUIPC, I see the PM commands are all there within FSUIPC, but then how do I avoid this causing a conflict with the MCP having been assigned within GFConfig.exe to PM with the above troubles?

The PM commands in FSUIPC can be assigned to operate PM's MCP. That's not a problem. You can also use FSUIPC or WideClient Lua plug-ins to drive the displays on any GF device. It isn't too hard, but you would need a list of the Project Magenta offsets from which to derive the way to get the information to display. If you do this you cannot also use the GF software. The GF driver does not cooperate with others using the same hardware.

In your second message:

In the meantime I saw that there may be a workaround using FSUIPC buttons and GFdisplay.lua.

No, GFDisplay.lua is only a test program and example of using Lua to drive GoFlight devices. It isn't a flight-time utility. When you start it, it simply does a series of display tests on all your connected GF devices, and then sits responding and displaying button or switch turning details.

You need a Lua program specifically designed to take PM values and modes and use them to set the displays and indicators on the MCP.

I got all the MCPPro buttons programmed for PM in FSUIPC

That's good. That's half the job.

I read that the GF MCP driver needs to be deleted to avoid conflicts, so I deleted GFMCP2k2.dll and GFMCP2k4.dll and the ifly and Leveld dll's but I left the PM dll.

Well, I'm pretty sure the GFMCP2k2.dll must be for FS2002 and GFMCP2k4.dll for FS2004, so I shouldn't think they should both be there in any case. Maybe this was the reason for your original problem, if GF purport to support PM? For a Lua plug-in driver for the MCP you are right to remove both though.

I don't know what Leveld.dll is, but I suspect it's an essential part of a LevelD aircraft systems logic?

If PM.DLL is GF's PM driver, then, yes, you wouldn't want that if you are writing your own Lua plug-in driver.

I think leaving the PM dll was wrong because I continued to get the problem above withe the Vs locking everything up (ie some sort of conflict), so I guess I need to delete that too. I am just not sure at present how I get the PM display to show up on the MCPPro (just dashes at the moment), it looks like it is within the MCPpro part of the gfd library

The "GFD library" in FSUIPC's Lua plug-in support is merely a library of functions which can be used by a Lua plug-in program. The library is a resource, not a companent active in its own right. It knows nothing about any specific GoFlight device, it simply obeys calls from your program to read buttons and write indicators and displays. The GFDisplay lua program was provided as an example.

Regards

Pete

[CBB]

Thanks, Pete. You are right, I have 50% working fine, in that when I turn knobs/press buttons on the MCPPro, it is updating the PM MCP perfectly. The problem is the other way around (getting the displays and lights on the MCPPro), I am trying with GFDisplay 130 because it looked like this was 90% there, although the GFDisplay.INI does not include the MCPPro lights (it does include the MCPBasic ones) such as VNAV, LNAV, N1, FLCH and VS. So I took Steveo38's MCPPro example at the end of the GFDisplay manual and added in these lights (see attached) and I deleted the sections for the other GF devices as I have no issue with those. Problem comes when I run the GFDisplay.exe, it just lets out a ping noise and does not open. I realised that this may be because it is an old program and does not run on Vista which I have on my server (where FSX, Goflight hardware and the PM MCP reside), although my clients each run XP (not sure that helps either as I just rtied running the EXE on one of the clients and got the same ping and no opening). Could you advise if there is a way I can get the EXE to run?

If this route is a no-go, I am down to doing something via a Lua, but the problem here is that I have no idea how to program a LUA, as there. In contrast the GFDisplay manual was very clear and easy to follow the structure for my purpose which seems quite simple. For example, I am not sure how I call on the PM offsets to display the values. Is there somewhere that explains how to program LUas for feedback from PM?

Best

GFdisplay.txt

[Pete Dowson]

Problem comes when I run the GFDisplay.exe, it just lets out a ping noise and does not open. I realised that this may be because it is an old program and does not run on Vista

I'm pretty sure there's nothing stopping it running on Vista. Are you sure it's simply not a case of no installed GFDev.DLL?

[LATER] I just spotted your TXT file attachment. I don't remember much about GFDisplay these days, but that seems to contain a debug log which does eventually show things happening with three devices. What do you expect GFdisplay to "open". It isn't a visual program, it just runs quietly in the background.

If this route is a no-go, I am down to doing something via a Lua, but the problem here is that I have no idea how to program a LUA, as there. In contrast the GFDisplay manual was very clear and easy to follow the structure for my purpose which seems quite simple.

Well the reason I abandoned that in favour of the Lua route was that GFDisplay's parameters are complex and arcane and inflexible, contrasting with the near- English programming capabilities of Lua, its infinite flexibility, and extremely good documentation (available free on the Internet, or in book form if you make a habit of it).

For example, I am not sure how I call on the PM offsets to display the values.

The ipc library contains a range of reads and writes to read and write any type of offset. The Library documentation doesn't only cover the gfd library but also all of those added to FSUIPC and WideClient. There are also lots of Lua examples provided with the Lua package and in the User Contributions subforum. None may do exactly what you want, but will certainly show sufficiently appropriate examples you can adapt. On top of that, when trying you can ask specific questions here and i or others will answer. I'm only against writing the whole thing for folks -- I prefer to help them write their own.

Is there somewhere that explains how to program LUas for feedback from PM?

Not specifically, because that's one possible application out of an almost infinite number. Lua is too flexible to provide examples of everything it can do. You need to adapt from other examples or just try things. It's worth it in the end as you find other things you'd like to be able to do.

Regards

Pete

[CBB]

Thanks again. Before I go the Lua route - which I get a rough idea of having looked at some examples but will need much more time to learn to program what I am trying to do - this is not a problem but given I feel I am so close on the solution with GFDisplay, I just want to be sure I can't use that first before switching to the Lua route for this particular problem. When I run the GFDisplay.exe nothing shows up in my winows taskbar and I can't see anything in the task manager, I just get a ping when I double-click on it and that's it (both with Vista and XP and running as administrator too). I have GFDev.dll in my FSX modules folder and the MCPPro is changing the values on the PM MCP perfectly.

The Debug code in the ini file I sent was what was in the original ini file. All I did was delete all the device sections and put in Steve08's MCPPro section with my modification for the missing lights.

Best

[Pete Dowson]

The Debug code in the ini file I sent was what was in the original ini file. All I did was delete all the device sections and put in Steve08's MCPPro section with my modification for the missing lights.

So, is this from the original file?

[GF Connections]

GFDev=DLL found

GF45=1

GFLGT=1

GFMCP=1

GFRP48=1

because this also seems to show it ran okay, at least insofar as recognising those device connections?

If they are from the original file, please delete that section AND the debug section and try again.

[LATER]

I've just tried running GFDisplay with your GFDisplay.txt (renamed as INI) and it loads okay. But if I remove GFDev.DLL it does exactly the same as yours. I'm positive this is the reason. I know you said you thought it was finding it, but I don't think so. You are probably being miseld by the old lines from the INI file you copied.

You simply need to copy GFDev.DLL into the same folder.

BTW, I just looked at the GFDisplay ZIP I provided, and the example GFDisplay.INI in there contains PM support for the GFMCP including all the displays. I'm sure adding the extra bits for the Pro wouldn't have been too hard. Trouble is I don't remember much of it now! ;-)

Regards

Pete

[CBB]

Pete, I am an idiot. I had GFDev.dll in my FSX modules folder but did not put it in my GFDisplay folder, Doh :oops: , sorry about this I should have known that as I have that file in each of my Wideclients for the same reason, I'll try that in the morning.

As for the INI file I have now deleted the entire [connections] and [Debug] sections, is that ok?

Yes, your MCP bit was VERY easy to adapt for the extra lights, it was v well explained (well I haven't tested it though)...I'l let you know results

MANY thanks

[CBB]

Hi Pete, GF Display is working very well now :rolleyes: with the MCPPro. One thing that does not seem right is that my V/S is not displaying the PM V/S properly but just as 88.880. I have attached the INI, is this something in the formula on the following line?

D4.2=C0 !C47 X4E6 S16 *100 D-40 ; PM's VS as (-)nnnn

The only other thing I noticed (which I'll keep an eye on) is that when I selected VNAV or LNAV on the MCPPro with FSUIPC open, sometimes it would come up as one button number (eg VNAV came up as joy 157, button 20) and other times as another (eg 157, 4 or 157, 7). Then there was a moment when it would select other button numbers without my pressing anything, including VS which may be why I had the VS problem originally! Is this a static elec problem or something else (eg a conflict)?

[Pete Dowson]

One thing that does not seem right is that my V/S is not displaying the PM V/S properly but just as 88.880. I have attached the INI, is this something in the formula on the following line?

D4.2=C0 !C47 X4E6 S16 *100 D-40 ; PM's VS as (-)nnnn

That appears to be the same as the one in the file I provided in the GFDisplay ZIP, so I assume it should be okay -- for a Boeing. For an Airbus that offset contains the FCU's FPA value, it seems (going by PM offsets lists on their website.

I don't see how it can produce 88.880 when I think the D-40 says it must be 4 digits, no decimal, and signed. Something else must be displaying the 88.880 and overwriting it. Check there's nothing else addressing D4 in the INI, and also that no other program, like GF's own, is writing to the MCP.

The only other thing I noticed (which I'll keep an eye on) is that when I selected VNAV or LNAV on the MCPPro with FSUIPC open, sometimes it would come up as one button number (eg VNAV came up as joy 157, button 20) and other times as another (eg 157, 4 or 157, 7). Then there was a moment when it would select other button numbers without my pressing anything, including VS which may be why I had the VS problem originally! Is this a static elec problem or something else (eg a conflict)?

Sounds like some sort of jitter or shorting on one or other of the rotaries. I don't know which switches correspond to which, but each rotary will have 4 button numbers assigned. Find out which is doing it and give it some rapid turns to try to clean it, or use a switch cleaner.

Pete

[CBB]

There definitely seems to be something else writing to the MCPPro.

Check there's nothing else addressing D4 in the INI

The only lines addressing D4 are as follows which look ok:

D4.1=C0 C47 "" ; PM blank VS

D4.2=C0 !C47 X4E6 S16 *100 D-40 ; PM's VS as (-)nnnn

D4.3=!C0 X7F2 S16 D-40 ; FS's VS as (-)nnnn

This would point to something else from GF interfering:

I deleted GFMCP2k2.dll and GFMCP2k4.dll and the ifly and Leveld dll's and the PM dll (FSDevFSX.dll, the GF data bridge, still runs as I need it for the other GF equipment, maybe this is still the problem), however there still seem to be conflicts, something seems to be trying to take control of the MCPPro. For example, the VS still lights up with a reading 88.888 and the MCP speed does not always initialise on the 240 as set in the PM MCP.ini but goes to a different number. I also had the speed spinning uncontrollably to different numbers when I tried to change it while the VS display of 88.888 was showing, it works ok if the VS display is blanked

(Btw, when I say I deleted GFMCP2k2.dll , etc I still have them in another folder, but not in my Goflight folder, not sure if that is an issue).

I am also pushing GF support but response is very slow. If there is a way of shutting down the interferer that should resolve the problem. I guess I could try closing FSDEVFSX.dll and see if that cures the MCP. Then I could try programming the other GF displays, as the only important ones are Gear Down lights, NAV1 and NAV2 radios, Transponder - [Later] looks like you already programmed those in the GFDisplay.ini, so even better!!

[Pete Dowson]

I deleted GFMCP2k2.dll and GFMCP2k4.dll and the ifly and Leveld dll's and the PM dll (FSDevFSX.dll, the GF data bridge, still runs as I need it for the other GF equipment, maybe this is still the problem), however there still seem to be conflicts, something seems to be trying to take control of the MCPPro.

I don't understand why GFMCP2k2.dll and GFMCP2k4.dll are installed in the first place if you are using FSX. Aren't those for FS2002 and FS2004 respectively? Are you sure FSDevFSX.dll doesn't control everything for FSX, the others being irrelevant? You probably need to use GFConfig to tell FSDevFSX not to do anything with the MCP?

Are the Leveld and PM DLLs specific GF drivers?

Sorry if I am getting things wrong. I really don't know anything about GF's own software, I only use their GFDev.DLL.

I am also pushing GF support but response is very slow. If there is a way of shutting down the interferer that should resolve the problem. I guess I could try closing FSDEVFSX.dll and see if that cures the MCP.

Well at least you'd know then.

Then I could try programming the other GF displays, as the only important ones are Gear Down lights, NAV1 and NAV2 radios, Transponder - [Later] looks like you already programmed those in the GFDisplay.ini, so even better!!

Maybe you can be selective in any case if GFConfig allows you to be so.

Regards

Pete