PFC Cirrus 2 Pro not recognized

[jimbooo]

ps       all the radio stack knobs and switches also work in the cockpit !!!

now we just need to find a way to light it !!!

[Pete Dowson]

16 hours ago, jimbooo said:

Now all the input changes seem to be active BUT the stack is still dark ?

All the displays are backlit digital numerals and the entire stack is unlit.

I was afraid that might be the case. The decoding of the switches is, as PFC told me, the same as for the original Avionics -- just arriving from different devices which I needed to open in my code.

The output to the displays is, however, obviously another matter. They probably need explicitly directing to the correct device. That is not so easy (especially, for instance, for the 4 comm radios which look identical to the software at present.

16 hours ago, jimbooo said:

seems like we are close to success here  -  any ideas ?

I don't know. I'd need to delve into the code much more deeply. I may pluck up courage and look at that, but not this week. One thing may help me: please try again but first set the LogTxData parameter in the PFChid64.ini file to "Yes". This might show me where and what is actually being sent to the displays and indicators -- probably mis-addressed.

Unfortunately the code was written many years ago and I don't remember it. (Old age wrecks memory). 😞

So, sorry, no guarantees. I'll let you know if I find something for you to try. Meanwhile, do the switches and dials do what you expect on the model within MSFS? I see that the FSUIPC log shows the appropriate commands being sent.

Pete

 

 

[jimbooo]

yes    the commands sent that register in the live log have the correct effect in the MSFS cockpit.   the radio knobs change the frequencies, the swap button operates properly ,the transponder codes change correctly.  i  think that part of the code is amazingly correct.

only the backlighting is off....

even though PFC is adamant about not supporting MSFS i think they keep a lid on that so they dont have to do any support for any interfaces like FSUIPC.     Your program works so well that it really increases their potential market.    Funny that they dont acknowledge that much...   It even worked many years ago with the PFC Serial console. (I had one in the MSFS2004 era)

Just for fun I will call my support guy at PFC.  maybe there is an easy way to simply light up the stack.  should be an easy one bit command.    If we can just light it up all should be working great...

Ill let  you know what i can find out.

Im getting older tooooooo.

Happy New Year...

 

[jimbooo]

per your instructions:

Set LogTxData to Yes in PFChid64.ini

Loaded Beech Baron and got to runway.

Exercised buttons on Radio Stack in the following order:

Com1 / Com2 /Nav1 / Nav2 /Transponder /Audio Panel / Autopilot VS and Target Altitude.

All work as they should in the MSFS cockpit panel and, of course, register in real time on the FSUIPC log.

Checked to make sure all the Avionics Master switches are "On"

Closed program.

Attached are the 2 log files for you to see.

Hopefully they help.

 

FSUIPC7.log PFChid64.log

[Pete Dowson]

19 hours ago, jimbooo said:

Attached are the 2 log files for you to see.

Hopefully they help.

Well, there's lots of information for me to analyse. I'll dig out the original specs from PFC which I worked from and see if I can make sense of it all. There are certainly lots of Writes to the various devices, but there must be something simple missing to get them to actually light up.

One thing I'm definitely going to ask PFC about -- how to distinguish between the 4 COMM devices when displaying the frequencies. Obviously the input details identify themselves as you turn the knobs (the data commands received will say COM1, COM2, NAV1 or NAV2), but initially, before you turn one, the driver needs to know which one to send each of the MSFS/P2D frequencies to.

I'll not get to this now till next week -- probably Tuesday or after.

Meanwhile, Happy New Year!

Pete

 

[jimbooo]

thanks Pete

when the Main Console is being energized there is a point where it lights up..  Theres likely something like that with the Radio Stack.  Even in the MSFS calibration screen they just have 4 separate entries for radios - rather than Com1, Com2, Nav1, Nav2 etc..

Sorry to make you revisit OLD programming - its a big mountain.....

Happy New Year

[jimbooo]

ps      on the subject of the radios -

when i exercise the radio knobs on my Radio Stack your programming does connect the correct knobs to the correct radio.

So you somehow, at the time you programmed those radios, could differentiate them.

Its odd that MSFS doesnt list them as Com1, Nav1 etc - but just 4 separate entries titled "radio"

[Pete Dowson]

17 hours ago, jimbooo said:

So you somehow, at the time you programmed those radios, could differentiate them.

No, the commands cominmg from the knobs or switches identify themselves.

I could deduce which one is which from that, but the radios need to display their current FS-set values on switch on, without expecting you to press a switch or turn a knob. If all else fails I can certainly do that -- once identified their device numbers would not change during that session.

Pete

 

[Pete Dowson]

Hi there,

At last I got some hints regarding commands to try to get your radio stack lighting up.  There were three others apart from the "ILLUMINATOR_POWER" one I was already using, and which worked fully on the earlier integrated radio stack. The other three are ILLUMINATOR_BACKLIGHT, ILLUMINATOR_AVI_MASTER and ILLUMINATOR_SIMULATOR_POWER.

I probably don't need to use all of those, but I've added them all in any case. The ones not really needed won't do any harm.

I attach the revised DLL below. Please try this and let me know.

Pete

PFChid64.dll

 

[jimbooo]

WOW     you got it  !!!!

with the new .dll the entire stack is lit and all knobs and buttons work perfectly.

should i just leave all 3 of the new commands in the .dll or should i experiment with which one is the critical one ????

 

thanks for your long term commitment to help me make this work.....

Happy New Year

[Pete Dowson]

13 hours ago, jimbooo said:

should i just leave all 3 of the new commands in the .dll or should i experiment with which one is the critical one ????

I'd leave well alone.

As this update works I shall make it the current release.

Pete

 

[jimbooo]

thanks again Pete

your ongoing help has been most impressive

[jimbooo]

at this point, with your help FSUIPC7 has properly connected to my entire console and radio stack in MSFS2020.   If you remember it was the Professional Flight Controls (Cirrus Pro 2 console and radio stack).

all the various instruments are receiving the correct input from FSUIPC. 

I have another issue that has shown itself.

My autopilot (AP) is a separate freestanding piece from RealsimGear and has an interface that drives that piece.  Since that piece of gear is not addressed in FSUIPC it obviously does not respond to your code.   The net effect of that is that when i try to do any setting on the hardware RSG AP - the RSG programming conflicts with FSUIPC and the net effect is that the in plane AP does not respond.  If I try to do any settings on the virtual AP the 2 programs apparently still conflict and nothing happens.   Therefore AP is unusable.  If I unplug the RSG AP then the virtual AP works fine with the commands from FSUIPC.

I would like to use the RSG AP if possible.  sooooooo   Im thinking if i remove (edit) all the FSUIPC commands that pertain to the operation of the AP - that should allow the RSG program to work unimpeded.

Is that a reasonable hypothesis and, if so, is there any easy way to do that ???

Any direction would be appreciated

 

thanks    Jim

[John Dowson]

11 hours ago, jimbooo said:

The net effect of that is that when i try to do any setting on the hardware RSG AP - the RSG programming conflicts with FSUIPC and the net effect is that the in plane AP does not respond.  If I try to do any settings on the virtual AP the 2 programs apparently still conflict and nothing happens. 

I don't understand why these would interfere with each other. Each is sending controls/events to the FS, which would then act on these requests updating the sim data, and then this data should be reflected back in FSUIPC.
If you set logging for Events and open the FSUIPC7 logging console window, you should see the events sent both from the PFC and RSG APs. Maybe try this and see what is logged.

11 hours ago, jimbooo said:

I would like to use the RSG AP if possible.  sooooooo   Im thinking if i remove (edit) all the FSUIPC commands that pertain to the operation of the AP - that should allow the RSG program to work unimpeded.

Is that a reasonable hypothesis and, if so, is there any easy way to do that ???

You can try this, but I am not sure if this will help, as this only changes what is sent when you activate the AP buttons on the PFC device - just not using them should suffice...

To do this, You would have to add an empty macro for each of the AP buttons (or a macro that does nothing) to the PFC.mcro file. However, better to try and understand why they are interfering first. 

John

[jimbooo]

My problem is no longer from any PFC device. I do not have the PFC autopilot.   All PFC devices are working properly.

I have instead a hardware dedicated AP from RealSimGear.(RSG)

I think the problem is some conflict with the RSG control program conflicting with FSUIPC.   If i hit the ON button on either the RSG AP hardware or the virtual cockpit ON button the AP flashes to ON for a second and then OFF. 

1. If i hit ON on the virtual cockpit AP the FSUIPC command is sent but the RSG does not see that command and since it is in the OFF condition it overrides the FSUIPC command and the AP reverts to OFF.

2. If i hit AP ON on the RSG hardware autopilot then FSUIPC doesnt see or interpret that command and, since it is in the OFF condition the AP again reverts to OFF

I will experiment over the weekend and report back on Monday

have a nice weekend

 

thanks

[John Dowson]

16 hours ago, jimbooo said:

I think the problem is some conflict with the RSG control program conflicting with FSUIPC. 

But why do you think this?

16 hours ago, jimbooo said:

1. If i hit ON on the virtual cockpit AP the FSUIPC command is sent

If you are clicking a button in the VC, what has this got to do with FSUIPC? The command will be sent by the VC, not FSUIPC - FSUIPC will receive this, for logging purposes, but it does not send the command. It only sends commands from hardware buttons/axes that you have assigned.

16 hours ago, jimbooo said:

2. If i hit AP ON on the RSG hardware autopilot then FSUIPC doesnt see or interpret that command and, since it is in the OFF condition the AP again reverts to OFF

If FSUIPC isn't seeing the command, then it is not being sent to the FS.

16 hours ago, jimbooo said:

I will experiment over the weekend and report back on Monday

ok.

16 hours ago, jimbooo said:

have a nice weekend

You too - cheers,

John