Pete Dowson

Strange that they are still not seen, even with the same ID or not. Maybe try unplugging them and plugging in again, see if that's detected. Can you supply the FSUIPC4.joyscan.csv file, from the Modules folder, please? That shows what FSUIPC found in the Registry and in its interrogations via directInput. You can set IDs in the registry using "JoyIDs", whichis a little freeware program you can find on the Internet. You should be able to set it in FSUIPC, but it needs to detect it first. I'll look at the CSV file to see what is happening. Pete

You logs show no rudder detected in the "Prev" one, but it is detected on the current log: 3167 Device acquired for use: 3167 Joystick ID = 1 (Registry okay) 3167 1=Saitek Pro Flight Combat Rudder Pedals 3167 1.GUID={C1F90690-D088-11E4-8001-444553540000} 3167 Device acquired for use: 3167 Joystick ID = 1 (Registry fixed) 3167 1=Flight Yoke System 3167 1.GUID={12E39840-D089-11E4-8001-444553540000} 3182 Device acquired for use: 3182 Joystick ID = 2 (Registry okay) 3182 2=Saitek Pro Flight Throttle Quadrant 3182 2.GUID={634041D0-D089-11E4-8001-444553540000} The trouble there is that it has an ID of 1 in the registry, which is the ID you already had assigned for the yoke. As to why it may sometimes not be detected, the usual reason is that you have power management enabled in the USB controllers in the PC. Go to Windows Device manager, and in the Properties of each USB hub o device listed, turn off power management if it is an option. This will stop devices "going to sleep". Additionally, with multiple devices, it is always a good idea to activate Joy Letters, so that even if the IDs change, the assignments remain intact.

I'm not sure what the logs relate to exactly, but "FSUIPC5sim.log" shows rudder deflection in the P3D4 values, for both the cintrol input and the deflection, though the max percent deflection appears to be less than 9% in each direction. But in this case FSUIPC is not really involved in the rudder or steering operations as you have them both assigned to the FS controls. In the FSUIPC5direct.log you are getting full (well over 98%) deflection in both control input and deflection. So, FSUIPC is operating correctly. If the indicator on the Lower DU is not showing the deflection then it is the doing of the NGX.. What problems do you have with ipc.write functions? There's not much syntacx in the one function: just select the right function for the value number type (ipc.writeSD for a signed DWORD, which is what you want), offset 0x3114 for the value of the rudder, then 0x3110 for the control number (obtained from the List of Controls document. If you want to use the FSUIPC "direct" controls, the numbers for those are listed on page 35 of the Advanced guide. It's the writing to 3110 which triggers the action, so always set the parameter in 3114 first. Pete

To activate the logging which would be most useful: 1. Open FSUIPC Options 2. Select the Logging tab 3. Check the option on the left for non-axis Events Also it would be useful to see when offset D70 was written to, so: 4. On the right-hand side of the Logging options, enter 0D70 as an offset and U32 as its type 5. In the next line enter 0D6C as the offset and S32 as the type 6. Check "normal log" below. 7. Click OK 8. Operate the PFC control which invokes the macro, write down the order in which you operate the switch and let me know, along with matching logs. Pete

What happens when it "stops working"? A crash or does it simply hang? If it is a crash please find the Windows Crash Details in the Event Viewer. I need those details. Of course. Only SimMarket sells it in Europe! You ignored my last message, so I'll repeat: To help you I need more information: 1. What warning is it? 2. What happens if you ignore the warning and continue? 3. How many times did you try? 4. What is the version number of FSUIPC? 5. What is the version number of P3D3? 6. Does FSUIPC make a log file? (FSUIPC4.LOG in the P3D modules folder). If so please show it to me. Pete

No. Access to offsets is available to all programs with or without registration. For commercial products a fee is negotiated for commercial use. Pete

Okay. I was more imagining starting there. The odd order of lost events seems very strange. i don't understand that. As I said earlier, with most of todays PCs, i can probably set 10 as default. that 20 has lasted very many years! Pete

This is so long ago now (so many things happened since then), I'm going to have to start over. And not today. it's my 75th birthday and i'm just about to switch off for the evening1 I've got the files though: Why don't you look at what you are going to upload first? FSUIPC5 - TankSelect1 macro.log -- log truncated before system even ready! FSUIPC5 - TankSelect2 macro.log -- waste of space. just a load and close 24 seconds after being ready. nothing in between. FSUIPC5 - no macro.log -- same waste of space. just a load and close 24vseconds after being ready. nothing in between. You don't even have Event logging enabled in any of those in any case. PFChid64 - TankSelect1 macro.log PFChid64 - TankSelect2 macro.log PFChid64 - no macro.log For these I need a few days in any case, to remember again what the macros do in the code and understand the logs again. But I'll wait for proper FSUIPC logs as requested as they are likely to be more productive. Pete

As well as what Dave says (it is always wise to have backups of all settings for all programs), unless you are specifically deleting the Modules folder or the files in it, none of your FSUIPC related files are changed by any FSX or P3D re-install. Even an FSUIPC reinstall only replaces the DLL itself and updates the contents of the documents folder. So why are you creating more pain for yourself than necessary? Pete

I don't know spanish, but Google tells me this is something like: to hlep you I need more information: 1. What warning is it? 2. What happens if you ignore the warning and continue? 3. How many times did you try? 4. What is the version number of FSUIPC? 5. What is the version number of P3D3? 6. Does FSUIPC make a log file? (FSUIPC4.LOG in the P3D modules folder). If so please show it to me. Pete

Sorry, what do you mean "transfer the values? Just perform the calibration! The minimum and maximum values shown on the right are default values. You've not changed them at all! If "8364" is you maximum value, pressing the SET button over the Max reading will record that. Currently the numbers 8364 and 8366 just indicate that with an input of 8364 and you max input set, as it is, to 16380, the resulting output value is 8366. That seems perfectly reasonalbe to me! Please read the User Guide. Follow the numbered steps given in the calibration section for good calibration! Pete

Right. Back at the PC. My wife has told me I shouldn't be working today (75th Birthday AND Bank Holiday), but i don't like things left outstanding. Sorry about the long detailed misunderstanding. Now that we may be talking about the same things, I have had another look at the log. As I said, there are 19 occurrences of 03 00 02 08 60 7D 20 00, i.e. "button pressed". But counting all the ones where it isn't pressed (03 00 02 08 60 7D 00 00) I get 575! Now for a normal rotary encode (whether phased or the more expensive decoded type) there should be an equal number. After all with such an encoder alternate clicks set on and off, so it should be seen as pressed roughtly 50% of the time on average. So, this does confirm your earlier hypothesis that the firmware in the device is acting on both changes (on and off) by sending a press followed by a release. It won't be the encoder itself, but how its output is being processed. Thus there will be a timing problem. If my (internal) polling isn't frequent enough it will miss the presses. Looking at the log in that light it seems that the period that the button stays looking "pressed" averages around 90-110 mSecs. And that's the ones which are detected. So I assume the ones not detected are shorter. The poll rate in FSUIPC is 50 per second (a sleep of 20 mS per loop). That should easily be enough for any device. But then we come to the second problme with your device's firmware: the number of polls needed per cycle! This appears to average 3-4 minimum between each 03 block of 8. By dividing the data into 8 byte chunks (01, 02, 03 and 04) it will on average poll and receive the values we want every 80 mSecs (12.5 per sec). Any press-release signalled which is shorter than that will be missed. So, you see what I mean about poor firmware design. If it had simple signalled the on or off per click as I think it should there would be no problem. And if it supplied all the data each time it is asked for, again no problem. The combination of two poor design features is pretty bad, IMHO. How to fix it? Well, I can make the poll rate timing settable by parameter, which I will do. But when adjusting this, please bear in mind that it is in a high priority thread -- which means when it is active nothing else can run in that processor core. So it will need to you find the highest time which works consistently.. Try 10 first, then work from there, increase till it doesn't, decrease till it does. 5.151d to test, soon. ... Pete

The calibration without "no reverse zone" selected results in FSUIPC sending "THROTTLEn SET" controls (older, fS98 style controls) instead of the AXIS ... controls. The latter do not have a reverse range: -16384 is idle and the whole range to +16383 is forward thrust. The THROTTLEn SET controls have idle at 0 and the forward thrust values are all positive. The negative ones are reverse -- not right down to -16384 normally. The limit is set in the Aircraft.CFG file, and is often something like 0.25 (25%), so -4096 would be full reverse thrust. Most aircraft which read the throttle values themselves (like PMDG) do not work well with FSUIPC calibrations because they affect the engine at a different time, and the calibration may result in a different value being used in any case making them appear to jerk. With PMDG aircraft the Axis controls would need assigning, and not calibrated. the way to get reverse then is to send THROTTLE DECR controls (like pressing the F2 key) when the throttles are cut to idle. With Saitek throttles the button pressed when you pull the throttle ever right back can do that. I really don't know what the Aerosoft Airbus does, but other users of that aircraft must know what to do. Have you searched this forum, and the User Contributions subforum? There are separate Reverser controls assignable in FSUIPC "direct to calibration", but they use THROTTLEn SET with negative values, the same as FSUIPC calibration with reverse does for the Throttles themselves. So i don't suppose they'd help. I don't know of any other way to have a reverse range than using THROTTLEn SET, so if that doesn't work you might be stuck with the "F2" method. Pete

I think we were talking at cross purposes. I was indeed thinking you were saying that the log proved that the lua function was not getting everything that FSUIPC was reading from the device. There are two things I will tell you when I get back to my PC (I am walking the dog at present). But first let me say that your device's firmware is rather badly, even amateurly, written. It is the first HID device I've ever encountered like it, over 16 years since such devices were supported by FSUIPC, and other drivers I have written. More soon, and possible solutions. Pete

Not that I know of. Did you ask Lockheed-Martin? But I see you mean for FSUIPC5, and in tat case the answer is (also) no. It is actually a new product, as P3D4 was. Your WideFS7 key will, however, still be valid. Please always post support questions to the Support Forum so they can be answered, not to one of the Reference Subforums. Thank you. BTW, you don't purchase specific versions of FSUIPC4, FSUIPC5 or WideFS7. Your FSUIPC4 is out of date and should have been updated. It is best always to be sure you are using the current version as older ones aren't supported. Pete

I count using a search and count feature in my text editor. I don't do it manually as the automated method is much more accurate and reliable. I counted all occurrences of Button changed: bRef=0, Joy=68, Btn=5 as well as the same followed by , Pressed and ,released And for the grand total, as I said, I counted HEADING BUG INC. You tell me why that might be wrong. I don't understand this. Is this a problem? No, I was just explaining it in case it seemed odd to you. I certainly did to me. Most HID devices seem to supply the wrole of the data in one batch. What is the value of your variable "rd", the report size? Yes, that is probably true. You normally don't have two programs reading the same device. Why are you doing that? Do you have to? Can't you stop one? If they're competing then fairly obviously the one which is a compiled program running outside of the Sim has a better chsnce of "winning" than an interpreted one running inside the Sim. Er, I think there's a misunderstanding here. The "buffer" ComRead is using is its own. it is where the data RECEIVED from the device is put. The buffer in the device, if it has one at all, is its own affair. I expect it only retains it till someone reads it. Why woulsd it retain a copy in case something else read it? It has no idea how many programs are on the other end of the USB cable! How would it know when to dispense with it? A rather pointless exercise and not helpful. Just counting the number of times the button changed was surely all that was needed. Again, I count by search and count. Using 03 00 02 08 60 7D 20 00 I count 19 times, EXACTLY the same number as Button changed: bRef=0, Joy=68, Btn=5, Pressed. For every change ComRead received in the button state there's a corresponding execution of the correct assignment! You are somehow getting mixed up. There's no way my code or your script is missing anything which has been read by COM.READ! By the way, you are counting clicks as button down only events, but alternate clicks are button ups. At least every single rotary encoder I've ever met does that. Pete

Is your other application sending the keystrokes, programmed in the sim? Please count the significant events.in the log. There are 66 occasions in the log where the HEADING BUG INC control is sent. There are 38 when "Button changed: bRef=0, Joy=68, Btn=5" occurs, half of them "pressed" and the other half "released". So, i make than 19 presses and 19 releases, all seen. How are you counting only 17 out of 32 when it is all of them? As far as I can see from the log, the COMread function in FSUIPC is getting every input, and (miraculously?) your Lua is responding correctly to each one. How do you see it so differently? Please, just count those events to see for yourself. BTW, the device seems to only send its data in batches of 8. That splitting is not FSUIPC's doing! It uses a buffer which is 1024 bytes long. It is used cyclically, with a "head" and "tail", and it reads enough to fill to the previous "tail position" (or the end of the buffer) -- if it gets to the end and there is more, it reads from the beginning to the tail. This works perfectly unless the device can supply more than 1024 bytes in the "poll" time -- the internal loop time, not yours -- which is 20 mSecs. That's never happened yet. Of course, the 1024 byte buffer could "overspill" (i.e. lose data) if whatever was using it could not read the data in time. But it would need to be very slow to do that. And your log shows it is not losing anything and in fact giving good results. So ... you say you are confused, but the log shows no reason for you to be puzzled, so your confusion rather puzzles me! BTW in the rather artificial groups of 8 being sent by the device, those starting 03 are the button states. Those are supplied whether the buttons have been changed or not. The button you are testing is the 20 00 at the end, which is 00 00 if it isn't pressed. Pete

Never have before thst I know of. Solution would be mouse macros (maybe -- more likely okay on P3D4, but with warning pinned above) , or L:Vars. Pete

Unlikely -- com.read merely pulls data from a buffer is being continuously replenished as data arrives. This is code in a separate high priority thread. The same functions (though not from Lua) are used in my COM drivers for the older PFC equipment which used serial port access, and for their later HID devices. My 737 cockpit is almost totally dependent upon those COM routines. You can use extra FSUIPC logging to see exactly what data arrives in the buffer. Just add this to the [General] section of the FSUIPC5.INI file: Debug=Please LogExtras=64 Also log changes to your Virtual Button set (offset appears to be 0x3344 + ((i-1) * 4 which, since i is fixed at 4, is actually 3350. Use the right-hand side of the Logging tab entering offset 3350, type U32 and 'hex' checked. That will show what is actually received and what your plug-in 'catches'. We can then see if they match. Pete

I don't understand what the NGX is reading. Can you log the rudder control and position offset s please? Logging tab, right hand side, offsets 0BBA (control position) and 0BBC (rudder position), both type S16. Then we can see what is actually being set and whether it is acted upon. Can you also confirm that you had the tsteering tiller and the rudder both assigned in FSUIPC "direct" and both calibrated? The "RBL" facility won't be operating otherwise. There's currently no way to change the assignment without using a Lua plug-in which receives the input value and routes it to which ever control or offset is appropriate at the time. In that case you'd not assign to the rudder but either to the Lua plug-in, or to "Luavalue" with the plug-in name, if it is permanently loaded and event driven by "event.param". Pete

You don't give enough details I'm afraid. Is this a PMDG aircraft for P3D4? If so, it may be possible to add them but I'm afraid I have no information for the 787. I've only implemented offsets for the 737NG, 747 and 777. If PMDG have again implemented a similar seystem then I can add this to FSUIPC5, but it isn't a trivial job and will take me a week or two -- even after I receive details from the SDK. (I don't myself purchase all these aircraft as I have no use for them myself). I can probably ask PMDG to send me the SDK file(s), but if you'd like to it might be quicker -- I think it would just the the ".h" type file in the aircraft's SDK folder. Sendas a ZIPPED attachment to petedowson@btconnect.com, or use DropBox. I'd need someone to check them for me too, when implemented. Pete

Sorry. Yes, all 8-byte types will be doubles (64-bit floating point) unless specifically mentioned as being integers. Pete

I don't think that is the problem, because you go on to say: So smooth with direct assigns, just not with HidDemo? Both are calling Simconnect, so it isn't the numbers of those which are different, it is the execution of the HidDemo. First, don't forget that it is all interpreted,. it isn't compiled into actual ccomputer native code. If you've not done so already, you need to try to streamline it to do only what you need it to do. The original example was very generalised. Looking at HidDemo as supplied, do you see it using "com.readlast"? Or have you changed that? ReadLast will DISCARD any queue of inputs only retaining the last one. This is the normal requirement for switches. For fast button operations you want to use com.read instead, and keep looping in that the poll function till there's no more when you exit and wait for the next event. I don't think there should be a need to accumulate them -- though maybe look at that if reading them all doesn't help. The problem with that is not seeing what you've changed it to whilst you are turning. Pete

Sounds like you have "no reverse zone" set on the 4 throttles page. Uncheck it so that the minimum values calibrated with give full reverse, Re-calibrate to get a central idle zone. Best way to do these things is to follow the actual instructions in the User Guide. See the Calibration section in that PDF. Pete

Is the timing of the "button pressing" from the encoder a bit temperamental? Have you looked at what is happening in the log, with button logging enable? With rotary encoders I usually find the you need to assign the same control to both "press" and "release", as eacg "click" is either a press or a release -- alternately. If the encoders are not actually giving different button presses for each direction, they may be of the phased type, which are more difficult to deal with and need special conditionals in the assignments, done by editing the FSUIPC INI file. There are examples for this in the Advanced Guide. It certainly sounds like you only assigned to the "press" not also the "release". Apart from alternate clicks, as above, you should note that assigning to contorls like INC and DEC results in a communication to SimConnect each and every time. Whether that loses some or not I don't know (it seems unlikely), but 'smoothness' is going to depend on the loading on that main core (usually core 0) at the time. That will vary. There's no way to do it synchronously. An alternative approach is to use the FSUIPC Offset controls. You'd need to find the correct offset. You can assign to an increment or decrement, specifying the actual value of the increment/decrement and you can have it cyclic, so 0-359 and back, for example. Exactly. So, why not? Pete