Pete Dowson

Yes. All these PMDG relationships merely consist of FSUIPC asking for the data, and when it is received, plonking it as it is into offset space. There's no processing. FSUIPC doesn't care what it is. The interpretation is up to the application reading it. The original offset space I allocated long ago wasn't large enough, so the incoming data is split into a couple of lumps and put in discrete places. The CDU stuff likewise. The error in the document was a miscalculation when I was mapping the PMDG documented header file onto the offset space, that's all. The easiest way for an application to access any of it really is to include the header in the program and define a pointer (or pointers, because of the split) to the structure's "offsetof" the first named value in that block. This is usually how I check them, but I couldn't get the 747 working on my system. Pete

PMDG 747 offset support was added several releases ago. Maybe it's just the slight misalignment in the offsets list which is the problem? This implies that it was okay before 5.122 and P3D4.1, yet if we are talking about PMDG data, that hasn't changed. Can you clarify? Are you reading a different set of offsets now? Well, the link Luke just posted about this was about a slight misalignment of the PMDG 744 offsets in the Documentation (only), NOT the program. And it finished with me providing an update to Luke which he checked as okay. That was late December. The update to include it would be 5.123, but that's awaiting P3D4.2, which I expect is delayed like most other things by Christmas! Here's a link to the updated document: Offset_Mapping_PMDG747QOTSII.pdf Pete

What are the typical names of those autosave files? There are add-ons which also save their own files when the SimConnect flight save facility is called (whether by program or menu). You can add AlsoManage lines in the FSUIPC5.INI file to deal with this. Pete

The log, "runways.txt" in the same folder, will show what is wrong. Show use that. Meanwhile, if you installed it and rann it correctly then there are two usual explanations for it not finding the correct scenery.cfg file: 1. The registry is not showing the correct paths, or 2. The FSX.EXE file has been renamed, possibly to fool some install process which does not know it. Pete

Well, thank you! Unfortunately my cold is simply cycling now between a terrible cough, and bouts of sneezing, both of which cause agony in my back (which is none too good in any case, with a spinal stenosis). Seems most folks around here have the same cold symptoms. I guess old folk like me take longer to shake these things off. Then others get it and return it slightly mutated! :-( Still, at least my eyes have stopped contant watering and I am able to do a bit of work. Will be busy trying to update my cockpit with the new release of ProSim737 (v2). Happy New Year nonetheless! ;-) Pete

Yes, SerialFP2 was the only software from them at the time I was adding this stuff to FSUIPC. Yes, if the firmware level is the same too, I'd definitely agree! Pete

Well that does look fairly conclusive. But, then, you said in your first post in this thread: which is odd -- unless they changed the protocol and it needs some other command? I would need to use a COM port monitor to find out, monitoring the exchange between the device and VriSim.exe (which, incidentally, isn't the name of their program when I implemented all this). Alternatively, did you try connecting it through FSUIPC, with VriSim running? i.e. using the method described in Appendix 3 to the Advanced Users guide with a pair of virtual ports? Then the Logging might show what is going on. Pete

Yes, both. the documentation of the Lua functions to do this is in your FSUIPC documents folder 9see the "ipc" library part of the Library pdf), and there are plenty of different examples in the "Exmples" ZIP file in the same folder. Lua itself, as a language, is documented on the lua.org website, and also in books easily obtainable. Pete

Good! Thanks, Pete

Ah, I noe see that more VRI COMs are logged by a separate option: LogExtras=x4 So set LogExtras=x44 for read and write and proper VRI labelling. (That's with FSUIPC VRI handling, of course, not direct accecc via Lua). Pete

The data is binary gibberish. It is either the wrong speed (but FSUIPC also uses 115200 for VRI devices), or more likely the wrong device. Is all those COM operations from LINDA? They only start after LINDA has started and the Lua error at time 105687 suggests so. Was the VRI section in the FSUIPC INI file removed? I'd rather see what FSUIPC initialisation tried and received. I only just saw that COM writes aren't logged, which is a pain. I don't know why that is (historical?). Would you like a version with Write logging added? Pete

You could do that pretty easily with a Lua plug-in. Assign and calibrate X and Y as usual, and in the Lua code read both brake offsets, perform your calculation, and send it to the ailerons via the normal aileron axis control. But note that your 0-255 range would become 0-16383 automatically. The aileron needs to go from -16384 to +16383 with 0 meaning level. But if a paraglider effectively has independent ailerons, I don't understand why this isn't programmed into the model you are using? Again, the same wort of Lua plug-in, or better part of the same one. In both cases adjust your computations to deal with the normal sim range of values (0-16383 for flaps too). Pete

FSUIPC4 runs in the P3D3 process, FSUIPC5 in the P3D4 process. They don't talk to each other, the same as two FSUIPC4's don't talk to each other. Each stays in its own process. The main reason you must have FSUIPC5 in P3D4 is that it must be 64-bit. 64-bit DLL's do not run in a 32-bit process, nor vice versa. Sgared cockpit is irrelevant to FSUIPC. If P3D3 and P3D4 work together in a shared cockpit, then just leave the P3D3 setup with FSUIPC4 and the P3D4 setup with FSUIPC5. Pete

It might be getting a response, just not one it recognises. Pete

I just thought, before going to the trouble of writing a special Lua, or getting and using a COM port monitor, there is COM port logging in FSUIPC. Just add these lines to the [General] section of the INI: Debug=Please LogExtras=x40 Pete

That simply means that COM7 exists. You'd need to check the Windows Device Manager "COM" list to see all the COM ports and what drivers they are using. Well, I doubt it'll help identify the difference between yours and his, but here goes: Immediately after Opening, it sends a "CMDRST" to reset it. Then, after 1.2 seconds, it sends a "CMDCON".and reads whatever is sent back. If it gets nothing back within 500 mSecs, it tries again, with the 1.2 secs delay and sending a "CMDCON". It limits it to 5 tries altogether. It doesn't check or use whatever comes back, but immediately sends a "CMDFUN" and waits up to 1000 mSecs for a response. If not, for up to 5 times total, it restarts at the CMDCON stage as before. If the response is recognised, it forms part of the log message "VRI xxxx (yyyy) detected on port z". The xxxx is what it received (after the first 3 bytes) and the yyyy is the FSUIPC name for it. The response it needs from an MCP2a is "???MCP2A". (Sorry, I don't remember what's in the first three positions: It is CMD for outputs, I just don't recall what it is for responses). All this info is just by me looking at the code. Please don't ask me to explain it. It is what I figured out by experiment, mostly, and using COM port monitor programs to see the sequence VRI's own drivers use. Maybe that's the best thing to do, unless you want to write a Lua plug in to follow the sequence and see what you get. Possibly his is a different version and returns something different? Pete

No idea, sorry. Ask over in the AVSIM P3D forum. I'm using 388.13 at present. But I hate long flights. I just like taking off and landing. Cruising can become boring unless there are lots of route changes and ATC involvement. I rarely do flights of more than 1 hour. Pete

So it seems that the other things you are doing are somehow interfering. I think you are in the wrong place. This appears to be a problem for which you need to seek help on the L-M support forum for P3D. But first you will probably need to do a process of elimination -- you've got too much going on to understand what could be happening. Eliminate as much as you can, then, if things work out okay, add stuff back one thing at a time. And I would strongly recommend that you use a different computer for all the other non-P3D things you want to do during a flight! Get a pad or a cheap "chromebook" or the like if you don't have another PC. Pete

Either use the REV option in the Calibration Tab, or, if not calibrating, just use suitable arithmetic modifiers in the Axis assignment section in the FSUIPC settings (INI file). The former is described in the User Guide, the latter in the Advanced User's Guide (section "Additional parameters to scale input axis values"). Not without doing that yourself with a Lua plug-in program. There's never been a need to add two analogue inputs together. It certainly doean't appear to make sense. And to make the result valid, both inputs would need to have half the full range to avoid over-maximum values. Pete

So with the exact same VRI device and ftdi driver, and exactly the same parameters in FSUIPC and the same direct access com.opn and com.write sequence, it responds on your system, but not on his? That seems to be what you are saying, right? Well, if everything else is the same, surely it must just be that com7 is the wrong port? Or the speed is set wrongly. Are VRi devices 115,200? BTW I don't know what I'm supposed to look at in the attached log. It's a LINDA logging, which doesn't mean much to me I'm afraid. Pete

Well done! Of course, you having the PMDG aircraft (whilst I do not) should allow you to find out more things like that to solve your needs, right? Pete

I don't see anything wrong from the logs (the FSUIPC5 run time log shows a good FSUIPC shut down when P3D was closed). The Windows error event being logged says "FSUIPC Unloaded" which is something which doesn't help identify anything. when this has occurred before it wasbecause something caused one a crash during a previous P3D session close down sequence, but one or other of FSUIPC's separate threads was still running when this crash occurred. That tends to result in the Registry being marked to stop FSUIPC5.DLL being loaded next time. As a result SimConnect goes through the motions to load FSUIPC5, as instructed by the DLL.XML file, but it doesn't actually load. Windows is faulty by NOT notifying SimConnect that this has happened, so when it allows FSUIPC to start execution, there's the "FSUIPC Unloaded" crash -- the address that provides is in fact the entry address, where obviously, as it hasn't loaded, there's no valid code. The only answer to get P3D running is to rerun the FSUIPC5 installer first -- I added code into that which fixes the registry entry responsible. Don't forget to run it "as administrator". Then, if it recurs, you'll need to track down what is actually causing the problem by a process of elimination. The last add-on I know about that could cause this was LINDA but I think updates to that fixed it. There have also been problems with devices in some Win10 updates. Pete

That's never a good idea. The INI file in there contains all your settings. Did you back things up first? Re-installing FSUIPC never needs any deletions being made first. The only file which sometimes needs to be deleted, because it can get corrupted (usually by other installers) is the DLL.XML file in your AppData\Roaming folder. If FSUIPC had ever been run there would be an FSUIPC4.INI file (your settings, or the default settings) and an FSUIPC4.LOG file. Since they are not there, FSUIPC hasn't even started, which points to a corrupted DLL.XML file. If you had showed me your Install LOG then I could tell you where that is, but maybe you can work it out for yourself? It's in the same folder as your Prepar3D.CFG file. If you have no other add-on DLLs being loaded then just delete the DLL.XML file and re-run the FSUIPC installer. Otherwise, it might be best to repair it, so show it here, or attach it, and I'll take a look. Pete

**** Updated on 21st May 2021 **** To use the Lua Socket library om FSUIPC5/6/7, first download the luasocket-2.0.2 library from: http://files.luaforge.net/releases/luasocket/luasocket/luasocket-2.0.2/luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip Extract and copy the file lua/socket.lua to your FSUIPC installation folder. Then, to use in lua scripts, use local socket=require("socket") There should be no need to copy the core.dll as explained below, but I will leave this thread for reference. Thanks to @Djeez for reporting this. ********************************** You an get lua sockets under Fsuipc5 by loading the 32-bit luasocket library from http://files.luaforge.net/releases/luasocket/luasocket/luasocket-2.0.2/luasocket-2.0.2-lua-5.1.2-Win32-vc8.zip Unpack it into "modules/Lua", but then replace "socket/core.dll" with the one from https://download.zerobrane.com/luasocket-win64.zip. [This is from a post by Luis Damas, with thanks!] Pete

No, the control sent is to be <custom control> as I've told you before, TWICE I think. Only after you assign that can you enter the number 70314 in the extra place which then appears. Sorry, but I have no idea what the "GF Manual" would suggest that for the PMDG 737. It may work for some other aircraft, I don't know. But why is that anything to do with "control to repeat"? Why do you think you cannot attach anything? Many folks do with no problems. See the paper clip and text "drag files here to attach or choose files" below the edit area. I suggest you do what is advised, several times, in this thread, instead of trying things seemingly at random. There's no more help I can give. I don't even use PMDG aircraft, so if you cannot handle it perhaps you should be asking in the PMDG forum? Pete