John Dowson

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.

They don't seem to be working, and neither the Moboflight events for those lvars. They are documented as being 'not tested'. Maybe ask on the FBW forums if there is a way to control the batteries. It was reported in the other post you raised that it there are some simvars that may allow you to read the battery state, although these are currently not accessible using FSUIPC7. If those simvars (or a variables) are writable, I could add them to offsets. But best to check with FBW how they should be controlled first.

Please DO NOT DO this. The resulting log file will be huge and useless. Turn all logging options off, unless I ask you to activate them. Please DO NOT post any video clips. They are useless to me. As I keep telling you, I need to see yout FSUIPC7.log and FSUIPC7.ini files at the time of the crash. Nothing else at the moment. I am just trying to determine if it is indeed FSUIPC7 that is crashing. Once I have this basic information, we can go from there. Just follow my instructions for now please.

Yes, sorry. I thought you wanted your buttons.profile section to replace your buttons. Button and key assignments are cumulative, so it takes the general section first, then augments (i.e. replaces or adds) with your profile assignments. So, the correct way would have been to add any of your button/key profile assignments to the general button and key assignments section. also changing the index numbers to make sure they are unique. And the calibration section depends on how you calibrated your axis, whether in a profile or not. Anyway, just FYI. Glad you sorted it out.

If it is FSUIPC7 that is crashing, I will look into it. However, I suspect not. If FSUPC7 is the culprit, there will be a crash event in the logs (NOT a fault event), and there shouldn't be any other events from MSFS or SLC, and the FSUIPC7.log file will show that it did not exit properly. I need to see this log file to see if it did crash and if so what it was doing at the time (may need extra logging added). Onve it is confirmed that it is FSUIPC7 that is crashing, we can proceed from there. However, it has been reported many times that FSUIPC7 is causing MSFS to CTD, and in each case I have so far investigated the problem has been else where.

If you run FSUIPC7 before you start MSFS, you can disable that option. MSFS will also try to start FSUIPC7 (if configured to do so), but that attempt will fail and you may get an error, but you can just ignore that. Let me know how it goes once you have updated/re-installed.

You are using a very old version of FSUIPC7. Please update to either the latest supported version, v7.1.0, or the current beta, 7.2.0. Also, the defaults in the [General] section of your ini are quite old and should be updated. The best way to do this is to remove everything under the [General] section of your FSUIPC7.ini and let that get rebuilt.

Ah, I forgot one thing about the 'Exit with FS' option. If/when FSUIPC7 is automatically started by MSFS, then the 'Exit with FS' option is automatically checked (and the 'Exit with FS' menu option removed). This is necessary as otherwise MSFS will not close down correctly with FSUIPC7 still running.