Pete Dowson

Hmmm. I'll have another look, but the code has simple comparisons. Can you show me a HidScanner log, please? (HidScanner is in the Download Links subforum, in the additional programs thread). Also a Log with this preset in ithe INI file [General] section: Debug=Please LogExtras=x200000 In problems reported before with multiple Bodnar boards, we found that the GUIDs are not permanently associated with a specific one, but more a specific connection (i.e. USB port), so swapping two connections over was completely undetectable by software. I assume it is Windows assigning these according to socket or order of detection This sort of destroys the point of having letters assigned. I'll get back to you when I've looked at the code again. Pete

Also look at this thread, which seems to be about X56 in its later parts. http://forum.simflight.com/topic/82573-fsuipc-button-assignment-not-working-for-all-devices/ Pete

I really don't know. It seems very odd that things can change of their own accord. Really only hardware can do that, so when I hear of such things I always first suspect the hardware. I know you can have self-modifying software, and that settings files can be changed, but FSUIPC most certainly doesn't do either. Settings are made by the user and simply saved. The most interference FSUIPC does is annotate the assignment entries to make them more understandable. Of course,as I understand it, Windows 10 is under continuous change and you can't stop it (or can you?). I've avoided Win10 completely except on my Surface Pro, but that's used only for Internet and Documents. I did have Windows 10 installed on a new PC recently, because the supplier wouldn't install Win7, but after several days of difficulty -- various drivers for my cockpit not working, crashes left right and centre, I went back to Win7, which in my opinion is the best O/S Microsoft ever produced. Pete

Weird. The constant reconnection in your last posted log was worrying though. Make sure the device is plugged into a USB port on the PC itself, not a hub, and probably a USB2 one, not USB3 as many devices do seem to have problems with USB3. I have seen various issues reported with the Saitek X range - X52, X55, X56. I think you maybe you should seek out the respective threads. One I just found is on the P3D website forum, here: http://prepar3d.com/forum/viewtopic.php?t=120515 It might be useful too to visit Saitek's support forum. One thing I find useful is to view the parameters logged by my HidScanner program, which you will find in the Useful Additional Programs thread in the Download Links subforum above. Pete

Re-downloading and re-installing exactly the same meterial really accomplishes nothing at all. Deleting the Settings merely rmoves whatever you already managed to set up. The thing here is that you did say So something has changed since then -- and it isn't the software, obviously. This part of the Log you submitted above definitely shows a bad hardware problem: 863860 ***** HID USB device reconnected: re-initialising FSUIPC connections 863985 ---------------------- Joystick Device Scan ----------------------- 863985 Product= Saitek Pro Flight X-56 Rhino Stick 863985 Manufacturer= Mad Catz 863985 Vendor=0738, Product=2221 (Version 0.20) 863985 Serial Number= 863985 ------------------------------------------------------------------- 864000 ***** HID USB device reconnected: re-initialising FSUIPC connections 864016 ---------------------- Joystick Device Scan ----------------------- 864016 Product= Saitek Pro Flight X-56 Rhino Stick 864016 Manufacturer= Mad Catz 864016 Vendor=0738, Product=2221 (Version 0.20) 864016 Serial Number= 864016 ------------------------------------------------------------------- 864047 ***** HID USB device reconnected: re-initialising FSUIPC connections 864047 ---------------------- Joystick Device Scan ----------------------- 864063 Product= Saitek Pro Flight X-56 Rhino Stick 864063 Manufacturer= Mad Catz 864063 Vendor=0738, Product=2221 (Version 0.20) 864063 Serial Number= 864063 ------------------------------------------------------------------- 864079 ***** HID USB device reconnected: re-initialising FSUIPC connections 864079 ---------------------- Joystick Device Scan ----------------------- 864079 Product= Saitek Pro Flight X-56 Rhino Stick 864094 Manufacturer= Mad Catz 864094 Vendor=0738, Product=2221 (Version 0.20) 864094 Serial Number= 864094 ------------------------------------------------------------------- 864110 ***** HID USB device reconnected: re-initialising FSUIPC connections 864110 ---------------------- Joystick Device Scan ----------------------- 864110 Product= Saitek Pro Flight X-56 Rhino Stick 864110 Manufacturer= Mad Catz 864110 Vendor=0738, Product=2221 (Version 0.20) 864110 Serial Number= 864110 ------------------------------------------------------------------- 864141 ***** HID USB device reconnected: re-initialising FSUIPC connections 864141 ---------------------- Joystick Device Scan ----------------------- 864141 Product= Saitek Pro Flight X-56 Rhino Stick 864141 Manufacturer= Mad Catz 864141 Vendor=0738, Product=2221 (Version 0.20) 864141 Serial Number= 864141 ------------------------------------------------------------------- 864172 ***** HID USB device reconnected: re-initialising FSUIPC connections 864172 ---------------------- Joystick Device Scan ----------------------- 864172 Product= Saitek Pro Flight X-56 Rhino Stick 864172 Manufacturer= Mad Catz 864172 Vendor=0738, Product=2221 (Version 0.20) 864172 Serial Number= 864172 ------------------------------------------------------------------- 864188 ***** HID USB device reconnected: re-initialising FSUIPC connections 864204 ---------------------- Joystick Device Scan ----------------------- 866297 Product= Saitek Pro Flight X-56 Rhino Stick 866297 Manufacturer= Mad Catz 866297 Vendor=0738, Product=2221 (Version 0.20) 866297 Serial Number= 866297 ------------------------------------------------------------------- 876547 ***** HID USB device reconnected: re-initialising FSUIPC connections 876563 ---------------------- Joystick Device Scan ----------------------- 876563 Product= Saitek Pro Flight X-56 Rhino Stick 876563 Manufacturer= Mad Catz 876563 Vendor=0738, Product=2221 (Version 0.20) 876563 Serial Number= 876563 ------------------------------------------------------------------- 876594 ***** HID USB device reconnected: re-initialising FSUIPC connections 876610 ---------------------- Joystick Device Scan ----------------------- 876610 Product= Saitek Pro Flight X-56 Rhino Stick 876610 Manufacturer= Mad Catz 876610 Vendor=0738, Product=2221 (Version 0.20) 876610 Serial Number= 876610 ------------------------------------------------------------------- 877813 ***** HID USB device reconnected: re-initialising FSUIPC connections 877829 ---------------------- Joystick Device Scan ----------------------- 877844 Product= Saitek Pro Flight X-56 Rhino Stick 877844 Manufacturer= Mad Catz 877844 Vendor=0738, Product=2221 (Version 0.20) 877844 Serial Number= 877844 ------------------------------------------------------------------- 877875 ***** HID USB device reconnected: re-initialising FSUIPC connections 877891 ---------------------- Joystick Device Scan ----------------------- 877891 ------------------------------------------------------------------- 877938 ***** HID USB device reconnected: re-initialising FSUIPC connections 877954 ---------------------- Joystick Device Scan ----------------------- 877954 ------------------------------------------------------------------- 878000 ***** HID USB device reconnected: re-initialising FSUIPC connections 878032 ---------------------- Joystick Device Scan ----------------------- 878032 ------------------------------------------------------------------- 878079 ***** HID USB device reconnected: re-initialising FSUIPC connections 878094 ---------------------- Joystick Device Scan ----------------------- 878094 ------------------------------------------------------------------- 878125 ***** HID USB device reconnected: re-initialising FSUIPC connections 878141 ---------------------- Joystick Device Scan ----------------------- 878141 ------------------------------------------------------------------- 878172 ***** HID USB device reconnected: re-initialising FSUIPC connections 878188 ---------------------- Joystick Device Scan ----------------------- 878188 ------------------------------------------------------------------- 878219 ***** HID USB device reconnected: re-initialising FSUIPC connections 878219 ---------------------- Joystick Device Scan ----------------------- 878219 ------------------------------------------------------------------- 882813 ***** HID USB device reconnected: re-initialising FSUIPC connections 882829 ---------------------- Joystick Device Scan ----------------------- 882829 Product= Saitek Pro Flight X-56 Rhino Stick 882829 Manufacturer= Mad Catz 882829 Vendor=0738, Product=2221 (Version 0.20) 882829 Serial Number= 882829 ------------------------------------------------------------------- 884469 ***** HID USB device reconnected: re-initialising FSUIPC connections 884610 ---------------------- Joystick Device Scan ----------------------- 884610 Product= Saitek Pro Flight X-56 Rhino Throttle 884610 Manufacturer= Mad Catz 884610 Vendor=0738, Product=A221 (Version 0.21) 884610 Serial Number= 884610 Product= Saitek Pro Flight X-56 Rhino Stick 884610 Manufacturer= Mad Catz 884610 Vendor=0738, Product=2221 (Version 0.20) 884610 Serial Number= 884610 ------------------------------------------------------------------- 884641 ***** HID USB device reconnected: re-initialising FSUIPC connections 884657 ---------------------- Joystick Device Scan ----------------------- 884657 Product= Saitek Pro Flight X-56 Rhino Throttle 884657 Manufacturer= Mad Catz 884657 Vendor=0738, Product=A221 (Version 0.21) 884657 Serial Number= 884657 Product= Saitek Pro Flight X-56 Rhino Stick 884657 Manufacturer= Mad Catz 884657 Vendor=0738, Product=2221 (Version 0.20) 884657 Serial Number= The USB connection, or the device itself, or even maybe the USB hardware in the PC, is playing up. You cannot get such frequent re-connections of a USB device except by something being wrong. I count 21 re-connections in the space of 21 seconds, and at one stage they were so short that even the identify couldn't be read. Surely neither Windows Game Controllers or P3D itself can handle a device doing this either? Have you checked? Pete

FSUIPC stores your settings in a file called FSUIPC4.INI, and reads that again next time. It also logs those joysticks it sees in its Log file, FSUIPC4.LOG. Those two files might help you understand what is wrong. Other X55/X56 users have found that the units recognition in both FSUIPC and Windows is variable. There are other threads on this subject. If you want further help, show me those two files. I would also need to know whether this is always with the same aircraft, and whether it is an add-on or not. Pete

Good. I won't release 4.959p generally, as I'm close to releasing a full build 4.960, probably Monday or Tuesday. Please just replace it then. Won't be any difference unless something else crops up over the weekend, but I hope to do the few documentation updates before then. Pete

Can you download a test version with the change I mentioned and check it please, with that parameter back? FSUIPC4959p_TEST.zip Thanks, Pete

Maybe. I've found an error in the routine which does "PatchSIM1friction" when you've added this to the INI file. There's a loop copying friction values across into SIM1 which finishes when the offset value in the source list is set at 0xFFFF.. Unfortunately the table ends with a DWORD 0xFFFFFFFF, so it doesn't match. The loop will continue too long and if it accesses anything not accessible you get the access error. It looks like this silly error has been there every since the built-in frictions patch was added. The difference since the 4.959e version is that some small changes in variable types were made to stop hosts of warnings appearing when we compiled with VS15 (to try to solve the Win10 problems with P3D). You should find that if you remove the "PatchSIM1Friction=Yes" parameter from the INI it will work. Please let me know if it doesn't. Meanwhile I'll fix this error in any case. I have some other things to sort out first, but if I post up a version 4.959p later today, or more likely tomorrow morning, could you try it for me please (with that parameter back in) and let me know? Pete

There's no change at all for FSX or FSX-SE hooking in any versions since the last FSX-SE update. I'll see where that crash offset places it. Pete

What was your previous version, please? The change in n from m was extremely minor, just in a test for P3D on the Traffic Limiter. It runs fine here on FSX-SE. Pete

Ah, you are selecting "direct to FSUIPC calibrarion". All FS controls are in the other selection, for normal FS controls. For most aircraft the Direct method works well. For PMDG and some Aerosoft aircraft the FS controls seem to work better, according to reports (I have none of those). FS has a bug in that if you Arm spoilers when on the ground they will assume you landed and will go to full braking mode! Always test such settings in the air! Those controls most definitely do work then! If you've been testing with the PMDG aircraft on the ground, try again in the air. They may have corrected it by preventing arming on the ground. That looks the same as the separate one I have, and those switches on the face definitely don't latch, they send an on when pressed and an off when released. Maybe Saitek changed their hardware recently? Pete

FSUIPC natively only supports these controller input types: 1. Regular controllers recognised by Windows as game controllers, or "joysticks". 2. PFC serial port axes, through my PFC driver modules 3. GoFlight switches and controls through their GFDev.DLL. Input (and output for that matter) from any HID (Human Interface Device) type USB connection can be supported through the use of Lua plugins using the com library. It has functions dedicated to HID facilities useful for these things.You'd need to program your own plug-in script to handle the inputs and send them on to FS via the ipc.control function, or maybe writing to FSUIPC offsets for more options. There is an example script supplied in your FSUIPC Documents sub-folder, in the Example Lua plugins ZIP file. It is called HidDemo.lua. It handles joysticks types -- which could really also be used directly, in the main part, though it could do a lot more.the Windows joystick API FSUIPC uses is limited to 6 axes and 32 buttons per device. This script could be adapted more many more. If your device looks petty much like a joystick in the ways understood by the assorted HID dedicated functions in the com library then it shouldn't be too hard to adapt this script. However, if they don't work then it may come down to a more basic level -- actually reading the raw data using the ordinary com.read type functions and trying to decode that. I've done this for a number of hardware units in my cockpit, including the CockpitSonic overhead. There's a program called HIDscanner available in the Download Links subforum thread about useful additional programs. The log that produces should show whether it will be easy or hard! There's no universal solution because outside of the Microsoft joystick specific mechanism USB devices can do almost whatever they like, with a driver normally supplied by the makers. Apart from joysticks there are other standard types like keyboards, mice and webcams, but there's no standard treatment for all control input types. Pete

Well, there are a lot of axis controls being sent and received, and not by FSUIPC. The SPOILERS_SET control (which is the old one, from FS98 days -- the current one is AXIS_SPOILER_SET) is being sent more than 10 times per second with parameter 0. That will certainly reset any Arm setting. FSUIPC will only send a new axis value when it is different from the last by more than a Delta value, as seen in the Axis assignments tab. I think you should assign to AXIS SPOILER SET, not SPOILERS SET, if you haven't already. I've noticed the latter does give difficulties in FSX and later. Maybe you should also show me your settings -- the FSUIPC4.INI file. The controls 66066 and 66067 are being sent by FSUIPC, but not reaching FS in any case. Here's what the log should look like: 2441025 Button changed: bRef=0, Joy=0 (D), Btn=5, Pressed 2441025 [Buttons] 17=PD,5,C66066,1 2441025 FS Control Sent: Ctrl=66066, Param=1 2441025 *** EVENT: Cntrl= 66066 (0x00010212), Param= 1 (0x00000001) SPOILERS_ARM_ON 2441337 Button changed: bRef=0, Joy=0 (D), Btn=5, Released 2444785 Button changed: bRef=0, Joy=0 (D), Btn=4, Pressed 2444785 [Buttons] 18=PD,4,C66067,0 2444785 FS Control Sent: Ctrl=66067, Param=0 2444785 *** EVENT: Cntrl= 66067 (0x00010213), Param= 0 (0x00000000) SPOILERS_ARM_OFF 2445019 Button changed: bRef=0, Joy=0 (D), Btn=4, Released Please try the default 737. I'm now suspecting that the PMDG aircraft is doing these things. If so then I'm afraid FSUIPC can't overcome what it is doing, though you may be able to use the 737X "custom controls" for those two functions, if they exist. Check the list in the .h type document installed in your 737X SDK folder. If there are controls specific to PMDG then you can assign them in FSUIPC using the <custom control> entry and entering the number. Incidentally: I thought you said you were using the Saitek Quadrant? Evidently not, as it isn't detected. So I assume that's why the switches may be toggles. Are they on the yoke unit? Pete

Sorry, I don't know what you are saying here. What exactly am I dictating should be "this way"? What way? If your switch it a latching one (unlike those on my Saitek Quadrant, I hasten to add -- I didn't know they had different models) then it should work the way you showed it being programmed, assuming FS or P3D obeys those controls properly. I was only explaining my understanding of what the switch might be doing. Perhaps you should go to FSUIPC's logging tab and enable Button & key logging, and Event logging.to see exactly what is happening. One possibility I can think of is that the spoiler axis lever is jittering, sending different values o FSUIPC which then sends them on to operate the spoilers. A value sent outside the arm zone would disarm it. Axis event logging should reveal that, if it is happening, too. Make sure the lever is parked in the "spoiler down" zone with enough calibration leeway to stop any values in that area being used. Me too. But I don't know what is going on with your system. Try doing the logging, then maybe we will both understand it more. Pete

Here's a Lua plug-in which will show frame rate, VAS total free, VAS max block size and the AI traffic count, all in a Lua display window in FS/P3D. I'll add this to the Lua examples package installed by FSUIPC on the next full release (which will be soon). -- Update the display at 500 msec intervals (see event at end) function mytimer(time) fr = ipc.readUW(0x0274) if fr ~= 0 then fr = 32768/fr end fr = math.floor((fr * 10) + 0.5)/10 mem = ipc.readUD(0x024C) memmb = math.floor((mem/1024) + 0.5) maxmem = ipc.readUD(0x0290) maxmemmb = math.floor((maxmem/1024) + 0.5) traff = ipc.readUD(0x025C) ipc.display("Frame Rate " .. fr .. " fps\nVAS free " .. memmb .. " Mb\nMax block free " .. maxmemmb .. " Mb\nTraffic " .. traff) end -- Adjust timing to taste: 500 = 1/2 second event.timer(500, "mytimer") I also have one which shows these values in a separate Window , but it will only run under WideClient (I use it on a Network PC). I can post that if you are interested. Pete

Sorry, the use of the title bar really only sensibly allows one value to be displayed properly. Most folks would use a different display method, either via a Lua plug-in or with a separate program. These methods have the added advantage of being able to convery the raw number into something more meaningful like Megabytes. For on screen in FS you can simply select the "FS display" or "FS window" option (sorry, don't recall exact wording, but it is obvious when you look) on the Logging tab. You can of course size that window and it should remember it if you save the flight, but there are no formatting facilities. It is always two lines, left-aligned. These built-in monitoring facilities are really only designed for ease of debugging programs or plug-ins. Pete

If it is a button, not a latching toggle switch, then it sends both a "button press" and "button release" signal (unless you hold it down). So your assignment to the release will cancel the assignment to the press! As far as I remember, the buttons on the Saitek quadrant are two way rocker switches. Is that not so?. Surely you should set one direction of the rocker to arm the speedbrake and the other direction (which would have a different button number) to disarm. However, the spoilers ARE the "speedbrakes", and "arming the speedbrakes" is normally a matter of pulling the spoiler lever to the arming position. This is actually calibratable in FSUIPC, as a region of the spoiler axis. Why not use that? Pete

Please note that version 4.953 is well out of date, not officially available, and not supported. Current is 4.959, with an interim release 4.959m also now available. Version 4.960 should be released around the end of the week. Pete

Thanks Joerg. It looks good in the Log too. Pete

Can those suffering from any of the problems detailed in this thread please now download FSUIPC 4.959m from the Download Links subforum above, and let me know if this fixes things. Thank you. Pete

That is working fine here. Please show me the specific INI file. 49+3 is just a slightly easier way to enter the parameter it needs and uses internally (and records in the INI fie) which would be 817 (=256 x shifts + 49). For instance, I've just assigned a small range to do the same (49+3) and the result in the INI is: 5=QX,B,1419,2903,0,0,1070,817 -{ TO SIM: AXIS_AILERONS_SET Leaving=key press & release: ctl+shft+1 }- Also, please note that version 4.955c is out of date and not supported. I can only support current versions. Pete

Maybe one or more of them is hogging the access to WideClient? It only has the one access point. It's actually possibly for a client application to sit in a tight loop making continuous demanss and never letting others get a word in. Cooperatively written programs moderate their requests to one batch every so many milliseconds, even up to 1 second intervals (like my own TrafficLook and WeatherSet programs). Decently written programs batch their requests together, efficiently, others make individual requests for every single item of information being read or written. WideClient does its best to allow lots of time for all the clients, but when it receives a request it can do but process it, no matter whether it is from the same application as the last one or not. To ignore it would make too many programs not work correctly. You may be able to impose mediation by determining which ones are the most demanding, and setting them to run at a lower prioriy, whilst raising the more efficient ones in priority. Pete

The only thing I can think of doing is to eliminate the others. Assuming only one thing is doing it, use a binary division process for speed. Assign 1/2 to "no thing". If it isn't in that half, it must be in the other half. Either way, reenable or disable half the others (now down to a 1/4, and so on. For, say, 256 entries this gets you the culprit in 8 tries only. Unfortunately that won't work if there's more than one culprit -- the resluts will be indecisive. So then the only way is all off, as you did then re-enable them one by one. When it occurs again, note that one and disable it again, then continue. I don't have a C2 so I can't really help more directly. Certainly such stutters never noticeably occurred when I did have the C2, and yours is the first such report in all the years it has been around with my driver. Maybe it is because of a change in FSUIPC, responding to whichever command it turns out to be. Pete

In WideFS. I need to see logs, as I keep saying. Pete