zfehr
-
Posts
186 -
Joined
-
Last visited
-
Days Won
2
Content Type
Profiles
Forums
Events
Gallery
Downloads
Posts posted by zfehr
-
-
3 hours ago, John Dowson said:
The MobiFlight add-on events use the *.evt files, and you need the MobiFlight WASM module installed to handle these events. That is the older method of using the MF events. The newer and better method is to use presets, which are handled by the FSUIPC WASM, and you don't need the MF WASM module to use these.
The logs you posted are strange in that they show no macro names being written to offset 0D70, and your hid log file is also not logging the macro names.
Add-on events are handled by FSUIPC, so will work. If the MF add-on events aren't working, then either the MF WASM isn't installed or perhaps these are no longer working as they have also been replaced/superseded by the presets/calculator code provided in the MF events.txt file.
Anyway, glad its now working...
John
I have the most recent Mobiflight installed and when I install the WASM module it tells me I have the most recent one installed. The odd thing is the Mobiflight events were working if I assigned them in FSUIPC, I copied and pasted those assignments into the PFC.MCRO file and they wouldn't work.
I cannot express enough how happy I am to have this working now.
-
VICTORY!!! Problem solved, it was using the Mobiflight.evt files for programming. They do work in FSUIPC but not with the PFChid part. I reprogrammed the radio stack buttons in FSUIPC for the commands in the events.txt file and then copied and pasted those over to the PFC.MCRO file making sure all Mobiflight commands had been erased or replaced. The unit is fully functional now and I am very pleased. It has been quite the learning curve working with it. I thank you John and Peter for your patience and guidance. I have attached the PFC.MCRO file
-
It sounds like you are getting this to work on your computer. I did notice that the Mobiflight commands I am using are not coming from an events.txt type file, they are in a .evt file. I have attached the two files I have in my FSUIPC folder for Mobiflight events. Do I need to define these commands in another way?
-
Changed names in PFC.MCRO by copying and pasting from PFCmacroIndex.csv
Still no joy getting it to work. I am out of time but will continue working with this later tonight (my time), and switch back to the events.
-
OK... I just changed all the assignments to the one I know works and found that only the CDI button is working. I had renamed based on an earlier test run with the HIDtest but will change back to the ones listed earlier and retest.
-
7 minutes ago, zfehr said:
Here are the log files. It would seem only the CDI button press is being picked up. I am sending the current PFC.MCRO file as well.
PFCHidlog.txt 8.84 kB · 0 downloads PFChid64.ini 450 B · 0 downloads PFC.mcro 1.19 kB · 0 downloads FSUIPC7.log 78.57 kB · 0 downloads FSUIPC7.ini 27.11 kB · 0 downloads
I changed the events that weren't working to presets per your instructions and this is the new FSUIPC.log
-
Here are the log files. It would seem only the CDI button press is being picked up. I am sending the current PFC.MCRO file as well.
-
18 minutes ago, John Dowson said:
Maybe also a good idea to monitor the macro execution offsets to check the dll is sending the correct data. Use Log->Offsets and monitor 0D6C as S16 and 0D70 as AsciiZ and check Normal log file.
36 minutes ago, John Dowson said:I have checked this now and using both add-on events and presets in macro files seems to work as expected, and for presets you can either use the preset control number or the preset name itself (i.e. <indexNo>=<macroName>=CP<presetName>, <parameter>) which is preferred - and easier.
So I am not sure why the add-on event is not being sent for you. Could you activate logging in FSUIPC7 for Buttons & Keys as well as Events, and generate a short log file where you try an execute a macro using an add-on event. You can also try this with the logging console window open (Log->Open Console) and see if anything is logged. Also maybe try with presets, presuming you have the FSUIPC WASM installed and enabled. To do this, for example, you would change your macro entries from, for example:
to
John
Will be able to do in a couple hours.
-
31 minutes ago, John Dowson said:
I will get back to you once I have checked. If its not working correctly at the moment, as I suspect, I will update to get this working and give you an updated version to test, but this may take a day or two.
John
I have waited since the release of MSFS2020 for either RealityXP to be compatible or a functional enough GNS530/430 simulation (like the Working Titles) that would allow me to use this expensive hardware with. I can certainly wait a day or two more.
Thank you.
-
1 hour ago, John Dowson said:
No - the event files are just used by FSUIPC, not by the PFChid64.dll.
The WAPi is also only used by FSUIPC, not by the PFChid64.dll. And you don't need the WAPI/WASM if using add-on events, as you seem to be using. The WASM / WAPI is only needed if using presets.
Your issue seems to be that the add-on events are not working when being used in a macro file. This surprises me but I will check this and get back to you.
Note that it is probably easier these days to use presets rather than add-on events. However, I am not sure if calling presets in a macro file is implemented (although it should be!).
I will check all this and get back to you.
John
The MSFS Garmin GNS530/430 don't have presets that I am aware of since it started out as an add on from Working Titles. Mobiflight utilized WASM and FSUIPC to allow home cockpit builders to operate but through those events. Those are the only commands that would make sense to use on this facsimile of a Garmin GNS430 face.
-
1 hour ago, Pete Dowson said:
And now I am almost 80 years old and retired it is really not in my capability to support it to the level you need. I know PFC switched their support to X-Plane, and are no longer interested in the FS series nor P3D.
Sorry.
Pete
Your work is appreciated and we are fortunate that it still works in Windows 10. I've owned the PFC hardware since 2007 and with over 3,300 hours on the Hobbs I am lucky it all still works... I've replace a couple switches that wore out, replaced a couple broken springs for the yoke, replaced worn out pots in the rudder pedals, and recently the circuit board stopped reliably sending power to the radio stack but fortunately the radio stack can be powered independently. The replacement cost is staggering!
-
Didn't work. Added:
[WAPI]
EnableWAPI=Yes[EventFiles]
0=MobiFlight-Events1
1=MobiFlight-Events2to PFChid64.ini and made no difference
Hopefully John will have some ideas.
-
The idea popped in my head today at the office. Possibly the PFChid64.ini needs the lines:
[EventFiles]
0=MobiFlight-Events1
1=MobiFlight-Events2Just like FSUIPC.ini needs them.
I'll try that when I get home.
-
44 minutes ago, Pete Dowson said:
Because the frequency being set was written to the Standby, and the Swap does its job.
Which implies that the Swap button isn't doing the right thing, as you seemed to be saying and what I am calling odd.
As it says in the PFC DLL documentation:
Note: All of the avionics buttons, knobs and switches can be re-programmed in FSUIPC’s “Buttons” section when using
FSUIPC version 3.30 or later. See the section about Button and Switch Re-programming later in this document.So you could program it there. You'd probably need a small Lua plug-in. For a swap just copy the ADF standby offset to the ADF active offset.
Pete
But I have tried assigning the swap frequency command to the button on the hardware and in doing so many of the hardware functions no longer work correctly for the ADF in the radio stack. Unfortunately that is not an option that works. In the PFCCom64.ini file I see entries for COM, NAV, and ADF1 ADF2 with alpha-numeric codes. Do those have anything to do with how FSUIPC sends their function to the sim?
This:
COM1sb=9349
COM1na=8848
COM2sb=9349
COM2na=9349
NAV1sb=5008
NAV2sb=5008
ADFsb=2192
ADFxsb=0
DME=2048
ADF2sb=0
ADF2xsb=649 -
Thank you. It is confusing since the commands work in FSUIPC and the C6#### commands do work in PFCCom64.
-
The physical radio stack works perfectly. The COM and NAV radios function correctly sending the frequency to the active frequency in the sim when you press the swap button. It is just the ADF that sends to standby in the sim unless the radio in the sim doesn't have a standby frequency feature in it. Is there a choice in the programming that allows one to choose between the ADF hardware sending to the active or standby?
-
I just tested this in an aircraft which has an ADF that does not have a standby frequency and the PFC Radio Stack ADF does send the signal to the active frequency (only one available) in the sim. The problem only seems to be if the aircraft one is using is equipped with an ADF that has a standby frequency so I am not sure how this is a PFC tech support problem.
-
I am not having a Mobiflight support problem. Mobiflight has the inputs to control the functions of the Working Titles Garmin GNS430/530 which is now what MSFS is using. It uses WASM and by sending a control input from FSUIPC it can then get the desired control in the sim. The control inputs I am entering into the PFC.MCRO are the same control inputs currently working in the PFC radio stack reprogramming the buttons available on its simple early GPS emulation, they are not in the placement of the Garmin units and not all buttons are replicated.
I copied and pasted the commands from my FSUIPC.ini file into the PFC.MCRO file. Those commands work in FSUIPC but do not seem to in PFChid64. Is there another way to input the commands so they will work?
-
1 hour ago, Pete Dowson said:
The button presses are read by PFChid64.DLL, not by FSUIPC. It is PFCHid64.DLL which is then obeying your macros, none of which are trying to send button press signals to FSUIPC.
You should use the PFChid64.ini option "LogMacroNames=Yes", which will log recognised buttons and give you the correct macro name for it.
You need + at the end of a macro name for the PRESS and a - for the RELEASE. If you leave that off you'll be executing the same macro for both press and release.
Pete
Thank you. I had already made a log based on reading an interaction you had in December trying to get a PFC C2 to recognize button presses. I have attached the log. Found I had to leave out the ENCODER_430_530_ or BUTTONS_430_530_ part of the name. I only get the CDI button to work but that is using C66375 which is native to MSFS for swapping between NAV and GPS. The C3#### codes for the Mobiflight.AS530 don't seem to do anything.
-
I have reviewed pages 4 and 5 of the PFChidDLL User Guide regarding Macros, and the FSUIPC7 For Advanced Users pages 17 and 18 regarding Format of Button Definitions for macros, and finally pages 35 and 36 regarding Macro Controls. After much trial and error I came to understand the instructions well enough to write this PFC.MCRO file. FSUIPC does not read any button presses when I attempt to use Assignments Menu for Buttons and Switches. I do have one minor success though, after manually entering the text the CDI button works momentarily... as long as it is held down it will change the source from GPS to VLOC. When I release the button it reverts. I believe from testing the PFC Test GUI program that the buttons send a signal upon pushing and another signal on release. The other buttons do not respond but they are programmed for Mobiflight commands I believe through WASM.
PS: I changed the parameter from 0 to 1 which made no difference. The PFC 430 sends a command upon pressing the button and again upon releasing the button.
-
11 hours ago, John Dowson said:
These are Pete's comments on this:
I have attached my .ini and .log files for FSUIPC and PFCcom64. The photos show the settings used in PFCcom64 relating to the ADF. Starting with IMG_1602 the PFC radio stack is in its default state with the ADF showing the current frequency on the left and the elapsed time on the right, press the FRQ button once and the time changes to standby frequency. press the BFO button per my settings and the ADF changes to ADF2 and the center light indicates this (now the frequencies shown and sent will be to the second ADF radio if so equipped). Press the ADF button and per my settings the radio shows the extended frequencies (used in Europe). You can see on the sim when I press the swap frequency the hardware is sending to the standby frequency in the sim and does not swap the frequency within the sim... only on the hardware do I see this. This may be a limitation imposed by having the hardware functionality for two ADF units.
If I program the FRQ button on the radio stack via FSUIPC to swap ADF frequency the functionality of the hardware gets all confused and doesn't work correctly.
Very few aircraft in MSFS simulate dual ADF radios. I find it much more challenging and hence rewarding to fly an IFR NDB or Lctr approach especially with 12 knot or higher crosswinds. Oostende Belgium has a very interesting approach that utilizes three NDB's, Croatia has many as well, Rijeka has one that when coupled with the STAR utilizes four! Keeps ones skills much more honed than watching the magenta line on the Garmin video game display!
PS. The photos did not load in order.
-
9 hours ago, John Dowson said:
Pete took a look and it seems that the PFC430 is recognised/supported and can be used with the PFChid64 driver, but no default actions are supplied and you need to provide these yourself via the PFC.mcro file. From the PFCmacroIndex.csv file, these are the macro names you need to define for the buttons (3rd column):
and for the encoders:
John
Thank you... I am looking forward to tackling this tonight.
-
1 hour ago, John Dowson said:
Good luck with that!
JetBrains DotPeek said neither the TestGUI nor the rxpgnsdriver were supported so that answers that question!
-
Just now, John Dowson said:
Ok, some progress... But did you see anything registered in the button assignments window? I don't think so, as the button state reported is always empty:
So no virtual flag would be triggered. However, it does look like something is changing, as the actual 'data read' is different, so you could perhaps do something with this, but that could/would be quite complicated - especially for a non-programmer, or someone who doesn't have the device...
I know. I wonder if I am up to getting a decompiler and seeing if opening up that rxpgnsdriver.dll would reveal anything to me?
PFC.MCRO file for use with PFC430 hardware with MSFS2020
in User Contributions
Posted
Allows operation of the Microsoft/WorkingTitle Garmin GNS530 via the button presses and knob turning on the Precision Flight Controls PFC430 hardware. Must have current PFChid64 installed.
PFC.mcro