f-ado

Hello Pete I understood the problem, it was my fault, I apologize. I did a copy of the original pfchid.dll (1.41) but it looks like the sim loads any DLL in the folder and therefore two instances of PFCHID were running.... the 1.41 being renamed, it created a default configuration file and so it called default functions. Just to be sure that 1.41 module was not conflicting with 1.48, I tested 1.48 again but same result, the fast flag was not detected in 1.48. I kept the good news for the end, I then tested your latest version 1.49 and it works very well. Well done Pete! Thank you so much, Fabrice.

Hi Pete I defined a macro for the baro knob and I confirm version 1.48 calls both the default baro function and my macro. So I believe I can say it affects all the buttons. If I restore 1.41, it only calls my macro (as expected). Fabrice

I have to check because to notice it, I need a default function that the aircraft supports and to override it. At least I can say that for the CRS/DG knob and CRS1/CRS2 knob, both default function and custom macros are called. I will try to override the baro knob with a custom macro to see if it continues to call the default baro function.

I can't be sure but it looks like I receive a number of steps greater than 1 only when I stress the knob. From my observation, even when I turn it fast, it starts and ends the sequence of macro calls with a value of 1 (or 255). So I would start by this implementation. By the way, I noticed a regression with version 1.48. The 8th knob (last one on the right) handles by default CRS1 & CRS2 and you toggle between them by pushing the knob. In my macro file for the B200, I was not interested to keep this function and I reconfigured it to manage the stand-by navigation frequency (CRS1 changes the whole number and CRS2 changes the decimal). With version 1.48, when I use this knob, I observe that both the default function (CRSx) and my custom macro are called. I don't think the problem is specific to this knob, I observe the same behavior with the CRS/DG knob (that I also reconfigured differently compared to the default function). Thanks and regards, Fabrice

Hi Pete I tried 1.48. If I well understood, it should call macros with < or > as long as the "fast" flag is detected (and irrespective of the number of steps). If I am correct, it seems the "fast" flag is not detected or probably not set by the firmware. The behavior remains the same than version 1.41. If calls + or - if the number of steps is 1 or 255, otherwise it calls the default macro. See below: 433417: Device #1 received: AttitudeRef[0] = 1 433417: Full macroname for decoded switch = "PFC_F1B200:AttitudeRef+", mask = X000003C0 433449: Device #1 received: AttitudeRef[0] = 3 433449: Full macroname for decoded switch = "PFC_F1B200:AttitudeRef", mask = X000003C0 433495: Device #1 received: AttitudeRef[0] = 4 433495: Full macroname for decoded switch = "PFC_F1B200:AttitudeRef", mask = X000003C0 and in the other direction: 898893: Device #1 received: AttitudeRef[0] = 255 898893: Full macroname for decoded switch = "PFC_F1B200:AttitudeRef-", mask = X000003C0 898924: Device #1 received: AttitudeRef[0] = 247 898924: Full macroname for decoded switch = "PFC_F1B200:AttitudeRef", mask = X000003C0 898924: Device #1 received: AttitudeRef[0] = 244 898924: Full macroname for decoded switch = "PFC_F1B200:AttitudeRef", mask = X000003C0 In the macro file, +/- change the altitude by 100 feet, and </> change it by 1000 feet. Why don't assume "fast" flag whenever the number of steps is greater than 1 (in absolute value)? Pete, I am already happy to configure the RIC with any aircraft whatever its complexity thanks to your tool. It took me one year to ask this question just to be sure I did not miss the "how to". I will not complain if it stays as is. :) Thank you again, Fabrice

My bad, I copied the positive values but there are also the negative values in the log: 214486: Device #1 received: Hdg[0] = 255 214486: Full macroname for decoded switch = "PFC_F1B200:Hdg-", mask = X000003C1 214517: Device #1 received: Hdg[0] = 252 214517: Full macroname for decoded switch = "PFC_F1B200:Hdg", mask = X000003C1 214548: Device #1 received: Hdg[0] = 250 214548: Full macroname for decoded switch = "PFC_F1B200:Hdg", mask = X000003C1 Honestely, I don't think it is the problem, as you said, they probably improved their firmware and broke the compatibility with the macros. I didn't know the story behind the PFCHID but I understand your position, no worry. :) Best regards, Fabrice

Hello Pete Yes in the second log file, I only turned the knob fast in a single direction (to make a shorter/smaller log file). If you look at first log file, you will see that it calls the Hdg macro with multiple cranks (counts) in both direction. Extracted from first log: 216108: Device #1 received: Hdg[0] = 1 216108: Full macroname for decoded switch = "PFC_F1B200:Hdg+", mask = X000003C1 216139: Device #1 received: Hdg[0] = 3 216139: Full macroname for decoded switch = "PFC_F1B200:Hdg", mask = X000003C1 216139: Device #1 received: Hdg[0] = 5 216139: Full macroname for decoded switch = "PFC_F1B200:Hdg", mask = X000003C1 216186: Device #1 received: Hdg[0] = 3 216186: Full macroname for decoded switch = "PFC_F1B200:Hdg", mask = X000003C1 I got my PFC setup in January 2016. As you can see, I can survive, I was only looking for an improvement. BTW, I also notice that all the eight knobs are "physically" pushable. I know that two are managed internally in the driver (to toggle CRS/DG and CRS1/CRS2) and two others are visible with PFCHID (HdgSync and LandLtsInbd). If you get the new specs from PFC, perhaps there is a way to make available the four remaining knobs. ;) Thank you very much for your great product (without it I would never buy the RIC) and your support. Best regards Fabrice

Hi Pete Please find attached the verbose log file, hope it can help :) I only turned the Heading knob this time, one crank to the left, one crank to the right, wait few seconds and then turned fast the heading knob on the left. PFChid.log

Hello Pete Please find a first log file before I read your latest instructions. The test procedure is 1 to 1 what you are looking after: 1- I turned the heading knob by one crank on the left (Hdg-) then one crank on the right (Hdg+). The log file confirms it. 2- I turned fast the heading knob on the left. We can see in the log file that it called Hdg- at the beginning and at the end of my user action, and in between, it called the Hdg macro with the number of crank (negative signed byte on the left). The expected "Hdg<" macro was never called. 3- I turned fast the heading knob on the right and we observe the same behavior than in step 2. 4- I repeated steps 1 to 3 with another knob: AttitudeRef In my B200 PFC macro file, I defined the macros as follow: 15=Hdg+ 15.1=C65823,65 ; 65 (>K:THROTTLE4_SET)= Hdg inc 15.2=C65823,0 ; reset 16=Hdg- 16.1=C65823,64 ; 64 (>K:THROTTLE4_SET)= Hdg dec 16.2=C65823,0 ; reset 17=HdgSync 17.1=C65823,66 ; HDG SYNC 17.2=C65823,0 ; reset 18=Hdg>=CM11:15 ; calls Hdg+ 19=Hdg<=CM11:16 ; calls Hdg- 20=AttitudeRef+ 20.1=C65823,71 ; AP ALT +100 20.2=C65823,0 ; reset 21=AttitudeRef- 21.1=C65823,70 ; AP ALT -100 21.2=C65823,0 ; reset 22=AttitudeRef> 22.1=C65823,78 ; AP ALT +1000 22.2=C65823,0 ; reset 23=AttitudeRef< 23.1=C65823,77 ; AP ALT -1000 23.2=C65823,0 ; reset The "Hdg" and "AttitudeRef" are not defined in my macro file so when there are called, they do nothing as expected (as default functions don't work with the Flight1 B200 aircraft). I will enable the flags you requested above and will upload a new log file. Thank you PFChid.log

I didn't say they didn't work, I said there were never called and in the log file, I saw that the "Hdg" macro was called in such situation. I will make a log file and post it once at home. Thank you

Hello Pete Thanks for your answer. What do you mean by the hardware may not be capable of that? I see the fast rotation in the PFCHID log file and I can also trap them into a "Hdg" macro. The only problem is that without conditional expressions in macro, I can't map properly the action. I can live with Hdg+ and Hdg- but when I turn too fast the knob I loose events as it calls the macro Hdg that won't be processed. I hope I am more clear (English is not my mother tongue). Thanks and regards Fabrice

Hello Pete I am using your PFCHID software to configure my Remote Instrument Control (RIC). I am able to manage almost every functionalities but I still have one concern to trap fast rotation on knobs. For example, I can trap events on the heading knob with "Hdg+" and "Hdg-". But if I turn the knob faster, it will not call the macros "Hdg>" or "Hdg<" as per the documentation. I see it calls instead the "Hdg" macro with the number of cranks as an input parameter. As far as I know, there is no possibility in the macro file to test the sign of the parameter to determine the direction of the rotation. To keep things simple, I would avoid to couple the macro file with a LUA file (to process the number of cranks and its direction) and therefore it would be helpful if I can rely on the "Hdg<" and "Hdg>" macros. Thank you Best regards Fabrice

Hello Yes it is possible but in two steps. You start to define your LVAR macros, for example: 1=L:Eng1_CarbHeatSwitch=set 2=L:LandingLightLeftSwitch=set 3=L:LandingLightRightSwitch=set Then you define the PFC macros 10=CarbHeater+=CM1:1,100 ; single action: call macro 1 with 100 as input 11=CarbHeater-=CM1:1,0 ; single action: call macro 1 with 0 as input 12=Landing+ ; multiple actions 12.1=CM1:2,1 ; call macro 2 with 1 as input 12.2=CM1:3,1 ; call macro 3 with 1 as input In the above example, I assume your PFC.mcro file is the first entry in FSUIPC config file. If not, change CM1 by CMx where x is the entry number of PFC.mcro inside FSUIPC.cfg. Finally, it works only with LVAR, I suspect AttitudePlane is an Aircraft variable (A:). Cheers Fabrice