Pete Dowson

Just to clarify that, the Buttons and Switches tab, used for assigning actions to these, will show the joystick number (or letter ID) for the joystick, and the button number. but the joystick device must be one which is recognised correctly. That recognition is recorded in the part of the Log you sadly cut off, and also in the INI file snd the FSUIPC5 joyscan file. Allthree files are useful and should definitely be shown in full as Thomas says. Pete

From your picture I see you mean the VOR and NDB heading, not the AP heading nor the compass heading! Sorry, I would have immediately told you "OBI" if you had been just a little clearer. I've never heard it called "flux gate", sorry. Anyway, glad you found the solution. Pete

Sorry, not sure what you mean. What compass adjustment? What's a "flux gate"? If you can do this adjustnmet on screen, in your cockpit display, then just enable FSUIPC event logging (in the Logging tab), then do it on screen, and check the FSUIPC log file to see what controls it logged for this, if any. If it is just a display function with no internal system then it may not use any controls, but just be something local to that gauge. Or perhaps these two controls would be what you are looking for? INDUCTOR COMPASS REF INC INDUCTOR COMPASS REF DEC If something you want isn't easily found by scrolling down the drop-down assignmewnt lists, try searching in the List of Controls documents provided in the FSUIPC Documents sub-folder. I found the above two by searching it for "Compass". There's also HEADING GYRO SET i'm not sure what that does without trying it. That is the heading readout, and it can be written. That's to set an AP heading directly, not by INCs and DECs. To INC and DEC it you either use the controls your already found for this, or you need to read the value first, increment it or descrement it, then write it back. You'd need a program or Lua plug-in to do that, and there's no point when controls are supplied to do just that. The control HEADING BUG SET does the same as writing to the offset. But it sounds like it isn't the AP heading bug you are interested in. Pete

In FSUIPC you only have the Elevator and a Throttle assigned: [Axes] PollInterval=10 RangeRepeatRate=10 0=4Y,256,D,2,0,0,0 -{ DIRECT: Elevator }- 1=4Z,256,D,0,4,0,0 -{ DIRECT: Throttle }- You have them both assigned "direct to FSUIPC calibration", but you've only calibrated the Elevator! You don't have a Profile for PMDG aircraft. It would be a good idea to create one, because PMDG Boeings do not work well with Throttles assigned in this way. For those add-on aircraft you really need to just assign to the regular FS controls (Axis throtte set), and not calibrate in FSUIPC. You said you had this all working well on a previous computer. Where are the settings you used for that? Those would have been a good start for you on your new computer. BTW your FSUIPC is out of date. The currently released version is 5.152. Pete

That’s probably left over from when you started the sim and would occur because you inadvertently started P3D twice in quick succession. The second one would have got that error and that copy of P3D would have been closed. It can’t have been from the session you just used as the error is followed immediately by a P3D closedown. The only other time you can see that is when trying to start the sim when a previous session has not prperly terminated. Pete

I don't know the Wilco 737, so unless someone else who uses the same aircraft sees your question I'm afraid you'll need to hunt for solutions yourself. (It would have been better to state the name of the add-on in your title to attract such attention -- shall I change the title or will you?). Maybe Wilco have their own support forum where such issues have been discussed? It is worth checking. Otherwise here are some ideas: 1. As I said earlier, use FSUIPC Event logging to see what may be actually sent when you operate the FMC using mouse and keyboard. I expect that the keyboard will be used as it stands for actual input of data into the FMC. I have hardware CDU's where the keyboard on the CDU is used as the computer keyboard, the Function keys being used for the non-alphanumeric functions. If you put P3D into Windowed mode (ALT+ENTER) and enable the Monitor logging on FSUIPC's logging tab you will be able to see the events on screen as you use the keys or mouse to operate the FMCs. 2. Mouse macros may work on that cockpit. It depends on how the gauges were written. Please check the FSUIPC User Guide for instructions. If mouse macros don't work then the next option is more likely to: 3. You may be able to use Local Panel Variables (L:Vars). To find out, run the Log LVars.lua plug-in (it is in the Lua examples ZIP file in the FSUIPC documents subfolder). To run that copy it to the Modules folder, snd assign a button or keypress to "Lua log Lvars". When you activate it you will get an on-screen list of LVars initially and as they change, so you can see what is operating the FMCs. Pete

Not the model, the Add-On aircraft maker. Or are you talking about the default 737? If so, which version of FS? Pete

You need to say which actual 737 aircraft you need this for. They will just as likely be controls, not 'offsets' in any case. You can use the non-axis Event logging in FSUIPC (Logging Tab) whilst using the on-screen FMC's, then check in the Log file (in the Modules folder) to see if they generated events which you can then assign as controls in the button assignments Tab. Pete

Hi Thomas, Nice to see you here! Thanks for contributing! I thought you'd be back hard at it this week! 😉 Best Regards Pete

You evidently either aren't setting the centre zone properly when calibrating, so the output with a centred rudder is not zero as it should be, or you have rudder trim set off-centre. The calibration screen shows not onlt the input but also the resulting output. Centre the rudder, the output should show zero. move therudder a little each side of centre. it should still show zero. If that's okay, it'll be your rudder trim. Pete

As I said, the FSUIPC facilities for Lua plug-ins are documented in PDFs in you FSUIPC Documents subfolder. For help understanding how to write them, look at some of the exmples provided in the ZIP file. To learn more about Lua and possibly see a tutorial you'd need to go to the Lua web site itself, Lua.org. Pete

Only by writing a Lua plug-in program to process the axis value as a paramater (ipcPARAM) and assigning the axis to that Lua using LuaValue <name of lua program>.. The plug-in would need to be loaded beforehand by an [Auto.<profile name>] section in the INI. It would use event.param to call a function and that would check whether you are on the ground or in the air and send the appropriate Control using that axis input value which is supplied as a parameter. I'm not surprised! Same answer as above except that instead of detecting whether you are on the ground you'd have another function, called by event.button, which changes a flag (just a value) which you can interrogate in the main function. Documentation for all these Lua facilities is contained in your FSUIPC Documents subfolder, along with lots of examples. Pete

First, you must NOT allow axes to be assigned in FSX and also in FSUIPC. If you are using FSUIPC for assignments, to buttons or axes, you need to disable each game controller in FSX. If you then do decide to make use of FSUIPC's facilities, you will find a User Guide in the FSUIPC Documents subfolder in the FSX Modules folder. Look up Calibration. Follow the numbered steps and you can't go wrong. Pete

Possibly (usually there's a "wake on LAN" setting in the BIOS. But how it is used I don't know. You might have to have something which tried to access a file on that PC, but it may equally be a special signal. I'd Google it if I were you. But in the case of WideServer / WideClient, it is WideServer which responds to requests from WideClient, not the other way around. It would simply be wasteful and possibly a performance problem if the Server had to keep check for any Networked PCs.to coax into asking it for attention. I use the BIOS option to start up when power is re-connected, so I don't need to attend to each client PC, which would be difficult as they are withing the cockpit shell (in the nose cone). So I just use a remote controlled mains socket for the whole cockpit. Are you talking about client applications or WideClient itself? Of course, it is not possible for WideClient to affect how Windows starts programs when you execure their EXE's -- that's something wrong you are doing! For WideClient, you supply no information to help so I have no idea what you have messed up. The client INI and LOG files are always important. Pete

How does WideServer (in FSUIPC) know about your Client PCs before WideClient does its connection request? Even if you had parameters in the INI to tell it about your clients, the process to get a program running on those clients would require something to be preloaded in them in any case. So, why not do as John mentions, have WideClient loaded automatically via the Windows start up mechanism? It will sit there trying to connect (at intervals) and then become fully active when FSUIPC and therefore WideServer is running? If the problem is with the WideClient Run command loading one of your Client applications, and that isn't started properly because that client is not yet connected, please use "RunReady" instead. Then your application won't be started until a proper connection exists. I have 7 client PCs, all of which run WideClient in this way. I power on the cockpit (using one remote switch, and they all come alive waiting to connect when the P3D PC (the server) is ready. Some client applications are run immediately using 'Run' but others which are funny about connecting are started using 'RunReady'. Pete

I don't have any PMDG aircraft, so I can't help directly. John may be able to help, but really for questions on PMDG aircraft you would be better off in the PMDG forums. I do have one question, though. How did you arrive at that format for the macros? You evidently didn't use the FSUIPC assignments tab to do it. why? The format you are using is for multiple part macros, with the .1 part succeeded by .2 etc. It would work with a single part macro but it is unnecessarilty complicated. For example, yoru first pair would normally be: 22=HDG_SEL_INC=C71812,214748364823=HDG_SEL_DEC=C71812,536870912 Als0 I find the parameters easier to understand in hexadecimal. After all, they are mostly just sngle bit values, so 22=HDG_SEL_INC=C71812,x8000000023=HDG_SEL_DEC=C71812,x20000000 The bits in the value are flags denoting the mouse action, as in the list supplied in the '.h' document in the PMDG SDK folder. Pete

John is my son, who is taking over from me. I am retired from FSUIPC development with effect from Jan 1st this year. John will be taking FSUIPC into the future. Pete

As well as logging the output to check, I would seriously advise you to consider changing from a USB-RS232 converter cable to a proper RS232 connection. I had no end of problems with those cables. they just don't seem to be suited to continuous traffic, locking up after a while. My PFC 737 cockpit is mostly based on RS232 com connections. I use BrainBoxes RS232 com port cards, installed in the PC. You can get them for the older PCI bus and for PCI-E. I've never had any trouble with those. Brainboxes also do a plug-in adapter which should work almost as well as their computer cards. Here, for example: https://www.amazon.co.uk/Brainboxes-RS232-Port-Serial-Adapter/dp/B00XUFCHQW/ref=sr_1_1?keywords=Brainboxes+serial&qid=1564484556&s=gateway&sr=8-1 They aren't cheap, but I think you'll find them worthwhile in the end. Pete

Thanks for explaining why you need this facility. It did seem a bit odd to us. I think John has now added it to his list of things to do and will get back to you about that when he can. Pete

Thank you for posting this. It is now clear. Pete

I can't really help 'fix' P3D to make it work. But it seems likely to me that Chaseplane is also using a DLL which is still enabled even when you are not running the program itself. Since most folks have no problems with Pan View no matter where it is assigned, the problem you are experiencing must be due to something you've installed, and ChasePlane seems the most likely culprit --- and that is common to both reports in this thread. Best to check on ChasePlane website, see what their support says. Pete

That Pan View control is just an FS contorl, and is merely sent to P3d. it would operate exactly like the pan view assignment in P3D. FSUIPC neither adds nor subtracts from it, it is merely sent on. It merely provides a way for the facilty to be used when the P3D one is stopped by disabling controllers there, as needed to avoid conflicts with FSUIPC assignments. Are you sure it isn't ChasePlane which is preventing its operation? BTW you say "pushed down on the hat". Hats are normally are pushable in any direction. By "down" do you mean towards you? Pete

The 12-digit key is associated only with the original name and email address you purchased it with. Use those and you will be fine. This NEVER changes -- it is the same throughout all versions of FSUIPC4 and all versions of Windows. If you can't remember the details of your purchase, open your account at SimMarket and retrieve them there. THEN cut--and paste to avoid any errors. Pete

You can send controls by writing the parameter to offset 3114 then the control number to 3110. (Or write both together in one 8-byte write). Pete

088C and 3AE8 are both for throttle 1 but in different units and number representations. Throttle 2 is 0924 and 3A28. These definitely contain what the Sim sees as the throttle lever positions. You must be monitoring them incorrectly. Please give more details. And what do you mean by "nothing is returned in the log" -- zeros or no entries at all mentioning the offsets? If the latter than you've not enabled the onitor to log them. Pete