Strange behaviour

[Gary Oliver]

Just a plus one to say this <FMC prompt missing happens to me too with multiple clients, all fine on a single PC with no clients. 

I have personally never seen the client connection issue, however I only run 2 simstack boards.  In a friends simulator with many simstack boards we had issues where PSX server and clients get into a state where they will not connect unless you follow the actions you did above.   Note: I am not saying its a problem with Simstack or PSX, but a commonality to you.

Cheers
G

[B747-400]

I have 11 SimStack Foundation boards with lot of I/O modules stacked on, and > 700 I/O wires connected (GND not counted  ). As well as lot of addons working together. All in all, the whole sim runs stable, and I'm more than happy!

Still digging into the "shutdown issue". I found out, that when I do the shutdown drill on PSX server with the mouse and the PSX graphical interface, all works as expected.

As soon as I do the same drill with genuine HW and SimStack, the menioned "shutdown issue" occures, sync lost etc.

Cheers
Hans

[Gary Oliver]

Interesting so there must be something in common that both my friends are sending to PSX and you are when you run the shutdown which is sending something invalid to PSX breaking it?

[B747-400]

Yeah, that need to be investigated indeed!

What I recognizes so far is: as soon as I use CutOff sw. 1, it seems to start acting wired. When I use my HW switches, but CutOff 1 with the mouse, all seems to work stable. Just preliminary info - but I could reproduce this two or three times.

I'm out over the WE, but next week I will dig deeper.

Cheers
Hans

PS:
Who needs Sudoku? We have our sims ...      

[asboyd]

The only thing I have connected are screens.
If I connect the FMC's keyboards via PSXSeecon (Opencockpit interfaces) it also happens.
It seems as though it is only when the clients connect to the server.
All clients load a cold and dark situ by default... then once the server starts they receive the CnD info from it (ie location, etc)
I switch on Battery, activate external power (connected via situ) and once the screens come alive, they show FMC on L2 for a second or two, then it disappears.
If I switch the FMC selector switch (above the top EICAS screen) to any option and back, then it reappears and all is normal.
If a go to the client PC and open a layout on the main screen, and power up the aircraft without connecting to the server everything is good.

Cheers,
AlexB

[Hardy Heinlin]

I can reproduce CDU display refresh problem sometimes, about once in 10 attempts. I'm not sure whether it's related to the client connection; it could be pure coincidence due to CPU load rather than due to network messages. When I load an inflight situ and then the cold & dark situ, and if the problem occurs then, the CDUs show the displays of the previous inflight situ instead of the MENU pages. I conclude, when the FMC prompt is missing, it just displays the MENU of the last situation which may be a cold & dark situation with an intentionally missing FMC prompt. I.e. it's not an FMC prompt problem but a problem that doesn't overwrite the last stored CDU displays, no matter whether they showed the MENU or the LEGS or NAV RAD etc.

Does anybody know a sim handling procedure that demonstrates the problem on every attempt?


|-|ardy

[B747-400]

I checked it on three different systems (one newly installed just 4 testing) ... and can reproduce client/server <FMC behavior each time, and how often I want.

Mentioned sending Qs64 and Qs92 with __ etc.

No difference, if system is started first time or when new situ loaded.

I can do more tests to check as per your procedure, but I'm out until Mo.

Cheers
Hans

[Hardy Heinlin]

OK, I just found the bug and fixed it.

In the FMS there's a resync timer that syncs FMC L and R. When the timer reaches zero it regenerates display string #1 on CDU L and R. This function is supposed to run on the server only. The bug was that the string regenerator wasn't inhibited on clients. Clients don't have the required data to regenerate that string, so they just blank that string and send it into the network. At random, when any client is a nanosecond faster than the server, the client's blank string #1 will overwrite the server's good string #1. Now they can't do this anymore. Bugger off, bug.


Regards,

|-|ardy

[B747-400]

That sounds great!

I think we all can not imagine the complexity of PSXs "behind the scenes".

Thanks for your update, Hardy!

Cheers
Hans

[Hardy Heinlin]

That bug fix is now available in PSX update 10.173:

https://aerowinx.com/board/index.php/topic,4191.0.html


Regards,

|-|ardy

[asboyd]

Thank you Hardy will try it out as soon as I can.

Cheers,
AlexB