Jump to content

hmoesch

Frozen-Inactivity
  • Content Count

    11
  • Donations

    $0.00 
  • Joined

  • Last visited

Community Reputation

0 Neutral

Profile Information

  • Gender
    Male

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No
  1. Hi Norman, I currently have the same problem and thus wanted to ask you, whether you ever figured out a lua script that allows to trigger the VS, UP and DN buttons of the Turbine Duke KFC225 auto pilot? Best regards Hans
  2. Thanks guenseli and Scotflieger for the fast reponses. Good to know that I did not miss an easy or obvious solution.
  3. Hello to all, it has been a while since my last post on this forum, but I recently run into an issue that I could not resolve and therefore wanted to ask for help here. I am using the original VRInsight MCP1 combo with FSX together with LINDA 2.9.3 v1 and registered FSUIPC 4.964. For the Realair Turbine Duke v2, I wanted to reassign the MCP SPD rotary to CRS, which works fine for the input, but on the LCD display output I still get the SPD value and not the value for CRS. My question is whether and how this can be changed? Maybe this a standard question, but I could not find a quick answer by searching this forum. Many thanks, Hans
  4. I think I might have finally found a solution for the problem. I have installed a PCIe USB controller card (Exsys EX-11064) on my ASUS P9X79 board, which gives me a separate (NEC) USB 2.0 controller. I now run the VRInsight devices through this Exsys card and all my GoFlight modules via two powered USB 2.0 hubs (Exsys EX-1177) that are connected to the onboard USB 2.0 ports and thereby go through the onboard Intel X79 USB 2.0 controller. That way the GoFlight modules are separatedly handled from the VRInsight modules and as a result I do not have any more interference between the two module types. :Whew: I hope this solution lasts...
  5. I will keep trying to find a solution and let you know, if I am lucky. The problem might also be Win7 or FSX related, because I was able to run all my VRi devices and GF modules with no problems on my old PC with XP and FS9. Thanks again for all your help and support!
  6. I have done that by: 1. Starting FSX without LINDA and without the GFDevFSX.exe bridge between GF modules and FSX (I control activity by the Task Manager). 2. Sitting in a standard airplane (Beech Baron) I then start the VRiSim Software, MCP is powered. 3. I now try to link FSX to the GF modules by starting GFDevFSX.exe. This works, meaning the GF modules light up, but the GF-166 radio modules will freeze as soon as I press a button. 4. Starting GFDevFSX.exe before VRiSim does not change anything, except that the GF-modules are fine until I start VRiSim. 5. I can rescue the freeze (with FSX still running!) by finishing VRiSim followed by unplugging-plugging the GF-166 modules. Then the modules are fine until (of course) I initiate VRiSim again. I just have to start the program with the MCP powered, I do not even have to start a specific MCP setup to get the freeze. 6. What I also noticed is that VRiSim will cause the freeze only, if at least one VRi device is powered and detected by the program, this can be either the MCP Combo or the CDUII. 7. And of course, as I mentionted above, the GF modules are also blocked by LINDA as soon as the program connects to the MCP via linda.lua (and FSUIPC). It seems that somehow connecting a powered VRi device to FSX by starting up VRiSim or LINDA blocks the connection between FSX and the GF modules (only the GF-166, not others) and that it does not matter, whether the GF-modules connect to FSX via the GFDevFSX.exe bridge before or after starting VRiSim. That is all I have figured out so far, but I still found no solution...
  7. Thanks, I am looking forward to your answer! :Praying:
  8. Ja. That's exactly what I did now. I changed the MCP COMport first from 4 to 16 and then from 16 to 18 (just to try some random numbers), but still no joy. The MCP is recognized by LINDA (after changing the FSUIPC.ini), but as soon as it is connected to FSX, the GF modules will freeze. I have repeated running FSX with and without the MCP connected now many times and the results are very reproducible. I also changed the USB connection of the MCP to different USB ports (just to try something else), but that does also not help. How can I do that? I cannot see any of the GF modules in the 'Geräte Manager' under 'Anschlüsse', there I can only detect the VRInsight devices MCP Combo and CDUII. I can see the GF modules under 'Hardware and Sound' of the System Utilities, where I am told that these modules are recognized as HIDs, but not as COMports.
  9. I just know that for the MCP Combo (COM4) and CDUII (COM5), because I can check that using either the VRiSim software or the hardware manager or LINDA. I was not aware of the fact that the GoFlight modules also use COMports, is there a way to figure that out? I checked the 'Hardware and Sound' section, where I can see all modules connected via USB, but I can only see COMports for the MCP Combo and CDUII not for other USB devices. Is there another way to check that? I did just that and the GF-166 modules stay blank once FSX (with LINDA) is running. I did several unplugs and plugs (I can hear the connecting and de-connecting sounds from Win7), but the GF modules will stay just blank. The LINDA console seems to respond by adding the line 'Restoring previous aircraft... Restore finished'. I also checked another combination, by inactivating linda.lua and running the MCP Combo via the VRiSim software instead. Guess what, that also interferes with the GF modules! So it seems that once the MCP Combo connects to FSX it interferes with the GF modules and they might indeed try to use the same COMport! Now if only I knew how to determine and change COMports for GF modules, I might be able to solve the issue! Update: I also changed the COMport number of the MCP Combo to a higher number (from 4 to 16) in the device manager, but that did not help.
  10. Servus Günter, thanks for the fast reply! I do not think that the problem is NGX-specific, because I tried several different FSX standard planes (and also the NGX) and they all behave the same. I have just downloaded and installed version 4.85, unfortunately the problem persists... :( Something I just found out is that not running the MCP Combo also helps. That is if I start FSX and LINDA with the MCP shut off (the LINDA console tells me that there is an error and it could not open the MCP combo port), then my GF-166 modules are fine and not not freeze. Does that tell us something useful?
  11. Hi everybody, I am new on this forum and I first would like to thank Artem Crum and Günter Steiner for the development of LINDA, which I think is just a terrific tool that makes a simmer's life so much easier! I have recently found a problem, however, which I have not been able to solve so far and that might be related to the linda.lua file. I am runnig FSX (Prof. + Acc pack) on Win7 64 and I have a number of hardware modules connected via several powered USB hubs including VRInsight's MCP Combo and CDUII as well as several GoFlight modules. I have also installed a licensed copy of FSUIPC4 4.84 (thank you Pete!). I was very excited when I discovered LINDA a couple of month ago and realized how powerful that tool is. After installation of LINDA all modules run fine except the GF-166 radio modules from GoFlight. For some reason, the modules will freeze upon starting FSX as soon as I touch buttons or knobs and they will not react anymore. I first thought it to be a hardware issue, but after contacting John Krieg from Goflight support (he was very helpful) I can now exclude a hardware problem, because the GF-166 modules run fine outside of FSX using a GoFlight test program. In addition, I have tracked the problem down to the linda.lua file, which seems to cause the problem. I did a number of tests, which revealed the following result: 1. Running FSUIPC together with linda.lua in the modules folder causes the freeze. 2. Removing FSUIPC from the modules folder solves the problem (GF-166 units run fine). 3. Removing the linda.lua file from the modules folder and the [LuaFiles] section from the FSUIPC4.ini file also solves the problem, so it is not FSUIPC per se. 4. Inactivating the GFDev.dll file (through which FSUIPC interacts with the GF modules), however, does not solve the issue (as long as FSUIPC runs linda.lua). I thus concluded that running the linda.lua file with FSUIPC somehow interferes with interaction of FSX with the GF-166 modules. Since I am stuck at this point, I would greatly appreciate any help, maybe there is a simple solution that I have overlooked. Many thanks, Hans.
×
×
  • Create New...