John Dowson

Thanks @Fragtality - I agree completely - the PFC driver must be monitoring either an offset or a control to know when to activate the displays (or turn the PFC on...). And I think this is the salient point: as the OP said it doesn't work like this as for all other planes, BUT the OP bound a button to activate this. So, if the OP could share what that assignment/binging is, then this may shed more light on the issue... Useful to know that he Fenix IS updating those offsets, so it can't be those. If its an event, which it seems likely, then it may be that the Fenix is just ignoring that event. You can send the event, but if its not handled, it won't be received (or logged) by FSUIPC - or the PFC driver. Logging would show this - i.e. if the OP tries the script you kindly provided and checks if the event sent is logged. Pete wrote the PFC driver, many years ago, in agreement with PFC. I have access to the source via github, but I really don't want to support this - it should be PFC that do this. I can maybe move the driver source across to my account and make it public if needed (and possible - I would need to talk to PFC).... I may take a quick look to see if there is anything obvious, but windows hardware drivers are an area about which I know next to nothing, and don't have the time (or inclination!) to do so. John

But this is what is confusing - there is no such button/switch. Control are only EVER sent to the FS, not to controllers. And the only thing to turn your stack on would be a power button on the stack itself. If pressing buttons on the stack are recognisd by FSUIPC, it must be ON.. But, I am now assuming that the problem is that the displays are not active for some reason... So, the PFC device must be monitoring an offset to determine when to light up the displays, and maybe this offset is not being populated by the Fenix? Have you tried monitoring the avionics master switch offset (0x2E80 or 0x3103) to see if those change value when the avionics are on in the aircraft? Or maybe the master battery offset (0x281C)? Maybe the PFC is waiting for one of those offsets to change to 1 before activating the displays (or 'turning on'). If that is the case, you could try either configuring your PFC hardware/driver to use a different offset, if that is possible, or maybe by spoofing the offset using lua, although I am not 100% sure the spoofing facility works if not being read from an external program, but you can try (see offset 0x0024). It would really help if you could respond to all of my questions - you seem to ignore most of them for some reason. Can you PLEASE explain what your binding is for the FBW that you use to get this to work - this would help enormously as, as far as I can tell, you have the same issue in the FBW without this binding. If I know what that is doing, it could shed some light on the issue with the Fenix (i.e. what is being used to trigger the displays).

Why are you using the right hand side? Axes are assigned on the left hand side...try that... You didn't need to do this - this is what I did to see what control to use. I mentioned that as that is how you determine what control to assign an axis or button to.

No, lvars should be available regardless of whether you are adding them to an offset or not. They must be available before they can be added to an offset, otherwise you would get an error when trying to add them to an offset. So something else must be going on, although I have no idea what... Are you sure that this is not just a timing issue - you have to wait for lvars to be received and available before using. I suggest that you retry with the logging console open (and set Debug level logging for the WAPI), and then you can see when the lvars become available. Or, if it doesn't work (without the lvar being added to an offset), wait a short while and try again. It is really the FSUIPC7.log file that will tell you what is happening, with appropriate logging enabled. I have no idea, sorry - check your SIOC documentation.

Why do you think FSUIPC7 is crashing? Do you have a crash report? Have you checked the FSUIPC7.log file? Are you aware that FSUIPC7 is iconised to your system tray once started? You can open the main window using Alt+F. Please see the User manual. John

ok...whatever works for you... This topic may be of interest - how to convert BCD to decimal in lua: John

This has not been "abandoned"... There is Plane Altitude, held in offset 0x0570: and also Indicated Altitude held in offset 0x3324: These offsets just hold the values as received from the FS. If the altitude reported in the offsets is 'way off', then this is an issue for Asobo - FSUIPC just reports/stores this data as received from MSFS. Check the Asobo forums - there are many reports on altitude issues, for example, see the following: https://forums.flightsimulator.com/t/incorrect-altimeter-readout/479399 https://forums.flightsimulator.com/t/if-qnh-is-lower-than-983-altitude-is-shown-incorrectly/470898 https://forums.flightsimulator.com/t/temperature-and-altitude-reporting-are-not-fixed-with-the-patch/431354 Note there are also two additional altitude simvars which are not held in FSUIPC offsets: PLANE ALT ABOVE GROUND Altitude above the surface PLANE ALT ABOVE GROUND MINUS CG Altitude above the surface minus CG If those are of interest, they can also be added to FSUIPC offsets - see the Advance User guide. John

If the server/client network addresses (or names) have changed, and you are using these in your Wideclient.ini (using the ServerIPAddr ini parameter) then you need to update that. Also, check that both client and server are in the same windows WorkGroup. You may also need to check your firewalls and add exceptions for the new server/client addresses. You can always temporarily disable any firewalls to test the connextion and to see if the firewall is an issue. If you are till having connection issues, and you are not using the ServerName or ServerIPAddr WideClinet.ini parameters, then I suggest you try adding them (ServerName preferred). You should really consult the WideFS documentation provided as all this is explained there, although in English I'm afraid... Regards, John

Glad you answered your own question! Not sure why you are reading the lvar value though...Presumably that is held in offset 0xA014, and so you can access that directly as a parameter of your event function.

Presumably the solution indicated above, i.e. by assigning the throttle lvars to offset, assigning your axes to those same offsets, and then scaling correctly. It is the actual scaling that @505Northman used that is missing as I gave several options...maybe he could respond... Otherwise, try setting up as detailed in this post and try the various scalings I provided to see which work... John

No, I only update (i.e. include the latest events.txt file) when I release a new version of FSUIPC7. You should not add them manually, you should download the latest events.txt file from https://hubhop.mobiflight.com/presets/, and use that to replace the one in your FSUIPC7 installation folder. Just click the Export presets button, followed by the events.txt button. You need to login to do this (create an account first if you haven't already). John

The log file you attached stops after 11 seconds...you really need to give more time. Did you have an aircraft loaded and ready-to-fly? Not according to the log, but as I say that stops after 11 seconds. Are you auto-starting FSUIPC7, or starting manually (and if so, why)? If the WASM menu items are disabled, this implies the the lvar information has not yet been received by FSUIPC7. This is only done once the aircraft is ready-to-fly (and after the LvarScanDelay period set). You are also using a very slow lvar refresh rate (Second). I suggest you change this to 6Hz. And please, always exit FSUIPC7 before attaching a FSUIPC7.log file. And the PMDG 737 takes an awful long time to load - be patient... John

No. What is FSUIPC actually doing? How are you 'using' the program? FSUIPC does nothing unless you tell it to. You really need to provide more information on what you are doing and what your issue is. John

What is this binding/assignment? Do you have anything assigned in the Fenix to turn the batteries on? If not, assuming the lvars are writeable, you can create a preset (in a file called myevents.txt file) to set the battery lvars, e.g. Fenix_A320_Batteries#$Param (>S_OH_ELEC_BAT1) $Param (>S_OH_ELEC_BAT2) Then assign to Prefix:Fenix A320 Batteries with a parameter of 1 for on and 0 for off. Alternatively, you can create separate presets for each battery, and separate presets for on/off if you prefer. The lvars.txt is one of the files I was after - I don't need to see your events.txt file (I have that) - I want to see your FSUIPC7.log file, generated with logging for events activated (in FSUIPC) and you turning on the avionics in the cockpit UI (as I asked for...). This would show any events/controls used by the avionics. It may also be useful to list the lvars before doing this, and again directly after. Comparing the two lists would then show if/what lvars have changed values. It may be obvious to you what your issue is, but it really is confusing to understand reading these comments.. I assume that you need to bind something (a switch or button) on your PFC stack to turn on the avionics in the aircraft, so lets try and sort that out first. And, from what I understand, you issue is nothing to do with PFC, it is the Fenix that is missing a function to turn the avionics on. The binding/assignment that does this for you in the FBW may help us understand... There also seem to be many presets already available for the Fenix (41 for the avionics alone, and 344 for the electrical systems) - have you looked through the preset list to see if anything is applicable (https://hubhop.mobiflight.com/presets/)?

The more posts here, the more confused I am... I thought that 1 was applicable: you say the button is working, but stanfard controls (Avionics On, Avionics Set, etc) do not work. And so I thought that you are looking for an assignment that when you press a button on yout PFC Radio Stack this turns the aircraft avionics on. But it seems that 2 is correct, as you say: YES So, if this is the case, what is turning the PFC displays on for other aircraft? Is this looking at an offset value, and if so, which one? If you can explain how this is configured for other aircraft, then maybe we can help... If its looking at an offset to do this, and that offset isn't being populated for the Fenix A320, then there are solutions available, assuming there is an lvar or something that holds this state (e.g. you can spoof the offset to an lvar value, if you can't change the offset that the PFC hardware is looking at for this). BUT, I still find this confusing, as you say: So you manually turn the PFC on for the FBW when the avionics are on. But then: YES which sounds like you want the PFC display to turn on automatically when the avionics are turned on in the plane... I think we are going around in circles here and neither @Fragtality nor I have a clear understanding of the actual issue...or maybe its just me... Normal behavior would be that you press a button on your hardware, this triggers the control, avionics turn on in the aircraft and your hardware displays light up. Is it that this is the case in other aircraft, but in the Fenix the aircraft avionics turn on, but your displays stay dark? If that is the case, then you need to know what is driving the displays to be turned on - is this an offset value, and if so, which?

So do I...it may be ok to duplicate the lvar name (not sure), but your index numbers are '0.1' and '0.1' when they should be '0.1' and '0.2', so there is no way to distinguish between those entries. And as they are both setting the (same) lvar to different values, I do not know which one will be used, although logging should tell you. Better to use the correct format, or switch to using presets, as advised. John

Could you list the available lvars for the Fenix please: Add-ons->WASM->List Lvars and paste/attach here from the FSUIPC7.log or FSUIPC7 main window. Please wait for a minute or two after the aircraft is loaded before doing this. Also, could you activate logging in FSUIPC7 for events and turn the avionics on in the cockpit UI and see what, if anything, is logged (in FSUIPC7.log), and also post that here. Thanks, John

Why are you creating a new topic when there is already a topic about this which you have already posted in? Please use that topic. I am closing this one. You can re-post your question there. John

I do not understand why you are buying everything twice...you only ever need a single license - it is per user not per machine, so its gine to install on multiple PCs if needed. But thanks anyway! You can use your FSUIPC7 license if/when you move to MSFS2020... The WideFS7 license is needed if you want to activate WideServer in FSUIP4. However, as I said, you will need to use the WideClient from WideFS6 if running on a 32-bit OS. John

Re-reading the support forum post (which I have just moved from the User Contributions sub-forum to the FSUIPC7 / MSFS support forum btw), I am slightly confused about your issue... You say your issue is with an assignment to 'power up my PFC Radio Shack'. But that is your hardware - you power that up by pressing the power button on the hardware itself, no? Assignments are for linking your hardware controls to a cockpit UI control. You ask what to assign to, so I presume the controls on your hardware are being recognised by FSUIPC, no? But what is the cockpit UI control that you are trying to assign to? You say you this is working for all planes apart from the Fenix A320, so what, for example, is the assignment you have for this in the Asobo or FBW A320? That may help me (and others) to understand your issue.... John

From the Advanced User guide, P37: Your macro file is therefore (obviously, I hope...) not correct for various reasons, and should be and if you want to add the right pump. it would be: Alternatively, it is probably easier to use presets to control lvars these days as they are more powerful. To create presets for these, create a file (in your FSUIPC7 installation folder) called myevents.txt, and add the following content: You can then assign to the controls Preset:Milviz C310 Left Fuel Pump and Preset:Milviz C310 Right Fuel Pump giving an appropriate parameter in the assignment. Again, i advise you to consult the documentation provided. Maybe, but the format of the files you are posting is obviously incorrect if you check the format against that specified in the documentation. I am suggesting that if you find that things are not working, check the format against the documentation before posting. This would save us both some time! John

A license is only needed for the registered facilities - assignments, access to the lua interface, etc. No license is needed for the unregistered facilities (access to offsets for third-party programs and developers using the FSUIPC SDK, logging facilities). Of course, people can keep using the trial license and never purchase FSUIPC, but this is not the intention and I obviously do not approve of doing this. I always leave a few days after the expiry of a trial license before generating a new one, and I will not generate a new license on the request of a user who has obviously already been using the previous trial license. Thanks, but I have only been developing/supporting FSUIPC for around 4 years now - previously this was done by Pete, my father, who deserves most of the credit! Regards, John

I doubt they are following this...just me I'm afraid...and, as you say, FSUIPC is just the middleware in this set-up, and I don't think there is anything I could do to help with this... John

You don't need to download the MobiFlight connector - you can export the preset file (events.txt) from the MobiFlight HubHob site (https://hubhop.mobiflight.com/presets/) - this is mentioned several times in the documentation. You need to create an account, and that site is the community reference for presets, so you should familiarize yourself with that (and create an account!). Yes. This is documented in the Advanced User guide, under Using Calculator Code Presets: Ok, but maybe you could explain what your issue was in case others have the same problem... John

Those entries are incorrect - you also need to specify the size if the offset, This tells me that you have not read (or have not understood) the documentation. I therefore suggest that you read the documentation on adding lvars to offsets which is in the WASM section of the Advanced User guide. This should also tell you what you need to assign your button to. Please always check the documentation first before requesting support. John