www.flightsim4fun.com - rksoftware

Hi Roar,
although I have different hardware I can confirm Ian's #7: NO INNER ENCODER DIGITS FUNCTION on COM Radio (I have the USB Version of Com Radio, used separately, not in the OC Pedestal)

It is strange:.
- when I only connect NAV Radio + Com Radio and use original 6.2 script, then inner encoder digit function works fine (no hardware issue)
- when I do little changes on 6.2 script (e.g take out FO's COM and NAV commands for devices 18 and 19, to make script more slim) then I have the same result as Ian on COM Radio
- when I leave script unchanged regarding device 18 and 19 commands but connect OVH-FWD and do only assignment changes -> all OVH inputs and outputs work fine, but lights Test does not work correctly and Com Radio shows a.m. behavior

When I use 6.3 script, lights test turn out worse than with script 6.2

My conclusion: PMDG must have included some changes in 737 for MSFS 202 compared with previous versions. Script may have worked fine for years without issues but it definitely doesn't work 100% fine with the new PMDG 737 for MSFS 2020

I think, most of the script logigc single sections work fine with the single devices, but the complete script seem to produce conflict between different devices. When I do a lights test, the main battery switch turns off and then a chain of events follows. And YES, I have double checked each switch assignment and there is no numbering mismatch between the script and the hardware.

Up to now I have only suspected that something is wrong with the El-STATES, as they also change when I do the lights test. As you already stated :
Maybe parts of the script code need to be revised and made more simple for the new PMDG 737 for MSFS 2020

I will do some more tests with different hardware combinations and use the driver with tracing function. That will take some time. I will let you know results when I have finished tests

Best Regards
Norbert

although I have different hardware I can confirm Ian's #7: NO INNER ENCODER DIGITS FUNCTION on COM Radio (I have the USB Version of Com Radio, used separately, not in the OC Pedestal)

It is strange:.
- when I only connect NAV Radio + Com Radio and use original 6.2 script, then inner encoder digit function works fine (no hardware issue)
- when I do little changes on 6.2 script (e.g take out FO's COM and NAV commands for devices 18 and 19, to make script more slim) then I have the same result as Ian on COM Radio
- when I leave script unchanged regarding device 18 and 19 commands but connect OVH-FWD and do only assignment changes -> all OVH inputs and outputs work fine, but lights Test does not work correctly and Com Radio shows a.m. behavior

Both 6.2 and 6.3 work fine for all Pedestal modules in my cockpit setup.
There are no changes in the script for the Pedestal modules between 6.2 and 6.3.

So to me this looks rather strange. I believe you are doing something wrong.

Why change the script? I am not going to response to issues that occurs when changes are made to the scripts.

Roar,
I completely understand and agree that you will not respond to issues when changes are made to the script. That should indeed be our own responsibility.

I did the changes for an own short test and returned to unchanged script directly after.

I only wanted to confirm that I have identical issue on COM Radio as Ian reported, independent if script was changed or not

My understanding:
Ian has (among other) Lights Test and COM-Radio problems with his Pedestal
I have Lights Test and Com Radio problems only when I connect my OVH. I don’t have a Pedestal!
Some of our problems are identical or similar

So I have to concentrate on the device 30 section (OVH) of the script.
I will do all further tests now with original unchanged script. The only modifications need to be assignment changes of OVH- inputs and outputs, neccessary to avoid numbering mismatch between script and hardware. No changes on other script sections, no changes of any script logic.

I will repeat all tests in a methodic procedure tracing everything with your new driver and with SIOC Monitor to circle the problem
I hope to find out
- Is there a hardware combination that leads to problems
- What assignment change leads to what problem
- What command leads to what problem

I will report findings after I have finished and double-checked all tests (what can take some time)

Best Reagrds
Norbert

Norbert,

when you test without OVH, do you disconnect USB and delete the MASTER line for the OVH in PMDG B737.ini?

Yes,
when I test without OVH, then I diconnect the USB device physically and do a new Airplane configuration on the Oi4FS Configuration page to make sure that only hardware is listed in the ini. file that is actually connected.

I do this each time after I have connected or disconnected OC devices - no problems so far.

Before next test I will additionally have a look into the PMDG B737.ini to see if everything is ok.

Norbert,

Not sure this has been communicated in this thread earlier.

Another thing to check is that if you have a self built module(OVH or another module) and not all swithces are connected in the hardware, these switches MUST be disabled in the script, otherwise wrong inputs can be sent to the driver.

mvr1918 wrote: ↑Wed Dec 21, 2022 9:20 am
Which script are you using?

To dig into these issues you should :

1) with SIOC Monitor find the input and output numbers of your Pedestal buttons, switches, leds and displays.
2) Check these numbers with the numbers used in the script.

I believe all script logic are OK as it has been used for years without any issuses reported and that the issues are all related to numbering mismatch between the script and the hardware.

This documents gives the correct numbering plan for a factory built Pedestal. This numbering plan is also used in the PMDG 737 v6.3P script,

https://1drv.ms/b/s!AjRjRKdTF9fGg-g7n1K ... A?e=gWeTcf



I had a brief look and checked that the correct number are used in the 6.3P script .Use Oi4FS script to check number in the most easy way.

I'm using v6.3P which is your most recent script. For the record, the only thing in it that I've changed is to support the older type FWD_OH that has 2 servo cards, from Device 37 to Device 38 (where applicable). This change is based on your instructions (different post).

I will test the pedestal again and see what happens, but all my OC hardware is built by them, with no alterations. I've had it many years and done enough testing with SIOC monitor to know that all inputs & outputs are numbered correctly.

Regards.

Roar,
that may be my problem. I have a self built OVH. Actually there are only 6 switches, that I don't have connected:

"SPOILER A" and "SPOILER B" on the FLT CONTROL panel
"VHFNAV", "IRS", "SOURCE" and "CONTROL PANEL" on the NAVIGATION / DISPLAY panel

All other switches, annunciators and displays are connected and work fine (except the lights test)

Please advise what is the best way to disable a switch in the script, when the switch is actually not present or not needed

I have simply deleted the associated lines in the script - maybe that was wrong

Example:
I haven't connected "Spoiler A" (Var 0049), consequently I deleted the lines as listed below:
Var 2705 (PMDG Spoiler A guard)
Var 2706 (PMDG Spoiler A Switch)
Var 0049 (OC Hardware Spoiler-A Switch)

Is this correct procedure or is there a disabling procedure without deleting lines?

Thanks
Norbert

Use // at the beginning of the line to disable it.

This was written some time ago and is on the www-flightsim4fun.com


The scripts for the PMDG 737 airplanes that come with OC4BAv5 and Oi4FS's PMDG 737 driver work with Opencockpits’ ready built P&P modules
CHRONO-Captain, EFISCaptain, MCP, EFIS-FO, CHRONO-FO, FMC-Captain, FMC-FO, COM1, COM2, NAV1, NAV2, ADF1, ATC, AUDIO1, AUDIO2 and OVH-FWD, OVH-AFT, MIP and PEDESTAL without any need for modification.

This script should be used if no modification is needed or serve as a base if modification is needed.

When is script modification needed?
1. If you have built any of the above listed modules based on Opencockpits IOCARDs and the connection numbering scheme is different than the default numbering scheme that is used in Opencockpits built modules.
2. If you have any of the modules listed below, either Opencockpits built modules or own built modules based on Opencockpits IOCARDs.
3. If you have any COM1, COM2, NAV1, NAV2, ADF1, ATC, AUDIO1, AUDIO2 modules using the IDC interface. The needed modifications are easy to do with the OC4BAv5 and Oi4FS Script Edit function. You only need to change the input, output and display connection numbers.

In case 3 above, you also need to modify the script so it uses Device 32 for any IDC connected modules. If your own built modules are not complete, there can be issues like “jumping” switches or modules that do not work correctly. You must then make modifications to the script to get rid of these issues. Disable none used inputs by inserting a "//" at the beginning of the script line of the input causing an issue.
This is done to the script .txt file and followed with a compilation to a script .ssi file.

PEDESTAL*
If IDC interface is used and not P&P modules for the COM, NAV etc., Device 32 must be used and inputs and outputs connection numbers changed to default PEDESTAL or your own numbering scheme.

All Servos needs to be calibrated and if needed the script must be modified.



If you have any issues with the scripts, visit the Forum and explain the issue in detail and support will be given.

Check out some Youtube videos here at my Youtube channel: https://www.youtube.com/user/roarkr51/videos
​

See viewtopic.php?p=4278#p4278


All users that report bugs should be running the new 6.4 script + PMDG 737 driver.