jordanal

That's because you are using the wrong controls. All the "Axis .... Set" controls only have positive input. They correspond to the controls FS assigns. This is why folks use FSUIPC to get reverse on the axis, as it converts the AXIScontrols into the older, original (FS98) controls which have a reverse range. Try using the controls I suggested. Don't just stop at the "Axis ..." ones. Pete Um, if I'm following you correctly, I'm getting the same results (negetive values issue) using the following: [Axes]...10=2V,256,F,65923,0,0,0 ; PROP_PITCH1_SET[buttons]....89=P2,22,C65923,-4096 ; PROP_PITCH1_SET Rev90=U2,22,C65923,0 ; PROP_PITCH1_SET Idle Regards, AL

Mixture cut-off is okay, but just having a digital reverse on/off control doesn't give you any variable reverse action. Are you happy about that? If not why not just do as many folks do with ordinary levers without any buttons or switches at all, simple dedicate part of the range for reverse. I know some folks have made little detents for the centre of the idle are they chose, glueing a little bit of rubber in or near the slot. Better to send Throttle1_SET with a negative parameter. Providing you calibrate an adequate idle (0) range to ensure there are no axis changes, that will simply engage reverse immediately. There's no such digital control, just use the axis one being used by the axis in any case - ThrottleN set, with your desired parameter, -4096. 5? Not sure what you want here, but, no, -4096 is full reverse. If you want other values use other parameters between 0 and -4096. No, use the relevant axis controls with the parameters as desired. Regards Pete True, it is unfortunite that Saitek did not inlculde part of the axis-output below the detent. But, one advantage is that I get really good lever control (resolution) becuase of the length of the lever travel over the range of the axis. No, I would not want to calibrate a ficticious idle somewhere above the detent. That would drive me nuts. I doubt I will take the time to physically modify the new Throttles, especially during the warrently period. I thought sending button parameters to the axis was the best solution as well but when I tried to set the compressed lever switches to axis variables with a -4096 parameter to force a reverse, I kept getting really weird axis/lever movements. Below is a log of another test I just performed with Prop_Pitch1. With the axis at 0, compressing lever button sends a -4096, but the lever visually jumps about half-way back up the axis. As you can see in the log below, the button commands -4096 parameter, but the axis immediately interferes with a 6144 parameter. Then when uncompressing the lever button with a 0 paremeter, the axis commands a 8192 parameter. Am I setting this correctly? Regards, AL [buttons]89=P2,22,C66421,-4096 ; AXIS_PROPELLER1_SET Rev90=U2,22,C66421,0 ; AXIS_PROPELLER1_SET Idle(LOG) 740688 *** AXIS: Cntrl= 65923 (0x00010183), Param= 325 (0x00000145) PROP_PITCH1_SET 740828 FS Control Sent: Ctrl=66421, Param=-13393 740828 *** AXIS: Cntrl= 65923 (0x00010183), Param= 1495 (0x000005d7) PROP_PITCH1_SET 741125 FS Control Sent: Ctrl=66421, Param=-15083 741125 *** AXIS: Cntrl= 65923 (0x00010183), Param= 650 (0x0000028a) PROP_PITCH1_SET 741297 FS Control Sent: Ctrl=66421, Param=-16384 741297 *** AXIS: Cntrl= 65923 (0x00010183), Param= 0 (0x00000000) PROP_PITCH1_SET 742797 Button changed: bRef=0, Joy=2, Btn=22, Pressed 742797 [buttons] 89=P2,22,C66421,-4096 742797 FS Control Sent: Ctrl=66421, Param=-4096 742828 *** AXIS: Cntrl= 65923 (0x00010183), Param= 6144 (0x00001800) PROP_PITCH1_SET 744563 Button changed: bRef=0, Joy=2, Btn=22, Released 744563 [buttons] 90=U2,22,C66421,0 744563 FS Control Sent: Ctrl=66421, Param=0 744610 *** AXIS: Cntrl= 65923 (0x00010183), Param= 8192 (0x00002000) PROP_PITCH1_SET 746344 FS Control Sent: Ctrl=66421, Param=-16123 746344 *** AXIS: Cntrl= 65923 (0x00010183), Param= 130 (0x00000082) PROP_PITCH1_SET 746469 FS Control Sent: Ctrl=66421, Param=-11703 746469 *** AXIS: Cntrl= 65923 (0x00010183), Param= 2340 (0x00000924) PROP_PITCH1_SET 746641 FS Control Sent: Ctrl=66421, Param=-8712 746672 *** AXIS: Cntrl= 65923 (0x00010183), Param= 3836 (0x00000efc) PROP_PITCH1_SET 747219 FS Control Sent: Ctrl=66421, Param=-8972 747219 *** AXIS: Cntrl= 65923 (0x00010183), Param= 3706 (0x00000e7a) PROP_PITCH1_SET 747375 FS Control Sent: Ctrl=66421, Param=-10532 747375 *** AXIS: Cntrl= 65923 (0x00010183), Param= 2926 (0x00000b6e) PROP_PITCH1_SET 747516 FS Control Sent: Ctrl=66421, Param=-13003 747547 *** AXIS: Cntrl= 65923 (0x00010183), Param= 1690 (0x0000069a) PROP_PITCH1_SET 747688 FS Control Sent: Ctrl=66421, Param=-15603 747688 *** AXIS: Cntrl= 65923 (0x00010183), Param= 390 (0x00000186) PROP_PITCH1_SET 747813 FS Control Sent: Ctrl=66421, Param=-16384 747813 *** AXIS: Cntrl= 65923 (0x00010183), Param= 0 (0x00000000) PROP_PITCH1_SET

Bump... Good morning Pete, I'm curious to know your initial thoughts to the above buttons request. Regards, AL

I'm sorry you're probably gonna get some cobwebs on 'ya there Pete but we all appreciate the effort. I think you're gonna find quite a few more folks editting and creating larger, more complex ini files for the new Saitek Yoke and Throttle Quads. If you're not familiar with it yet, it has a 3-way modal switch on the right forfinger that works nicely in FSUIPC as a tripple modal switch. I just finished assigning almost 100 buttons to the general section of my ini file yesterday and needless to say, comment lines really help. This morning I'm rewritting my aircraft-specific sections... Regards, AL

Yes Sir, I received a new Saitke Yoke & Throttle set for Christmas and have been using 4.208 beta (See thread requesting new buttons below) and had manually inserted standalone comment lines for each of the yoke buttons. While using the GUI to test new throttle-lever button assignemnts, I noted that these comment lines, which had sequencial index numbers assigned before the semi-colon, were completely erased by new assignments from within the GUI. Hope this helps... Welcome back... AL

Hi Pete, It is my undestanding that inserting standalone comment lines in the FSUIPC.ini file is acceptable as long as each comment has an index number associated with the line. With FSX-sp1 and FSUIPC v4.208(beta), I'm finding my comment lines are being over-written/ereased when using the FSUIPC GUI. I had several button comments such as: [buttons] 0=;Yoke Button #1 5=;Yoke Button #2 9=;Yoke Button #3 These were erased the next time I made changes in the "Button Assignments" page in the FSUIPC GUI. I have not yet had the oportunity to see if the same is true for FS9 and FSUIPC3. Just thought I'd let you know... AL

Hi Pete, I hope you and your family had a Merry Christmas/Holiday. I received a new Saitek Yoke for Christmas and have spent some time over my Christmas vacation translating my old CH-Products FSUIPC.ini file to fit the new hardware. One thing that is really different between the CH Yoke/Throttle and the Saitek Yoke/Throttle is the fact that the Throttle axis do not "include" a momentary lever-switch within the range, but the switch resides fully "below" the minimum axis range. In other words, the detent for all levers is -16383 vice a higher position as on the CH throttles. This lever detent (-16383 - minimum axis) is also the top of a uncompressed lever-switch whereby the very minimum lever postion compresses the switch for as long as the lever is below the detent. Axis values remain -16383 even when the lever is below the detent, compressing the switch. So the old way of calibrating a reverse zone below the detent no longer works when using these new Saitek throttles. Therefor we must assign these digitial lever switches for Reversers and Mixture cutoffs. Saitek Throttle travel depiction: Lever-Max/Up ---------------------- Lever Detent/Switch-Uncompress ---------- Lever-Min/Switch-Compressed 16383 -16383 / Switch-Off -16383 / Switch-ON For the moment, assigning a repeat ® 65966 THROTTLE1_DECR to lever one for example, simulates holding the F2 key down to force the reverse. But the repeat rate is slow (even after setting various repeat rates) to reach full revearse. I also prefer not to flood repeate switch positions if I don't have to. I would prefer/request "THROTTLE(x)_REV" variables that digitially turn on the reversers by sending (-4096) immediately when the switch is compressed. Releasing the lever switch (back up to detent) with 65967 THROTTLE1_CUT already works well and coincides nicely with the mimimum axis (-16383) in the detent. So for throttles, I see a need for five new reverse-on variables (I'm guessing sending a -4096 to the throttle position when on): THROTTLE_REV THROTTLE1_REV THROTTLE2_REV THROTTLE3_REV THROTTLE4_REV The same is true for reversing the prop-pitch digitially with the prop-lever switches. Request five new reverse pitch variables for their respective compressed lever switches (again, assuming they would be sending a -4096 to force a reverse axis position): PROP_PITCH_REV PROP_PITCH1_REV PROP_PITCH2_REV PROP_PITCH3_REV PROP_PITCH4_REV I should note that I found the variable names for PROP_PITCH(x)_HI and PROP_PITCH(x)_LO to be backwards. I set the uncompress (U) position of the PROP lever switches to PROP_PITCH(x)_HI and this sets the prop levers to idle, again coinciding nicely with the minimum axis (-16383) in the detent. Assigning PROP_PITCH(x)_LO to the uncompressed switch would actually set the prop-lever axis to full/up/16383. These _HI/_LO names seem to be backwards much like the ZOOM_IN/OUT variables of which I know you're already aware. As for the Mixture levers, assigning the compressed mixture lever switches (when bellow the detent) to MIXTURE(x)_LEAN works nicely for full cutoff of the fuel flow when below the detent (compressed switch). The problem with mixture levers on the Saitek is, there are no variables to assign digitially, the idle position of the mixture axis when uncompressing the lever switches, back to the detent position. We need five new MIXTURE(x)_IDLE variables that I'm assuming set a 8192 (idle) value when the respective lever switch is released (back up to the detent). This would work nicely with the bottom of the Mixture axis lever travel (-16383) detent, also sending the 8192 idle position: MIXTURE_IDLE MIXTURE1_IDLE MIXTURE2_IDLE MIXTURE3_IDLE MIXTURE4_IDLE My current FSUIPC.ini for a twin such as the default King-Air: [Axes] 0=2X,256,F,65763,0,0,0 ;AXIS_AILERONS_SET 1=2Y,256,F,65762,0,0,0 ;AXIS_ELEVATOR_SET 2=2Z,256,F,66420,0,0,0 ;AXIS_THROTTLE1_SET 3=2U,256,F,66423,0,0,0 ;AXIS_THROTTLE2_SET 4=2V,256,F,66421,0,0,0 ;AXIS_PROPELLER1_SET 5=1X,256,F,66424,0,0,0 ;AXIS_PROPELLER2_SET 6=1Y,256,F,66422,0,0,0 ;AXIS_MIXTURE1_SET 7=1Z,256,F,66425,0,0,0 ;AXIS_MIXTURE2_SET 8=0X,256,F,66387,0,0,0 ;AXIS_LEFT_BRAKE_SET 9=0Y,256,F,66388,0,0,0 ;AXIS_RIGHT_BRAKE_SET 10=0Z,256,F,65764,0,0,0 ;AXIS_RUDDER_SET [BUTTONS] 52=R2,20,C65966,0 ;THROTTLE1_DECR 53=U2,20,C65967,0 ;THROTTLE1_CUT 54=R2,21,C65971,0 ;THROTTLE2_DECR 55=U2,21,C65972,0 ;THROTTLE2_CUT 56=R2,22,C66006,0 ;PROP_PITCH1_DECR 57=U2,22,C66007,0 ;PROP_PITCH1_HI 58=R1,6,C66011,0 ;PROP_PITCH2_DECR 59=U1,6,C66012,0 ;PROP_PITCH2_HI 60=P1,7,C65987,0 ;MIXTURE1_LEAN 61=P1,8,C65992,0 ;MIXTURE2_LEAN As always, thanks for your help Pete, Repsctfully, Al Jordan

I believe the values are for display purposes. Depending on the device, yours may be different. I don't recall having ever messed with those on the axis assignments page. Sorry. AL

I've alwaysl left the Delta and IN/Out values to the scanned defaults. 256/-16384/+16384 in my particular case. As long as the device appears to be working with a decent level of resolution, I would probably ignore messing with these for right now until you are fully familiar with all of FSUIPC. But, FWIW, if you make the Delta 512, then you would have coarser control (64 positions), if you make the Delta 128, you would have fine control (256 positions) over the range, but with more overhead by increasing the number of position reports of the device to FS. Hope this helps... AL

After restarting FS or making changes in FSUIPC, you may have to tap the toe brakes with your feet to complete the initial USB scan of the toe brakes positions. This also true of many other USB devices such as throttles. Look at the throttle positions when you first start FS, they don't correspond to the lever positions until you move them just a bit. Then they're good to go for the entire time FS is running. Hope this helps... AL

On the WideServer PC, start FS as normal. Then, on the WideClient/remote PC, start the wideclient.exe file and wait for it to connect to FS over the network. Once WideClient.exe is connected then you can start any FS application on the remote PC and they will see FS running. If FS doesn't inidcate "Waiting for clients" in the FS window boarder, or WideClient.exe doesn't indicated "Connected" then you have other issues to resolve before trying to start the apps on the remote PC. Most connection issues are of the network or firewall type. Ensure TCP port 8002 is open in the Firewall on both PC's. Good luck... AL

Joystick Calibration tab - second or third page (right arrow button).

Damn Ken, you beat me by one whole minute! We must have hit the submit button within seconds of each other :lol:

Congratulations Pete! After a quick check of the PMDG 747 using FSUIPC v3.764, I'm happy to report that all 4 engines/gauges started normally, as expected. Advancing the throttles also increases all 4 EPR gauges. You seemed to have fixed the issues noted in this thread. v/r, AL

Some more facts for you and PMDG. Same issue with both betas v3.759 and v3.763. Again, v3.75 works as expected. Disabling WideServer.dll in the modules folder makes no difference. Same hot-start issue is noted with either the above beta versions. I now believe this to be some sort of guage problem. After closer examination, I can hear the (hot-start) engines 2-4 actually spool-up when I advance their respective throttle levers. Animation on the N1 fan also changes on the respective engines when advancing the throttle lever. EGT is ~ 512 degees, N2 @ 63%, N1 ~ 25%, EPR @ 1.00, and all three are unresponsive to throttle movemnt. Testing done with PMDG Boeing 747-400 United P & W variant. Regards, AL

My PMDG contacts have been trying 3.763 for me with the 747 and cannot reproduce these problems, so this is likely to be quite a tough nut to crack. There's really no much FSUIPC involvement in any of the actions their code uses to start engines. Do you have any other FSUIPC client programs running at the same time? And when you say "and no EPR" do you mean no indication at all, or a constant value of 1.0? Regards Pete In my particular case, this is on a Core2Duo E6700 O/C'd. After auto-starting engine 2-4, each slowly rises and stays at 512 degrees, vice dropping back to the idle ~ 410 degrees. I believe EPR stays @ 1.0 even when advancing these three thottles (seperate throttles on a CH Throttle-Quad set in FSUIPC calibration). This installation is also a WideServer (latest full version) with Activesky, FS Flight Keeper, Radar Contact, and FS Real time running as applications on the Wide-client. When I discovered that dropping back to v3.75 fixes the issue, it was the only thing I changed and then immediately restarted FS9. I ran the same wide-client applications and the same FSUIPC.ini config. It makes me wonder if the chap at PMDG is testing v3.763 with a FSUIPC calibration set and individual throttles for hardware. I also checked the throttle idle calibration in FSUIPC during this issue and the output for each throttle was set correctly and advancing witht the throttle levers as expected. Same throttle calibration is still in use back on v3.75. The other thing that should be passed on to PMDG, on these three engines, when it appears to hot-start (512 degrees) the bleed-air never comes out of these engines (2-4) only the good engine #1. This is indicated both in the ECS display and the bleed-air buttons on the overhead, below the pack switches. But, the start buttons do close for each engine and I am able to switch on the hydrolics for each engine. To my humble eye, it almost appears as a timing issue; like something in the end of the start sequence is missed, and they don't spool back to idle.

Hi Pete, It appears that the latest FSUIPC3 beta may be adversly affecting the PMDG 747 engine start sequence. After installing beta v3.763, I could not start engines 2 through 4, either manually or through the auto-start sequence. The issue is easily idenified by the EGT going straight to 512 degrees and no EPR. Although, engine # 1 never seems to experience this hot-start issue. I looked through the FSUIPC.log file and did not see anything unusual. My guess is, some of the new features in the FSUIPC betas are conflicting with the custom PMDG 747 coding. As soon as I reverted back to v3.75, all the engines started fine. This issue was observed over several executions of FS9. I wanted to find out if any other PMDG 747 owners have experienced this issue so I posted over in their forum first here: http://forums.avsim.net/dcboard.php?az=7470&page= Regards, AL

Correct path for the application log. Of course with everything else I had fubar'd troublshooting the axis issues over the past week, the error in my Vista applications log could have been somehow a result of that as well. I will check the application log when I get home to see if it happened again when I recently had to reinstall FSUIPC4 v1.04 the other day, after installing HiFiSim's ActiveSkyX utility on a my wideclient; in order to set the simconnect.ini file working for both FSUIPC and ASX.

Nope, no concerns here as FSUIPC v4.104 seems to be wokring here so far. Just wanted to bring the application-log to your attention. If I'm not concerned about and you're not too concenred about it then it sounds like it's no big deal. Again, glad you're back and thanks again for your help with the axis issues. Your support always has been and continues to be top notch.

Pete, I don't even know what side-by-side is, or means. I am simply reporting an observation that in my MS Windows Vista Event - Application log, that when I run the FSCUIPC v4.104 installer.exe, I notice this error in the Vista "Application" log viewer. I wasn't trying to uninstall anythig at the time. No, I have never see any error indications in the FSUIPC installation log located in the modules folder nor does it appear to be affecting FSCUIP v1.04 performance in any way. I just thought you'd like to know that I see this error when I install FSCUIPC v1.04. You said you had Vista Premium and FSUIPC v1.04 running on box. Look in the Vista Event log viewer under application, do you see this side-by-side error around the time you had installed FSCUIPC v1.04? Al

Well hello Pete, welcome back! I trust your daughter got some useful work out of you? :lol: As for repairing simconnect in Vista, I think you are correct. The simconnect.cat, simconnect.manifest, and simconnect folder were owned by "TrustedInstaller" which is non-visable account. To remove these files and folder for both FSX RTM & SP1, I had to change the ownerships to me (admin). Well, when I put these back after fixing the axis issue, with me still as the owner, simconnect was non-functioning. Becuase the TrustedInstaller is not a selectable account to apply to a file or folder, I could not force the owneship back to the way I originally found it. So yes, I think you would have to uninstall and re-install FSX in its entirety. I was reluctant to do this becuase I had just built a new PC and had alreay installed and registered FSX several time in the last few weeks. Vista-U's "save previous versions of files" saved my keaster though. I'm not exactly sure what the specific circumstances are when v1.04 generates the side-by-side error in Vista's system log, but it seemed to happen every time in installed it. Meaning, it happened with FSX RTM & SP1, and both with and without the simmconnect folder. v4.072 never exibited this error in the system log at anytime. Glad you're back...

Well, I seemed to have fixed my lost axis issues mostly through persaverance, trial-an-error, and reading forums. :D This thread http://forums.simflight.com/viewtopic.pvista+axis is what helped me the most. First, I rolled back (uninstalled SP1) and repair-installed FSX when I noticed I continued to have the same problem. Hmm, I could have sworn I had FSUIPC axis functionality in FSX RTM. It looked identical to what Peter Hayes saw above, with the rescan button greyed-out on the axis tab. At this point, I thought it a good idea to roll-back FSUIPC as well to a known good starting point, or so I thought. The only other FSUIPC version I had was 4.072 which I though I must have been previously using with FSX RTM. I then "properly" uninstalled my CH devices and manually cleaned out the remaining stale CH DirectInput Devices under HKCU. The only two DirectInput devices I now had were for my keyboard and mouse. Good to go I thought. Re-enabled my CH devices and I was shocked to see I still could not get CH devices to show up on the axis tab. For the next six hours I tried everthing under the friggin sun except a complete re-install of Vista-Ultimate which was not going to happen becuase FS9 is still perfect. After coming across the aforemention thread, it was then shocked to see that the axis assignemnts tab was broke up until v4.08 which is the earliest version that worked with Vista (six hours wasted by a version difference of 0.008). Damn if I didn't install 4.104 with my current FSX RTM installation and bam, all CH devices worked on the first try. Instaled SP1 and the axis assigments continue to work like a champ with both SP1 and FSUIPC v4.104. Also, as mention in Pete's sticky at the top of this forum, do not attempt to delete any simconnect dll or Wxsx folder under Windows in Vista. If you do manage to change the permissions enough on this and the parent folders and get them deleted, then guess what? A repair-install of FSX and or SP1 does not recreate the cat files or folders for the simconnect dll becuase only the "TrustedInstaller" account can put these back and it only does that on a clean install of FSX or SP1. Oh, and I had cleaned out my recycle-bin don't you know! :evil: I did manage to utilize Vista's new revert to older file version function whereby it saves older copies of files, and there I found a copy of each of the simconnect dlls and cat files for the Wxsx folder. Whew, time to fly!.

Pete, Was does the following mean regarding this issue? This "side-by-side" error is generated in my Vista Event Log (Application) each time I install FSUIPC4 v1.04. I downloaded and installed the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86) from Microsoft thinking there's an extraneous dependacy, but I still get the side-by-side error. Log Name: Application Source: SideBySide Date: 5/25/2007 6:37:01 AM Event ID: 33 Task Category: None Level: Error Keywords: Classic User: N/A Computer: AlComp Description: Activation context generation failed for "F:\Install Queue\Pete Dowson - FSUIPC v4.104 Beta\Install FSUIPC4.exe". Dependent Assembly Microsoft.FlightSimulator.SimConnect ,processorArchitecture="x86",publicKeyToken="67c7c14424d61b5b",type="win32",version="10.0.61234.0" could not be found. Please use sxstrace.exe for detailed diagnosis. Event Xml: 33 2 0 0x80000000000000 5344 Application AlComp Microsoft.FlightSimulator.SimConnect ,processorArchitecture="x86",publicKeyToken="67c7c14424d61b5b",type="win32",version="10.0.61234.0" F:\Install Queue\Pete Dowson - FSUIPC v4.104 Beta\Install FSUIPC4.exe

Yup, I figured out copying aircraft specific sections of the ini file the week FSX came out. Agreed much easier. I have been using aircraft-specific settings for several years now as well. Right now I'm using a very simple ini file for troubleshooting purposes of this issue. Thanks again for checking the issue this weekend. Much appreciated...

Thank you so much Peter for replying. You're the very first person to indicate similar issues. I am seeing the exact same thing only with SP1 and FSUIPC v4.1+. Yes, I can see axis in FSUIPC if I enable cotrollers within FS, but up until SP1, I always had that unchecked so I didn't have to mess around with conflicting axis assignemsnts within FS. I would just disable all of them with the checkbox. I have an elaborate multi aircraft-specific FSCUIPC ini file which I have used for years, and continue to use in FS9/FSUPIC3 to this day. Again, the fact that I can see buttons in FSUIPC4 indicates that some part of FSUIPC4 is working, so it has to be something with FSUIPC4 axis detection and perhaps simconnect. Maybe by uncheckecking the controllers in FS, it prevents controllers from going out simconnect to FSUIPC, or however it works. I'm sure Pete has that all figured and will try to explain it to me and I probably won't understand the low-level driver stuff, again, :lol: You did give me temporay fix, at least for the long 4-day holiday weekend (starting today :D ) to just enable and assign some axis within FS and use my existing calibrations within FSUIPC4 until Pete gets back. Thanks again, I'm sorry, but misery really dooes love company! :twisted: v/r, AL