Conversation
In production mode, if connection could not be established, the system was endlessly looping trying again.
The connection is only established at MPF startup, should we later loose the serial port for some reason, the system would not
re-establish the connection by itself. Therefore, it is better to exit MPF should the connexion not be established, and manage a restart externally.
In case of a problem with a serial port, the warning message clearly indicates the faulty port.
In case of MPF shutdown due to comm failure, do not try to close the faulty connection which is already in the closing state (avoid cascading exception).
Regarding OPP platform:
- in the rare case where there is only one device, do not treat it as special case regarding serial
- if device does not report a serial number, default it to #0
- _poll_sender (opp.py):
- optimize for speed
- send pool before waiting response
- logs port name and serial number attached
|
|
Don't understand what's wrong with the faulty check. |
|
The failing test looks like a random disconnect from the CI process, probably nothing to worry about. The OPP changes make sense, but could you fill in the PR description with clarification about why you're removing the production-mode retry of serial connections? That can be useful for on-location machines if the serial boards have a slow startup. |
Done |
|
Since this is breaking current behavior, it would be ideal to have a config option to configure how MPF should behave on serial disconnect. If production mode should behave differently, then a separate config for that. Thanks for working on this! |
2 participants
Improves serial communication behaviour in case of error
Serial connection is only established at MPF startup, should we later loose the serial port for some reason, the system would not re-establish it by itself and exits.
Therefore, there ought to be an external mechanism (bash script) to manage the situation, for instance trying to reset serial port, restart MPF or at last resort rebooting.
In production mode, if connection cannot be established, the system is endlessly looping trying again. This can lead to a blocking situation. This PR removes this loop.
Other improvements:
In case of a problem with a serial port, the warning message clearly indicates the faulty port.
In case of MPF shutdown due to comm failure, do not try to close the faulty connection which is already in the closing state (avoid cascading exception).
Regarding OPP platform: