Page 6 of 29 FirstFirst ... 234567891016 ... LastLast
Results 51 to 60 of 287

Thread: A320 FMGS B38

  1. #51
    75+ Posting Member anzabon's Avatar
    Join Date
    Apr 2014
    Location
    Moon Base
    Posts
    78
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Tcane is right, theres no auto-update available on all PCs...

    Bon

  2. #52
    25+ Posting Member



    Join Date
    Mar 2014
    Location
    Italy
    Posts
    29
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Hi Jeehell,
    there is no update available so far, when I run the updater, it appears :service under maintanance...
    Ben

  3. #53
    75+ Posting Member anzabon's Avatar
    Join Date
    Apr 2014
    Location
    Moon Base
    Posts
    78
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Hmm, also strange:
    Yesterday I've installed 38.3 and tested a short startup. Worked so far.
    Today I started the hole system like every day... and there seems to be no connection between FMGSServer and FMGS clients any more. But WideFS recognizes all three WideClients.
    All input assignments in iitcreator are correct and able to be tested in iitcreator, so all output assignments are, all poti and switch assignments in FMGSConfig are there and working, network recognizes all PCs with their right IPs, "StarterFSX" brings no error message - but when I choose "ExtPwr" in FSX, there's no light on the Overhead panel, and there's also no light on the virtual OVHD display. Also strange: I cannot move any virtual switch on the OVHD display software. In short: there's power available for the hole system, everything stays dark.
    I have tried three hours without success and don't know what's wrong. I've changed nothing. Any hints?

    Best regards,
    Bon

  4. #54
    25+ Posting Member



    Join Date
    Dec 2012
    Location
    Switzerland
    Posts
    61
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Hi Bon
    I had the same behavior today with one of the two clients. Then I started the client software as administrator. And it worked - like discussed many times here. Have you tried this?
    Regards
    Adrian

  5. #55
    75+ Posting Member anzabon's Avatar
    Join Date
    Apr 2014
    Location
    Moon Base
    Posts
    78
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Hello Adrian,
    yes, I know this behaviour and I always start all software parts as administrator. BTW: the hole system is Win7.
    But many thanks for your input. I remember that this special problem also occured in B37.4 when I've implemented the PDF, ND and EWD/SD dim poti control via hardware (FDS FC-1 card). When I disconnected all the dim potis from all three FC-1 cards, it worked again. Maybe this is the same issue in B38.3 but I have to test that yet. Now I have to work. I don't think it's a problem in FMGS but with the FC-1 card connection via hardware connect. Mysterious. Will reply.
    Best regards,
    Bon

  6. #56
    2000+ Poster - Never Leaves the Sim


    OmniAtlas's Avatar
    Join Date
    Jun 2012
    Location
    Sydney, Australia
    Posts
    2,107
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    B38.3 -- no TCAS alerts on IVAO for some strange reason even with TCAS TFC set to ALL, TCAS mode to TA/RA.

    Traffic shows up on IVAP client internal TCAS.
    Soarbywire - Airbus Flight Simulation and Engineering | Jeehell FMGS - Free professional A320 avionics software for the cockpit enthusiast.


  7. #57
    150+ Forum Groupie
    Join Date
    Aug 2013
    Location
    eddn
    Posts
    210
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Hallo Jl, Hallo Guys,

    Got some similar issues like the other guys. Start again a one hour trip, after 20 minutes the Hardware FCU (Connected on a OC Mastercard with SIOC) stop to work. Recognized no inputs or outputs. It seems to be, thats are the same or similar issue like Bon... respectively my problem with no working OC Card some time ago... In the last version the problem has gone...

    With the non-function autoupdate was already mentioned.
    Off course i start all clients and server as admin!

    King regards
    Florian

  8. #58
    25+ Posting Member



    Join Date
    Dec 2012
    Location
    Switzerland
    Posts
    61
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Hello everybody

    Today, I flew two legs (LSZH-LSGG-LSZH) with B38.3. And now I also discovered the 'disconnection problem' as reported here as well. I was running two clients. Only the client with PFD, ND, and MCDU on it disconnected twice. The other client with EWD, SD, standby instruments, and HW drivers for FDS and Skalarki never disconnected.

    Here are some extracts from the logs I attached.

    I started the simulator on 17:10:03 as can be seen in log logNDB.txt
    Code:
    *17:10:03* Navdata module launched Server
    *17:10:03* 
    *17:10:06* 
    *17:10:06* Navdata1:
    *17:10:06*  -ARPTliste:15336
    *17:10:06*  -NavaidListe:18198
    *17:10:06*  -FIXliste:183324
    *17:10:06*  -AWYsegments:97152
    *17:10:06*  -MarkerList:2545
    *17:10:06* 
    *17:10:06* Navdata2:
    *17:10:06*  -ARPTliste:15165
    *17:10:06*  -NavaidListe:18211
    *17:10:06*  -FIXliste:180118
    *17:10:06*  -AWYsegments:96338
    *17:10:06*  -MarkerList:2574
    *17:10:06* 
    *17:10:06* server started on port:8006
    ...
    Then I started the 'PFD/ND/MCDU' client SW (IP 192.168.1.91) without 'administrator rights'. According to the logNDB.txt the client connected but then an error occurred and it disconnects as shown below:
    Code:
    ...
    *17:10:49* Client connected:    192.168.1.91
    *17:10:50* Client connected:    192.168.1.91
    *17:11:01* Client Disconnected: 192.168.1.91
    *17:11:02* Client error 10053
    *17:11:02* Client Disconnected: 192.168.1.91
    ...
    I stopped the client SW and restarted the SW with administrator privileges. I also started the 'Standby/HW' client (IP 192.168.1.93) with administrator privileges. Then the logNDB.txt shows this:
    Code:
    ...
    *17:11:13* Client connected:    192.168.1.91
    *17:11:22* Client connected:    192.168.1.91
    *17:11:26* Client connected:    192.168.1.91
    *17:11:48* Client connected:    192.168.1.93
    
    ...
    On the WideFMGSserver screen only the connection of the clients started with administrator privileges are visible. Following the extract:
    Code:
    WideFMGS server Log.
    port 8003:192.168.1.91 connected
    port 8004:192.168.1.91 connected
    port 8005:192.168.1.91 connected
    port 8003:192.168.1.93 connected
    port 8005:192.168.1.93 connected
    port 8004:192.168.1.93 connected
    After more than one hour of flying (it happened during takeoff in LSGG), the 'PFD/ND/MCDU' client stopped working. All three displays were 'frozen'. So I stopped the client SW and restarted it with administrator privileges. The logNDB.txt shows the following entries:
    Code:
    ...
    *18:21:08* Client Disconnected: 192.168.1.91
    *18:21:09* Client Disconnected: 192.168.1.91
    *18:21:09* Client error 10053
    *18:21:09* Client Disconnected: 192.168.1.91
    *18:21:25* Client connected:    192.168.1.91
    *18:21:37* Client connected:    192.168.1.91
    *18:21:39* Client connected:    192.168.1.91
    ...
    Please note that the client error reported (10053) is exactly the same one as when I started the client SW without administrator privileges.

    And the WideFMGSserver shows this:
    Code:
    ...
    port 8003:192.168.1.91 disconnected
    port 8004:192.168.1.91 error
    port 8004:192.168.1.91 disconnected
    port 8005:192.168.1.91 disconnected
    Fpln OnError
    port 8003:192.168.1.91 connected
    port 8004:192.168.1.91 connected
    port 8005:192.168.1.91 connected
    ...
    The next client communication problem of the 'PFD/ND/MCDU' client was after 20 minutes. So the time was much shorter between the 1st and the 2nd crash than between the initial start and the 1st crash. The following extract shows the rest of the logNDB.txt entries:
    Code:
    ...
    *18:40:12* Client Disconnected: 192.168.1.91
    *18:40:12* Client Disconnected: 192.168.1.91
    *18:40:12* Client error 10053
    *18:40:12* Client Disconnected: 192.168.1.91
    *18:40:28* Client connected:    192.168.1.91
    *18:40:38* Client connected:    192.168.1.91
    *18:40:42* Client connected:    192.168.1.91
    *19:00:02* 
    *19:00:02* Module stopped normally

    And the corresponding entries of the WideFMGSserver log:
    Code:
    ...
    port 8003:192.168.1.91 disconnected
    port 8004:192.168.1.91 error
    port 8004:192.168.1.91 disconnected
    port -1: error
    port 8005:192.168.1.91 disconnected
    Fpln OnError
    port 8003:192.168.1.91 connected
    port 8004:192.168.1.91 connected
    port 8005:192.168.1.91 connected
    I also have to mention that my 'PFD/ND/MCDU' client runs at 100% CPU (which seems normal according to the discussions I followed). Hence, it may not have enough CPU time to run the communication 'on-time' (this is my speculation ). The 'Standby/HW' client has the same HW as the 'PFD/ND/MCDU' client, but the CPU runs at 40-60% only. Therefore, it might be interesting to here from you all, if only the 'max CPU' client disconnects or if it happens to 'any' client.

    I apologize for the very long report. But I hope that this can help to sort out the root cause of the communication problem. Many thanks to all of you for being so active in this forum!

    Adrian
    Attached Files Attached Files

  9. #59
    150+ Forum Groupie


    Miatanet's Avatar
    Join Date
    Dec 2011
    Location
    Switzerland
    Posts
    206
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Hi all,
    I just come back from a short test flight after updating to the latest version and I flew from LSGG to LSZH without any issues, no disconects, all went fine and was exciting as always. Thank you again JL for that outstanding software.
    Using Skalarki HW and FSX with four PC systems.

    Best regards
    Stefan

  10. #60
    2000+ Poster - Never Leaves the Sim
    Join Date
    Mar 2008
    Location
    France,Nice
    Posts
    2,652
    Contribute If you enjoy reading the
    content here, click the below
    image to support MyCockpit site.
    Click Here To Contribute To Our Site

    Re: A320 FMGS B38

    Hi Buentead (and the others with disconnects...)

    It's possible that too much CPU strain could make the client disconnect .This is to "save" the server from waiting too long transmitting data it removes the lagging client, otherwise the whole network would suffer lag. I'll try to increase the delay before it "cuts" the connection.
    I can't say much more than sizing the computer correctly to run the PFD and ND which are heavy CPU users.

    You can try to reduce the PFD/ND loads by adding these 4 lines in the PFD.ini and ND.ini files (put the 4 lines in the 2 files, do not put the ND lines only in the ND.ini...):
    PFDminDelay=0.1
    PFDmaxDelay=0.3
    NDminDelay=0.1
    NDmaxDelay=0.3

    (the default values are 0.04 and 0.2)

    You should also refrain from using the EGPWS as it adds CPU usage.
    A multi core CPU is best (ideally core i7 or similar...).

    Regards,
    JL

Page 6 of 29 FirstFirst ... 234567891016 ... LastLast