Jump to content
The simFlight Network Forums

ckovoor

Members
  • Posts

    117
  • 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,542 profile views

ckovoor's Achievements

Newbie

Newbie (1/14)

  • First Post Rare
  • Collaborator Rare
  • Week One Done Rare
  • One Month Later Rare
  • One Year In Rare

Recent Badges

3

Reputation

  1. 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)
  2. 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
  3. 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.
  4. 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.
  5. @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.
  6. @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.
  7. 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.
  8. 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.
  9. 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.
  10. 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.
  11. For a Client running FSX on Windows 10 x64 , keystrokes sent by WideClient were not being intercepted by the LUA. The problem and its solution are described in this thread: https://forum.simflight.com/topic/85961-wideclient-not-transmitting-keystrokes-to-local-fsx-on-networked-client-running-on-windows-10/
  12. I tried this out too...... Extract from WideClient.ini [7.148]: [User] PostKeys=Yes KeySend1=RunKey1 KeySend2=39,8,FS98MAIN KeySend3=37,8,FS98MAIN KeySend4=36,8,FS98MAIN KeySend5=38,8,FS98MAIN KeySend6=40,8,FS98MAIN Extract from FSUIPC.ini at Client: [Auto] 1=Lua networkrotation [LuaFiles] 1=networkrotation [Keys] 12=39,8,x010066C0,x01 -{Right: Press=offset byte set, offset 66C0 }- 13=37,8,x010066C1,x01 -{Left: Press=offset byte set, offset 66C1 }- 14=36,8,x010066C4,x01 -{Home: Press=offset byte set, offset 66C4 }- 15=38,8,x010066C3,x01 -{Up: Press=offset byte set, offset 66C3 }- 16=40,8,x010066C2,x01 -{Down: Press=offset byte set, offset 66C2 }- [Programs] Run1=CLOSE,C:\FS Files\WideClient7148\WideClient.exe networkrotation.lua had to be modified to make use of the free FSUIPC user offsets at 0x66C0 - 4. -- initial values lX = 0.0 lY = 0.0 lZ = 0.0 lPitch = 0.0 lBank = 0.0 lHeading = 0.0 -- increments delHdg = 11.25 delPitch = 1 -- camera rotations function rotate_right (offset, value) if value == 1 then lHeading = lHeading + delHdg if lHeading >= 180 then lHeading = lHeading - 360 end set_eyepoint () ipc.writeUB (0x66C0, 0) end end function rotate_left (offset, value) if value == 1 then lHeading = lHeading - delHdg if lHeading <= -180 then lHeading = lHeading + 360 end set_eyepoint () ipc.writeUB (0x66C1, 0) end end function rotate_down (offset, value) if value == 1 then lPitch = lPitch - delPitch if lPitch < -90 then lPitch = -90 end set_eyepoint () ipc.writeUB (0x66C2, 0) end end function rotate_up (offset, value) if value == 1 then lPitch = lPitch + delPitch if lPitch > 90 then lPitch = 90 end set_eyepoint () ipc.writeUB (0x66C3, 0) end end function rotate_reset (offset, value) if value == 1 then lPitch = 0.0 lHeading = 0.0 set_eyepoint () ipc.writeUB (0x66C4, 0) end end -- set the eyepoint function set_eyepoint () ipc.writeStruct( 0x86A0 , "6FLT" , lX , lY , lZ , lPitch , lBank , lHeading ) -- X, Y, Z, P, B, H end event.offset ( 0x66C0, "UB", "rotate_right") event.offset ( 0x66C1, "UB", "rotate_left") event.offset ( 0x66C2, "UB", "rotate_down") event.offset ( 0x66C3, "UB", "rotate_up") event.offset ( 0x66C4, "UB", "rotate_reset") The result is marginally better than the earlier one, in that the lagginess appears to have decreased slightly, though it is still there. But of course, the lagginess might have other causes, stemming from the Windows 10 environment, rather than have anything to do with the FSUIPC-WideFS-Lua method. Whatever it is, I am happy to have got it working on Windows 10. Thank you, as always, Pete, for your outstanding program and the help and support you give us. Regards, Chakko.
  13. Hi Pete, I seem to have found a workaround or a temporary solution to the problem I am facing. Realizing that the essential problem in my setup is that Postkeys=Yes allows WideFS to communicate stably and consistently with FSX/FSUIPC through the medium of FSUIPC Controls, rather than KeyPresses, I surmised that the reason that my networkrotation.LUA was not working consistently in intercepting and acting on the KeyPresses must be that event.key() suffers from some inability to trap the WideClient-sent Keypresses consistently in a Win 10 environment. So I tried event.control() instead, thus: Extract from WideClient.ini [7.148]: [User] PostKeys=Yes KeySend1=RunKey1 KeySend2=39,8,FS98MAIN KeySend3=37,8,FS98MAIN KeySend4=36,8,FS98MAIN KeySend5=38,8,FS98MAIN KeySend6=40,8,FS98MAIN Extract from FSUIPC.ini at Client: [Auto] 1=Lua networkrotation [LuaFiles] 1=networkrotation [Keys] 12=39,8,65672,0 -{Right: Press=PAN_RIGHT }- 13=37,8,65671,0 -{Left: Press=PAN_LEFT }- 14=36,8,65875,0 -{Home: Press=PAN_RESET }- 15=38,8,65735,0 -{Up: Press=PAN_DOWN }- 16=40,8,65734,0 -{Down: Press=PAN_UP }- [Programs] Run1=CLOSE,C:\FS Files\WideClient7148\WideClient.exe Event section from networkrotation.lua (other parts unchanged): event.control ( 65672, "rotate_right") event.control ( 65671, "rotate_left") event.control ( 65734, "rotate_down") event.control ( 65735, "rotate_up") event.control ( 65875, "rotate_reset") The solution is clumsy in that the FSUIPC PANning control is being intercepted and 'reinterpreted' by the LUA, and there appears to be a slight lag at the Client as a result, but at least it is synchronised with the other 6 views generated by my other Clients (not running Windows 10). I look forward to your comments. Thanks and Regards, Chakko.
  14. Dear Pete, As a matter of fact, I am using neither the default FSX assignments nor the FSUIPC assignments for view-panning. As recounted in the original thread at: https://forum.simflight.com/topic/81979-wideview-fsx-network-panning-using-fsuipc4-and-widefs/ we did try those out initially, but found that as the Panning command is a time-based command, it resulted in view-mismatches across the 7 networked Clients I have on my system. So we switched to using the SimConnect_CameraSetRelative6DOF function instead, actioned by a LUA entitled networkrotation at the Client FSUIPC. This networkrotation.lua uses event.key() to intercept key-presses sent by the local WideClient. I now realize that in a later post in the thread I had described the modified process, and should have reproduced that here for your reference: Summary of Process: When a panning-command (via Hat-Switch button) is applied at the SERVER, FSUIPC-WideServer sends a KeySend number to all networked Clients. At each CLIENT, WideClient receives the KeySend number and sends a key-press to FSX-FSUIPC. An auto-started LUA script intercepts this key-press and rotates the view appropriately using the SimConnect_CameraSetRelative6DOF function. Certain options in the wideviewx.ini file at the CLIENTs and SERVER need to be set to ensure that it does not interfere. A new Camera Definition is also installed on the CLIENT(s) to keep this option separate. So, at each WideClient: [User] KeySend2=39,8,FS98MAIN KeySend3=37,8,FS98MAIN KeySend4=36,8,FS98MAIN KeySend5=38,8,FS98MAIN KeySend6=40,8,FS98MAIN and from there to this LUA auto-started by the local FSUIPC4: -- initial values lX = 0.0 lY = 0.0 lZ = 0.0 lPitch = 0.0 lBank = 0.0 lHeading = 0.0 -- increments delHdg = 11.25 delPitch = 5 -- camera rotations function rotate_right () lHeading = lHeading + delHdg if lHeading >= 180 then lHeading = lHeading - 360 end set_eyepoint () end function rotate_left () lHeading = lHeading - delHdg if lHeading <= -180 then lHeading = lHeading + 360 end set_eyepoint () end function rotate_up () lPitch = lPitch + delPitch if lPitch > 90 then lPitch = 90 end set_eyepoint () end function rotate_down () lPitch = lPitch - delPitch if lPitch < -90 then lPitch = -90 end set_eyepoint () end function rotate_reset () lPitch = 0.0 lHeading = 0.0 set_eyepoint () end -- set the eyepoint function set_eyepoint () ipc.writeStruct( 0x86A0 , "6FLT" , lX , lY , lZ , lPitch , lBank , lHeading ) -- X, Y, Z, P, B, H end event.key ( 39, 8, "rotate_right") event.key ( 37, 8, "rotate_left") event.key ( 40, 8, "rotate_down") event.key ( 38, 8, "rotate_up") event.key ( 36, 8, "rotate_reset") The LUA has worked very reliably, and apart from the uniform rotation across the network views it actions, it also allows me to set the angular increments to my liking. It is only now with the issues that Win 10 has with SetWindowsHookEx that I am having a problem. .......................... But, in order to test your suggestion, I went back to using the FSUIPC assignments thus: [Keys] 12=39,8,65672,0 -{Right: Press=PAN_RIGHT }- 13=37,8,65671,0 -{Left: Press=PAN_LEFT }- 14=36,8,65875,0 -{Home: Press=PAN_RESET }- 15=38,8,65735,0 -{Up: Press=PAN_DOWN }- 16=40,8,65734,0 -{Down: Press=PAN_UP }- along with PostKeys=Yes in WideClient, and YES, IT WORKED to produce reliable panning responses with both 7.15 and 7.148 versions! If you would like, I can forward you the corresponding logs in a subsequent post. However, unfortunately, I don't think this is the best solution for me, because the Pan commands are not synchronised with the LUA rotations that are occurring at my other Client views. I am wondering if there is a way of modifying the current LUA so that it will be reliably responsive to key-presses sent via the PostKeys=Yes method, as the FSUIPC assignments are.....do you think that would that solve my problem? Regards, Chakko.
  15. Dear Pete, I thank you very very much for going into the details of my situation and spending so much of your time to help me. Some personal commitments away from the sim will prevent me from spending much time with it over the next few days, so please forgive me for my slowness in testing the new version of WideClient that you have created solely to help me solve my problem.......but I will get back to you as soon as I possibly can. Thank you for all that you do for me/us. 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.