Jump to content
The simFlight Network Forums

ckovoor

Members
  • Posts

    122
  • Joined

  • Last visited

  • Days Won

    3

ckovoor last won the day on October 7 2016

ckovoor had the most liked content!

1 Follower

Profile Information

  • Gender
    Male
  • Location
    VOBL

Recent Profile Visitors

2,777 profile views

ckovoor's Achievements

Apprentice

Apprentice (3/14)

  • Reacting Well Rare
  • Dedicated Rare
  • Conversation Starter Rare
  • First Post Rare
  • Collaborator Rare

Recent Badges

3

Reputation

  1. Dear Pete and Michel, I had a similar problem on Win 10, though with FSX and FSUIPC4-WideFS7, some time ago, and the problem and its resolution are found in this thread: https://forum.simflight.com/topic/85961-wideclient-not-transmitting-keystrokes-to-local-fsx-on-networked-client-running-on-windows-10/ Just in case this helps. Regards, Chakko.
  2. Dear Pete, I spent the last few hours consolidating all the Lua files for the PMDG B747v3: (1) all the files communicating with the XML Gauge files into a single Lua file (2250 lines of code). (2) all the files on both input and output sides of the hardware MCP-EFIS-DSP into a single Lua file (about 750 lines of code). I used different handles for distinct COM channels as you advised. (3) all the files on both input and output sides of the hardware radio-nav console into a single Lua file (again, different handles). And then I ran them, and it all worked perfectly, and the performance, is, if anything, better than before! I mean the displays, and the controls appear more rapidly responsive than before. So I shall be following your initial advice to consolidate/rationalize all the LUA files across my system, and return them (in their much smaller numbers 😉) to the Modules folder which is their ideal home. And in this way stay far away from the 127 file limit. I'll look into the other suggestions/points also, over the next few days. Thanks for your help and support! Regards, Chakko.
  3. Hi Roman, Many thanks for your suggestion. To test your idea quickly, I wrote a Lua entitled killLua.lua containing the instruction, in the first instance: ipc.writeSTR(0x0D70, "LuaKill LuaB747v3\\B747v3RearPedstl"), and ran it after assigning it to a button press, but to no effect. I also tried, in the second instance: ipc.macro("LuaKill LuaB747v3\\B747v3RearPedstl"), again, to no effect. So maybe this will not work for Lua files located outside the Modules folder. ......... Dear Pete, Most of the Lua files which make up the initial 127 are, in fact, files communicating with Arduinos on dedicated COM ports, and for that reason, as far as I know, they cannot be combined. In this set of 18 Lua files for the PMDG 747, 10 of these are files are communicating with 9 distinct Arduinos on 9 distinct COM ports. And that is pretty much the same for all the other aircraft I fly. With some aircraft using INS units, there are more COM channels involved. I agree that with the Lua 's dealing with Gauge files and Panels, I might be able to combine some of them, but that is going to result in some massively long files, and experience with this has taught me to keep things modular. In any case I'd still go over 127 because of the Arduino-related files. ........... Thanks and Regards, Chakko.
  4. I plead "Not Guilty" to the charge of profligacy in spawning Lua plugins. I operate a touchscreen-based system with 6 monitors on a Server PC, and 10 monitors and 7 additional PC's on a WidevieW/WideFS network. A video of its operation in the case of the PMDG 747-400 (QOTS II v3) can be seen here: https://www.youtube.com/watch?v=saFJ_xGBDTs and should give you an idea of it's complexity. In the case of the PMDG 747-400 v3 here is the [Auto] section of the 747v3.ini file located in Modules\Profiles with a justification for each Lua plugin: [Auto] 1=Lua LuaB747v3\\b747v3inputsL 2=Lua LuaB747v3\\b747v3inputsR 3=Lua LuaB747v3\\B747v3outputs1 4=Lua LuaB747v3\\B747v3outputs2 5=Lua LuaB747v3\\B747v3Overhead 6=Lua LuaB747v3\\B747v3Captain 7=Lua LuaB747v3\\B747v3Copilot 8=Lua LuaB747v3\\B747v3Centre 9=Lua LuaB747v3\\B747v3Quadrant 10=Lua LuaB747v3\\B747v3RearPedstl 11=Lua LuaB747v3\\B747v3_RN1 12=Lua LuaB747v3\\B747v3_RN2 13=Lua LuaB747v3\\B747v3_RNinputs 14=Lua LuaB747v3\\B747v3lights 15=Lua LuaB747v3\\B747v3Panels 16=Lua LuaB747v3\\B747v3MotorQuad1 17=Lua LuaB747v3\\B747v3MotorQuad2 18=Lua LuaB747v3\\B747v3ATstate (1) For the B744 MCP-EFIS-DSP hardware unit I used 4 distinct Arduino Mega 2560 units, each on a dedicated COM port, hence Lua's 1 through 4. (2) I created my own 2-D panel set for the PMDG 747-400 v3, because it did not come with native 2-d panels. I wrote individual .XML Gauge files for the Captain's Panel, Centre Panel, Co-Pilots Panel, Throttle Quadrant, Rear Pedestal, Forward Overhead and Rear Overhead. Each of these gauge files write to custom LVars which are then communicated to the sim via distinct Lua plugins. Hence Lua's 5 through 10. (3) I built a universal radio-navigation hardware console containing 3 Arduino Megas, each on a dedicated COM port. However, as the B747v3 interfaces with this console in a unique way, the 3 associated Lua plugins are unique to this aircraft. Hence Lua's 11 through 13. (4) B747v3lights.lua collects information about external lighting from my Server (cockpit) PC for transmission to the networked external view PC's (using WidevieW) to create coordinated ground illumination effects. (5) B747v3 Panels.lua is there to start the various panel windows of the B747 in specific locations and sizes to overcome certain graphics card issues I face on my system. (6) I recently built a Universal Motorized throttle quadrant (which you can see in development here: https://youtu.be/xM2Jp8nfjdA ) which requires a unique set of Lua's to interface with each particular aircraft that it is being used with. It contains 2 Arduino Mega's, hence Lua's 16 and 17. I also had to write another Lua to determine the Autothrottle state, in order to know when to power the stepper motors. This Lua communicates with an autoit script which extracts this information by pixel detection (method I described here: https://forum.simflight.com/topic/78417-lua-for-pixel-analysis/ and the basic issue is brought up here: https://forum.simflight.com/topic/92628-programmatically-discovering-whether-the-autothrottle-is-active-in-the-pmdg-747-400-v3/ ) Now, when I reveal that I also operate the PMDG B777-200, PMDG MD-11, PMDG 737-800, Level-D B767-300, FSLabs A320, SimCheck A300B4-203, Digital Aviation Fokker 100, Majestic Dash 8 Q400, Flight One ATR 72-500, and Aerosoft CRJ 700, and that I have built dedicated MCP's for each of them, and each of them interfaces with the other hardware/software (radio-nav console, throttle quadrant, gauge files, CIVA INS units, Wide View lighting effects) in unique ways, one might wonder how I didn't breach the maximum number of 127 earlier. I should add that apart from the aircraft-specific Lua's that I have mentioned, I also have some common Lua's that I use for all aircraft, and these remain in the Modules folder: like for manipulating scenery on my external-view monitors (refer to this post on network panning: https://forum.simflight.com/topic/81979-wideview-fsx-network-panning-using-fsuipc4-and-widefs/ ). As a matter of fact, I was led to this solution by your own comments in this thread: https://forum.simflight.com/topic/74784-lua-files-are-not-shown-in-fsuipc-gui/ in which you state that "a maximum of 127 Lua files can be assigned -- the first 127 in the list in the INI file. You can have other Lua files, preferably in other folders, which can be called by any of those, or directly in [Auto] sections." Fair enough, I'll try to work with that. To conclude, I have to say that "it is all your fault", Pete, for having brought this extremely powerful programming tool within the ambit of FSUIPC4, which was brilliant enough to start with. I believe I have built a uniquely versatile simulation system, and none of it was achievable without FSUIPC4 and LUA. Thanks and Regards, Chakko.
  5. Hello John and Pete, I'm (still) running FSX-SP2 and Win 7 x64 with registered FSUIPC4.974b. I have lots of hardware (MCP's, throttle quadrants, radio consoles) containing Arduino Mega's, and hence numerous LUA scripts to manage them. So a few days ago, I reached and breached the upper limit of 127 LUA files in the Modules folder. So I created sub-folders for each aircraft within the Modules folder, as for example Modules\LuaB747v3 containing all the Lua files pertaining to that particular aircraft. These LUAs are then started automatically from the Modules\Profiles\B747v3.ini file, thus: [Auto] 1=Lua LuaB747v3\\B747v3inputsL One negative fallout of the this arrangement is that if I need to start or kill a LUA on the fly using a button press (as I often need to do when testing hardware controlled by the Arduinos) I cannot do it as easily as when the LUAs were located in the Modules folder. For in that case I could assign a Lua (run) or LuaKIll to a particular button press and have it run or stop a chosen LUA on the fly. In the new arrangement, in order to run a LUA using a button press, I have to create a LUA file within the Modules folder, say called runLUA.lua containing the command, as for example: ipc.runlua(LuaB747v3\\B747v3inputsL), and then run the LUA by assigning it to a button press. It's cumbersome, but still worthwhile, especially while testing/debugging Arduino-related programs. I see no way of terminating such a LUA externally. So, my question: is there any way of terminating/kiling a Lua file located in a folder other than Modules? Something like an ipc.killLua() command? Thanks and Regards, Chakko.
  6. Hi, I am building a generic Boeing-style motorized throttle quadrant for use with my PMDG B744v3, B772 and B738 and maybe also the MD-11 (in FSX SP2, Win 7x64, with FSUIPC4). The 4 throttle levers and the single speedbrake lever are each geared to a potentiometer which senses the current lever position (0 to 16384) and a NEMA 17 stepper motor which drives the lever when the autothrottle is active. Each throttle lever also supports a reverser lever, connected to a potentiometer sensing its position (0 to -4096). An AT disconnect button is mounted on lever 1, and a TOGA button on lever 2. The flaps lever will be added soon. Here's a photo of the test rig: The hardware is controlled by a single Arduino Mega 2560 R3 in conjunction with five Big Easy Driver boards (to drive the steppers). When the autothrottle is "active", the coils of the stepper motors can be energised, and the throttle levers driven to their target positions. Essentially the system needs to know at all times whether the autothrottle is active (or not), because that determines whether power is to be applied to the stepper motors driving the levers. With the (PMDG) B777-200 this is easily done, because the B772 MCP has a green annunciator on the AT pushbutton switch, which lights up whenever the AT is active, with a corresponding FSUIPC offset (MCP_annunAT = 0x6572 BYTE) which one can read to determine this. So in the case of the PMDG B772 one simply applies power to the steppers whenever 0x6572 == 1, and removes it when it is zero. It seems to work reasonably well, though I am not absolutely certain about its behaviour during AT HOLD mode. With the (PMDG) B747-400, however, there is no equivalent push-button switch or annunciator. In the real world, as I understand it, the pilot would learn about the state of the autothrottle from the AT mode displayed in the first column of the FMA. If the AT mode is one of: THR REF, SPD, THR, or IDLE, then the AT is active and power is to be applied to the stepper coils/servo motors. But if the AT mode is HOLD or blank, then power is to be removed from the coils as the thrust levers should now be able to be moved freely without any resistance. Unfortunately, afaik, there is no way of discovering the AT mode on the FMA by programmatic means, i.e, this information appears not to be accessible by way of the PMDG SDK/FSUIPC offsets. So my question is this: is there any other way of discovering, absolutely, whether the AT is active? I am particularly interested in the response of RW 747 pilots who have a deeper understanding of the system logic, and of cockpit-builders who might already have encountered this problem and maybe have a solution. Here is the relevant information that is provided by the PMDG 744 SDK through readable FSUIPC offsets: 659D 1 BYTE MCP_IASBlank (=1 when IAS/M display blanked out) 65A7 1 BYTE MCP_ATArm_Sw_On 65C2 1 BYTE MCP_annunTHR 65C3 1 BYTE MCP_annunSPD 65C5 1 BYTE MCP_annunVNAV 65C6 1 BYTE MCP_annunFLCH 65C8 1 BYTE MCP_annunVS 65C9 1 BYTE MCP_annunALT_HOLD Thanks, Chakko. (also posted on the PMDG 747v3 forum)
  7. Dear Pete, I attach separate zip folders for each of PMDG B737v1.2, B747v3.0 and B777v1.1, with the simulator restarted each time, and running FSUIPC 4.975a. Please note that I did not connect the Arduino-based MCP/EFIS/DSP hardware each time, so the log files may contain the LUA error: bad COM handle, which can be ignored. Please let me know if I can provide any further information. Chakko. B737v1.2.zip B747v3.0.zip B777v1.1.zip
  8. Dear Pete, I started FSX and loaded the PMDG 737v1.2, waited for it to complete initializing systems, then after about a minute loaded the PMDG 747-400v3.0. A PMDG popup immediately warned that it is not a good idea to load a second PMDG aircraft in succession, but I went on nevertheless, and the 747v3 completed loading. Again, after a minute or so, I tried loading the PMDG 777v1.1, and again ignored the PMDG warning ..... but the 777 did not load completely, i.e. all panels were not displayed, and the menu options stopped working. So I had to shut down FSX. I tried a second time with similar results. It seems that the maximum number I can load in succession is 2 PMDG aircraft. So would it be okay if I sent you a separate log for each aircraft, with the sim restarted each time? Or would you want me to load them in pairs, like 737-747, 747-777 and 737-777? I await your instructions. Chakko.
  9. Dear Pete, First, thank you very much for looking into this. I shall be loading FSUIPC 4.975a and test-logging with the PMDG 737, 747 and 777, as I have all three, and will provide you with the zipped files, soon. I am not sure why you have provided the FSUIPC 4.974b (dll), as I already have that, and I have mentioned in this thread that the problem does not occur with that version. The problem is only with FSUIPC 4.975a, and simply replacing that DLL with FSUIPC 4.974b clears the issue. Also, as mentioned in the other thread concerning the B777 at : https://forum.simflight.com/topic/90304-pmdg-777-fsuipc-offsets-not-updating/?do=findComment&comment=546961 , the same problem occurs with the B777, but not the B737. That is, the B737 functions normally with FSUIPC 4.975a, but the B777 does not. Anyhow, I'll work on getting you the logs now. Thanks, Chakko.
  10. @AirPanther Hi, I can confirm that my PMDG 777-200LR v.1.10 suffers from the same lack of access to FSUIPC offsets as my PMDG 747-400 v.3.00 in FSX SP2 and FSUIPC 4.975a and Win7x64. The Event ID's for controls (on the input side) seem to work, but many of the "PMDG specific" FSUIPC offsets (for displays and annunciators on the output side) are clearly not being read/accessed. The problem disappears immediately when I replace FSUIPC 4.975a with FSUIPC 4.974b (which is the last one I had downloaded prior to 4.975a). I should mention that I also have the PMDG 737-800 NGX v.1.20 in FSX SP2 and Win7x64, but that airplane seems to work normally and the "PMDG specific" FSUIPC offsets are successfully read with FSUIPC 4.975a. Chakko.
  11. @AirPanther : I wonder whether your issue is related to a similar one I am facing with the PMDG 747v3 (offsets) in FSX SP2 and FSUIPC 4.975a that I reported at: https://forum.simflight.com/topic/89157-fsuipc-pmdg747v3-missing-offsets/?do=findComment&comment=544470 I shall try using FSUIPC 4.975a with my own PMDG 777 and get back to you. Chakko.
  12. I have created Voice-Interactive Checklists (using Windows Speech Recognition and Text-to-Speech facilities) for a variety of airplanes in FSX, though not by using this LUA script, but using a third party freeware: VoiceMacro. For details please visit: https://voicemacro.net/ and then proceed to my post in the VoiceMacro forums at: https://voicemacro.net/ForumVM/discussion/405/flight-simulator-co-pilot-for-cockpit-checklists-fsx-and-windows-7-x64#latest Checklists and Profiles I have already created for some common aircraft are referenced here: PMDG B747-400: https://forum.pmdg.com/forum/main-forum/general-discussion-news-and-announcements/pmdg-747-queen-of-the-skies-ii-forum/71104-voice-interactive-checklists-for-the-b747-400-qots-ii PMDG B737-800 NGX: https://forum.pmdg.com/forum/main-forum/pmdg-737-ngx/75062-voice-interactive-checklists-for-pmdg-b737-800-ngx PMDG MD-11: https://forum.pmdg.com/forum/main-forum/pmdg-legacy-products/67885-voice-interactive-checklists-for-the-pmdg-md-11 SimCheck A300B4: https://forum.aerosoft.com/index.php?/topic/154190-voice-interactive-checklists-for-simcheck-a300b4/&tab=comments#comment-986217 Flight One ATR72-500: http://atr.flight1.net/forums/voiceinteractive-checklists-for-flight1-atr72500_topic6739.html?SID=10078-f5dc6bdea27f27a7bdf42075462963 Flight Sim Labs A320 X: https://forums.flightsimlabs.com/index.php?/topic/25728-voice-interactive-checklists-for-fslabs-a320x/ Majestic Dash 8 Q400: http://majesticsoftware.com/forums/discussion/793/voice-interactive-checklists-for-mjc8-q400 Level D B767-300: https://www.dropbox.com/sh/51bgejl2j83anjf/AACmtjJDcMbJBLvvcTL7oJMwa?dl=0 PMDG B777-200: https://forum.pmdg.com/forum/main-forum/pmdg-777-forum/71229-voice-interactive-checklists-for-pmdg-b777-200 Chakko Kovoor.
  13. Dear Pete, Apart from this problem with the PMDG B747-400 v3, FSUIPC 4.975a appeared to be functioning normally, but then that is only after a few days of testing, and not with all the aircraft that I fly. I need to do more extensive testing with all the other airplanes I fly before I can be certain. So, I shall stick with FSUIPC 4.974b for the time being, but will sometime soon re-test 4.975a and supply you with Install and Run-Time Logs for you to check. But I will open a separate thread for that. Thanks and Regards, Chakko.
  14. Dear Pete and John, I operate the PMDG B747-400 QOTS II v3 on FSX-SP2 and Win 7 x64 with registered FSUIPC4. The B744v3 from PMDG does not come with 2-D panels so I constructed my own working 2-D panel sets with my own XML gauge code and FSUIPC4-LUA scripts. I also built a hardware MCP+EFIS+DSP unit using Arduino Megas and FSUIPC4-LUA. Of course Pete's documentation for the FSUIPC offsets and the PMDG 747 SDK for Control Event ID's are the backbone of this implementation. You can see the system in operation here: https://www.youtube.com/watch?v=saFJ_xGBDTs Anyway, all was going well with FSUIPC 4.974b until a few days ago when I saw a newer version FSUIPC 4.975a and decided to install it. And immediately thereafter, the B747v3 stopped working properly. Specifically, the inputs and outputs to and from my Hardware and XML gauges were not being read or linked properly to the PMDG software. Replacing the FSUIPC4 DLL with the earlier version 4.974b immediately solved the problem and everything started working again. I switched the modules back and forth a few times, so I can confirm that something has broken, at least as far as the B747v3 in FSX is concerned, in the move from FSUIPC 4.974b to 4.975a. I have posted this report in this thread, because I suspect it may have something to do with the modifications that have been discussed here, which may or may not have been necessary for the FSX version of the B747v3, for which development ceased several months ago. For the time being I am reverting to FSUIPC 4.974b in order to be able to fly this wonderful airplane again. Would you please investigate? Thanks and Regards, Chakko.
  15. Interesting! But isn't Ram Air Pressure (or Total Pressure) = Static Pressure (or Ambient Pressure) + Dynamic Pressure ? So if you needed Ram Air Pressure to feed your hardware with, you would need to add the values as above. Also wouldn't Static Pressure (or Ambient Pressure) be a value which doesn't change very rapidly with time ........ unless, of course, you are travelling very fast indeed (vertically through altitude layers or horizontally across isobars) within the atmosphere? Just my two cents. Chakko.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.