PFC C2 Pro - Fuel Selector Marco PFCHID

[String]

Sorry for the delay... I have been traveling and just got home.

I have set LogLoopActions=Yes

Once again your time a expertise is appreciated; log attached.

Chris

PFChid64.log

[Pete Dowson]

I tried to reproduce this problem here by faking things on one of my only PFCHid devices (a couple of panels on their 737NG MIP), but effectively exactly the same setup (though a different switch, naturally) worked fine. 

I'm afraid I'm out of ideas. I really don't understand the problem, as it only occurs on one of the positions on your multiway switch. The code is the same for each case!

I'll have a look at the log when I can allocated some time, but meanwhile why not use the Lua plug-in i suggested and do away with the macro intervention? i.e this idea from August 22nd:

Quote

 

BTW if I cannot solve this strange problem with PFCHid, or it simply takes too much time, your needs could probably be met with a Lua plug-in:
You would use event.intercept to get notification of the write to 0x3880 (Engine 1 Tank Selector) and if the "UD" type value is 0 write 0,  if 1 write 2, if 14 write 3.  This would actually be more efficient than using macro file execution.

 

Pete

 

 

 

[Pete Dowson]

I think I may have nailed it.  Can you try this test version, please, and let me know:

PFChid64_511_TEST.zip

Pete

 

 

 

[String]

Pete,

I think you got something going here...

TankSelect1/0 and TankSelect1/1 positions are now working, but TankSelect1/3 is not.

Chris

FSUIPC5.log

PFChid64.log

[Pete Dowson]

7 hours ago, String said:

TankSelect1/0 and TankSelect1/1 positions are now working, but TankSelect1/3 is not.

And TankSelect1/3 worked before? What about TankSelect2/3?

The number is simply a number. The code doesn't do someting different just because its a 3 instead of a 0, 1 or 2.

I could really do with seeing your current macro.

Pete

 

[String]

3 hours ago, Pete Dowson said:

And TankSelect1/3 worked before? What about TankSelect2/3?

Sorry my error I should have typed TankSelect1/2 and not 1/3. Both the Tank Selectors on the C2 Pro console, TankSelect1/2 and TankSelect2/2 have not work to this point

3 hours ago, Pete Dowson said:

I could really do with seeing your current macro.

 

Attached it the current macro that I have been testing with.

Chris

PFC.mcro

[Pete Dowson]

19 hours ago, String said:

I should have typed TankSelect1/2 and not 1/3. Both the Tank Selectors on the C2 Pro console, TankSelect1/2 and TankSelect2/2 have not work to this point

Sorry, you mean nothing appears to have changed at all even with the updated version? I am now confused!

Looking at the only part of the PFChid64 log which appears to be all of the testing of TankSelect you did, from here on:

     3078: Using macros from "C:\Flight Sim\Prepar3D v4\Modules\PFC.mcro" selected
     3078: Macroflag mask for "TankSelect" = 00070004

These three lines show position 1 using the correct macro:

    11328: Device #2 received: TankSelect[0] = 1
    11328: Full macroname for decoded switch = "PFC:TankSelect1/1", mask = X00070004
    11344: Requested macro "PFC:TankSelect1/1",00 via offset 0D70

Then this is position 3:

    15375: Device #2 received: TankSelect[0] = 3
    15375: Full macroname for decoded switch = "PFC:TankSelect1", mask = X00070004
    15375: Requested macro "PFC:TankSelect1",0E via offset 0D70

which does not select a /3 macro!

Then there's another position 1, followed by positions 0  then 1 then 0.

    19235: Device #2 received: TankSelect[0] = 1
    19235: Full macroname for decoded switch = "PFC:TankSelect1/1", mask = X00070004
    19235: Requested macro "PFC:TankSelect1/1",00 via offset 0D70
    23110: Device #2 received: TankSelect[0] = 0
    23110: Full macroname for decoded switch = "PFC:TankSelect1/0", mask = X00070004
    23110: Requested macro "PFC:TankSelect1/0",00 via offset 0D70
    27375: Device #2 received: TankSelect[0] = 1
    27375: Full macroname for decoded switch = "PFC:TankSelect1/1", mask = X00070004
    27375: Requested macro "PFC:TankSelect1/1",00 via offset 0D70

Another position 3 for the same tank:

    31157: Device #2 received: TankSelect[0] = 3
    31157: Full macroname for decoded switch = "PFC:TankSelect1", mask = X00070004
    31157: Requested macro "PFC:TankSelect1",0E via offset 0D70

But no test of position 2 on the first switch!

You moved to the second switch:

    34235: Device #2 received: TankSelect[1] = 1
    34235: Full macroname for decoded switch = "PFC:TankSelect2/1", mask = X00070004
    34235: Requested macro "PFC:TankSelect2/1",00 via offset 0D70
    36641: Device #2 received: TankSelect[1] = 0
    36641: Full macroname for decoded switch = "PFC:TankSelect2/0", mask = X00070004
    36641: Requested macro "PFC:TankSelect2/0",00 via offset 0D70
    40516: Device #2 received: TankSelect[1] = 1
    40516: Full macroname for decoded switch = "PFC:TankSelect2/1", mask = X00070004
    40516: Requested macro "PFC:TankSelect2/1",00 via offset 0D70

So, positions 1 and 0 on that apear to be okay.

Finally we get to the only test of position 2:

    41719: Device #2 received: TankSelect[1] = 2
    41719: Full macroname for decoded switch = "PFC:TankSelect2", mask = X00070004
    41719: Requested macro "PFC:TankSelect2",0F via offset 0D70

which, like postion 3 on the first switch, doesn't select a /2 macro.

So from that log it appears that there's a problem with TankSelect1/3 macro, and TankSelect2/2 macro.

Now, looking at your macro file:

[Macros]
1=TankSelect1/0=C65958
2=TankSelect1/1=C65955
3=TankSelect1/2=C65957

There seems to be no TankSelect2 macros supplied in any case (!???) and no TankSelect1/3 macro.

So, please, what is going on at your end? The macro file doesn't appear to match the log, and is incomplete in any case. I can't see anything I can do this end, it appears to be incorrectly configured, that's all.

The bug I fixed was that with certain mactos, the switch was being placed into a "scan" list and so repeatedly queried and actioned. That's appropriate when the offset being set doesn't match what is needed, so that the computer settings stay matched to the switch setting. But it gets into that never ending loop when you have a macro not setting that value into the offset. with macros it shouldn't have attempted to match anything.

BTW in FSUIPC you are Monitoring offset 0D70 with the wrong Type seleected. Please change that to an ASCIIZ choice for your next test.

Pete

 

[String]

On 9/17/2018 at 2:59 AM, Pete Dowson said:

Then this is position 3:

    15375: Device #2 received: TankSelect[0] = 3
    15375: Full macroname for decoded switch = "PFC:TankSelect1", mask = X00070004
    15375: Requested macro "PFC:TankSelect1",0E via offset 0D70

which does not select a /3 macro!

I did not include /3 in the macro, because the documentation says to use /0 for the first switch position, /1 for the second switch position and /2 for the third switch position. We see that TankSelect1 it is call position 3, but it should be 2. Unlike the TankSelect2 switch which calls for 0, 1, 2 positions as documented for that type of switch.

 

On 9/17/2018 at 2:59 AM, Pete Dowson said:

Another position 3 for the same tank:

    31157: Device #2 received: TankSelect[0] = 3
    31157: Full macroname for decoded switch = "PFC:TankSelect1", mask = X00070004
    31157: Requested macro "PFC:TankSelect1",0E via offset 0D70

But no test of position 2 on the first switch!

I can change the macro for TankSelect1 from /2 to /3, but that seems not to address the issue why is it not calling for position 2.

 

On 9/17/2018 at 2:59 AM, Pete Dowson said:

Then there's another position 1, followed by positions 0  then 1 then 0.

    19235: Device #2 received: TankSelect[0] = 1
    19235: Full macroname for decoded switch = "PFC:TankSelect1/1", mask = X00070004
    19235: Requested macro "PFC:TankSelect1/1",00 via offset 0D70
    23110: Device #2 received: TankSelect[0] = 0
    23110: Full macroname for decoded switch = "PFC:TankSelect1/0", mask = X00070004
    23110: Requested macro "PFC:TankSelect1/0",00 via offset 0D70
    27375: Device #2 received: TankSelect[0] = 1
    27375: Full macroname for decoded switch = "PFC:TankSelect1/1", mask = X00070004
    27375: Requested macro "PFC:TankSelect1/1",00 via offset 0D70

 I agree TankSelect1 positions 0 and 1 work perfectly 🙂

 

On 9/17/2018 at 2:59 AM, Pete Dowson said:

You moved to the second switch:

    34235: Device #2 received: TankSelect[1] = 1
    34235: Full macroname for decoded switch = "PFC:TankSelect2/1", mask = X00070004
    34235: Requested macro "PFC:TankSelect2/1",00 via offset 0D70
    36641: Device #2 received: TankSelect[1] = 0
    36641: Full macroname for decoded switch = "PFC:TankSelect2/0", mask = X00070004
    36641: Requested macro "PFC:TankSelect2/0",00 via offset 0D70
    40516: Device #2 received: TankSelect[1] = 1
    40516: Full macroname for decoded switch = "PFC:TankSelect2/1", mask = X00070004
    40516: Requested macro "PFC:TankSelect2/1",00 via offset 0D70

So, positions 1 and 0 on that apear to be okay.

I agree 🙂

 

On 9/17/2018 at 2:59 AM, Pete Dowson said:

Finally we get to the only test of position 2:

    41719: Device #2 received: TankSelect[1] = 2
    41719: Full macroname for decoded switch = "PFC:TankSelect2", mask = X00070004
    41719: Requested macro "PFC:TankSelect2",0F via offset 0D70

which, like postion 3 on the first switch, doesn't select a /2 macro.

So from that log it appears that there's a problem with TankSelect1/3 macro, and TankSelect2/2 macro.

I am curious why the log shows "PFC:TankSelect2"  and not "PFC:TankSelect2/2" and the same issue applies to TankSelect1 except for the fact TankSelect1 is using 3 and not 2 for the third physical switch position.

 

On 9/17/2018 at 2:59 AM, Pete Dowson said:

Now, looking at your macro file:

[Macros]
1=TankSelect1/0=C65958
2=TankSelect1/1=C65955
3=TankSelect1/2=C65957

There seems to be no TankSelect2 macros supplied in any case (!???) and no TankSelect1/3 macro.

I have not assigned any macros to the TankSelect2 currently. I have been logging TankSelect2 without macros to understand what it was doing.

 

On 9/17/2018 at 2:59 AM, Pete Dowson said:

BTW in FSUIPC you are Monitoring offset 0D70 with the wrong Type seleected. Please change that to an ASCIIZ choice for your next test.

Changed 

I have now run two tests:

TankSelect1 Test with the following macro

[Macros]
1=TankSelect1/0=C65958
2=TankSelect1/1=C65955
3=TankSelect1/3=C65957

 

TankSelect2 Test with the following macro

[Macros]
1=TankSelect2/0=C65958
2=TankSelect2/1=C65955
3=TankSelect2/2=C65957

In both cases the Tank switch that is not being tested, does not have any macros assigned.

Chris

 

FSUIPC5-TankSelect2 Test.log

PFChid64-TankSelect2 Test.log

FSUIPC5-TankSelect1 Test.log

PFChid64-TankSelect1 Test.log

[Pete Dowson]

1 hour ago, String said:

I did not include /3 in the macro, because the documentation says to use /0 for the first switch position, /1 for the second switch position and /2 for the third switch position. We see that TankSelect1 it is call position 3, but it should be 2. Unlike the TankSelect2 switch which calls for 0, 1, 2 positions as documented for that type of switch.

It seems that the switch is returning 0, 1, 2 and 3. My code isn't inventing those numbers, they are what arrives. Are there definitey only 3 positions? If so there's something a bit wrong with the device or its firmware.

1 hour ago, String said:

I am curious why the log shows "PFC:TankSelect2"  and not "PFC:TankSelect2/2"

I don't know about the FSUIPC logs, but I think your log names for the PFChid program are the wrong way around. As far as I can see, the Tankselect2 log is for TackSelect1 and vice versa. Otherwise nothing make sense!

It is odd. But now we have results for both switches, it looks like it only accepts 0 and 1.  The return' for 2, and that odd 3, give the 'default' without the /n part.  I can look for exactly that now we have some details. Maybe the macro coding was only ever tastest with only two positioned switches

For any other logs, please do both together, not separately. The way you've done it makes it harder working it all out for me. it might be clearer for you like that, but best for you to test as you wish without any macros, and for me with the full set of macros.

I'll be looking at this in the morning.

Pete

 

 

 

 

[String]

14 minutes ago, Pete Dowson said:

It seems that the switch is returning 0, 1, 2 and 3. My code isn't inventing those numbers, they are what arrives. Are there definitey only 3 positions? If so there's something a bit wrong with the device or its firmware.

Yes, only three positions per switch. OFF, ON, X-FEED

16 minutes ago, Pete Dowson said:

For any other logs, please do both together, not separately. The way you've done it makes it harder working it all out for me. it might be clearer for you like that, but best for you to test as you wish without any macros, and for me with the full set of macros.

Just to be sure I understand what you are saying regarding logging both together.

I will setup and use the macro as shown below for future testing with only one log.

[Macros]
1=TankSelect1/0=C65958
2=TankSelect1/1=C65955
3=TankSelect1/3=C65957

4=TankSelect2/0=C65958
5=TankSelect2/1=C65955
6=TankSelect2/2=C65957 

Chris

[Pete Dowson]

Okay. I've delved deeper. The PFC specification tells me that "Tankselect" has 4 positions, not 3:
0 = Off, 1=All, 2=RtoL Crossfeed and 3=LtoR Crossfeed.

It is because of the Crossfeed specification that only 0 and 1 are taken as they are. The two crossfeed values take another course.

I don't know why your Cirrus appears to be so different, nor why PFC haven't altered your Firmware to match correctly the different switching you have. If you only have 3 real positions howw is it providing all 4 of those values (at least for Tank Select 1?

The reason i couldn't reproduce any such problem here with the HID devices I have is that whilst I have multi-position switches (eg the Autobrake, which has 5), none of the others are tagged for special treatment for Crossfeeds. (My 737 crossfeed is on the forward overhead, a CockpitSonic product, also  with my own drivers).

I shall see if I can make an exception to the Crossfeed settings to give you your /2 and /3/

Pete

 

[Pete Dowson]

10 minutes ago, Pete Dowson said:

I shall see if I can make an exception to the Crossfeed settings to give you your /2 and /3/

Try this one (but you need to decide what to do about your unexpected (?) 4th position, the one returning 3. Maybe macro that too, just in case?(.

PFChid64_512_TEST.zip

Pete

 

[String]

3 hours ago, Pete Dowson said:

Try this one (but you need to decide what to do about your unexpected (?) 4th position, the one returning 3. Maybe macro that too, just in case?(.

This version works perfectly when I use the /3 in the macro for TankSelect1 and /2 for the TankSelect2.

Excellent!

 

4 hours ago, Pete Dowson said:

The PFC specification tells me that "Tankselect" has 4 positions, not 3:
0 = Off, 1=All, 2=RtoL Crossfeed and 3=LtoR Crossfeed.

I did some additional checking that I should have done earlier and just like you said the fuel selector has 4-positions, but only on the older units that I was unfortunately unfamiliar with. Additionally, based on the information below, not unit Feb of 2018 did they add the ability to configure the Fuel Select.

From Precision Flight Controls

"As of February, 2010 we started shipping a new model with Carb Heat switches on either side of the throttle quadrant. Until September we supported two firmware versions, both of which required 32K parts. In September 2010 however we were able to combine the two via a configuration setting."

Firmware Version 5.01, 2018 Feb 21
"Fuel Select" can now be configured for "Single 4-way, disable TO/GA" as well as "Single 4-way" and "Dual 3-way". Due to the wiring of some legacy units, turning the fuel select knob will also toggle TO/GA. This will mostly be seen on very old units converted from serial to USB. 

The new setting will disable channel 48 (J10 pin 5) and only that channel.
TO/GA was moved to on-board slave channel 18 (J26 pin 3) when the second fuel select knob was added (Version 4.04). That input will continue to work, regardless of the Fuel Select setting, if it is desired to retrofit an older unit with TO/GA.

 

I am running firmware 5.00 not 5.01. What are your thoughts regarding loading and testing the new firmware?

Chris

[Pete Dowson]

11 minutes ago, String said:

 

I am running firmware 5.00 not 5.01. What are your thoughts regarding loading and testing the new firmware?

Well, the changes don't seem too drastic and hopefully would not stop my DLL running properly.  Don't know about TO/GA though.

Did you try my updated DLL yet?

Pete

 

[String]

6 minutes ago, Pete Dowson said:

Did you try my updated DLL yet?

Log from v5.12 attached and it works perfectly 🙂

Chris

PFChid64.log

[Pete Dowson]

2 hours ago, String said:

Log from v5.12 attached and it works perfectly

Good. thanks. I'll get on with other stuff now.

Good flying!

Pete

 

[String]

Pete,

I have been testing the fuel select switch over the past few days and it works flawlessly. Thank you!

I then continued on and completed the testing of all remaining switches and rotary encoders on the PCF C2 Pro console and have discovered three issues:

1. Magnetos
When SLOWLY switching from Magneto1/3(both) to Magneto1/2(left magneto); Result: triggers Magneto1/4(start) and then Magneto1/2(left magento). Same is true for Magneto2

RAPIDLY switching from Magneto1/3(both) to Magneto1/2(left magneto) ; Result: Works correctly sometimes triggering only Magneto1/2(left magneto)

2. Kohlsman
Barometeric scale adjustment knob not functioning; Added macros "Alt+" and "Alt-"; The barometeric increase now functions, but the barometeric decrease does not.

3. Flaps and Cowl Flaps
Using PFCHID v5.11; when the flaps or the cowl flaps are actuated; PrePar3d will crash to desktop. Went back to PFCHID v5.01 and tested both flaps, cowl flaps function properly. 

The log ends when the Flap down switch was pressed. I once again thank your for your help.

Chris

PFChid64.log

PFC.mcro

[Pete Dowson]

For #1, the DLL is not able to take different actions for fast and slow turning of a multi-position switch. That sounds more like confusion in the firmware. Isn't that similar to where you said you occasionally got '3' for the '0' position of the TankSelect? I'll see if the log makes any sense of all that.

#2 must surely be a firmware problem? No way would the default baro adjust be wrong. Or is okay with default aircraft, just not with your add-on one?  If it isn't with defaults I need the log showing that, before you added macros please.

For #3 I would need the crash log from Windows. You don't appear to be using macros related to those switches.

This is really getting a bit much for me at present, as I have loads of other stuff on my plate. I think you must be the only user of this hardware using FSX or P3D? Maybe you'll need to contact PFC about some of this? I simply don't have any hardware to test with and they have evidently changed it quite a bit in the last 10-15 years.

I'll see if I can glean anything reasonably quickly from logs, though this time I do really need the FSUIPC log as well, please, with 0D6C and 0D70 being monitored (as S32 and ASCIIZ respectfully), and event logging enabled 

Pete

 

 

 

[Pete Dowson]

10 hours ago, String said:

1. Magnetos
When SLOWLY switching from Magneto1/3(both) to Magneto1/2(left magneto); Result: triggers Magneto1/4(start) and then Magneto1/2(left magento). Same is true for Magneto2

Looking at the log, EVERY instance of Magneto1/4 was certainly triggered by the receipt of the indication 4 from the hardware.  I assume the same is true for Magneto2, though the log indicates that at that time your mcro file didn't cover that.

So in this case the DLL is only doing what is asked. A matter for PFC?

10 hours ago, String said:

2. Kohlsman
Barometeric scale adjustment knob not functioning; Added macros "Alt+" and "Alt-"; The barometeric increase now functions, but the barometeric decrease does not.

Both Alt+ and Alt- macros are invoked correctly, so i think this is something to do with your aircraft. I'd need the FSUIPC logging to check that further. But I'd still like to know why you needed the macros as the default action should work. Test with a default aircraft as well please.

10 hours ago, String said:

3. Flaps and Cowl Flaps
Using PFCHID v5.11; when the flaps or the cowl flaps are actuated; PrePar3d will crash to desktop. Went back to PFCHID v5.01 and tested both flaps, cowl flaps function properly. 

As already said, without the crash log I can't do anything with this report. When there's a crash the crash data is ALWAYS needed. Get it from the Windows Event Viewer. (I have looked at the code for flaps, and there's precious little. And I looks like it hasn't been changed at all since first written let alone between 5.01 and 5.11).

This is all I can do for now ...

Pete

 

[String]

13 hours ago, Pete Dowson said:

Looking at the log, EVERY instance of Magneto1/4 was certainly triggered by the receipt of the indication 4 from the hardware.  I assume the same is true for Magneto2, though the log indicates that at that time your mcro file didn't cover that.

So in this case the DLL is only doing what is asked. A matter for PFC?

1. Magnetos: I ran a test with PFC's "Test GUI" and you are correct, this is a PFC issue. 

 

15 hours ago, Pete Dowson said:

Both Alt+ and Alt- macros are invoked correctly, so i think this is something to do with your aircraft.

Kohlsman: Tested again and no problem this time;  user error.

 

15 hours ago, Pete Dowson said:

without the crash log I can't do anything with this report. When there's a crash the crash data is ALWAYS needed. Get it from the Windows Event Viewer. (I have looked at the code for flaps, and there's precious little. And I looks like it hasn't been changed at all since first written let alone between 5.01 and 5.11).

The attached FSUIPC and PFChild logs are taken when I pressed the flaps down button. The simulator immediately became unresponsive, next the simulator closed, no error message.

No "Error Logs" in the Event Viewer Application events section to be found.

PFChid64.log

FSUIPC5.log

[Pete Dowson]

8 hours ago, String said:

The attached FSUIPC and PFChild logs are taken when I pressed the flaps down button. The simulator immediately became unresponsive, next the simulator closed, no error message.

No "Error Logs" in the Event Viewer Application events section to be found.

Really? You looked for Errors (marked with a red icon) in the Application Logs list?

Without that information I really have little chance of finding what is going on. There's nothing special about how those switrches are treated. The code for the flaps operation is just 8 innocuous lines.

Meanwhile, if there truly is no crash information, I'll try adding log lines to track through where the code goes when the flaps switch is activated. it'll be a temporary version of the DLL from which i'll need the log. But take another look first, please.

Pete

 

[Pete Dowson]

I've had one thought. One of the changes made especially to try to find the problems with macros was adding extra logging to the parts of the code devoted to setting controls to repeat. In the end it turned out to e something different. But the flaps switches are repeating ones, so it is exercising new code added just for logging the repeat tables.

Just in case there's an error in my logging code, could you (temporarily) disable all the logging options and see if that fixes the flaps problem?

Pete

 

[String]

1 hour ago, Pete Dowson said:

(temporarily) disable all the logging options and see if that fixes the flaps problem?

Pete,

When logging is disables the sim no longer crashes to desktop when pressing the flaps or cowl flap switches.

You nailed it!

Chris

[Pete Dowson]

7 hours ago, String said:

When logging is disables the sim no longer crashes to desktop when pressing the flaps or cowl flap switches.

You nailed it

Okay. That narrows it down considerably. I'll have a look at those areas of code.

So there will be one more update to check, WITH the Logging, just to make sure I've fixed it.  Later today.

Pete

 

[String]

On 9/24/2018 at 1:22 AM, Pete Dowson said:

Both Alt+ and Alt- macros are invoked correctly, so i think this is something to do with your aircraft. I'd need the FSUIPC logging to check that further. But I'd still like to know why you needed the macros as the default action should work. Test with a default aircraft as well please.

Pete,

Looks like an issue does exist with the Kohlsman Barometeric scale adjustment knob that was difficult to identify. 

ISSUE: Barometeric scale adjustment knob fails to send the Kohlsman commands when "AltAir" is added to the marco file. When "AltAir" is removed from the macro file, the Barometeric scale adjustment knob resumes to send commands and functions normally.

[Macros]
1=TankSelect1/0=C65957
2=TankSelect1/1=C65956
3=TankSelect1/3=C65958
4=AltAir=C66317

This also addresses your question why I added the "ALT" macros in an attempt to get it to function.

Logs provided with the "AltAir" macro and without.

Once the simulator was running I switched the "AltAir" on and off (4) times and then rotated the Barometeric scale adjustment knob both CW and CCW

Chris

 

PFChid64 - with AltAir mcro.log

FSUIPC5 - with AltAir mcro.log

FSUIPC5 - without AltAir mcro.log

PFChid64 - without AltAir mcro.log