John Dowson

They are toggle events - toggle events don't usually have a parameter (although if I remember correctly some actually do!). A toggle event switches between two states, and no parameter is usually needed. They are not variables, they are events. See https://docs.flightsimulator.com/flighting/html/Programming_Tools/Event_IDs/Aircraft_Electrical_Events.htm: Although that is confusing, as it talks about index when i presume they mean parameter (simvars can be indexed, not events, as far as I am aware). So a param of 24 would indicate circuit 24 (and its a toggle event with a parameter, in this case justified!). What circuit 24 is, I have no idea - this will be dependent on the implementation of the electric circuits in the aircraft and you would need to dig into the aircraft config files to determine what that is. Just use the parameters as logged. John

Presume you mean 034E or 0x034E. Maybe you have configured to use the wrong offset? How are you actually using this offset? I do not see any assignments using this offset in your ini. Please explain how this offset is being used, and by what. There are also no annotations/comments in your ini, even though Annotate=Yes is set, which is strange. Then this must be an issue with the update - FSUIPC hasn't changed. You need to see what has changed in the FQZ - maybe try VatSim support? You could try logging offset 0x034E using FSUIPC's offset logging facilities log as U16 in hex and send to the FS Title bar. You should then be able to see what the offset is holding.

Not yet, but I will add another lock on sending calc code when lvar/hvar updates are being received in the next beta, which I am planning on releasing in a couple of days. Increase it further - your log still shows lvars are being discovered after this period, and you are getting the new lvars continually pushed. You want to set it to a value where most, if not all, lvars are found on the first scan. Try 15 seconds, and if you are then still getting new lvars pushed, increase further. John

How am I supposed to help you when you provide no information as to what your problem actually is? Please explain what your problem is, and also attach your FSUIPC4.ini and FSUIPC4.log files. However, before anything else, please update to the latest version of FSUIPC4, which is 4.977. Only the latest version is supported. John

There are no such functions. To read a simvar that is not currently held in an offset, you have to first add it to an offset via the myOffsets.txt file, and then read the offset value. There is no direct way of reading a simvar due to the asynchronous nature of the simconnact API (i.e. you request a value and sometime later you will get the value back via a message). You can also write the value of a simvar to an lvar (using calc. code) and then read the value from the lvar, but I wouldn't recommend this method due to the delay between writing and reading - you have to wait for the updated value to be returned, also for the lvar to be recognised and returned to FSUIPC if the calc code also creates the lvar. You can use the same method. Or wait until next week when I release the beta which has access to Input Events. Note that the Input Events available are/will be restricted to the 'set' ones. Asobo have indicated that more Input Events (toggle, inc, dec) will be accessible in future updates. John

You also have a large null zone set on your proppitch axes: And as I said, you will be better off creating a profile-specific calibration section for the DC-6. You could also clean-up the aircraft names in your profiles to use substring matching, so, for example, change this: to this: That will then catch all variants, i.e. any aircraft containing the string 'PMDG DC-6'.

Not really. Those lua functions read offsets. Of course, if the offset holds an avar (aka simvar) or lvar, then you are reading the value of that variable. What does this mean? The examples how the variable, the type and the units, e.g. the example from the Advanced User guide: i.e. 3rd column is simvar/avar variable name, 4th column is type, as defined in the same place I am not sure what your problem is or why you are asking this.... You can't, either via simconnect or guage code in the WASM. As I have said, I will be adding access to Input Events (aka B vars) in the next release. There is no access to O type variables at the moent. As I have said, no access at all to O vars. For B vars, no direct access at the moment (again, wait until I release access to Input Events). I have already shown you a hack to introduce an lvar to control b vars. Please try and understand the answers I have already given - you seem to be asking the same questions again and again. These new variable types are new to us all. And access is limited to such variable types. I have no further information other than what is provided in the MSFS SDK documentation. John

What controls are they assigned to? You can try setting logging for axes controls and see what is logged, if anything, when you move the assigned levers. Looking at the HubHop page for the King Air (https://hubhop.mobiflight.com/presets/), it looks like the condition levers require a combination of axes controls (SET_FUEL_VALVE_ENG1/2), lvars (L:Condition_Lever_CutOff_1/2) and simvars/a:vars (TURB ENG CONDITION LEVER POSITION:1/2). I have no idea how you would set-this up with a PFC device (I don't have any!), but I could look into how to control with a standard joystick axes if you like to see if that helps. Note it was previously reported that the controls for the condition lever were working, but they were not controlling the visuals, i.e. you could hear the change in the engine but the lever in the VC wasn't moving - that maybe why you also need to set the lvar and avar. See I can take a look at the condition lever in the Asobo King Air, but this will be next week. I can only do this with a standard joystick axis, but if this can be done we can then look into how to set this up with the PFC driver, if possible. That is strange... what do you see on the PFC config page for the left lever? Does it jump from 0-100 there? Could you activate logging for Axes Controls in FSUIPC7, and generate a short log file where you just load the aircraft and then move the left lever through its full range, from min to max, and then back again. Then exit FSUIPC7 and show me/attach your FSUIPC7.log file, together with your PFC.cfg file and FSUIPC7.ini file. Normally an axis that jumps from 0-100 and back again has been flagged as a digital axis in the registry, and you need to clean the registry to resolve this (there is a FAQ entry on how to do this in the FAQ sub-forum). However, as this also seems to be interfering with the right propeller, best to show me those files before anything else. John

License sent via PM. John

You seem to be using an old version of the WASM/WAPI - latest version is: In later version of the WASM/WAPI, you don't need to reload as lvars are automatically pushed to clients when discovered. Presumably there is a later version of Pauls';s ,Net client dll that can be used (probably using WAPI 1.0.2), so you should update. And update your WASM version (and FSUIPC) to the latest version before anything else. John

If you are still having issues, try adding the following to the [General] section of your FSUIPC7.ini file: VRIDisableCMDRST=Yes This was added to prevent issues with a power-spike when using VRInsight MCP panels - see the following You can also add additional logging for VRI devices by setting a Log->Custom value of x4, or x44 for additional logging. This should then log any com data received by FSUIPC over the com port. Please also see the following post: John

Sorry, but I have no idea what is causing this. Your log does not show anything - the throttle *_EX1 controls don't srrm to be logged for some reason. And as throttles 3 & 4 are on the same device, I do not understand how these can continue to work if 1 & 2 are failing, The next time this happens, can you open the FSUIPC axes assignment panel and see if the throttles are still recognised there, and if your assignments are still recognised. Your throttle calibration is rather strange: Those are quite large idle zones, and no calibration for throttles 3 & 4. In the DC-6, you are using profile-specific axes assignments but not a profile-specific calibration section. Can you create a profile-specific calibration section for the DC-6, and then remove the throttle calibration for throttles 1 &2 (click the Reset button in the throttle calibration page). I am not sure that this will help, but the only difference between throttles 1/2 & 3/4 is that the 1/2 throttles are calibrated. John

That preset will only work if you have added the additional code to the C510_interior.xml file, as explained in the post where I specified these. No. Those presets change the value of the lvar L:FSUIPC_C510_Ignition_1/2, which is defined in the additional code that you have added to the C510_interior.xml file, You cannot. That is the name of the preset, and only exists within FSUIPC. FSUIPC maps that preset name to the calculator code that is defined (i.e. '1 (>L:FSUIPC_C510_Ignition_1)'). The variable that exists in the sim is L:FSUIPC_C510_Ignition_1, and that is because you have manually added this (or should have). You can only discover other variable types using the dev tools provided by MSFS. See https://www.badcasserole.com/uncovering-input-events-using-the-msfs2020-model-behavior-dialog/. Note that it is currently not possible to directly control B-type (and other variable types such as O) from external applications. The additional code you add to the C510_interior.xml file introduces an additional l-type variable (or lvar) to control the B:var. I am currently working on a new feature to allow assignments directly to 'Input Events', which are (as far as I am aware) closely related to B-type variables (if not exactly the same). I will be releasing this additional feature in a beta release in the next days, probably early next week. John

Nothing in the splash screen. The main window of FSUIPC tells you what version you are using and if its the latest version or if an update is available. John

License sent.

Why, what is the problem? Open the button assignments panel, then move your fuel cut-off lever up or down. The button should then be registered in the Joy# and Btn# windows. Thenn check Select for Preset and click the Find Preset... button located under the first drop-down (Control sent when button pressed). If you then go to MobiFlight->PMDG->B737-700->Fuel you will see the presets for the cut-off levers which you can select. Please make sure that you are using the latest version of FSUIPC. 7.3.25. Please try reading the provided documentation. This is simply a basic assignment to a preset and I don't understand why you would need to contact support for such a basic question, especially as you already have a video showing you how to assign.... John

The latest, and only supported version, is 7.3.25. Please update. It should tell you you need to update in the main window when you start FSUIPC7.... This shouldn't matter as long as the throttle is calibrated correctly, and you should get full throttle movement even when the throttle shows limited value ranges. Have you calibrated your throttle? If noy, please do that. If you get the same problem, please show me/attach your FSUIPC7.ini file. and generate a log file with logging for Axes Controls activated and show me that - just load your aircraft, move each throttle (that is having issues) slowly through its full range and back again, and then exit FSUIPC7 before attaching your FSUIPC7.log file.

If using FSX, please use the main support forum. This is a sub-forum for FSUIPC7 / MSFS2020 only. I will move your post (and update the title). What do you mean by 'my inputs are overrun'? Can you please attach your FSUIPC4.ini and FSUIPC4.log files. John

Yes, should be the same.

It could be that the axes have been flagged as digital axes in the registry. To correct this, see the following FAQ entry (this was written for saitek controllers but applies to all): John

Now I can see you have your axis assigned and calibrated, so I am not sure what the issue actually is... Maybe its this: You have created this profile, but there is no [Axis.Baron 58] section, not even an empty one. Try deleting that ptofile, before you start P3D, and then create the profile again. You should then be asked if you want to import your general axis assignments and go from there.

Installing FSX, or anything else for that matter, should have no effect whatsoever on your P3D/FSUIPC installation. I am a bit confused by your issue. You say you are unable to calibrate your throttle, but the ini file you attached is pretty empty and shows no assignments whatsoever in FSUIPC. Where have you assigned your throttle? It needs to be assigned before being calibrated. Your files show that you have installed P3d, and therefore also FSUIPC5, under C:\Program Files. If you have installed there, under a windows protected folder (Program Files), then you will need to run P3D (and also FSUIPC) with administrator privileges (as well as all other P3D/FSUIPC clients). Are you doing this? Your log file shows that you are using two Leo Bodner devices - are these separate cards or on the same card?

@DrDave- I am not sure I understand the point of your post, or why you are attaching a pdf (of a log file I presume). Do you actually have an issue that has not already been clarified in this post? But there is - have you not even read this topic? My first comment on this issue: Is that not clear?

As I said, you don't need to keep the logging window open, just keep the event logging active, and maybe also activate logging for Buttons & Keys. Then when you get your issue, immediately (i.e. before trying to recover from it or doing anything else) go into FSUIPC's logging tab and click the New Log button to start a new log file. Then find your FSUIPC6.1.log file and rename and save that somewhere. Once you have 3 or 4 of these log files, you can examine them to see if you can see any similar events occurring just before you get the issue. You can also post/attach the log files here and I can take a look.

Your ini is pretty empty and doesn't contain much - your settings will be in your Jet.ini file in your Profiles folder. All it tells me is that you are using an old and unsupported version of FSUIPC6 (6.1.9) and should update to the latest and only supported version (6.2.0). You can clean your profile section, to catch more variants, by changing this: to this: You should keep the event logging enabled for the time being (no need to keep the console window open), and when you experience this issue you can start a new log (from FSUIPC's logging tab) and then save the log containing the events that lead up to your issue. Once this has happened 2 or 3 rimes, you can then compare the logs to see if any of the logged events could cause this issue. This may be easier in the QW or Captain Sim, as with the PMDG you would also have to decode any custom and Rotor Brake controls to understand what is happening.