Pete Dowson

Aaarggghh! Sorry, my fault! That Lua was derived from my Test lua but with the loop removed. You need the original test Lua, "comloop.lua". Do you have that still from the original Beta testing? If not I can send you it. However, it doesn't really matter for this testing because the serial port is still being used as it is normally with the FSUIPC INI parameters, yet in this case, no problem. that's the main result. Yes, of course, because that Lua program doesn't touch "VRIdriver", having no loop in it! Sorry for misleading you. I was misleading myself too -- the bits near the beginning of that Lua about setting known ports need to be removed now. :-( Okay. That's pretty much expected from your previous findings. However, it is odd that itdidn't finish initialising the device, but perhaps it needed a reset by now. Wow! In the first case FSUIPC is doing nothing with the Port except opening and closing. The same code as opening and closing it for the Lua program, except that it would have been opened and closed in the main FSX thread, not in the Lua thread. There will be two other threads - a reading one and a writing one, but they are identical for Lua. Curiouser and curiouser! I'll have a look to see how easy it is to make FSUIPC create a special thread just for the Opening and Closing. Though this seems like a futile thing to me. There must be something I'm missing here. But all of the rest of the code is effectively being bypassed now. Yes, thank you. Unfortunately it is still a puzzle. Regards Pete

I expect whichever software controls the MCP waits until it can connect to FSUIPC. No, it's the other way around. All FSUIPC applications look for a connection to FSUIPC. Whether they wait for it before they become fully active or not is up to them. Regards Pete

Right. As well as enabling logging (Debug=Please and LogExtras=x4) and redoing the above test, when you get time can you please download 4.608a: http://fsuipc.simflight.com/beta/FSUIPC4608a.zip And run three separate tests to see what may occur with this problem: 1. No SerialFP2, no VSPE, the single device COM port defined in the INI, no Lua file loading. Load up FSX, let it fully initialise etc. Close FSX. Save the Log. Does the ASE problem occur? 2. Similar: No SerialFP2, no VSPE, the single device COM port defined in the INI, no Lua file loading. Add "TestOptions=x400" line to FSUIPC4.INI [General] section. Load up FSX, let it fully initialise etc. Close FSX. Save the Log. Does the ASE problem occur? 3. Similar: No SerialFP2, no VSPE, the single device COM port defined in the INI, no Lua file loading. Change the line to "TestOptions=x800" line to FSUIPC4.INI [General] section. Load up FSX, let it fully initialise etc. Close FSX. Save the Log. Does the ASE problem occur? Between them, these pretty much eliminate all the code which is peculiar to FSUIPC's explicit VRI handle, in contrast to the pure Lua-comms handling only which was the subject of the last test you did yesterday (and which I'm still curious about as to why it didn't let SerialFP2 attach -- log awaited). Thanks & Regards Pete

It will be completely to do with whatever software is handling your MCP. FSUIPC doesn't "send" information anywhere, it merely makes it available for applications like PM to read. If the battery and avionics are off, the relevant data read by applications will say so. If you mean the display on PM's own MCP graphic, then you need ot talk to PM support. If the MCP hardware you are using is driven directly by the PM MCP software you also need to talk to PM support. If your MCP hardware is driven by a driver program outside of PM, you need to talk to the MCP hardware support or at least the folks who supply the driver. FSUIPC really doesn't have any direct control over any displays. Regards Pete

If you are starting out on this is would probably be a lot easier to use Profiles instead. You have to make one small change to the FSUIPC INI file first. There's a chapter about Profiles in the user manual. I think you'll find it a lot easier in the long run. Why on Earth are you messing with the Delta? As the documentation explains, that's only either for very specific software-controlled axis purposes, or to overcome excessive jitter. the default Delta value is perfect more all normal use. If you select "direct to FSUIPC calibration" you MUST calibrate in FSUIPC or the axis won't work! It's inputs will go nowhere. There is actually little point in assigning axes in FSUIPC at all if you don't calibrate them as well. Why close and reopen the options each time? That will simply take longer. The first axis it sees moving with be the one registers. Of course. There's probably a little movement on the elevator when you move the ailerons and the elevator is registering first. This is precisely why there's the "ignore axis" option, so that you can tell FSUIPC to temporarily ignore changes on a moving axis in order to register another. Please please do have a look at the documentation! If you read through the axis assignments section it does explain all this. Rescan will show the first moving axis which isn't being ignored. If you ignore the active axis and rescan it will find the next. That's the whole point of those options! Regards Pete

It doesn't need emulating as it is a function provided by the PM MCP. To assign it to a button or keypress in FSUIPC you simply assign to PM MCP KCodes, with a parameter of 49 (for Captain's instruments) or 149 (First Officer's). This is listed in the Advanced User's guide to FSUIPC in the added controls section). Yes it does, and rather than trawl google and posts, why not try the faster ways? Just searching supplied documentation for something like "STD" finds it quickly enough -- in my document and in the PM Offsets list too. This is how I find these things. Search facilities can be very useful! Pete

tested this shortly. FSUIPC.log says a connection but got no connection to SerialFP. But the error does not come up when ending FSX. Interesting. It works okay here with the MCP Combi -- it was that way of doing things which I used when developing the Lua programs as it saves having to re-load FS every time you make a small change to the Lua coding. Are you sure you set both COM ports correctly and that SerialFP2 was looking at the correct one? Okay. Please enable VRInsight logging in FSUIPC (Debug=Please and LogExtras=x4 lines in the [General] section of the INI file). I'd like to see why yours is different. At least it is progress that there was no problem after FSX restart. That eliminates a lot of code and allows me to concentrate on a smaller part. Regards Pete

Yes. Regards Pete

Not really. Together with WideFS it enables programs such as Project Magenta, Sim-Avionics and Flight Deck Software to provide instrumentation which can operate on a Network of PCs. My own system uses 5 PCs for instance. But multi-monitor cockpits on one PC are enabled by multiple video connections or hardware such as the Matrox TripleHead2Go. Multiple monitors on multiple PCs for scenery views can be set up using WidevieW, which is a package by Luciano Napolitano, not me. Undocked views, camera angles, etc, are all part of an interesting subject, but not one I know much about and certainly with no relation to any software of mine. I think the type of software you are after is exemplified by EZDOCK: http://www.flight1.com/products.asp?product=ezdockcam No, FSUIPC has no relation to these sorts of functions. Take a look at EZDOCK. Regards Pete

You seem to have posted again in a different thread, but without explaining your problem, and also showing that you are using an unsupported version of FSUIPC. So, is everything really okay now? Else what is the reason for the other thread? Pete

You've started a new thread. Please keep to the same thread so we have some continuity. What was the problem again? It's mostly ordinary English and tells you step by step what the Installer is doing. It means no more than that. Version 4.57 is from last year and not supported. You need 4.60 at earliest. Please update before returning. Pete

With most encoders that happens naturally because they send pulses faster when turned faster and slower when turned slower. First you should make sure you program both the "press" and "release", which will give you twice as many operations -- two per complete pulse. Second, don't turn the knob the long way. 180 degrees is the most you ever need to turn it. Those two alone reduces it to less than 5 turns max. Third, adjust the PollInterval, as described in the FSUIPC Advanced User's document, where it specifically mentions rotary encoders. Then you should miss few if any pulses. Pete

Can you see if you can find the "Caps Lock" key on your keyboard, please, andf use it to turn CAPS off? It is very difficult to read and make sense of. FSUIPC4 installation does not install PFCFSX.DLL, EPICINFO5.DLL or any of their ancillary files. The FSUIPC4.INI and LOG files are only produced when FSUIPC4 is run. You are not looking at the FSX menu. The menu is a horizontal menu bar at the top of the FSX screen when in flight mode. The initial selection dialogue is NOT a menu and is not changed in any way by any add-ons. Pete

Your ASE (or AivlaSoft EFB) is reconnecting? I cannot really test that aspect at present. My cockpit system, to which I can connect ASE, is in disarray whilst changes are being made. I'll do a real test next week. Meanwhile I shall keep thinking of things to try. Is it okay to use you as guinea pig, to try things? I will have to follow a process of elimination, bypass different bits of the VRI additions. It means those probably won't work in any interim test versions, which I shall number 4.608a, b, c etc. I'll let you know when i have thought of the next one to try. 4.608 was like previous, working okay, but with no overlapped comms I/O, so okay for FS but a little less efficient for the Lua program. Okay. I'll concentrate on that. I thought it was to do with FSX not terminating properly. I've no idea how the VRI side of things mucks SimConnect in other processes up. Only trial and error will tell ... Tomorrow, maybe ... [LATER] ... meanwhile, please keep tests simplified by having only the single COM port (no VSPE, no SerialFP2), and also no Lua loading for the device -- temporarily remove the VRInsight section in the INI file. If you haven't already tried that simplification, perhaps you could try now, please -- it will make the difference between multiple thread access to the COM port and single (main) thread access. Also, another test, with only Lua opening the ports: in the example Lua plugins provided, find VRI_SetMach.lua (you may be already using this). Instead of having any VRInsight sections at all in the INI file, edit that Lua so that these lines show your normal two COM ports VRIdriver = "COM2" VRIdevice = "COM5" then run the Lua program, THEN SerialFP2. This should operate in the same way as the INI file automatic settings. See if it makes any difference. Regards Pete

Shame. The comms code in that version is the smallest, simplest I can make it and still have it work. I can't repro the problem here, only the occasional one with FSX never terminating, and as I said, that occurs without any VRi stuff involved. I wonder why no one else has reported these problems? Regards Pete

Can you try 4.608: http://fsuipc.simflight.com/beta/FSUIPC4608.zip and let me know if it any better please? Pete

I've checked, and it seems that the HYDRAULIC_SWITCH_TOGGLE control takes parameters numbered from 1, so that agrees with your findings. And I can also read the switch states separately in SimConnect. So in the next update for FSUIPC4 I have changed offset 341E to use separate bits for each of the 4 possible switches. [LATER] If you want to try using the offset 341E in this way, try http://fsuipc.simflight.com/beta/FSUIPC4608.zip Bit 0 = pump 1, bit 1 = pump 2, bit 2 = pump 3 and bit 3 = pump 4. Regards Pete

So, please confirm that you ARE running 4.60 or later. I won't support anything earlier in any case. That F-18 program obviously thinks you have 4.53. Show me the FSUIPC4 log and Installer Log if you aren't sure. Pete

But I don't understand, then, how SimConnect connections can go wrong on a complete restart of FSX. When the process is closed there should be no part of SimConnect left. Are you leaving ASE running whilst closing and reloading FSX? Maybe it's process copy of SimConnect DLL is getting somehow confused with its Pipe? Pete

Okay, I understand your problem now, but unfortunately since I know nothing about SIOC I cannot really help. Does SIOC have a Support Forum? Or else you could try the Forums at MyCockpit -- there are a number of SIOC users there. http://www.mycockpit.org/forums/ Regards Pete

Same here. I'm afraid those show only the same info as you put into the thread title. The error means something like "pipe broken", and the most likely reason for that is that the FSX process is still running, even though it looks closed. Please check for this -- use the Task Manager, Processes list. If "FSX.EXE" is listed, terminate it and try ActiveSky or whatever again. I would get an error if the "end FS" didn't end it properly. I think this is maybe what you are seeing. As I said earlier, i get this about 50% of the time on my main FSX system with no FSUIPC4 VRI device. I've never checked the error number in ActiveSky but next time I will. I expect it to be similar to yours. Regards Pete

Seems you didn't read my previous reply, so I'll repeat it: I can't tell for sure without a complete FSUIPC log, but the usual reason is either an invalid registration key, or an incorrect system date which makes the key look invalid because it was purchased AFTER "today's" date. If you aren't even registered then possibly the DLL is corrupted of has been tampered with. A log would show if this is the case. Pete

Sorry, I don't understand. Each parameter value (0 to 3) operates the correct switch, but also reverses the other three? Is that what you mean? Or do you just mean that the SIOC code doesn't work. I don't know anything about SIOC, but I assume that when you reproduce that section 4 times you would need to renumber the "Var 3 Link" for each switch? Pete

Would that use up a COM port? Don't understand that. Sorry, I don't understand why you need to do most of that, nor how any of it impinges on COM port availability. And what do you mean by "SP2"? Is that SerialFP2? If so and you were loading that before FSX (or letting FSX load it) then the problem you had might have been merely due to SerialFP2 grabbing the device on COM3 first. You should be starting SerialFP2 using the [Programs] facilities in FSUIPC4.INI, as documented in the VRInsight dox I included. That makes sure FSUIPC4 gets the device first. Regards Pete

Buttons and switches are identical except for the latching. In FSUIPC you can program the "Press" (which is also, for a latching switch, the "on" position), and the "Release" (the "off" position) independently. FSUIPC allows you to assign to any of the FS controls (defined and named in its CONTROLS.DLL -- that's there FSUIPC gets them from), as well and quite a few additional ones created and added by FSUIPC. Some of these controls are Toggles, some have "ON" and "OFF" variants, and some have "SETS" (when a parameter determines the actions). In some cases all 4 variants are available. If what you want to do only has a toggle control then you either have to program it for both your "on" and "off" positions, and just make sure things are in sync to start with, or use an alternative method. One alternative which is usually viable is using the Offset controls added by FSUIPC to actually change the variables inside FS directly. For example, offset 0D0C is a Word offset containing a bit for each of 10 separate light switches. Using "offset word setbits" and "offset word clearbits" with offset x0D0C and different parameters you can implement ten on/off light switches. If you want to get into this area you'll need the FSUIPC SDK as well, because that contains the complete documented list of offsets. Regards Pete