PFC Cirrus 2 Pro not recognized

[jimbooo]

I have PFC Cirrus Pro 2 USB console and radio stacks. All work in XPlane 11 and all switches and axes are functional in the PFC test program.

I have purchased FSUIPC7 and Wide FS and have installed properly.  i see the splash screen when I start and can access FSUIPC via the shortcut (Alt F).

Per the Manual instructions I have downloaded PPFChid64.dll and have placed in the FSUIPC7 folder.

The manual says that I should see that program under the "add-ons" menu in order to activate it.

I DO NOT see it and therefore I cant get anything to work.  I see my PFC equipment show up in the Microsoft window but nothing works (of course)

A couple yoke buttons do show but no axes show up.    Any ideas ????

[Pete Dowson]

10 hours ago, jimbooo said:

I have PFC Cirrus Pro 2 USB console and radio stacks. All work in XPlane 11 and all switches and axes are functional in the PFC test program.

I have purchased FSUIPC7 and Wide FS and have installed properly.  i see the splash screen when I start and can access FSUIPC via the shortcut (Alt F).

Per the Manual instructions I have downloaded PPFChid64.dll and have placed in the FSUIPC7 folder.

I don't know the Pro 2, so couldn't swear that all of its switches and functions are supported in the PFChid driver. Do PFC supply a driver for XPlane? I know they changed focus to XPlane, away from MS, some time back.

10 hours ago, jimbooo said:

The manual says that I should see that program under the "add-ons" menu in order to activate it.

Which manual is that? The manual supplied with PFChid certainly doesn't. It will be loaded and run by FSUIPC automatically after the Sim is in a "ready to fly" state.

10 hours ago, jimbooo said:

I DO NOT see it and therefore I cant get anything to work.  I see my PFC equipment show up in the Microsoft window but nothing works (of course)

A couple yoke buttons do show but no axes show up.

On the Cirrus I seem to remember that the Yoke is a normal joystick device and seen by Windows and the Sim, not needing any attention from a driver. The rest of the functions on the Cirrus do need a registered FSUIPC and then you can assign switches and quadrant levers as desired.

A log is produced (PFChid64.LOG) when the driver starts. This will be is the same folder -- check for it.

Pete

 

[jimbooo]

I guess my PFC is actually just named Cirrus Pro - so its likely the same one you are familiar with.   It integrates with XPlane seamlessly with their supplied software.  PFC is definitely NOT encouraging use in MSFS.  I have chatted with them repeatedly.

According to them the Yoke is NOT seen as a joystick device.  They have an add on from a German company that actuates the servos attached to the yoke so the feedback is proper to the planes dynamic forces.  You can feel the pressure on the ailerons and elevator during takeoff especially.

Since yesterday i have experimented and finally got the 6 throttle quadrant levers to show in the FSUIP window - and the switches on the main panel AND on the yoke now respond properly.

Only the yoke itself does not show.    Obviously if I cant get that working I will not be able to use the Cirrus console.   It works so well in XPlane I was hoping to get this working.

I had a serial PFC console years ago and used a previous FSUIPC with that and it worked very well back in the MS 2004 version !!

Is it unusual that the PFChid dll does not show in my "add-ons" menu ??  It is installed properly in the FSUIPC folder ??  

I believe there are some PFC Cirrus users that do have the yoke working in MSFS - are you out there ??

Thanks for the quick response, Pete - anything else I should be exploring ???

[jimbooo]

ps     I was sure that I saw somewhere in your Manual that the PFC dll file should be listed under "add-ons"

On page 11 under the add-ons heading here is the text i copied:

"The Add-ons menu item will only be displayed when one or more compatible add-ons are found when FSUIPC7 is started. This menu can include (amongst others) a menu entry to access the PFCcom64 user interface (when the PFCcom64.dll is located in the FSUIPC7 installation folder), and a menu entry for the WebSocket server (provided by Paul Henty and included in the FSUIPC7 installer). 1

[jimbooo]

pssss:   I do have a registered paid for version of FSUIP7

[John Dowson]

The PFC menu will only be added once you have an aircraft loaded and ready-to-fly, at the time the connection check dialog is displayed.  If you check your FSUIPC7.log file, you will also see the following message when it is loaded (i.e. when FSUIPC7 is started, not when the menu entry is added):
         1016 Loaded PFCcom64.DLL okay!

However, if your device is recognised without this, then you (obviously) don't need it.

If the switches on the yoke are recognised, then so should the yoke itself. Do you see anything registered at all in the axis assignment dialog when you move the yoke? Note that if you see another axis, registered, you can click the Ignore button to ignore that for the rest of the time the axis assignment dialog window is open.

If you still have issues, please attach your FSUIPC7.ini and FSUIPC7.log files.

John
 

[jimbooo]

i will try your suggestions later tonite - thank you again for the help !

i have already tried to get the yoke motions to register with no success yet.   

i will check for the 1016 entry in the log as you requested and reply with the .ini and ,log files if I still have  no success.

[jimbooo]

Heres the outcome of the experiments you suggested:
1. "Log file 1016 Loaded PCFhid64.dll okay"   - not showing in the .log file  / I have the Cirrus II USB so I have the hid file in the FSUIPC folder not the com file.
2. The yoke program that PFC is using to provide feedback on the yoke servos is:  CLS2 Sim v4.14 from Brunner Elektronic AG.   I purchased the Cirrus console earlier this year.  This may be a new method PFC has for their newer Cirrus consoles - the servos are very good at providing tactile feedback on the yoke.    This should not affect the actual console buttons and switches - which also do not show in the FSUIPC assignment windows.
3. The yoke switches and console switches all show and register in the PFC GUI test program but the yoke motion does not show ??  I have a call into PFC support to see where the yoke motion would be shown (this may be my problem but everything works fine in XPlane). 
4. I loaded the C172 / started plane positioned at the runway running and ready to fly.  Used Alt F to get the FSUIPC window: 
a) Tried Button and Switch Assign - pressed yoke buttons and they registered OK - no console buttons or switches registered - could not get any console events to register.
b) Tried Axis Assign / Axes Assign and all 6 throttle quadrant axes registered
c) Tried Joystick Calib and no yoke motion registered / I have non PFC Rudder pedals and they registered OK.
Started AI flight and it crashed after takeoff - Closed sim and copied .ini and .log files (attached)
I see alot of "Macros not found" entries in the .log file - Is this my problem ???  No console buttons or switches seem to register anywhere in addition to the yoke movements.  Im assuming the Macros are necessary to connect the console ??
Ill report on the response i get from PFC support once i get the callback

[jimbooo]

Heres the latest.

Got word from PFC that the yoke program from Brunner actually has a driver for MSFS !!!

They told me how to install it so I will do that tonite and see if the yoke begins to magically workk !!! 

Still doesnt answer why all the Macros dont load but maybe this will fix the yoke problem.

[John Dowson]

13 hours ago, jimbooo said:

1. "Log file 1016 Loaded PCFhid64.dll okay"   - not showing in the .log file  / I have the Cirrus II USB so I have the hid file in the FSUIPC folder not the com file.

If Loaded PCFhid64.dll  does not show in your log, then the dll  is either not in the correct location, or you are using an older version that is not supported by FSUIPC7.  I have attached the latest version, just in case: 

PFChid64.dll

However, as I keep saying, if your device is recognosed (you can assign to buttons on this device, so it is recognised), then you do not need it.

13 hours ago, jimbooo said:

2. The yoke program that PFC is using to provide feedback on the yoke servos is:  CLS2 Sim v4.14 from Brunner Elektronic AG.   I purchased the Cirrus console earlier this year.  This may be a new method PFC has for their newer Cirrus consoles - the servos are very good at providing tactile feedback on the yoke.    This should not affect the actual console buttons and switches - which also do not show in the FSUIPC assignment windows

Again, this implies you don't need the PFC/FSUIPC driver dll.

13 hours ago, jimbooo said:

3. The yoke switches and console switches all show and register in the PFC GUI test program but the yoke motion does not show ??  I have a call into PFC support to see where the yoke motion would be shown (this may be my problem but everything works fine in XPlane). 

Then this would imply that something else is needed from PFC for the yoke motion, if their own test program doesn't even recognise it....

13 hours ago, jimbooo said:

a) Tried Button and Switch Assign - pressed yoke buttons and they registered OK - no console buttons or switches registered - could not get any console events to register.

What console buttons? Is this on the same device, or a different device or the same one?

13 hours ago, jimbooo said:

Started AI flight and it crashed after takeoff - Closed sim and copied .ini and .log files (attached)
I see alot of "Macros not found" entries in the .log file - Is this my problem ???  No console buttons or switches seem to register anywhere in addition to the yoke movements.  Im assuming the Macros are necessary to connect the console ??

No log or ini files attached. Have you assigned to any macros? Do you have any in your installation folder?
I do not understand this without seeing those files...

10 hours ago, jimbooo said:

Got word from PFC that the yoke program from Brunner actually has a driver for MSFS !!!

Ok.

10 hours ago, jimbooo said:

Still doesnt answer why all the Macros dont load but maybe this will fix the yoke problem.

Macros have nothing to do with devuce/controller recognition, so will not be related to your yoke recognition issue.

John

[jimbooo]

Im getting the latest software update from Brunner for the yoke controller so we should set aside that problem until i sort out that update. h

however

I installed the dll file you sent although i think the one i had was current (5.1.4.1).  I put into the main FSUIPC folder as instructed.

Started sim and got in plane ready to fly - running on runway ready to take off.

Got to FSUIPCC by Alt F

yoke of course still is not recognized - 

the only buttons that register are B3, B4 and rocker switch B0 and B2 / these switches are on the yoke.

On the console (Cirrus II Professional) nothing registers - likewise the 

PFC radio stack nothing registers and the entire unit is dark. 

Under ""Axes Assign" all 6 Throttle-Prop-Mixture axes register properly as do the Thrustmaster rudder pedals.

nothing else registers anywhere.

I thought i attached the .log and .ini files on a previous note but im re-doing the attachment here.

Maybe those files will help

Thanks Again for the help...

PFChid64.log PFChid64.ini

[jimbooo]

thought it might be helpful for you to see the cockpit.   The Light Grey central unit with the yoke is the PFC C2 Professional.  Its what im calling the "console"

to the left of the console is the PFC radio stack.  this contains 2 nav coms, audio panel, transponder, ADF and DME.

On the right is the Real sim Gear Garmin 650/750 and autopilot.

Thee rudder pedals are from Thrustmaster and operate on a joystick axis - so pose no issues.

[Pete Dowson]

Your log shows a regular attempt to open the PFC.MCRO file, which is listed as the default file for FSUIPC macros.  Try creating a small macro file containing just: this one line

[Macros]

and save it in the same folder as PFChid64.dll.

I'm not sure why that log entry occurs as Macros are only used to override a default action taken on specific switches and buttons. The method of doing this is detailed in the user guide supplied.

To work out why some buttons and switches aren't working, edit the PFChid64.ini file changing these lines:

LogDecode=Yes
LogIPCwrites=Yes
LogMacroNames=Yes

Then run the system and operate each button, switch or knob once. The log produced should then show what is actually recognised, and what action it assumes is needed.

It may help you to set Console=Yes as well, so you can see on screen the results in real time.

Pete

 

[jimbooo]

i will try your suggestion later today -

Im not sure how to create a small Macro file ??

can you explain please

i think i understand the rest of your suggestions

 

thanks

[John Dowson]

14 hours ago, jimbooo said:

Im not sure how to create a small Macro file ??

Create a text file, rename it to  PFC.MCRO, open it in an editor an add the line:
    [Macros]

    

[jimbooo]

I have done as you requested.

Created text file PFC.MCRO and put it in the FSUIPC folder.  I have attached it here so you can make sure I did it properly.

I edited the .ini file as you suggested. I also attached that for you to see.

Upon opening MSFS the "console" display screen opens and displays all the inputs that are read from my PFC Cirrus2 Pro.   I hit every button, knob and vernier as suggested  and it appears that all the switches,, buttons, knobs and throttles are properly read. I have attached the .log file for you to see.

When i close the "console" screen apparently displaying the .log file in real time I can no longer use the AltF to see my assignment screen ?

I will be updating the drivers later today for the Brunner yoke which may solve the problem of FSUIPC not reading any yoke movements.  

Not sure what i should do now ?   Should I go back to the original .ini file ? - I will need to have AltF working to take the next steps for assigning inputs.   ??

Thanks Again for spending the time with me to get this working....

 

ps   opening splash screen shows Web serv. are "stopped"  When i hit "start" a message says ""failed to listen to prefix http://local host: 2048/fsuipc/'because it conflicts with an existing registration on the machine".

This has never shown before ??

PFChid64.log PFChid64.ini PFC.MCRO.txt

[jimbooo]

finally got AltF to work again

but

nothing shows under any of the assignment options ??

[Pete Dowson]

15 hours ago, jimbooo said:

Created text file PFC.MCRO and put it in the FSUIPC folder.  I have attached it here so you can make sure I did it properly.

Must have been okay as there are no errors for it logged.

15 hours ago, jimbooo said:

I edited the .ini file as you suggested. I also attached that for you to see.

Upon opening MSFS the "console" display screen opens and displays all the inputs that are read from my PFC Cirrus2 Pro.   I hit every button, knob and vernier as suggested  and it appears that all the switches,, buttons, knobs and throttles are properly read. I have attached the .log file for you to see.

Yes, they all appear to be doing the correct thing. They operate the Sim via FSUIPC offsets, and the latter should work. They don't need assigning in FSUIPC, so you won't see them there.

Did none of them actually do what they are intended to do, in the MSFS cockpit? The offsets look correct, but they'll be the ones which work in FSX and P3D. It is possible that some aren't implemented in MSFS -- or just aren't present in whatever aircraft you have loaded.

I'll have to leave that latter check to John, but you'll need to state the aircraft in use, and double-check that they don't work. I can see some which would be common to all aircraft -- eg the battery switch.

If any of the offsets have changed then you'll need overriding macros added to PFC.mcro. If you are using a complex add-on aircraft such as those from PMDG then I suspect they will all need overrides, to use the special controls added by PMDG for their aircraft.

For wholesale changes it might be easier to use as set of overrides which operate FSUIPC's "virtual buttons". Then you could do the real assignments in FSUIPC.

Pete

 

[Pete Dowson]

It also occurs to me that many offset changes, such as those instigated by the PFC driver as a result of you operating switches, will cause it to send Events ("controls") to MSFS. So, you could enable non-axis Event logging in FSUIPC's Logging tab, and check the FSUIPC7.LOG file after operating your switches etc.

Pete

 

[John Dowson]

1 hour ago, Pete Dowson said:

Must have been okay as there are no errors for it logged.

Yes there are:

    76141: Macros not found: "C:\FSUIPC7\PFC.mcro"
The OP attached a file named PFC.MCRO.txt - he needs to remove the .txt extension  - but is it really an issue if this empty macro file cannot be ran?

1 hour ago, Pete Dowson said:

Did none of them actually do what they are intended to do, in the MSFS cockpit? The offsets look correct, but they'll be the ones which work in FSX and P3D. It is possible that some aren't implemented in MSFS -- or just aren't present in whatever aircraft you have loaded.

I'll have to leave that latter check to John, but you'll need to state the aircraft in use, and double-check that they don't work. I can see some which would be common to all aircraft -- eg the battery switch.

What offsets are being used, and for what- (where is this info? The PFChid64.log shows some macro's being called in PFC.mcro (which is empty!):
    76235: Full macroname for decoded switch = "PFC:LandingLight", mask = X00000000
...
    76375: Full macroname for decoded switch = "PFC:Obs1", mask = X00000000
...
    76391: Full macroname for decoded switch = "PFC:CRSencode", mask = X00000000
etc

I am not sure what those are and why they don't have an error if the PFC.mcro can't be found...maybe Pete could explain?
 

1 hour ago, Pete Dowson said:

It also occurs to me that many offset changes, such as those instigated by the PFC driver as a result of you operating switches, will cause it to send Events ("controls") to MSFS. So, you could enable non-axis Event logging in FSUIPC's Logging tab, and check the FSUIPC7.LOG file after operating your switches etc.

That is a good idea - and please attach your FSUIPC7.log file as well.

John

[Pete Dowson]

1 hour ago, John Dowson said:

Yes there are:

    76141: Macros not found: "C:\FSUIPC7\PFC.mcro"
The OP attached a file named PFC.MCRO.txt - he needs to remove the .txt extension  - but is it really an issue if this empty macro file cannot be ran?

No, there's no issue other that creating a growing log as it retries. There were so many other entries now that I hadn't noticed that error repeating every few seconds, so widely spaced.

1 hour ago, John Dowson said:

What offsets are being used, and for what- (where is this info? The PFChid64.log shows some macro's being called in PFC.mcro (which is empty!):
    76235: Full macroname for decoded switch = "PFC:LandingLight", mask = X00000000

Interesting -- not sure what happened to the IPCwrite line for that particular switch, but most are like this:

    76375: Full macroname for decoded switch = "PFC:Obs1", mask = X00000000
    76375: ... IPCwrite 0C4E[2] = 1, 0x1
The IPCwrite line shows the offset (0C4E in this case), the size (2 bytes, i.e 16-bit), and the value, in decimal and hex.

I think it might be better for the OP to change these lines in the INI

LogDevices=No
LogDeviceChanges=No

to avoid clouding the issue with all that Device information.

If the LandingLight switch still shows no offset I'll need to look at the source to see what it thinks it is doing. This line is also a little odd:

    76156: ... IPCwrite 0000[16] = -1655080864, 0x9D597860

The 16 bytes at offset 0000 are marked in my list as "Reserved for diagnostics". I've a vague feeling I used a mechism here to allow by to test paths through the driver without the requisite hardware attached.

Seeing that these two odd lines are right at the start I'm thinking they were somehow before the driver thought it was okay to write to offsets. I don't see any other recognised switches without accompanying IPC write lines -- more than one such in some cases.

1 hour ago, John Dowson said:

I am not sure what those are and why they don't have an error if the PFC.mcro can't be found...maybe Pete could explain?
 

An entry in the MCRO file is merely used to override the default action. By default most, if not all, switches on a Cirrus do have actions programmed into the driver, mostly via offsets (maybe all, I don't remember.

The logging of the full macroname just shows the macro which would have been executed if one was present in the mcro file  The driver would send the request via offsets (0D70 etc). If there isn't one, it does it more directly as stated.

It also handily shows what  function the operated switch is recognised as performing.

Hope things are clearer for you now?

 

[John Dowson]

4 minutes ago, Pete Dowson said:

An entry in the MCRO file is merely used to override the default action. By default most, if not all, switches on a Cirrus do have actions programmed into the driver, mostly via offsets (maybe all, I don't remember.

The logging of the full macroname just shows the macro which would have been executed if one was present in the mcro file  The driver would send the request via offsets (0D70 etc). If there isn't one, it does it more directly as stated.

It also handily shows what  function the operated switch is recognised as performing.

Hope things are clearer for you now?

Yes, thanks - that explains it. I can maybe check what offsets are being used (from the PFC  log) and can see if they are working for the aircraft being used if @jimbooo could attach an FSUIPC7.log file, together with a PFChid.log file, both generated with the logging changes that you have already suggested.

John

[Pete Dowson]

1 minute ago, John Dowson said:

Yes, thanks - that explains it.

Good. I also see why the first LandingLight switch operation didn't send and IPCwrite. It's a toggle action on a bit in 0D0C. So the driver would read it first to send the toggled result back -- it must have already been set correctly. Later there's this:

   223750: Full macroname for decoded switch = "PFC:LandingLight", mask = X00000000
   223750: ... IPCwrite 0D0C[2] = 1015, 0x3F7

to toggle it the other way.

 

 

[John Dowson]

2 minutes ago, Pete Dowson said:

It's a toggle action on a bit in 0D0C. So the driver would read it first to send the toggled result back -- it must have already been set correctly. Later there's this:

   223750: Full macroname for decoded switch = "PFC:LandingLight", mask = X00000000
   223750: ... IPCwrite 0D0C[2] = 1015, 0x3F7

to toggle it the other way.

That makes sense, and that will trigger the event LANDING_LIGHTS_TOGGLE - this event should work in most default aircraft (but maybe not all), and some add-ons but certainly not all of them. It certainly works in the C172, as does writing 0x3F7 to 0x0D0C, which results in: taxi lights off, beacon, landing, nav and strobe lights on (as well as others, which the C172 doesn't actually have) . 0x3F7 = 001111110111 so that is as expected (bit 3 is 0 so Taxi off).

John

[Pete Dowson]

6 minutes ago, John Dowson said:

0x3F7 = 001111110111 so that is as expected (bit 3 is 0 so Taxi off).

The log entries following the one I showed are:

   224094: Device #1 received: LandingLight[0] = 0
   224094: Full macroname for decoded switch = "PFC:LandingLight", mask = X00000000
   224094: ... IPCwrite 0D0C[2] = 1011, 0x3F3

So it is only bit 2 changing.