John Dowson

Can you please attach your FSUIPC7.ini, FSUIPC7.log and FSUIPC7.JoyScan.csv files please and I will take a look. Are your assignments still working, or do you have to edit/change the ini or re-assign when your devices are detected and given a different letter? This really shouldn't happen, unless windows is generating a new GUID for your devices. I will know more when I can see your full files. John

I have the Bravo and have no issues. I can check for some of your aircraft (ATR, CRJ, PMDG 737) but not for the ones I don't have (Fenix A320 or the Justflight BAE 146). This will be nothing to do with Honeycomb, and will be due to the way you have assigned. Well, do this when you get a chance and report back. John

I cannot tell what is happening as you have not activated logging for Buttons & Keys. Please do this, also set logging for Events, and remove all other logging, and then show me the FSUIPC7.log file showing your issue. If you open the logging console (Log->Open Console), you should be able to see what is happening in real-time and this might give you some insight, Otherwise, attach your log here and I will take a look. Also please check and remove any key press assignments in MSFS for any key combination assigned in FSUIPC7. You can do this if there is something that holds the state of the fuel control (i.e. on or off). This may be an lvar or a simvar. You would need to add this to a spare FSUIPC7 offset, if not already available, then overload your key press assignment (i.e. assign both to the same key press) and then add an offset condition on each assignment, so only one is executed. Alternatively, you can define the presets so they only actually do anything if the state is correct, and overload your assignments to send both presets. Then only one should actually do anything. You also seem to be duplicating MF presets (available in the events.txt file) in your myevents.txt file. Why are you doing this? Better to just use the MF presets, but if you want to use your own then you should at least give them a unique name. As you are using the same preset names as MF, I do not know which preset definition will be executed - it could be either. John

Yes That looks ok and should work, so I don't know why it isn't. Just checked that here and it reverses the axis here. In the calibration page, do you see the in/out values move when you move the throttle lever (you need to have the aircraft loaded and ready-to-fly)? You should see the difference in the in/out values between when the rev box is checked and when not. You can also reverse an axis using an axis scaling value of -1 - this is described on page 41 of the Advanced User guide, section Additional parameters to scale input axis values. You are confusing reversing the axis with reversers ON an axis - they are two different things. You have also calibrated in the sim/EFB with a reverser axis, but have calibrated in FSUIPC7 with no reverse zone. This will invariably cause issues. If you are using a reverser axis, you need to uncheck the No reverse zone checkbox in the FSUIPC7 calibration page and then calibrate with a reverser axis. Othewise, you need to switch the calibration on the EFB to 'Throttle hardware has no reverser axis'. As the CRJ uses the *_EX1 controls for throttle, you have to use Send to FS as normal axis. You cannot use these axes controls with Send direct to FSUIPC calibration, as doing that would use the standard axes controls which do not work in the CRJ. Take off axis control logging for the time being and your log files will be a lot smaller. I will ask you to activate logging if/when needed. You are not using profiles-in-separate-files, so I only need one ini, your FSUIPC7.ini. Try calibrating with a reverse zone. Otherwise switch to Send to FS as normal axis and try with the Axis Throttlen Set controls If you cannot get this to work, activate logging for axes controls, load the aircraft and then: 1. Move the throttle in the VC through its full range, to max throtle and back to min/idle. 2. Move your assigned axis through to full throttle and then back again Then exit FSUIPC7, and show me your FSUIPC7.log and FSUIPC7.ini files. John

The controls/events listed when Select for FS control is checked ARE the sim events - I just replace the underscores with spaces and only capitalize the first letter to make it more readable and look better. All FS events/controls are also listed in a text document in your FSUIPC7 documents folder, both in alphabetical order and control number order. This is a question for MSFS - nothing to do with FSUIPC7. I cannot do anything about this. Of course, and I have told you this many times - just check Select for Input Event. You can assign buttons and keys to input events, as well as to entering/leaving an axis range. You cannot directly assign to an axis - you need lua for that. It does recognise the tab key as an additional modifier, but not the windows key. I removed this as it invariably causes issues. See page 25 of the Advanced User guide for a list of the available modifiers (or shifts) : Not sure what you mean here. Presumably by output keypresses, you mean when FSUIPC7 sends keys, such as on a button press, and input keypresses are assignments to key presses in FSUIPC7? All modifier keys are available in both (although different shift values are used, as documented). You can also add offset conditions to key press assignments, as you can for button assignments. As I keep saying, you can assign directly to Input Events. However, you cannot use input events in calculator code, so you cannot use them (i.e. B:vars) in presets. This is due to MSFS, not FSUIPC7. If you want to access B:vars / Input Events, there is a hack you can do (i.e. via changing the aircraft xml files) which I have explained in several posts, but I would not recommend this (it works by adding your own l:var to control the b:var, and then use the lvar). John

Note that you can now use Input Events (or lvars) for most controls. However, I am still having issues finding out how to assign to the fuel cut-off triggers, below the throttles. These trigger the events TOGGLE_FUEL_VALVE_ENG1 and TOGGLE_FUEL_VALVE_ENG2, but sending these (or the SET_FUEL_VALVE_ENG1/2 controls) doesn't seem to do anything. There are also no Input Events or lvars for these triggers (that I can see). Further info in this topic: John

For the pitot static/off switch, you can use the lvar C510_Pitot_Switch_Position. John

Ok. Not sure why - battery, avionics, starter all work easily via Input Events. The only difficulty I am having at the moment is for the fuel cut-off triggers and the pitot heat/static switch which don't seem straight-forward - I will look into these further tomorrow. You can also use FSUIPC logging - events and Input Events, and open the logging console (Log->Open Console) to see the messages in real-time. Of course - just check Select for Input Event in the assignments panels. You can choose between Standard FS controls (including PM controls), Presets or Input Events for assignments. Thats strange, and I do not see that here. Windows normally uses the windows (or CMD) key, not the alt key, which is why it is recommended not to use this as a modifier (and I think I removed this in FSUIPC7). Yes, that seems to be the key combination for the nav log. No idea where this is defined - it isn't listed under the keyboard controls. Modifier keys just allow for more distinct assignments. Using them will not prevent anything else that is also using and receiving them. Yes. This is for receiving keys. Normally FSUIPC receives key press/release events from MSFS via SimConnect. However, for some button-controllers (i.e. controllers that send configurable key press combinations on a button press) the key presses will not be received. For such controllers, you can set this and FSUIPC7 will install a global keyboard hook and receive all key presses directly from windows and not from MSFS via SimConnect. You only need to set this option if you are using a button-controller that sends key presses that are not seen by FSUIPC7. FSUIPC7 cannot control how other programs respond to your key presses. Choose a combination that doesn't trigger other actions - there are many possible combinations. John

In FSUIPC... It certainly is - see, for example, the image on page 36 of the User guide - notice the Rev checkbox. This is for reversing an axis, and will be in each calibration panel for axes that can be reversed. No idea what this means, sorry... zip/compress them if too large to attach directly. Your upload limit will increase the more you post. It is usually much better to assign with Send direct to FSUIPC calibration and calibrate, and assign using Send to FS as normal axis only if the aircraft is having issues with FSUIPC calibration. If you assign using Send to FS as normal axis then this will also be calibrated in FSUIPC, but AFTER values have been sent to the FS and received back, which can also create issues with certain aircraft. If assigning in this way and you do not want FSUIPC to calibrate, then you must create a profile-specific calibration section (or else the general calibration section will be used) and disable any calibration settings you have there (i.e. click Reset in each of the calibration tabs). I am not going to look at your files yet - I have no idea what I am looking for! As I said, lets do one aircraft/issue at a time. If I can show you how to do that, it may become clear to you. So please let me know what aircraft you are using, what issue you are having, and show me/attach your ini and log files for this. I don't understand the issues you are having - if you had everything working with the saitek controller, it should be relatively straightforward to switch to using the Bravo. John

You are also using a very old beta version of FSUIPC7, 7.3.26g: Please update to the latest and only supported version, 7.4.11. You need a later version to assign to Input Events correctly.

I have just looked at the ini and log files you posted, and they report no devices acquired for use by FSUIPC7: So your devices are not being controlled by FSUIPC7. No idea why this is. Are your devices working and recognised by FSUIPC or not? And this is nothing to do with the aircraft you are using...If your devices are not recognised, we need to look into this first rather than assignments for a specific aircraft,,, You have raised quite a few support requests on this so I presume your devices were recognised. What has changed? John

Well, they should provide information on how to control the aircraft, whether this be standard events, lvars/hvars or input events. However, it is not difficult to detemine how any switch works, by either using FSUIPC logging (which will log events and input events. when selected) or using the facilities provided by MSFS (devel functionality, mainly behaviors console). I wouldn't expect developers to provide presets or Spad.Next snippets. These are both community-driven efforts. And as the C510 seems to mainly use Input Events, you cannot use presets/calculator code for most functions of this aircraft. And you must see the difficulty here. Your Alpha/Bravo controllers are nothing like the actual instruments in the C510, and so some mapping is necessary, and people will want to map these controls differently. For example, the Alpha uses a magneto to start the aircraft (i.e. it is for GS aircraft). There is no sensible mapping of this to engine L/R start buttons - you have to decide how you want to do this. But once you have decoded which controls/buttons to use. it should be relatively straightforward to implement/assign. I got these working using my saitek X55 controllers within a few minutes, assigned to the appropriate Input Events. I will look into assigning these on my alpha/bravo. What would you like to use, for example, for the engine start buttons on the alpha/bravo?

First, you posted in the wrong sub-forum - I have moved your post to the correct place, the sub-forum for FSUIPC7. This issue is documented in the README.txt file that comes in the zip file you downloaded (as well as in many other support requests in this forum): John

The C510 does have these input events, although I think the standard controls might also work, or at least some. Will take a look when I have time, but also need to familiarise myself with the start-up procedure first.

You may as well aslo remove these entries if you no longer use these devices: John

Note that you have no general assignments and you are not using substrings for your profiles. Therefore if you load an aircraft that does not exactly match a profile entry, you will have no assignments in FSUIPC7. Revise your profile strings - they all look a bit strange. For example, change this: to this: and this: to this: etc. Do this for all your profile aircraft, i.e. use substrings to match all variants.

You can reverse in the calibration page. But what am I looking at? You have reported so many issues. Lets do one issue at a time please. Load an aircraft you are having issues with. Activate appropriate logging for your issue (i.e. if it is with an axis, activate logging for an axis). Then reproduce your issue, exit FSUIPC7 and then attach both your FSUIPC7.ini and FSUIPC7.log files and I will take a look.

This is not a 'FSUIPC thing'... An axis is just an axis, it depends how it is configured. Configuring an axis for throttle on the Bravo is EXACTLY the same as configuring an axis on a saitek device. There is no difference as far as FSUIPC is concerned, it is just another axis on a controller. So it all depends on how it is configured. Did you re-configure you assignments for the Bravo? Did you disable the bravo in MSFS, or at least remove the default assignments? You are assigning to the wrong controls. For the CRJ, you need to assign to the _EX1 controls (i.e. THROTTLE1_AXIS_SET_EX1 & THROTTLE2_AXIS_SET_EX1, or THROTTLE_AXIS_SET_EX1). If your throttle was working on your saitek controller, then you must have been using this axis control. For each aircraft. you need to check how your axes were assigned with the Saitek and then redo your assignments with the bravo. I don't understand how you would expect it to work without doing this. Please do this., Any further issues, please at least attach your FSUIPC7.ini file so that I can see your assignments. John

Also, have you read the documentation for the C510, especially the start-up procedures? You have to open the fuel cut-off levers under each throttle - see page 27. Are you doing this before trying to start the engines?

There is no event function associated to lua globals. No, you would have to use polling to do this - maybe on a timer, and use this to determine if the lua global variable value changes and then call your function. Otherwise, to use an event callback, you would have to use a free offset, i.e. write the lua variable value to a free FSUIPC offset in the server and monitor that offset in the client with event.offset. John

Please see the FSUIPC Lua Library document - the ipc.set finction is documented as follows: Given the above, why not? John

I have the Alpha and Bravo on my flight system, but I don't have the C510 installed there yet - and haven't used this system for quite a while now and everything will need updating. I also don't fly this aircraft - I purchased to help others out with assignments as it is quite different from most other aircraft. Ok, I can look into the assignments needed for the batteries and the alternator. As I said, I don't currently have this fully configured - only a couple of assignments on my development system. However, I will take a look and get back to you. Looking at your ini, these assignments are wrong: and should be: Did you manually change this? John

👍No problem! 😎

Try the attached version, 7.4.12d. Add the following to the [General] section of your FSUIPC7.ini file: MaxCustomControlNumber=96323 John FSUIPC7.exe P.S. As your question/issue is with FSUIPC7, please use the sub-forum dedicated to FSUIPC7 / MSFS for such posts. I will move your post.

What event/control numbers are those? Third-party events start at number 69632, and the first/lowest custom event number shown in that web page is this one: EVT_MD11_PED_CPT_RADIO_PNL_XFER_BT_LEFT_BUTTON_DOWN 69644 i.e. event 69664. If you look at the log file you posted, you will see this: So this is the range you can use for third-party events (also known as custom controls). Looks like the TFI Design MD-11 uses third-party control numbers from 69644 to 96323, so you currently won't be able to use those above 84232. This is currently a hard-coded maximum. For the next release I will add an additional ini parameter so that the max custom control/event number can be specified. I will release the next version shortly after SU15 is released, which should be any day now. Once I have made this change, I will also post details in this topic and can maybe supply you a beta version to test (if not released yet). Your log file shows errors when using custom events above 84232: These other errors in your log file: are because you are trying to use buttons assigned to presets before everything is loaded. You cannot use presets/lvars/hvars until the WAPI has established a connection and the initial set of lvars have been received, which is logged here: So you need to wait a short while (an additional 7 seconds or so) after the aircraft is loaded before you try and operate it via FSUIPC7 assignments to presets. John