Tcane is right, theres no auto-update available on all PCs...
Bon
Printable View
Tcane is right, theres no auto-update available on all PCs...
Bon
Hi Jeehell,
there is no update available so far, when I run the updater, it appears :service under maintanance...
Ben
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
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
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
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.
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
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
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: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
...
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: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
...
On the WideFMGSserver screen only the connection of the clients started with administrator privileges are visible. Following the extract: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
...
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: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
Please note that the client error reported (10053) is exactly the same one as when I started the client SW without administrator privileges.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
...
And the WideFMGSserver shows this:
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:...
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
...
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:
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 :wink:). 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.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 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
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
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