fsuipc 3536 axis assignment question

[ranm]

Hello

I've tried using FSUIPC 3536 to achieve a more presice calibration of my home built throttle quadrant. FSUIPC 3536 doesn't seems to pick up the Y-Rotation axis of the joystick.

I'm using a Plasma controller, which presents 2 X 8 axis joysticks to Windows XP. It works fine with FS assignments, calibrated with FSUIPC, but I would like to use direct assignment if I could. FSUIPC detects all other axis fine; CH Yoke and Pedals, as well as the plasma's other axis, but not y-rotation, which is Engine 1 mixture :(

I turned off the FS joystick off while trying direct assignments, the Y-Rotation shows up in Windows XP and is calibrated OK using Control panel, and as I said, works when assigned from FS (after re-enabling the joystick)

Any help would be appreciated

Regards - Ran

[Pete Dowson]

I've tried using FSUIPC 3536 to achieve a more presice calibration of my home built throttle quadrant. FSUIPC 3536 doesn't seems to pick up the Y-Rotation axis of the joystick.

...

I'm using a Plasma controller, which presents 2 X 8 axis joysticks to Windows XP.

8 axis joysticks? The Windows facilities for joysticks I'm using only provides 6 axes, 1 POV and 32 buttons per joystick. I believe DirectInput caters for more, but I am not using that -- you'd need to use the normal FS assignments for those axes which aren't part of the standard 6 I'm afraid. Sorry.

Regards

Pete

[ranm]

Thanks for a quick reply pete

Windows XP supports 8 axis joysticks 'out of the box', as I can see all 8 in the Windows XP games controller applet.

I'm only using 6 axis anyway:

x-axis: throttle 1

y-axis: throttle 2

z-axis: prop pitch 1

x-rotation: prop pitch 2

y-rotation: mixture 1

z-rotation: mixture 2

FSUIPC detects all above but not the y-rotation axis.

In any case, I will keep on using the fS assignments as you suggested as that works for now

Kind regards - Ran

[Pete Dowson]

Windows XP supports 8 axis joysticks 'out of the box', as I can see all 8 in the Windows XP games controller applet.

Yes, but that's via DirectInput. The standard Windows API "joyGetPos" doesn't supports more than the six, X Y Z R U V. There is a POV, and it is possible that your rotation axis is coming through on that (rotation being like a point-of-view control as well I suppose).

If it is a POV then I could add it (as "axis P") to the FSUIPC facilities. Can you see if it is recognised at all in the Buttons Tab -- that does look at POVs as well, splitting them into up to 8 buttons for the main directions.

I'm only using 6 axis anyway:

x-axis: throttle 1

y-axis: throttle 2

z-axis: prop pitch 1

x-rotation: prop pitch 2

y-rotation: mixture 1

z-rotation: mixture 2

Eryou have 2 each of X, Y and Z? Is that how they are labelled? Are you sure they are not coming through as two separate joystick numbers if so? The API I am using names them X Y Z R U V.

FSUIPC detects all above but not the y-rotation axis.

But by what name does FSUIPC see them, please? Certainly not by X Y Z X Y Z, it is either seeing them as X Y Z R U V (with one missing for now -- till we find out why) or as Joy #n X Y Z and Joy #(n+1) X Y Z.

If your Y-rotation is acting like a POV it may not give a big enough change in any case for me to see it changing. Just to test that I may send you a test version of FSUIPC with a very low detection threshold. Maybe I need to make it adjustable.

Meanwhile, I enclose a little program called "Joyview". This uses the same Windows facilities that I am using and can show us whether we can read all your axes, and even what sort of values we'll get.

Just unzip it to the desktop and double click it. You'll see a list of input devices, numbered [01] to [16]. These correspond to my joystick numbers 0 to 15 (just add one). They may or may not show device names -- probably, for generic USB devices, they all all listed as "None". Don't worry about that. Open each device in turn, via the little + button and select its "joyGetPosEx()" entry.

Far over to the right there are some checkboxes. Make sure the "JOY_RETURNALL" one is checked. You can look at the calibrated values with "JOY_RETURNRAWDATA" unchecked, or the RAW values with it checked. Leave all the others unchecked.

Move the assorted axes around and see the values change. Let me know what you find, please.

Regards,

Pete

Joyview.zip

[ranm]

Hi Pete

using JoyView, the axis for the throttle have been discovered as follows (I didn't check FSUIPC but I assume these will be the same):

Joystick 3

--------------

throttle 1 - X

throttle 2 - Y

prop pitch 1 - Z

prop pitch 2 - V

mixture 1 - missing (persuming should be U - value constant on 32767)

mixture 2 - R

The plasma controller I use has dedicated connection for a POV switch which I don't use, so it shouldn't be a factor.

Thanks again - Ran

[Pete Dowson]

mixture 1 - missing (persuming should be U - value constant on 32767)

Ah, this I assume is your Y-rotation? If it were really 'U' then Joyview, and FSUIPC, could see it. 32767 (hex 7FFF) is a sort of default "not connected" reading, the same would be obtained by an open circuit.

It seems that your controller is, instead, using one of the other 2 axes which aren't accessible using this interface.

Sorry, but if Joyview can't see it then neither can FSUIPC. Unless you can change the Plasma connections you have, or reprogram it to use 'U', then I'm afraid you will have to continue with FS assignments, at least for that axis.

It doesn't hurt to use FSUIPC assignments mixed with FS assignments, but just be sure that the same axes are not assigned in both otherwise you will get conflicts and jitters caused by the double readings and applications.

Regards,

Pete

[ranm]

Cheers Pete

I would have thought that the 2 'other' axis not supported by FSUIPC are the ones Windows calls Slider1 and Slider2, just because they are coupled together. - never mind. Next time I have my throttle open, I will connect the last two axis to see if one of them shows up as U. - I'm curious now :)

I appreciate your help, and thanks again for a great product in FSUIPC.

Ran

[Whiteox]

We've had interesting experiences with FSUIPC 3.537 dll and trying to get the Jet Reverser mapped to a lever on a yoke.

We eventually got it to work very well, only to find that it inteferred with the graphics and that none of the keyboard controls would work. Upon restart (FS9), the Reverser lever worked once, then did nothing. Re-assigning the lever in FSUIPC made no difference as it had kept the settings anyway.

Some of the responses in forums I've seen tend to confuse the setup neccessary between 3.35n and 3.357.

For example it is neccessary to assign FSmixture in FS9's Control to the same axis as used in FSUIPC 3.350 - BUT in FSUIPC 3.537 it is not clear that the FSMixture control should be assigned in FS9, as it states somewhere that the same axis assignments should be not be mapped by FSUIPC and FS9. -

Does the FSMixture control have to be assigned to the same lever in FSUIPC 3.357?

FS9 saw the lever in question as 'X rotation' while FSUIPC saw it as 'U'.

Does U equate to X rotation?

Also in FSUIPC, if the U Axis was defined first, then set to Reverser, then calibrated on the next tab, by the time you got back to the Axis tab, it would show a completely different axis (like Y). I suppose that by now FSUIPC would have written a new .ini with the selected values of the U axis? Is a restart needed?

In any case none of these worked by trial and error, except once after a restart when the graphics screwed up. I suspect if X rotation is a POV then that may have something to do with that.

With regard to the cfg files, if FS9 is set to disable the yoke, then does that mean that ALL the functions/assignments of the yoke have to go through FSUIPC to make it work?

Thanks :?

[Pete Dowson]

I seem to have read this before in another thread? Please don't post the same things twice, it just makes a lot of extra work.

We've had interesting experiences with FSUIPC 3.537 dll and trying to get the Jet Reverser mapped to a lever on a yoke.

Trying? This is probably the commonest action FSUIPC is used for, and it has been used in this way now since FS2000 days with no problems. Why did it need "trying"?

We eventually got it to work very well, only to find that it inteferred with the graphics and that none of the keyboard controls would work.

You most definitely had something else entirely going on there then -- there is absolutely no way FSUIPC touches any of that.

Some of the responses in forums I've seen tend to confuse the setup neccessary between 3.35n and 3.357.

There's no difference whatsoever unless you want to use FSUIPC's axis assignments. And no one's asked questions here, until now, so why are they "responding" elsewhere? The Beta versions are provided here for a reason, so I can get testing and feedback. It is no use having that going elsewhere! :-)

For example it is neccessary to assign FSmixture in FS9's Control to the same axis as used in FSUIPC 3.350 - BUT in FSUIPC 3.537 it is not clear that the FSMixture control should be assigned in FS9, as it states somewhere that the same axis assignments should be not be mapped by FSUIPC and FS9.

If you are confused by Axis assignment in FSUIPC, why on Earth use it? Use the assignment in FS. Of course you can assign an axis to the mixture in FS OR in FSUIPC, not both. Either way it would be picked up by the default setting for reverser in FSUIPC's Calibrations.

An easier way without going via "mixture" is to use the "direct to FSUIPC calibration" option to assign it directly to the Reverser!

Surely, isn't it obvious that FSUIPC's Axis Assignment is an alternative to FS's axis assignment, with more facilities. That's what it says. Why any confusion? It is ANOTHER FACILITY! That is all. Would it be clearer if it were in a different program called "AXISASSIGNMENT"? If so, why, exactly? I am vey very puzzled over this reaction.

My general advice is: if you don't understand it you probably don't need it at all, so don't use it. It was added in answer to requests, and I'm sure those who requested it will use it well.

FS9 saw the lever in question as 'X rotation' while FSUIPC saw it as 'U'. Does U equate to X rotation?

Sorry, I've no idea. There's no such thing as "X rotation" in the standard Windows joystick API. It must be a name given to or by DirectInput. However, if the same axis changes the numbers, then, yes, it IS the same axis, by definition! That's how I would find out if I needed to know.

Also in FSUIPC, if the U Axis was defined first, then set to Reverser, then calibrated on the next tab, by the time you got back to the Axis tab, it would show a completely different axis (like Y).

The axis calibration facility scans the axes and shows the one with the biggest change at that time. It does this initially and the scan can be repeated by clicking the Rescan button. Please read the documentation about this. It explains at length, with pictures, how to use that tab.

If an axis is shown as soon as you select the tab it usually means that axis is changing. If you aren't touching it this would usually indicate some jitter. You might need to use the Ignore button to see the one you want to program next, or check on another.

I suppose that by now FSUIPC would have written a new .ini with the selected values of the U axis?

No, it writes the INI with ALL the changes you have made on any or all Tabs, only when you press Ok to exit. At any time before you press Ok you can Cancel, or press Escape, and NONE of the changes you made, at all, during this entire entry to FSUIPC options, will be effected, all of the previous values will be retained.

Is a restart needed?

No, never. Only after user Registration, when you are prompted to restart. Why should one be needed at any other time? That would be horrendous!

In any case none of these worked by trial and error, except once after a restart when the graphics screwed up.

I really cannot imagine what you are doing, but the fact that other things got screwed up is certainly an indication that something else is wrong with your FS installation. I would advise reinstalling FS itself.

I suspect if X rotation is a POV then that may have something to do with that.

POVs are not read and cannot be detected by FSUIPC's axis programming. They are only read by the Buutons tab and converted to 8 buttons according to direction.

With regard to the cfg files, if FS9 is set to disable the yoke, then does that mean that ALL the functions/assignments of the yoke have to go through FSUIPC to make it work?

Not just yoke, all and any joystick devices. But you don't have to disable them, I only said you could IF you wanted to do everything through FSUIPC. It might be more efficient, and certainly more flexible that way (what with the aircraft-specific capabilities). But you don't have to. You certainly can mix them. Just take care not to have any specific axes or buttons programmed in two places at the same time.

Regards

Pete