Jump to content

XPJavelin

Business class
  • Posts

    14
  • Joined

  • Last visited

Posts posted by XPJavelin

  1. Hi,

     

    Some years ago, I wrote a small book which contained the following schematics, in order to better explore the 737 electrical services as modeled by different flight simulation producers in P3D and X-Plane.

    Electricals737.jpg.2b4bccade03e01b8aa4cfa35c7f14b3d.jpg

    So I've fired up the Level Up and tried to re-apply my exploration steps (basically a set of non-normal procedures) to this model and see how it goes.

    Step 1, study the STANDBY-BUS (AC, DC)

     

    I do :

    STANDBY POWER SWITCH .... BAT
    SWITCH DC-BAT : ON
    SWITCH STANDBY POWER : BAT
    SWITCH BUS TRANSFER : Checked in AUTO.

    Placing the STANDBY POWER switch on BAT, makes the standby AC BUS powered from the BAT using the STATIC INVERTER. It also makes the DC STANDBY BUS powered from the Battery.

    The STDBY ALT VIBRATOR (of the analog standby gauges) should be heard (TtTtTtTtTtTtTt....) because this service is powered by the DC STANDBY BUS. This is not the case in the LevelUp at this point.

    IN the level up, by contrast to the IXEG and the PMDG, the vibrator only sounds when an AC source is plugged in as if the DC STBY BUS was only powered through an AC/DC transformer, or as if the vibrator was powered by a wrong bus.

     

    Other services looks good (like IRS1, NAV1, RIGHT ENG INIGITERS...)

     

    Step 2, study the HOT BAT BUS (DC)

    With the battery switch to OFF, I've found that the FUEL SHUTOFF VALVE is governed by the HOT BAT BUS, which is great. (I can shutoff engines with BATT OFF).

    ENGINE #2 .... start an engine fire in the simulator

    There is no master caution nor ring bell as expected since they are only powered by the BATTERY BUS. However we should have the engine fire handle 2 illuminate. But we don't have it in the level up. (Checked in the PMDG, in the IXEG). Extinguishers are on the HOT BAT BUS.

    That should allow the end of the procedure, even with the BATT switch to OFF.
     

    FIRE HANDLE #2 .... PULL AND ROTATE ONCE
    FUEL CUTOFF #2 .... CUTOFF

    Step 3, study the BAT BUS (DC), and the SWITCH BAT BUS (DC)

    Battery (BAT) Switch
    OFF –> removes power from battery bus and switched hot battery
    bus when operating with normal power sources available

     

    So I have applied that proedure below to ensure the aircraft keeps an AC source (the GPU here) but deenergize the BAT BUS. 

    GPU .... CALL AND MONITOR CONNECTION
    EXTERNAL POWER .... CONNECT TO AIRPLANE ELEC. SYS.
    
    APU .... START (don't connect it)
    
    BATTERY SWITCH ... OFF

    In the LevelUp, APU CONTROL (SW HOT BAT BUS) is now failed as shown by the (expected) shutdown of the APU. 

    However, the first officer displays fail also.  As they are powered by the DC BUS 2 thanksfully to the tAC/DC transfomer TR 2 from the current AC source, that should not happen.

    The VHF1, NAV1 set of instruments are now black, but it looks incorrect as those are powered by the DC STANDBY BUS. Which should be powered from the TR1 from our AC source.

    However, the STDBY ALT VIBRATOR (of the analog standby gauges) is still heard as expected but we already show the noisy vibrator cannot be use as an electricla state witness in the LevelUp (because in the LevelUp it always sounds as soon as an AC source is connected, while IRL it sounds when the DC STDBY BUS is powered - that's different).

    Step 4, study of the safeguard or AC/DC TR3 by the AC TRANSFER BUS 1 , using the TR3 transfer relay (737NG only)

    So we start both engines, connect their AC generators, remove the GPU, disconnect the APU (naturally)

    then :

    GEN 2 .... OFF

    Results are

    TR2 is 29 Volts before GEN 2 OFF and drops to 0 Volts after. Is Ok, since the parent bus is dead.

    TR3 is 29 Volts before GEN 2 OFF and drops to 0 Volts after . Is is not OK in a B737NG, since it should be rescued by the TR3 transfer relay and linked to a new parent( AC TRANSFER BUS 1.)

     

    The same happens when I fail the AC gen 2 source using X-Plane failures menu.

    Step 5, combined loss of TR2 and TR3 : loss of DC BUS 2

    Now at this time, I usually continue to be mean with my 737 and fail the TR3 on top of the previous failure, in order to isolate the effect of the loss of DC BUS 2, (but keep BAT BUS, from the BATTERY in this configuraiton)

    ADD A FAILURE OF TRU 3

    unfortunately, this seems not possible in X-Plane failure menu. Expected results are the failure of the right hand side windshield wiper as a witness of the loss of the DC BUS 2. (not possible to try in the LevelUp).

    Step 6, explore differential services powered by DC BUS 1 on the one hand and DC BUS 2 on the other hand

    At this step I isolate the left hand side from the right hand side. I use the following procedure.

    Establish an normal electrical state on AC APU electricity, both side connected.
    
    BUS TRANSFER .... OFF

    BUS TRANSFER OFF isolates the AC sides (cancel BTBs), as well as the DC sides ( cancels DC cross tie). BUS TRANSFER SWITCH OFF also disables the TR 3 Transfer relay that allows AC Transfer bus 1 powering TR 3 in the event of an AC Transfer bus 2 failure.

     

    Step 6.1 : explore right hand side DC services

    APU .... STARTED AND ON BUS
    BUS TRANS .... OFF
    APU GEN 2 (RIGHT) .... OFF

    image_2022-01-15_202916.png.903d2a37b8aa0b61d53c2fbb377cdd26.png

    SOURCE OFF and TRANSFER BUS OFF light up. Good.

    However, the TR2 is at 0 amps and 0 volts before and after the right source disconnection, so the AC/DC transformers need a little work. We should see a plain functional TR2 before the disconnection and a drop to 0 V/0A after it.

    This works in the PMDG and the IXEG. Here, it's not clear.

    Whatever, a simple test is to press the MACH WARNING SYSTEM 2 on the overhead, it should not ring as it is linked to the DC BUS 2. Here it does ring. CABIN DOOR LOCK should also fail. Good news : the right hand side wiper fails.

    Step 6.2 : explore left hand side DC services

    APU GEN 2 (RIGHT) .... ON
    APU GEN 1 (LEFT) .... OFF

    TR1 DC Amps drops to zero A, that's great.

    The left hand side wiper freeze. Great.

    Step 6 summary : the TR2 and TR3 need some work but TR1 is OK.

    Step  7, effect of BUS TRANSFER reestablishment

    BUS TRANSFER .... AUTO

    TR1 measurements go back to normal voltage and amperage and the left hand side wiper unfreeses. Good. DC BUS 1 power is reestablished.

    Step 8, study of the DC BUS TIE, downstream the TRs.

    image_2022-01-15_213855.png.00e96ef0b11330aaedfe03274f510989.png

    After an airrcaft reload to ensure every past failures are cleared,,

    the idea is to fail the TR1 to restore the power in DC BUS 1 from DC BUS 2 via the  DC TIE BUS. However it's ot possible to fail the TR1 to conduct the test.

    Conclusion : the backbone of the electrical architecture of the 737 is essentially present in the LevelUp737, but it's simplified and I struggle reading TR2&3 amperage and voltage reacting to several experimental conditions. (More)

  2. Hello in the case of Fail Operational aircraft, the C/R button is missing on the front panel, near ENG and SUS buttons.

    Months or years ago I made the same remarks to Zibo and it was added to the Zibo 738 but it is missing here in the Level Up, that is is is only realistic to make our levelUp 737 CATIIIa fail passive only ATM.

     

    Best regards

  3. 2 hours ago, flyexp3 said:

    Could you confirm you have not a running real-time security scan tool

    Unfortunately I cannot disclose such information.

    2 hours ago, Stuart_737 said:

    I moved the folder and all is working fine.

    I elected to edit the suspicious script based on this report instead. I was not going to move the Gigantic X-Plane folder and break all my home cockpit dependencies.

    At line 224 : commented and replaced by manual flie path.

    --xplane_file_path            = find_dataref("zibomod/Xplane_Path")
    xplane_file_path = "/opt/X-Plane/X-Plane 11/"

    it seems the problem is gone with that change.

    This seems magical since the Zibo file in their script also has the same line, at line 220 in their version of the lua script.

    I don't CTD anymore but of course, the bug cannot be marked as solved or close unless devs investigate.

    You are welcome for the help.

     

    • Like 1
    • Thanks 3
  4. I appreciate your help and effort here to support me and people on the forum.

    I'd like to emphasize that I did spend some time to help you narrow down where a potential problem layed, and narrowed it to this script.

    The same xlua and zibomod plugins work together well in conjunction in the Zibo738X not in the LevelUp.

    From that point, I'd expect the LevelUp Team to review their code, I mean, on their side, which would seem a better search&resolution pattern given the information already gathered for you.

    Maybe it's a detail, a file with an incorrect case, as Linux is case sensitive. But I'll let to other the dig into the xlua script.

    • Like 1
  5. Removig the plugin folder "zibomod" solves the crash (of coursse the ACFT is inoperative).

    When I try to copy the zibomod folder from my original Zibo 738 installation into the levelup, the same logfile is produced.

     

    Running the Zibo738X; no problem and XP11 reports as well :

    Zibomod plugin running.
    Zibomod plugin: Reading navigation data...
    Zibomod plugin: Loaded file >/opt/X-Plane/X-Plane 11/Custom Data/earth_nav.dat<
    Zibomod plugin: Loaded file >/opt/X-Plane/X-Plane 11/Custom Data/earth_fix.dat<
    Zibomod plugin: Loaded file >/opt/X-Plane/X-Plane 11/Aircraft/Airliners/B737-800X/B738X_apt.dat<
    Zibomod plugin: Loaded file >/opt/X-Plane/X-Plane 11/Aircraft/Airliners/B737-800X/B738X_rnw.dat<
    Zibomod plugin: Loaded file >/opt/X-Plane/X-Plane 11/Aircraft/Airliners/B737-800X/B738X_gate.dat<
    Loaded: /opt/X-Plane/X-Plane 11/Aircraft/Airliners/B737-800X/plugins/zibomod/lin_x64/zibomod.xpl (zibomod.by.Zibo).

     

    Now if I remove the xlua folder but keep the zibomod folder, crashes is solved (but ACFT inoperative of course).

     

    My conclusion is the interaction with the plugin Zibomod and your architecture is where is located the problem.

     

    I remove all xlua script folders and putting them one by one again

    B738.a_AXP_1_EQ_commands
    B738.a_AXP_2_flightcontrol_commands
    B738.a_AXP_3_FMOD_commands
    B738.a_AXP_4_FMOD_logic

     

    so far so good

     

    and then 

    0:19:20.166 E/SYS: THREAD FATAL ASSERT: "::pthread_mutex_destroy" OS error
    0:19:20.166 E/SYS: THREAD FATAL ASSERT: err=16.000000
    0:19:20.166 E/SYS: THREAD FATAL ASSERT: 
    0:19:20.166 E/SYS: THREAD FATAL ASSERT: 
    0:19:20.166 E/SYS: THREAD FATAL ASSERT: /jenkins/design-triggered/source_code/app/X-Plane-f/../../core/thread/UTL_thread.cpp:302

    happended when I added the folder

    B738.anav

  6. X-System folder:'/Ubuntu/X-Plane 11/', case sensitive=1
    0:02:42.719 E/SYS: THREAD FATAL ASSERT: "::pthread_mutex_destroy" OS error
    0:02:42.719 E/SYS: THREAD FATAL ASSERT: err=16.000000
    0:02:42.719 E/SYS: THREAD FATAL ASSERT: 
    0:02:42.719 E/SYS: THREAD FATAL ASSERT: 
    0:02:42.719 E/SYS: THREAD FATAL ASSERT: /jenkins/design-triggered/source_code/app/X-Plane-f/../../core/thread/UTL_thread.cpp:302

     

    Log_LU.txt.zip

×
×
  • Create New...

Important Information

Please read the Terms of Use