Pete Dowson

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

I'd leave well alone. As this update works I shall make it the current release. Pete

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

It changes more rapidly in some parts of the world than others, and 2009 is 14 years ago! I believe it can get into double figures during such a period in NW America. Pete

The runway data provided in the runway files (Runways.csv, R5.bin and Runways.xml) does include the MagVar stated in the airport data file. If you have later MagVar figures you could use those, but the TRUE heading is still correct using the Mag Heading AND the MagVar supplied in the Makerwys data. TRUE headings don't change. I expect newer add-on airports will already have more up to data MagVars included. Makerwys is designed to extract and provide data from the airport files in BGLs. I'm sorry if this is not what you want. Pete

Before what? MakeRwys just reads what it says in the BGLs. That's never been changed. Maybe the MagVar at the time of the scenery build was 3 degrees different to now. Is MSFS using updated data but not applying this to the sceneries? Please note that MakeRwys is no longer being maintained. The source is now open to developers -- John will give you the details if you need them. Pete

MakeRwys assumes the format of the BGL files follow the decoding of clever folks on the website fsdeveloper.com. If modifying them destroys that format then MakeRwys won't be able to decode it. I suggest you extract the sections of the Runways.txt, T5.csv and G5.csv files relevant to your modified airport for me to look at. Maybe there's a clue there. Pete

I used a new shortcut with the command being "makerwys.exe />500" (with thee path to the exe of course) and it worked fine. Yes, on Win10. I always use shortcuts when adding parameters, then I can name them appropriately (like "MakeRwys All lengths"). There obviously mustn't be a space between the / and the >, else you'd certainly get the result you said. I can't imagine why Windows would interpret /> as just >. Pete

Right. I should have noticed -- the runway length is less than 1500 feet in those two airports (and in several others in the same BGL). See this in the MakeRunways README document: MINIMUM RUNWAY LENGTH By default MakeRunways imposes a minimum runway length of 1500 feet, otherwise runways are omitted from the data files. This is to eliminate so-called "ghost" runways being included -- very small runways provided only to allow AI Traffic to be directed better for landings and takeoffs. If necessary you can override this value. Just use a command line parameter in the form: />n where n gives the number of feet to be considered the maximum for exclusion. Take care not to make this too small for fear of including those "ghosts", but if you really do want to see all, you can set />0. Pete

Right, so there's no Runway information for those in the Runways.xml file either. I think there must be something missing in the BGL definition for those airports. I'll try and find time to take a look at the BGL in the next few days. Pete

Well, there would be no F5 entries as there doesn't appear to be any airport frequencies in the BGL definitions. It looks like MakeRwys cannot compute the actual start point, which involves the threshold offset. Could you show me the relevant sections of Runways.xml? My MSFS installation is not only out of date, but the PC it is on is out of commission at present pending some changes I was planning. So, it would help if you count ZIP and send me the file involved: Official\OneStore\fs-base-genericairports\scenery\0502\APX46170.bgl Pete

I would need to see the relevant sections of the Runways.txt file. That is the log of the analysis made. Are they default airports? Pete

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

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

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

To my surprise I received a reply from PFC already (didn't expect a response till the New Year). It seems that, though the Avionics stack is now composed of several separately identified devices (it used be be all integrated), the actual units behave the same as the older ones. This being so, I assumed it was therefore only a matter of recognising these new units and decoding the inputs in the same way. I've made such changes, but I don't know if it is really that simple -- especially regarding the displays and indicators. Perhaps you could try it and let us know. Make a safe copy of your existing PFChid64.DLL and replace it by the attached version. Try it with the same PFCHid64.ini logging options as before, and let us see the resulting Log when you try things out. Also note what you see on the displays and indicators, if anything actually does show. I'm not convinced it will work. The code is very complex and I've not delved too deeply. But it's worth a try, just in case! Pete PFChid64.dll

Radar Contact takes care of that automatically, but make sure you are allowing 'Information Text' to show. It's a P3D option, normally defaulted 'on'. Pete

Just checked. The mask details the actions relevant to this control/button, thus: #define MFNOSEL 1 // Selection digit used or not (if not, param) #define MFNSEL0 2 // 0 #define MFNSEL1 4 // 1 #define MFNSEL2 8 // 2 #define MFNSEL3 16 // 3 #define MFNSEL4 32 // 4 #define MFPLUS 64 // + #define MFMINUS 128 // - #define MFFASTP 256 // > #define MFFASTM 512 // < So, it details the suffices relevant to the macroname -- a selector number, an increment or decrement and for the latter whether a fast (higher value) or normal change. The way these are encoded into the full macroname is documented in the PDF.

I think that Mask value is for something different. You want the driver to log all reads as well as writes? Better done in FSUIPC, really. The more important clue is in the line before: 224094: Device #1 received: LandingLight[0] = 0 So, the switch is being turned OFF (0). The previous entry shows it being turned on (1). The entry right at the beginning was missing an IPCwrite log because the switch in MSFS must have been OFF already: 76235: Device #1 received: LandingLight[0] = 0 76235: Full macroname for decoded switch = "PFC:LandingLight", mask = X00000000

The log entries following the one I showed are: 224094: Device #1 received: LandingLight[0] = 0 224094: Full macroname for decoded switch = "PFC:LandingLight", mask = X00000000 224094: ... IPCwrite 0D0C[2] = 1011, 0x3F3 So it is only bit 2 changing.

Good. I also see why the first LandingLight switch operation didn't send and IPCwrite. It's a toggle action on a bit in 0D0C. So the driver would read it first to send the toggled result back -- it must have already been set correctly. Later there's this: 223750: Full macroname for decoded switch = "PFC:LandingLight", mask = X00000000 223750: ... IPCwrite 0D0C[2] = 1015, 0x3F7 to toggle it the other way.

No, there's no issue other that creating a growing log as it retries. There were so many other entries now that I hadn't noticed that error repeating every few seconds, so widely spaced. Interesting -- not sure what happened to the IPCwrite line for that particular switch, but most are like this: 76375: Full macroname for decoded switch = "PFC:Obs1", mask = X00000000 76375: ... IPCwrite 0C4E[2] = 1, 0x1 The IPCwrite line shows the offset (0C4E in this case), the size (2 bytes, i.e 16-bit), and the value, in decimal and hex. I think it might be better for the OP to change these lines in the INI LogDevices=No LogDeviceChanges=No to avoid clouding the issue with all that Device information. If the LandingLight switch still shows no offset I'll need to look at the source to see what it thinks it is doing. This line is also a little odd: 76156: ... IPCwrite 0000[16] = -1655080864, 0x9D597860 The 16 bytes at offset 0000 are marked in my list as "Reserved for diagnostics". I've a vague feeling I used a mechism here to allow by to test paths through the driver without the requisite hardware attached. Seeing that these two odd lines are right at the start I'm thinking they were somehow before the driver thought it was okay to write to offsets. I don't see any other recognised switches without accompanying IPC write lines -- more than one such in some cases. An entry in the MCRO file is merely used to override the default action. By default most, if not all, switches on a Cirrus do have actions programmed into the driver, mostly via offsets (maybe all, I don't remember. The logging of the full macroname just shows the macro which would have been executed if one was present in the mcro file The driver would send the request via offsets (0D70 etc). If there isn't one, it does it more directly as stated. It also handily shows what function the operated switch is recognised as performing. Hope things are clearer for you now?

It also occurs to me that many offset changes, such as those instigated by the PFC driver as a result of you operating switches, will cause it to send Events ("controls") to MSFS. So, you could enable non-axis Event logging in FSUIPC's Logging tab, and check the FSUIPC7.LOG file after operating your switches etc. Pete

Must have been okay as there are no errors for it logged. Yes, they all appear to be doing the correct thing. They operate the Sim via FSUIPC offsets, and the latter should work. They don't need assigning in FSUIPC, so you won't see them there. Did none of them actually do what they are intended to do, in the MSFS cockpit? The offsets look correct, but they'll be the ones which work in FSX and P3D. It is possible that some aren't implemented in MSFS -- or just aren't present in whatever aircraft you have loaded. I'll have to leave that latter check to John, but you'll need to state the aircraft in use, and double-check that they don't work. I can see some which would be common to all aircraft -- eg the battery switch. If any of the offsets have changed then you'll need overriding macros added to PFC.mcro. If you are using a complex add-on aircraft such as those from PMDG then I suspect they will all need overrides, to use the special controls added by PMDG for their aircraft. For wholesale changes it might be easier to use as set of overrides which operate FSUIPC's "virtual buttons". Then you could do the real assignments in FSUIPC. Pete

Your log shows a regular attempt to open the PFC.MCRO file, which is listed as the default file for FSUIPC macros. Try creating a small macro file containing just: this one line [Macros] and save it in the same folder as PFChid64.dll. I'm not sure why that log entry occurs as Macros are only used to override a default action taken on specific switches and buttons. The method of doing this is detailed in the user guide supplied. To work out why some buttons and switches aren't working, edit the PFChid64.ini file changing these lines: LogDecode=Yes LogIPCwrites=Yes LogMacroNames=Yes Then run the system and operate each button, switch or knob once. The log produced should then show what is actually recognised, and what action it assumes is needed. It may help you to set Console=Yes as well, so you can see on screen the results in real time. Pete