Pete Dowson

Posted twice, for good measure? You seem to have started P3D before connecting the devices. Is that right? FSUIPC signals that devices were connected after everything was started and so re-scans. The INI file report that only the Throtte was connected, as you said, but it appears to be listed with the same GUID as the Stick. Did the Throttle respond okay in the Axis Assignments tab? Check now if you don't know. I need to analyse the log further -- it's a rather complicated sequence because of the re-scanning. but it does look to me like a screwed up Registry for these devices. It's the Registry entries for the two devices. I am not convinced you uninstalled the devices properly at all. As John said whilst I was away: and I requested again last Friday: but to which you replied, rather confusingly and ambiguously: If you do this properly it should clear out all references to your devices. To be sure it does, first unplug them. Then, knowing it's the devices themselves which need uninstalling (not explicitly drivers now), you use Device Manager (one of the Control Panel apps). When you select uninstall for a device entry you are also asked whether you want to also uninstall drivers. Just say yes. Confim everything. Re-boot the PC. THEN In case there are multiple entries as you suggested Friday, do all that again. Keep doing it and re-booting until there are NO entries for those devices there. ONLY THEN reconnect them Oh, one other thing, whilst in Device Manager: find all the USB devices and ensure that 'power management' is turned off in the Properties of every one of those which has such a facility. Now start P3D. Let me know the result then, with those three files again. I'd like to compare the result you then get with what you already supplied. I honestly think all of this is down purely to the mess some Saitek installs seem to make of the Registry. Please, if there's anything you don't understand or can't find, do not guess. Ask. Pete

I had to delete that post. You included your Registration for others to copy. If SimMarket find that now being distributed for others to use they will invalidate it and you will have to purchase another. it is a violation of the terms of sale! Please ONLY post the three files I listed!!! Pete

You would have to try using that instead of the one you are using. Pete

Well _tl appears here as a function call. I just don't know what that function is. I would have used the more usual (I think) if read.LVar("L:AB_MPL_FD") == 0 then I don't see how your _tl is reading the LVar to compare with 0. It looks like some function you forgot to include from wherever you got it. Surely there's a syntax error reported in the FSUIPC4 log. Did you check? They might be, but does it tell you how to use them? But FSUIPC provides a built-in control to List all current L:Vars and their current values, and there is a live log provided, on screen, by the example Lua plug-in provided to Log them. I doubt you can unless some other user has experimented and worked it out. I'm surprised they were supplied with the aircraft files -- that is most unusual. The aircraft makers don't provide them for user benefit. Pete

Is it complete there? What is _tl("L:AB_MPL_FD", 0) Did you use the Lua plug-in to Log LVars as they change to see if that FD one did operate with 0 and 1? What list did you use? In some aircraft implementations the L:Vars you find are indicators not actuators -- they just indicate the state of the switch to other parts of the cockpit implementation. Have you considered using Mouse Macros instead? FSUIPC3, FSUIPC4 or FSUIPC5? Don't edit the [LuaFiles] section. That is generated automatically! You are loading 6 lua files automatically, no matter what aircraft you load. Is that what you want? And how am I supposed to tell if you are loading the one you are asking questions about? You say some things work. if so, then surely it must be loaded? Pete

Why lost? Run P3D4. Then provide THREE files, not TWO: FSUIPC5.INI FSUIPC5.LOG FSUIPC5.Joyscan.csv You just forgot to supply the log file as requested. The whole point of adding those two lines, which you did, was to get more information in the log, but I cannot use that information unless you supply that log. Pete

And the Lua file doing your UDP exchange is running in FSUIPC5? If so, that is weird. I certainly don't think a 32-bit DLL can run in a 64-bit process. I see that the "socket.lua" file uses a DLL called "socket.dll", not "socket_core.dll", though I suspect that the socket.dll needs socket_code. Do you have a socket.dll there? Pete

Not yet. But if you have it working there will be other DLL's (as well as FSUIPC5) either in Modules or in a subfolder in Modules, like Modules\Lua or similar. Pete

Oh, so they have -- at the start! ;-). I looked at the end, where most folks add them. Apologies. Pete

Unfortunately, the LuaSockets files needed aren't included in those ZIPs. They appear to be the main Lua interpreters and ancillaries. Pete

Could you explain how, please? That "socket_core.dll" is definitely the 32-bit version. Are you using P3D4 and FSUIPC5? Pete

And still no log. the INI and CSV are no use on their own. I asked you (twice before now) to add two specific lines to the INI and supply the resulting log. Pete

By having a miimum of 4 acceptable, if there is a delay after 4 characters are received then you will get what has already arrived. The delay may be from the Arduino end, or it could be a higher priority action happening in the PC. Altough I do set the comms input at high priority, it isn't at "critical" level, which would be needed to have exclusive use of a processor core for that thread, but not warranted and problematic. So why not use that? Fixed length messages are bound to be more reliable and easier to handle. 3823203 LUA.0: A=00 3823218 LUA.0: 261 This illustrates what I said. 4 characters arrived but there was a delay before the "261" part. 3823297 LUA.0: A=00259 3823422 LUA.0: Here the delay was before the terminator you otherwise wait for. In any case, shouldn't you be discarding invalid input? Pete

MOVED TO SUPPORT FORUM Please ALWAYS post support questions to the Support Forum, and certainly not to "User Contributions". (After all, this is a request for help, not a contribution to help others). =================================================================================== The error message is from some program you are using interfacing with FSUIPC, it is not from FSUIPC. It will simply mean that the program could no longer talk to FSUIPC, which isn't really surprising if you'd closed P3D down! The program is evidently not noticing that P3D has closed. maybe try starting it using the {Programs] section in FSUIPC with a "CLOSE" or "KILL" keyowrd included? Pete

They don't change names. The name, email and key will be those you originally registered with and as notified per your SimMarket account. The same three fields apply thoughout the life of FSUIPC5, they won't change. Pete

The values were 8182 and (separately) 16384 for the two actions, and they would be Parameter fields for the relevant "custom control" number(s) you already know. Pete

Sorry, i should have been clearer. The full release is 5.14, but there's an interim update 5.141e, which is available (DLL replacement only) in the Updated Modules thread of the Download Links subforum above. That's where all my software is availalbe. Actually I misspoke when I implied 5.14 wasn't supported. it still is at present. But it is best when dealing with problems that both of us are using the same. Pete

Thank you Fred! Pete

Yes, but I did think it included both. If not, I'm sorry, I think more searching is needed. Maybe some good user will post a better link, or even supply the actual file(s). I'd then see if could host them here to make things easier in future. Getting in touch with Luis Damas would be a good idea -- I've sent him a PM. Pete

Unfortunately, it appears to be a 32-bit DLL. I've sent a PM to Luis Damas, the poster of the original link. Pete

Like what? A is the Stick and B is the Thottle. IDs 0 and 2. You must have had a third device at one time as there are assignmwents to a non-existent device 1. You have, so far, not bothered to provide the extra logging with the option I requested added to the INI file. Also you are still using FSUIPC version 5.14. Please update to the currently supported version. Then do that logging I asked for on Friday, and supply Log, INI and the Joyscan CSV file. Really your INI file is a bit messy. You have odd Profile names like " p3d" and "Prepar3d" which must be hard to differentiate, as well as "axc" and "CRJ900". I can't really analyse all of that, so, as a test, try moving that INI file out, or renaming it 9so you don't lose it), then let FSUIPC generate a fresh one. Pete

So, what's different from Friday? REally, that symptom is definitely indicative of a hardware problem with the throttle(s) themselves. It could just possibly be a conflict with something else affecting throttles -- you would need to Log axes and see what the axis inputs to the Si, look like. Logging Tab, axis events. Also log other events in case it is interference from another control altogether. Lookng at the INI file I see that FSUIPC is not actually involved in the Throttles. the assignments are to the same controls as if assigned in the Sim, and they are not calibrated at all. So FSUIPC is actually doing nothing different to P3D. Pete

Sorry, that was a typo. not ival, just val. but it is wrong in any case. The val inside the parentheses is not needed, it is not in the syntax. Do you mean the VALUE of an LVar? I am pretty sure they are all Double floats, so you'd need to use ipc.writeDBL(0x66C0, val). However, if an integer value is sufficent for your needs, the corrected version I provided should work. Of course it depends on what the program which is reading it needs. Do you know that? Just writing to a user offset does nothing unless something is reading it. What now is there not to understand about writing to offsets? Pete

So, you shouls see it then in the Calibrations tab. FSUIPC actually intercepts the same control from P3D no matter whether you assign the FS control in P3D or in FSUIPC. It does exactly the same in both cases. With add-ons I can understand some of them not liking ax axis fed back into the Sim at a different (lower) Simconnect priority level. FSUIPC has to do that, otherwise it would end up in an infinite loop. PMDG Boeings certainly can have problems with that on throttles because they read the axis at one level at the same time as FSUIPC feeds as another. The two values may well be different (due to calibration and slopes). But it doesn't actually NOT work. And certainly rudders, ailerons, elevators, toe brakes, etc, are okay on pretty much all default and add-on aircraft. What about throttles, elevator, ailerons? Check with logging . Exable axis logging and see the controls actually being sent to the Sim. They'll show in the log no matter where you assign or whether you use calibration or not. I really have no other ideas. There are many users with those controls and no problems -- it is usually throttles which give problems with Saitek. You could of course try the usual remedy with most things wrong with Saitek -- uninstall their software altogether. Then go to the Windows Device Manager, find the rudder device, right-click and uninstall, being sure to check to delete drivers too. That should correct any Registry problems. Then re-boot. Pete

Okay. That actually works the same as if you assign in P3d. 1. Where, in the Assignment tab or in the Calibration tab, or both? 2. Does this apply to both Direct FSUIPC assignment AND FS control assignment, or only the latter? 3. Which FS rudder control do you assign to: "Axis rudder set" or "Rudder set"? 4. Does this apply to all aircraft -- default included -- or only add-on aircraft? 5. Check your rudder trim: an extreme setting for that will nullify rudder inputs in P3D. You can zero it by assigning a button or key to "Rudder Trim Set" with a parameter of 0. 6. Try also just assigning the rudder in P3D -- not as a possible solution necessarily, just to check. Pete