PFCHID macros

[f-ado]

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

Edited May 31, 2017 by f-ado

[Pete Dowson]

9 minutes ago, f-ado said:

I am using your PFCHID software to configure my Remote Instrument Control (RIC).

I had on of those when I had a PFC console.

10 minutes ago, f-ado said:

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.

Really?

I think the fast/slow rotation system was dependent on an appropriate indication from the device. i don't recall it being based on internal timings of changes in the DLL itself. Perhaps the hardware is not capable of that?

Pete

 

[f-ado]

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

[Pete Dowson]

16 minutes ago, f-ado said:

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.

Can you show me a log or anything? It is a long time since i had any access to such hardware and the software itself is pretty old now. I will try to help, but it may take some time with some revision necessary and so much else going on at present. 

Show me a log and the macro file and i'll try to fit you in. I do try to deal with support questions within a short space of time but I cannot guarantee it.

I really need more technical inforamation. If there is a documented facility for this then I'm positive that it used to work. Have you checked that your PFCHid is up to date, for instance?

21 minutes ago, f-ado said:

The only problem is that without conditional expressions in macro, I can't map properly the action.

Isn't that what there's also Hdg> and Hdg<

I can't imaginre you are the first user with such needs. You say Hdg> and Hdg< don't work as advertised. Do they do nothing?

Pete

 

[f-ado]

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

[Pete Dowson]

21 minutes ago, f-ado said:

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.

Ah, yes, sorry. So you did. But that takes me back to my first comment, that if the hardware sends the same thing for a fast turn as it does for a slow one, naturally the same action will be triggered.

21 minutes ago, f-ado said:

I will make a log file and post it once at home.

I think I need the log to show me what is coming from the hardware.  Let me see ...

... Yes. Use

LogComms=Yes
LogData=Yes
LogDecode=Yes

in the INI. Run it but only use the knob in question. Turn it slowly both ways, then wait a while 9so i can see a gap in log times) and turn it fast each way.

[LATER]

Actuallly, having a quick look at the code, the unit sould be indicating fast in the data it sends. There are time constraints. the code ifnores a "slow" withing 110 mSecs of a fast -- probably to stop that odd 1 being added when you stop turning.

Maybe you aren't turning it fast enough for the hardware to indicate it?

Pete

 

[f-ado]

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

[f-ado]

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

[Pete Dowson]

9 minutes ago, f-ado said:

Please find attached the verbose log file, hope it can help :)

Well, I see the 255 (-1) returns for one direction, and either 1 or sometimes 2 -7, presumably from when you turn it fast in the other director, but no -ve equivaluents (254 - 248, say. did you run it fast both ways?

I can see that the HDG macro is invoked for anything other that 1 or 255. So i'm thinking the original spec didn't mention anything about multipl counts. And I would certainly have noticed when I had a RIC. How old is your unit? They might have improved it and revised the firmware.

I'm going to have to find the original specifications for the PFC protocol. And I may have to ask PFC to supply these again, or, better, updated ones, because it was many years ago that I dealt with any of this and it was all on another PC. I have some archives and I might be able to find them, but it could take a while. I'll make a note to get back to you when I can, probably next week. Put a reminder in this thread if I haven't got back before the end of next week.

Pete

 

[f-ado]

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

 

 

[Pete Dowson]

23 minutes ago, f-ado said:

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

They are all positive. "negative" ones would have numbers like 255 to 248 or less.

25 minutes ago, f-ado said:

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. ;)

Quite honestly, if PFC are still making new products and expecting me to support them in FS then they should at least tell me about them and possible compensate me.I did get some hardware from them for my earlier work, but nothing now for many years. They only seem to care about X-Plane these days.

Maybe you should appeal to them. i don't like to let folks down but they do trade on my good will, and i wouldn't mind if I wasn't so busyn(I do wish P3D had never been invented. FSX-SE was bad enough. FSX could have subsided nicely by now)). i wasn't planning to be still doing this stuff at age 74 and I'd like to get time to fly my own cockpit occasionally -- something I last did way back in April.

So,sorry, I don't think enhancements to PFCHid are likely. I'll check what is happening with the multiple values returned, next week, but nothing more.

Pete

 

[f-ado]

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

[Pete Dowson]

As I said, remind me if you see nothing here by the end of next week.

Pete

 

[Pete Dowson]

I've looked at PFCHid and the PFC protocol for encoders. As far as I can see, the protocol says you might get the number of steps (i.e. the 1, 2, 3, or 255, 254, 253 for -ve) and/or a "fast" flag, indicating it is being turned fast.

For macros, my code seems not to handle both more than 1 step AND the "fast flag", if they both occur.

I need to know if you get the fast flag, so I've modified the code a little to check that and use > or < if it is set irrespective of the number of steps returned. Download this update please:

http://fsuipc.simflight.com/beta/PFChid148_TEST.zip

If this works, well and good. If not then I guess I'll need to determine "fast" from the number of steps. In that case you'll need to do more experiments with logging enabled, please. You'll need to determine how many steps should be needed to make a > or < selection. (After all 2 or 3 may just be the result of you turning a little too far -- it would be irritating not to be able to get +1 or -1 changes).

I think all the users of the RIC and the heading knob in the past must have either been using standard Heading gauges, which would be handled without a macro, or were quite happy without the "fast" entries. Because PFCHid has been around like this for about 12-13 years!

Let me know please. I'm working on the 64-bit conversion now and would obviously like whatever fix seems best in both versions.

Pete

 

[f-ado]

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

 

[Pete Dowson]

2 hours ago, f-ado said:

Why don't assume "fast" flag whenever the number of steps is greater than 1 (in absolute value)?

I can certainly do that, but didn't you read this part of my last message?

If not then I guess I'll need to determine "fast" from the number of steps. In that case you'll need to do more experiments with logging enabled, please. You'll need to determine how many steps should be needed to make a > or < selection. (After all 2 or 3 may just be the result of you turning a little too far -- it would be irritating not to be able to get +1 or -1 changes).

Are you sure you'll still be able to get the small changes if I treat all with more than one step as "fast"?

Pete

 

[f-ado]

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

 

[Pete Dowson]

16 minutes ago, f-ado said:

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).

Odd. I've changed nothing else. I'll check. It is very difficult without any suitable devices.

So is this happening with all buttons with default actions? And only buttons, nothing else? If it is alll buttons and nothing else it narrows it down well -- i should be able to track it down by simulation of the button press.

Pete

 

[f-ado]

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.

[f-ado]

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

[Pete Dowson]

1 hour ago, f-ado said:

So I believe I can say it affects all the buttons.

Okay, thank you. I'll tske a look.

Pete

 

[Pete Dowson]

14 hours ago, f-ado said:

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).

I've not been able to reproduce this at all.  In fact it looks impossible. There's only one call to the Macro execution function in the whole program, for all types of input, and if that succeeds in executing a macro (i.e. it finds one and identifies it for execution by FSUIPC) then the only calling function exits, doing nothing more for that input.

So it remains a puzzle at present. Perhaps you could do some more logging please -- logging in PFCHid and also log Events in FSUIPC.

I've re-programmed the fast/slow determination for the decoders. If you'd like to test that please download

PFChid149_TEST.zip

Pete

 

[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.

[Pete Dowson]

39 minutes ago, f-ado said:

I did a copy of the original pfchid.dll (1.41) but it looks like the sim loads any DLL in the folder

Not two with the same name though -- you can't have two files withthe same name in the same folder. Windows won't allow it. I assume you renamed one.

The Sim isn't loading it, FSUIPC loads any it recognises as being suported by its facilities.

40 minutes ago, f-ado said:

tested your latest version 1.49 and it works very well.

Good. Thakns for testing.

I'll be rleeasin this formally, along with PFChid64.dll for P3D4 and PFCcom64.dll also for P3D4 withing the next day or tow. The P3D4 versions need FSUIPC 5.102 which isn't quite there yet.

Pete