alpinflier

I still made some additional tests. Firsts I sent commands with FSUIPC, by "custom control" to offsets 69933 to 69936. Same result. My last hope was a mouse macro, because this should simulate exactly what the mouse click on the screen does. But unfortunately it is all the same. The buttons go in and out without problems, but the sound does not stop any more, after it has been triggered once. To compare this, I tried to operate the test button for the LE devices the same ways. It operates without problems. LEDs are off, when the button is released. Urs Meyer

The hardware is not involved. I can send a 1 and a 0 by any button, but also by an input/output console, that sends 1 or 0 to any sdk event. The buttons on the NGX screen do exactly what the command asks for: a 1 presses the button in, a 0 makes it come out. Sound is started correctly, but not stopped, when button has come out. I know, this sounds strange, but I can reproduce it on my test pc and on my homecockpit pc. Urs Meyer

Hi all I am just going on with my Opencockpits B737 aft overhead, connecting it to my PMDG NGX. Most functions are working now, but I have a problem with the following events: EVT_OH_WARNING_TEST_MACH_IAS_1_PUSH (THIRD_PARTY_EVENT_ID_MIN + 301) EVT_OH_WARNING_TEST_MACH_IAS_2_PUSH (THIRD_PARTY_EVENT_ID_MIN + 302) EVT_OH_WARNING_TEST_STALL_1_PUSH (THIRD_PARTY_EVENT_ID_MIN + 303) EVT_OH_WARNING_TEST_STALL_2_PUSH (THIRD_PARTY_EVENT_ID_MIN + 304) Sending a 1 to the NGX results in a push down of the buttons, visible on the NGX cockpit screen and the corresponding sounds are heard. But the following 0 makes only return the buttons to their rest position, the sounds don't stop. The only way to stop them is using the mouse, pushing the buttons on the screen and release them. First I thought this must be an error of the driver (OCP4NGX), but I see the buttons return with a 0, so I think the 0 is well detected from NGX, but sounds not stopped. Is this a known issue? Any comments are most welcome. Urs Meyer

Finally I have found the reason for my confusion concerning FUEL_annunXFEED_VALVE_OPEN. The values are output correctly by PMDG, 2 for in transit, 1 for open. The only small error is found in the sdk definition "unsigned char FUEL_annunXFEED_VALVE_OPEN; // 0: Closed 1: Open 2: In transit (dim)" The remark (dim) should be behind "Open". Now it is really up to the HW manufacturer to optimize the data transfer. Concerning the document: I mean sort of a change list, as it is used in program version history files, but directed to coming versions. Urs Meyer

Hi Kyle Thank you very much for the fast reply. I think the driver just takes the value it gets (0, 1 or 2) and hands it over to SIOC variable. Can't imagine that it exchanges numbers. Therefore my question. Is there a public document where we can see, what is planned resp. place wishes for a NGX re-visit? By the way, in general I am very happy with your fantastic program. My problems have only to do with homecockpit setup, which doesn't belong to your main user group. But I am gathering a lot of practical experience and can perhaps help to find good solutions for optimised hardware control. Best regards Urs Meyer

Hi PMDG friends I am actually taking into operation my B737 overhead from Opencockpits. There are different LEDs with full and dimmed brightness. Unfortunately there is only one, that is fully supported by PMDG NGX: unsigned char FUEL_annunXFEED_VALVE_OPEN; // 0: Closed 1: Open 2: In transit (dim) Moreover I get 1 for "in transit" and 2 for "Open". This could be an error of the driver (OCP4NGX), but please check. The OC hardware supports directly 1 for open, 2 for dimmed. All other bivalent LEDs get only boolean from PMDG. I can make the brightness step with an SIOC script, but it would be nice getting correct values from PMDG in the future. Another surprise was the general use of LED outputs. They work without problems in operation. But the light test does not source a 1 on all individual outputs. So the outputs do not represent the LED states 1:1. Would it be possible in the future to do this? Then cockpit builders can forget all light-test, cold and dark and individual light controls scripting. Just use LED outputs and bring them onto panel. The rest is done by PMDG program. That would be great!!!!!!!!!!!!! Any comments are most welcome. Thank you in advance. Best regards Urs

Hi Kyle Sorry to bother you again. I tried to circumvent the missing variable above and was looking for a variable to show the "TOGA" mode, but without success. Is it correct that there is no sdk data available for that? Best regards Urs Meyer

Hi Kyle Thank you very much for this ultra fast answer :smile: . To be precise: I don't want to change the ATArmed variables, but I would need an additional variable (call it as you want to), that drives the coupling mechanism between my controlstand levers and the PMDG levers: - controlstand drives PMDG levers, i.e. pilots may move the levers (manual control) - PMDG drives controlstand levers, i.e. flight computer drives the levers (autothrottle) If such a variable (boolean) could be realised for the planned update it would help a lot. If there are questions please let me know. Best regards Urs Meyer

Hi all I would like to realise the A/T function in my homecockpit with motorised throttles, based on PMDG737NGX and P3D. As far as I know throttle levers are controlled by pilots as long as A/T is off or only armed. As soon as TOGA is selected, A/T is engaged and throttle levers are controlled by the PMDG. But there are additional changes between „armed“ and „engaged“ during takeoff and flight, e.g. the „THR HOLD“ at takeoff. Unfortunately there are only two variables available in PMDG SDK to control external equipment concerning A/T: - MCP_ATArmSw - MCP_annunATArm both indicating that A/T is armed. But they cannot be used to control the automatism of the levers as required. There should be a variable "A/T engaged" that reflects all the internal conditions and dependencies. Some functions could be realised by software using the variables above and some others as Speed, AGL, a.s.o., but that is quite complicate and will probably not cover all situations. Therefore my question to PMDG : Is it possible to provide such a variable in the future ? It would help very much to realise a realistic A/T behaviour in home cockpits. If I’m wrong please let me know and have some hints to solve this problem. Thanks for any comments Urs Meyer