John Dowson

You could try this user contribution for the Bravo leds: John

@FHamoudi No problem. I'll create a sticky topic for this so its always at the top of the forum and easier to find/see. The attached license is valid until 12th June: FSUIPC7.key

Which aircraft and lvar are you talking about? If you let me know I could possibly check it here - as long as its not an add-on aircraft. Note that not all lvars are writeable - some are read only, but its not possible to tell which without trying them (as far as I'm aware).

Just checked the MobiFlight spreadsheet to determine the state if the FBW events, and the FCU VS/ALT pull/push events are all documented as: dev version, soon on experimental (see https://docs.google.com/spreadsheets/d/1jTXlcHaJWx0B7TB63Pmma7bKwpxsxXJO6EJ3ECt7zpc/edit#gid=172455454) So these aren't working yet on the stable - and also not in the experimental. So, it sounds like you need the dev version for these to work at the moment, or maybe wait until it has been moved to the stable.

Also, just checked again, and it looks like those controls for the VS pull/push don't work, but the altitude ones seem ok, but please test. I'll keep looking for the VS pull/push....

What aircraft are you using? Your A320NX profile is only set-up to be used with the following aircraft: Airbus A320 Neo Alitalia 8K (A32NX Converted) Is this the old FBW A320 that replaced/augmented the stock one? If so, its vety old now. The latest FBW A320 is installed as a distinct A320 to the stock one, and is called: Airbus A320 Neo FlyByWire So, first can you check that you are up-to-date with the latest FBW release. Also, in your FSUIPC7.ini, you should change this: to this: to pick-up all variants (including the stock A320). If you don't want to include the stock A320 in your profile, you can adjust so that the name you enter is a substring match to only the FBW A320 (e.g. 1=FlyByWire). How have you assigned this? I see nothing in the ini you attached that does this... Once you have checked you are using the latest FBW A320, please try again. You can also open the console window (Log -> Open Console) to see which events are being sent when you pull/push the knobs in the UI, then try your assignment to these functions to see if they emit the same controls. You can attach your .log file (and updated .ini) with this logging if still not working.

Please don't create new topics for ones that already exist. You should have posted your request here: I will add a new trial license to that topic shortly, but it will be for 7 days or so. This topic is now locked.

If it appears (and has disappeared) from a PMDG menu, you will ask to ask PMDG support I'm afraid. I don't have any PMDG aircraft and didn't even know FSUIPC appeared in a menu option there (or what that option does!). If it appears in the add-on menu for P3D, then it is installed and running ok. No idea what the issue could be. Was your TQ6 assigned through FSUIPC6? What has changed? If it was previously working, something must have changed. Please show me your FSUIPC6.log and FSUIPC6.ini files. John

I can't read those images. Please show me your FSUIPC7.ini file.

Ok, thats good. What did you assign to for these? Did you try what I suggested: ? That won't animate the knob, but should hopefully activate what you have set. Not much point at the moment - an explanation and your ini and log files is usually more informative than a video. How are you assigning to push/pull the knobs?

I have released another beta, v7.2.0d. Please see the Announcement: Hopefully this will be the final beta. I am planning to update the documentation (to include an example on how to use the lvar offsets functionality as it seems not to be clear) and will make this the official version later this week (or over the weekend). John

I think its best to allow offset 0818 to be written to in feet, as this can then be used directly with the AP_ALT_VAR_SET_ENGLISH control. I have updated FSUIPC7 for this and will release in the next few days, when I release v7.2.0. O will release this as v7.2.0d (beta) today via the 7.2.0 beta announcement page. With this implemented, you can write a lua script to inc/dec the selected altitude. To do this, you should use the lua event.button function to assign the button, rather than the UI. The handling functions should: - read the current setting from offset 0x0818. This will be in meters*65536. - convert the value read to feet by dividing by dividing by 65536 (to get metres) then multiply by 3.280839895 to convert to feet - then adjust the value by the increment/decrement amount (in feet), taken from lvar L:XMLVAR_Autopilot_Altitude_Increment - write the resulting value back to offset 0x0818 I can provide such a script if you like. I can look into this after I have released the pending changes in both FSUIPC6 and FSUIIPC7, probably next week. John

Hi Bruno, so basically your throttle is being recognised by FSUIPC5, neither your buttons or axis? Could you show me/attach your FSUIPC5.ini, FSUIPC5.log and FSUIPC5.Joyscan.csv files please. Also, if you have installed any Saitek software or drivers, best to remove/uninstall those and use the windows default drivers. John

Sorry, this is wrong. Using the AP_ALT_VAR_SET_ENGLISH control does work and updates the displayed value and changes the AUTOPILOT ALTITUDE LOCK VAR:3 variable with the provided parameter. Offset 0818 is currently read-only, so updating the offset directly won't work (although I will look into updating so that writing to the offset triggers the AP_ALT_VAR_SET_ENGLISH control). The problem will be how to determine the correct parameter value to send with the AP_ALT_VAR_SET_ENGLISH control. the parameter is the value to be displayed (in feet), so you would need to read the displayed value, which is in offset 0818 but in metres, so you would need to convert this to feet, and add/subtract the appropriate increment/decrement and then set the value. You could do this in a lua script but it may be easier if I do this by enabling writes to offset 0818. I will look into both.

I'm not sure what caused your original issue. If you are using the PMDG SDK, it could be related to the update, but I don't think that would cause those symptoms.

First, sorry for the delay. For the VS speed knob, you can try the following: For increment/decrement (rotating the knob), try assigning to AP_VS_VAR_INC AP_VS_VAR_DEC both with a parameter of 3. For the Pull, assign to AP_PANEL_VS_ON with a parameter of 1 on press, and AP_PANEL_SPEED_HOLD with a parameter of 1 on release For the Push, assign to VS_SLOT_INDEX_SET with a parameter of 1 on press, and AP_PANEL_SPEED_HOLD with a parameter of 1 on release They seem to have the same affect as push/pulling the knob, but I'm not 100% sure on this, and there is no animation of the knob when sending these. The Altitude knob seems more complicated. The inner knob, which changes the inc/dec values between 100 and 1000 can be assigned by using the lvar XMLVAR_Autopilot_Altitude_Increment with a value of 100 and 1000 respectively. The inc/dec controls use the AP_ALT_VAR_SET_ENGLISH control, but this doesn't seem to have any affect when I assign to this. This actually changes the AUTOPILOT ALTITUDE LOCK VAR:3 which is held in offset 0818, so you could try adjusting this directly. I haven't tried this. However, changing this does not seem to have any affect either. Pulling the altitude knob sends a ALTITUDE_SLOT_INDEX_SET control with parameter 1, and pushing the same control with a parameter of 2. You could try assigning to those. Note that there are the following additional events provided by FBW for their A320: VSpeed: A32NX.FCU_VS_PUSH - (>K:A32NX.FCU_VS_PUSH) A32NX.FCU_VS_PULL - (>K:A32NX.FCU_VS_PULL) A32NX.FCU_VS_INC - (>K:A32NX.FCU_VS_INC) A32NX.FCU_VS_DEC - (>K:A32NX.FCU_VS_DEC) A32NX.FCU_VS_SET - ? Altitude: A32NX.FCU_ALT_PUSH - (>K:A32NX.FCU_ALT_PUSH) A32NX.FCU_ALT_PULL - (>K:A32NX.FCU_ALT_PULL) A32NX.FCU_ALT_INC - (>K:A32NX.FCU_ALT_INC) A32NX.FCU_ALT_DEC - (>K:A32NX.FCU_ALT_DEC) A32NX.FCU_ALT_SET - ? I've also tried these but without much luck. I've attached the FBW FSUIPC event file for the additional events, in case you haven't got it - just drop it into your FSUIPC7 installation folder and it will be picked-up the next time you run FSUIPC7, and the additional events will be available for assignment. But, as I say, I haven't had much luck with those - you may want to ask about them on the FBW support or discord channel. There are also various additional MobiFlight events for the control of the FCU VS and ALT. Generally the MF events just set lvars or activate lvars, bur they can also contain more complicated code, which you can also use in FSUIPC via the ipc.execCalcCode lua function. However, it may be easier to try the MF events directly, but to use these you will need the MF WASM module installed, and make the events you want to use known to FSUIPC7 via adding an event file (like the FBW one, but for MF events). Sorry I can't be of more help. I'm not that familiar with the A320 (any version), so you may be better off asking directly on the FBW forums/discord channel for further information, especially why the events they provide don't seem to be working. Here's the event file: flybywire-aircraft-a320-neo.evt (thats from https://github.com/flybywiresim/a32nx/tree/master/docs, where you may find more info). Please report back if you find out anything more. I will also take another look at the altitude inc/dec via offsets when I get time, but not being familiar with the A320 I'm not sure about the managed/selected modes and the slot index variables, etc. I think that there is also another simvar like this, AUTOPILOT VS SLOT INDEX, bit this isn't currently requested or available in the FSUIPC offsets. I could add this if useful. John

As you found, you cannot do this using the FSUIPC [Programs] ini section. The only thing I can think of is to try lua. You could monitor for the push-back event (maybe TOGGLE_PUSHBACK, number 66483 - or log events to see what control and control number is used) and then use event.control to wait for the event. In your handling function. you can try using the (inbuilt) lua os.execute function to run VLC. I'm not !00% sure if this will work as I haven't tried/tested to see if the os.execute function is available and working. Please report back if you get this to work!

Axis controls are only sent when changed by more than the delta value, which is by default set at 256. This should be sufficiently small enough to not notice the small increments, but if you notice this you could try reducing this delta. You can adjust this in the Axes Assignment dialog panel. Try reducing that to see if this helps. Another thing you could try adjusting is the PollInterval (in the main [Axis] section). The default is 10ms. You could try reducing this, maybe in conjunction with adjusting the delta value, but try with just the delta adjusted first.

I have added a new ini parameter for this in the attached version, v6.1.2d. To hide your registration details, add the following ini parameter to the [General] section of your FSUIPC6.ini file: HideRegDetails=Yes FSUIPC6.dll

Ah, ok. In FSUIPC7 this has been moved to a separate pop-up window. I think I still need to keep this information available/visible for most users. However, I can add a new ini parameter that will hide this information. You don't say which version of FSUIPC you are using, but this would be for FSUIPC6 only (as FSUIPC4 & 5 are now closed for future development).

I think thats just the way they behave -they are 'momentary' after all. But they should have some affect - those ones I mentioned for the battery don't seem to do anything. As I say, probably better off asking on the FBW forums. If you get a solution or an answer, please report back! Thanks for the link - hadn't seen that FBW documentation, useful...

Your log shows that FSUIPC7 exited normally as MSFS stopped running: The event you see in the event viewer is produced to to MSFS crashing. You should check to see if there are any other events relating to MSFS crashing. Note that if FSUIPC7 is started by MSFS (the default), it will ALWAYS exit with MSFS, so if/when MSFS crashes, this causes FSUIPC7 to close and also sometimes generates events in the event viewer. If FSUOPC7 did crash, it should/will not cause MSFS to crash - it is a separate executable after all. If/when MSFS crashes and FSUIPC7 closes, please check your FSUIPC7 log file. If you see that FSUIPC7 has exited gracefully (from the end of the log), then FSUIPC7 did not crash. You need to report the error to Asobo.

Blimey, why is it so large - what logging do you have activted? You could try zipping it - it should compress pretty well, but maybe not enough. Please try that first.

But as I have said 3 times now, what you are double-clicking IS NOT FSUIPC. It is a link to a batch script, installed oprionally by the FSUIPC7 installer, that: - displays a splash screen - starts MSFS It is then MSFS that starts FSUIPC7. If you want to start just FSUIPC7, you have to double-click the FSUIPC7.exe But what has this got to do with your CTD issue?

Could you maybe explain how you have assigned your AP Vertical Speed and Altitude buttons (i.e. rotate for inc/dec, and push/pull for setting/?). This is for the following support request (that I also need to look into): Thanks.