Report bugs and issues for the PMDG 737 for MSFS here
-
- Posts: 14
- Joined: Mon Jan 04, 2021 11:42 am
- Location: EDDH
Report bugs and issues for the PMDG 737 for MSFS here
Hi Roar,
first of all, I tried to install Oi4FS.v3 but couldn't get it to work. Just moved back to .v2 for now < will try it another time.
With .v2 all is working well with my setup.
I just noticed 2 TFR behaviors yesterday.
On COM 2 - the TFR is working only each 2nd press. Means I have to klick 2 times to switch active/stdby. (while on COM 1 its working normal)
On ADF - the TFR is working only with a long press. (with just a short press its just switching for a second but then switching back)
BR
Chris
first of all, I tried to install Oi4FS.v3 but couldn't get it to work. Just moved back to .v2 for now < will try it another time.
With .v2 all is working well with my setup.
I just noticed 2 TFR behaviors yesterday.
On COM 2 - the TFR is working only each 2nd press. Means I have to klick 2 times to switch active/stdby. (while on COM 1 its working normal)
On ADF - the TFR is working only with a long press. (with just a short press its just switching for a second but then switching back)
BR
Chris
Chris
(EDDH)
(EDDH)
Re: Report bugs and issues for the PMDG 737 for MSFS here
The Oi4Fs is now in version 4. So skip Oi4FS v3.
I will look into the 2 issues. I though the COM issue was solved.
I will look into the 2 issues. I though the COM issue was solved.
Re: Report bugs and issues for the PMDG 737 for MSFS here
The Overspeed and Underspeed indicators on the MCP IAS display issue are now fixed and work OK.
COM2 TRF now works with a single push on TRF button
ADF TRF now works with a single push on TRF button
ADF Standby Frequency can now be set to all valid frequencies.
ADF Standby frequency are not sync'd with virtual ADF Standby frequency, but work locally on ADF hardware module and is therefore fully functional.
The new scripts - PMDG B737 v6.2.ssi and PMDG B737 v6.2P can be downloaded here:
COM2 TRF now works with a single push on TRF button
ADF TRF now works with a single push on TRF button
ADF Standby Frequency can now be set to all valid frequencies.
ADF Standby frequency are not sync'd with virtual ADF Standby frequency, but work locally on ADF hardware module and is therefore fully functional.
The new scripts - PMDG B737 v6.2.ssi and PMDG B737 v6.2P can be downloaded here:
-
- Posts: 44
- Joined: Mon Nov 28, 2022 7:38 pm
Re: Report bugs and issues for the PMDG 737 for MSFS here
Hi,
I’m new in this forum, so this is my first post.
Recently I bought PMDG 737-800 for FS 2020 and Oi4FS software to get my Opencockpits Hardware work with the PMDG Boeing.
First of all I want to report my experience and come to some issues / problems later
I started with 4 Opencockpits devices:
1x EFIS (Captain side)
1x MCP V3
1 COM Radio
1x NAV Radio
Following Roar’s excellent installation description everything worked from the first try
Now the more challenging issue:
I have a self made overhead panel consisting of a self made aluminum frame, equipped with complete set of Opencockpits FWD OVH panels + some parts frome the AFT OVH: LE DEVICES, IRS Panel + 5 Annunciators for 3x gears down + 2x Reverser, what gives me appr. 140 Inputs, more than 140 Annunciator outputs plus some 7- segments displays on the electric panel as well as for FLT ALT and LAND ALT.
Electronic for the OVH is based on Opencockpits Hardware as listed below:
1x USB Expansion Card, 2x Master Cards, several Input- and Output cards, 2x Displays II Cards and 2x Outs Cards. Outs Cards give me 2x 32 additional LED outputs with three intensity levels (off, on and partially on for dimming). I did the wiring on my own so I had to modify the PMDG B737 v6.2 script accordingly.
I linked my AFT OVH parts to device 30 and I re-assigned all Input-, Output- and Digit-Numbers to fit to my configuration.
Result: nearly every switch, push button, encoder, annunciator, and 7-segments display work fine – that was much more easy than I thought, as I was not familiar with SIOC until then. Thanks Roar for that excellent software. (Up to now I have used my OC hardware with the Zibo B738 on X-Plane 11 with LUA scripts - no SIOC, where everything worked fine so that I can exclude hardware failures.)
Now my minor actual issues with the PMDG B737 v6.2 and / or the PMDG 737-800
1) Wiper: as already reported by another user the script only offers „off“ or „ low speed“ but the rotary switchs on the OC hardware and on the PMDG OVH have 4 positions: PARK – INT – LOW – HIGH
After my first training with SIOC, I could modify the script so that both wipers work now correctly on the 4 positions.
(hopefully the rain effects in FS2020 will be updated sometime to come close to what we see on X-Plane 12)
If required (and allowed by Roar) I can post my wiper modification in this forum
2) Generator disconnect switches: when I operate the disconnect swithes on my OC hardware, the switches on the PMDG OVH (on PC Monitor) work correctly. Guards open and switches move in the same direction as on my OC hardware – but nothing else happens. The generators only disconnect when I click the switches on the screen. Someone else having this problem? Roar would you please also check.
3) LE Devices: on first try only the left displays show flaps activities, the ones on the right side remain off. I looked into the script and found two different CO variables: AUDI3_POWER_ON for the left side and OVH_AFT_POW_ON for the right side.
For left flaps display script reads:
Var 0240, name FlapsDisplayL, Link SUBRUTINE
{
C0 = &AUDI3_POWER_ON = 0
For right flaps display script reads:
Var 0241, name FlapsDisplayR, Link SUBRUTINE
{
C0 = &OVH_AFT_POW_ON = 0
After I changed the right side below Var 0241 to „C0 = &AUDI3_POWER_ON = 0“ as well, both sides worked.
I also tried with C0 = &OVH_FWD_POW_ON = 0 because I only use device 30 for FWD and AFT, but this does not work (I don’t understand the AUDI3 thing, OVH_xxx_POW_ON sounds more logical for me)
I can live with actual flap display behaviour but it makes me only 95% happy. Displays for flaps light up simultaneously in groups as if all flaps of that group get into position exactly at the same time. The display behaviour on the OC LE Devices Panel is not the same as on the PMDG panel, where each flap seem to be indicated still in groups, but individually and not simultaneously. I tried to modify the script so that flap light conditions will be read from the actual PMDG flap lights on the LE Devices and not from the flap position, but I failed. Maybe someone can help me with a modified script section or I have to do some more training on SIOC.
4) Brightness behavior of valves: Annunciators for CROSS FEED, ENG VALVES and SPARE VALVES have 2 brightness levels - dimmed (when valves are moving) and bright (when valves are in position). On the PMDG OVH it’s the other way round.
Annunciators for ANTI ICE VALVES should have same behavior, but actually they only have the high level of brightness. Is this something that is missing in the script or is it my problem due to changed assignments?
That should be enough for today. I have tested OVH with airplane on the ground only to see if my assignments are correct. Next step is to test start from cold and dark and on some flights.
Best Regards
Norbert
I’m new in this forum, so this is my first post.
Recently I bought PMDG 737-800 for FS 2020 and Oi4FS software to get my Opencockpits Hardware work with the PMDG Boeing.
First of all I want to report my experience and come to some issues / problems later
I started with 4 Opencockpits devices:
1x EFIS (Captain side)
1x MCP V3
1 COM Radio
1x NAV Radio
Following Roar’s excellent installation description everything worked from the first try
Now the more challenging issue:
I have a self made overhead panel consisting of a self made aluminum frame, equipped with complete set of Opencockpits FWD OVH panels + some parts frome the AFT OVH: LE DEVICES, IRS Panel + 5 Annunciators for 3x gears down + 2x Reverser, what gives me appr. 140 Inputs, more than 140 Annunciator outputs plus some 7- segments displays on the electric panel as well as for FLT ALT and LAND ALT.
Electronic for the OVH is based on Opencockpits Hardware as listed below:
1x USB Expansion Card, 2x Master Cards, several Input- and Output cards, 2x Displays II Cards and 2x Outs Cards. Outs Cards give me 2x 32 additional LED outputs with three intensity levels (off, on and partially on for dimming). I did the wiring on my own so I had to modify the PMDG B737 v6.2 script accordingly.
I linked my AFT OVH parts to device 30 and I re-assigned all Input-, Output- and Digit-Numbers to fit to my configuration.
Result: nearly every switch, push button, encoder, annunciator, and 7-segments display work fine – that was much more easy than I thought, as I was not familiar with SIOC until then. Thanks Roar for that excellent software. (Up to now I have used my OC hardware with the Zibo B738 on X-Plane 11 with LUA scripts - no SIOC, where everything worked fine so that I can exclude hardware failures.)
Now my minor actual issues with the PMDG B737 v6.2 and / or the PMDG 737-800
1) Wiper: as already reported by another user the script only offers „off“ or „ low speed“ but the rotary switchs on the OC hardware and on the PMDG OVH have 4 positions: PARK – INT – LOW – HIGH
After my first training with SIOC, I could modify the script so that both wipers work now correctly on the 4 positions.
(hopefully the rain effects in FS2020 will be updated sometime to come close to what we see on X-Plane 12)
If required (and allowed by Roar) I can post my wiper modification in this forum
2) Generator disconnect switches: when I operate the disconnect swithes on my OC hardware, the switches on the PMDG OVH (on PC Monitor) work correctly. Guards open and switches move in the same direction as on my OC hardware – but nothing else happens. The generators only disconnect when I click the switches on the screen. Someone else having this problem? Roar would you please also check.
3) LE Devices: on first try only the left displays show flaps activities, the ones on the right side remain off. I looked into the script and found two different CO variables: AUDI3_POWER_ON for the left side and OVH_AFT_POW_ON for the right side.
For left flaps display script reads:
Var 0240, name FlapsDisplayL, Link SUBRUTINE
{
C0 = &AUDI3_POWER_ON = 0
For right flaps display script reads:
Var 0241, name FlapsDisplayR, Link SUBRUTINE
{
C0 = &OVH_AFT_POW_ON = 0
After I changed the right side below Var 0241 to „C0 = &AUDI3_POWER_ON = 0“ as well, both sides worked.
I also tried with C0 = &OVH_FWD_POW_ON = 0 because I only use device 30 for FWD and AFT, but this does not work (I don’t understand the AUDI3 thing, OVH_xxx_POW_ON sounds more logical for me)
I can live with actual flap display behaviour but it makes me only 95% happy. Displays for flaps light up simultaneously in groups as if all flaps of that group get into position exactly at the same time. The display behaviour on the OC LE Devices Panel is not the same as on the PMDG panel, where each flap seem to be indicated still in groups, but individually and not simultaneously. I tried to modify the script so that flap light conditions will be read from the actual PMDG flap lights on the LE Devices and not from the flap position, but I failed. Maybe someone can help me with a modified script section or I have to do some more training on SIOC.
4) Brightness behavior of valves: Annunciators for CROSS FEED, ENG VALVES and SPARE VALVES have 2 brightness levels - dimmed (when valves are moving) and bright (when valves are in position). On the PMDG OVH it’s the other way round.
Annunciators for ANTI ICE VALVES should have same behavior, but actually they only have the high level of brightness. Is this something that is missing in the script or is it my problem due to changed assignments?
That should be enough for today. I have tested OVH with airplane on the ground only to see if my assignments are correct. Next step is to test start from cold and dark and on some flights.
Best Regards
Norbert
Best Regards
Norbert
(EDDH)
Norbert
(EDDH)
Re: Report bugs and issues for the PMDG 737 for MSFS here
1)
The reason for only having 2 states for the Wiper switches is that the Opencockpits OVH hardware panel uses 2-way switches for the Wipers.
User with 4-way switches will need to modify the script.
It is OK with me to share the script for 4 way switches.
2)
The DISCONNECT switches should work OK, Check in IOCPConsole that the correct Events are in use when you use the hardware switch.
It could be that as you do not have the full ELECTRICAL panel implemented in your hardware and that is the cause of the incorrect function you have.
This can be corrected by modifying the script.
3)
As i never owned any OVH-AFT, I never wrote a OVH-AFT script myself, so this script part is an user developed script.
I can't help here, maybe the script developer( I do not remember who did it) can provide some insights. Check in older topics here at the Forum.
4)
Valve outputs from the PMDG are 0: Closed, 1: Opened 2 (dim): In Transit(bright)
The script code for these valves has no brightness control implemented as they only reacts to either a value of 0 or a 1.
The script can be modified if brightness control is wanted. You have then to wire the outputs to Display outputs and not to Led outputs. See image for how to dim.
The reason for only having 2 states for the Wiper switches is that the Opencockpits OVH hardware panel uses 2-way switches for the Wipers.
User with 4-way switches will need to modify the script.
It is OK with me to share the script for 4 way switches.
2)
The DISCONNECT switches should work OK, Check in IOCPConsole that the correct Events are in use when you use the hardware switch.
It could be that as you do not have the full ELECTRICAL panel implemented in your hardware and that is the cause of the incorrect function you have.
This can be corrected by modifying the script.
3)
As i never owned any OVH-AFT, I never wrote a OVH-AFT script myself, so this script part is an user developed script.
I can't help here, maybe the script developer( I do not remember who did it) can provide some insights. Check in older topics here at the Forum.
4)
Valve outputs from the PMDG are 0: Closed, 1: Opened 2 (dim): In Transit(bright)
The script code for these valves has no brightness control implemented as they only reacts to either a value of 0 or a 1.
The script can be modified if brightness control is wanted. You have then to wire the outputs to Display outputs and not to Led outputs. See image for how to dim.
-
- Posts: 44
- Joined: Mon Nov 28, 2022 7:38 pm
Re: Report bugs and issues for the PMDG 737 for MSFS here
Hi Roar,
thanks for early response.
1) please find my wiper modification below. Please feel free to use it, if you want to offer this as an option in your script
I will respond to 2) ...4) later
For left wiper I have replaced Var 0087 of your script by Variables 3000 to 3003 and
for right wiper I have replaced Var 0088 of your script by Variables 3005 to 3008: (Input numbers 32- 35 and 27-30 are my actual assignments and need to be changed for other configurations)
Var 2715, name WIPER_L_C, static
Var 3000, name sWIPER_L_PARK, Link IOCARD_SW, Device 30, Input 32
{
IF &sWIPER_L_Park = 1
{
&WIPER_L_C = 0
}
}
Var 3001, name sWIPER_L_INT, Link IOCARD_SW, Device 30, Input 33
{
IF &sWIPER_L_INT = 1
{
&WIPER_L_C = 1
}
}
Var 3002, name sWIPER_L_LOW, Link IOCARD_SW, Device 30, Input 34
{
IF &sWIPER_L_LOW = 1
{
&WIPER_L_C = 2
}
}
Var 3003, name sWIPER_L_HIGH, Link IOCARD_SW, Device 30, Input 35
{
IF &sWIPER_L_HIGH = 1
{
&WIPER_L_C = 3
}
}
Var 2716, name WIPER_R_C, static
Var 3005, name sWIPER_R_PARK, Link IOCARD_SW, Device 30, Input 27
{
IF &sWIPER_R_Park = 1
{
&WIPER_R_C = 0
}
}
Var 3006, name sWIPER_R_INT, Link IOCARD_SW, Device 30, Input 28
{
IF &sWIPER_R_INT = 1
{
&WIPER_R_C = 1
}
}
Var 3007, name sWIPER_R_LOW, Link IOCARD_SW, Device 30, Input 29
{
IF &sWIPER_R_LOW = 1
{
&WIPER_R_C = 2
}
}
Var 3008, name sWIPER_R_HIGH, Link IOCARD_SW, Device 30, Input 30
{
IF &sWIPER_R_HIGH = 1
{
&WIPER_R_C = 3
}
}
thanks for early response.
1) please find my wiper modification below. Please feel free to use it, if you want to offer this as an option in your script
I will respond to 2) ...4) later
For left wiper I have replaced Var 0087 of your script by Variables 3000 to 3003 and
for right wiper I have replaced Var 0088 of your script by Variables 3005 to 3008: (Input numbers 32- 35 and 27-30 are my actual assignments and need to be changed for other configurations)
Var 2715, name WIPER_L_C, static
Var 3000, name sWIPER_L_PARK, Link IOCARD_SW, Device 30, Input 32
{
IF &sWIPER_L_Park = 1
{
&WIPER_L_C = 0
}
}
Var 3001, name sWIPER_L_INT, Link IOCARD_SW, Device 30, Input 33
{
IF &sWIPER_L_INT = 1
{
&WIPER_L_C = 1
}
}
Var 3002, name sWIPER_L_LOW, Link IOCARD_SW, Device 30, Input 34
{
IF &sWIPER_L_LOW = 1
{
&WIPER_L_C = 2
}
}
Var 3003, name sWIPER_L_HIGH, Link IOCARD_SW, Device 30, Input 35
{
IF &sWIPER_L_HIGH = 1
{
&WIPER_L_C = 3
}
}
Var 2716, name WIPER_R_C, static
Var 3005, name sWIPER_R_PARK, Link IOCARD_SW, Device 30, Input 27
{
IF &sWIPER_R_Park = 1
{
&WIPER_R_C = 0
}
}
Var 3006, name sWIPER_R_INT, Link IOCARD_SW, Device 30, Input 28
{
IF &sWIPER_R_INT = 1
{
&WIPER_R_C = 1
}
}
Var 3007, name sWIPER_R_LOW, Link IOCARD_SW, Device 30, Input 29
{
IF &sWIPER_R_LOW = 1
{
&WIPER_R_C = 2
}
}
Var 3008, name sWIPER_R_HIGH, Link IOCARD_SW, Device 30, Input 30
{
IF &sWIPER_R_HIGH = 1
{
&WIPER_R_C = 3
}
}
Best Regards
Norbert
(EDDH)
Norbert
(EDDH)
-
- Posts: 44
- Joined: Mon Nov 28, 2022 7:38 pm
Re: Report bugs and issues for the PMDG 737 for MSFS here
lets solve the problems one after the other, starting with item 2) of my initial post
2) DISCONNECT switches:
I have checked in IOCPConsole:
When switch value is "1" and I send a switch value "0" directly via the OICPConsole then I can see switch moving (same as if I operate the switch on my hardware) but the drives still don't disconnect.
They only disconnect when I click the switches on the monitor. Really strange behaviour.
After clicking switches the associated annunciators on my hardware (DRIVE / SOURCE OFF / GEN OFF BUS) turn on as expected
ELECTRICAL Panel is completely implemented in my hardware and all other associated switches and annunciators work fine
Any idea or can other user report same problem?
Thanks in avance
Norbert
2) DISCONNECT switches:
I have checked in IOCPConsole:
When switch value is "1" and I send a switch value "0" directly via the OICPConsole then I can see switch moving (same as if I operate the switch on my hardware) but the drives still don't disconnect.
They only disconnect when I click the switches on the monitor. Really strange behaviour.
After clicking switches the associated annunciators on my hardware (DRIVE / SOURCE OFF / GEN OFF BUS) turn on as expected
ELECTRICAL Panel is completely implemented in my hardware and all other associated switches and annunciators work fine
Any idea or can other user report same problem?
Thanks in avance
Norbert
-
- Posts: 44
- Joined: Mon Nov 28, 2022 7:38 pm
Re: Report bugs and issues for the PMDG 737 for MSFS here
Please find my update regarding 4 issues of my initial post below:
1) 4 way WIPER switches: solved by script modification acc. to previous post
2) Generator DISCONNECT Switches: solved now by script modification
Reason for problems: For the DISCONNECT switches I use ON -OFF switches on my hardware acc. to Opencockpits component plan
But PMDG seem to expect a short switching pulse only to disconnect the drives. Emphasis lies on SHORT pulse. That could be done by a (M)ON – OFF (momentary ON) switch, operated for a very short time to disconnect, or by script modification. After some hours and countless trial and errors I figured out the correct time span for that event: command only worked correctly when the switching pulse is between 0,1 sec and 0,6 sec long. 0,7 sec and longer don’t work. So I modified script as explained below:
When left drive disconnect switch (Var 0076) is operated on Opencockpits hardware than we
- send a „1“ to the guard Var 2624 to open (command taken from the original script)
- send a „0“ to the switch event Var 2625
- send a delayed „1“ , delayed by 0,3 sec to the switch event Var 2625 to release after 0,3 sec (30 x 10 ms)
Same modification to be done for right drive disconnect switch (Var 0077, 2626 and 2627)
That works perfectly fine with SIOC DELAY and TIMER function as well. Drives now really disconnect, associated annunciators turn on and drives cannot be connected again within the actual flight (same as in real live, when drives have been disconnected, generators need maintenance before next operation)
@ Roar, if you put this delay command into your script, there should be no disadvantages but script will work for ON -OFF switches and MON-OFF switches as well without further modification
3) OVH-AFT: I can live with actual operation. I will modify script as a „nice to have“ later after further SIOC training
4) Valve outputs dimmed and bright: nearly solved by script modicfication. Valves outputs (annunciators) that have 0 - 1 – 2 state work fine now after adding a SUBRUTINE to change „1“ to „2“ and vice versa
Some other valves outputs only have 0 – 1 states on IOCPConsole, although they have bright and dimmed states on the PMDG OVH. I think I will add 2 sec long transit parts between by using SIOC TIMER or DELAY Function.
Best Regards
Norbert
1) 4 way WIPER switches: solved by script modification acc. to previous post
2) Generator DISCONNECT Switches: solved now by script modification
Reason for problems: For the DISCONNECT switches I use ON -OFF switches on my hardware acc. to Opencockpits component plan
But PMDG seem to expect a short switching pulse only to disconnect the drives. Emphasis lies on SHORT pulse. That could be done by a (M)ON – OFF (momentary ON) switch, operated for a very short time to disconnect, or by script modification. After some hours and countless trial and errors I figured out the correct time span for that event: command only worked correctly when the switching pulse is between 0,1 sec and 0,6 sec long. 0,7 sec and longer don’t work. So I modified script as explained below:
When left drive disconnect switch (Var 0076) is operated on Opencockpits hardware than we
- send a „1“ to the guard Var 2624 to open (command taken from the original script)
- send a „0“ to the switch event Var 2625
- send a delayed „1“ , delayed by 0,3 sec to the switch event Var 2625 to release after 0,3 sec (30 x 10 ms)
Same modification to be done for right drive disconnect switch (Var 0077, 2626 and 2627)
That works perfectly fine with SIOC DELAY and TIMER function as well. Drives now really disconnect, associated annunciators turn on and drives cannot be connected again within the actual flight (same as in real live, when drives have been disconnected, generators need maintenance before next operation)
@ Roar, if you put this delay command into your script, there should be no disadvantages but script will work for ON -OFF switches and MON-OFF switches as well without further modification
3) OVH-AFT: I can live with actual operation. I will modify script as a „nice to have“ later after further SIOC training
4) Valve outputs dimmed and bright: nearly solved by script modicfication. Valves outputs (annunciators) that have 0 - 1 – 2 state work fine now after adding a SUBRUTINE to change „1“ to „2“ and vice versa
Some other valves outputs only have 0 – 1 states on IOCPConsole, although they have bright and dimmed states on the PMDG OVH. I think I will add 2 sec long transit parts between by using SIOC TIMER or DELAY Function.
Best Regards
Norbert
- Attachments
-
- script mod drives disconnect.jpg (98.95 KiB) Viewed 2605 times
Best Regards
Norbert
(EDDH)
Norbert
(EDDH)
Re: Report bugs and issues for the PMDG 737 for MSFS here
Thanks for your findings and good work. I will add these new code in an update to be downloaded here from the Forum.
re: #2
The original code works fine with the PMDG 737 NGXu in P3D, but it seems that thare has crept in a bug or change in the PMDG 737 for MSFS airplane code. Just tested the original code in both P3D and the MSFS and confirm your findings.
re: #2
The original code works fine with the PMDG 737 NGXu in P3D, but it seems that thare has crept in a bug or change in the PMDG 737 for MSFS airplane code. Just tested the original code in both P3D and the MSFS and confirm your findings.
-
- Posts: 44
- Joined: Mon Nov 28, 2022 7:38 pm
Re: Report bugs and issues for the PMDG 737 for MSFS here
Hi Roar,
you are wellcome. Forum lives from helping eachother. You got me back on track by recommanding to watch the IOCPConsole. That was very helpful.
I think, it’s time to contact PMDG now regarding #2 and #4 to avoid further script changes if they have created bugs:
#2: if it is a bug from PMDG they should change, if it is a deliberate change than the script needs to be changed
#4 same for the valve annunciator behavior.
a) For ENG VALVE-, SPARE VALVE- and CROSS FEED annunciators (Var 1067, 1068, 1069 , 1070 and 1073) PMDG uses 0 – 1 – 2 states, where „2“ means „in Transit = bright“ . That works correctly on the PMDG OVH (on the PC Monitor) but Opencockpits IOCard Outs want the other way round
with SIOC : 1 = bright and 2 = dimmed
This can be changed by PMDG in generall or by a script subroutine (see below)
b) For ANTI ICE VALVE- and RAM DOOR VALVE annunciators (Var 1152, 1153, 1156 , 1157, 1177 and 1178) we only can see 0 – 1 states although the PMDG OVH (on the PC Monitor) shows correct dimmed and bright behavior.
By watching state changes on the IOCPConsole I realized that additional Variables 1158, 1159 and 1160 change states in relationship to Variables 1152, 1153, 1156 , 1157, 1177 and 1178.
BUT …
The additional variables change state immediately when switch command send „1“ but there is a 2 second delay when switch command sends a „0“
If PMDG can change to 0 -1 -2 as well for these b) valves, we can use identical sripct modification as on the a) valves
If PMDG want to stick to their 2 variables with "0" and "1" states only, we can use the delayed behavior for a dimmed state during ON -> OFF, but they should also offer a delayed state for OFF-ON as well.
Best Regards and have a nice weekend
This is a script modification for the cross feed valve annunciator with software controlled brightness
Same can be done hardware controlled by using a 10 K Ohm potentiometer - then the V3010 variables are not needed
you are wellcome. Forum lives from helping eachother. You got me back on track by recommanding to watch the IOCPConsole. That was very helpful.
I think, it’s time to contact PMDG now regarding #2 and #4 to avoid further script changes if they have created bugs:
#2: if it is a bug from PMDG they should change, if it is a deliberate change than the script needs to be changed
#4 same for the valve annunciator behavior.
a) For ENG VALVE-, SPARE VALVE- and CROSS FEED annunciators (Var 1067, 1068, 1069 , 1070 and 1073) PMDG uses 0 – 1 – 2 states, where „2“ means „in Transit = bright“ . That works correctly on the PMDG OVH (on the PC Monitor) but Opencockpits IOCard Outs want the other way round
with SIOC : 1 = bright and 2 = dimmed
This can be changed by PMDG in generall or by a script subroutine (see below)
b) For ANTI ICE VALVE- and RAM DOOR VALVE annunciators (Var 1152, 1153, 1156 , 1157, 1177 and 1178) we only can see 0 – 1 states although the PMDG OVH (on the PC Monitor) shows correct dimmed and bright behavior.
By watching state changes on the IOCPConsole I realized that additional Variables 1158, 1159 and 1160 change states in relationship to Variables 1152, 1153, 1156 , 1157, 1177 and 1178.
BUT …
The additional variables change state immediately when switch command send „1“ but there is a 2 second delay when switch command sends a „0“
If PMDG can change to 0 -1 -2 as well for these b) valves, we can use identical sripct modification as on the a) valves
If PMDG want to stick to their 2 variables with "0" and "1" states only, we can use the delayed behavior for a dimmed state during ON -> OFF, but they should also offer a delayed state for OFF-ON as well.
Best Regards and have a nice weekend
This is a script modification for the cross feed valve annunciator with software controlled brightness
Same can be done hardware controlled by using a 10 K Ohm potentiometer - then the V3010 variables are not needed
- Attachments
-
- Annunciator brightness.jpg (68.08 KiB) Viewed 2588 times
Best Regards
Norbert
(EDDH)
Norbert
(EDDH)