Develop WiThrottle Integration plan

[dcc-ex]

Develop WiThrottle Integration plan

[mstevetodd]

My initial thoughts on your list:

intercept the Turnout aspects of Withrottle to call into the TPL layout handling.

As long as the server sends a list of turnouts and state updates, it can define and use them however it wants.

Intercept loco acquisition so that it cant steal a loco TPL is animating.

Client waits for Mx+ response to its Mx+ request. So server can simply choose not to respond, or (better) send only a message explaining the issue.
-OR- (better?) Server can reply with Mx+, but then ignore any speed/direction requests while server is in control.

Use Routes to allow ED to send a loco onto a TPL route.

Same as turnouts, client does not care what is behind the list. The route list could be dynamic based on the current loco acquisition state or whatever. Sort of a "menu".

Pre populate a throttle when handling a loco over from TPL

Client should accept unsolicited Mx+ messages and add that addr to throttle "x". ED and WiThrottle should always have throttle "0" visible (?).

BUT not sure how to handle multiple ED clients here.

This seems simpler if the flow looks something like this:

1. Client requests loco address AAAA for a specific throttle "x"
2. Server responds with Mx+AAAA
3. Client selects a "Route" which indicates server should control AAAA
4. Client still shows AAAA, but any client speed/direction requests are ignored with message "Loco AAAA running under TPL"
5. Server completes task and stops ignoring speed/direction for AAAA.

This removes the need for the server to "guess" at which client and throttle.

[Asbelos]

Good ideas. Makes sense, thanks.On 19 Nov 2020 18:31, mstevetodd <[email protected]> wrote: My initial thoughts on your list: intercept the Turnout aspects of Withrottle to call into the TPL layout handling. As long as the server sends a list of turnouts and state updates, it can define and use them however it wants. Intercept loco acquisition so that it cant steal a loco TPL is animating. Client waits for Mx+ response to its Mx+ request. So server can simply choose not to respond, or (better) send only a message explaining the issue. -OR- (better?) Server can reply with Mx+, but then ignore any speed/direction requests while server is in control. Use Routes to allow ED to send a loco onto a TPL route. Same as turnouts, client does not care what is behind the list. Pre populate a throttle when handling a loco over from TPL Client should accept unsolicited Mx+ messages and add that addr to throttle "x". ED and WiThrottle should always have throttle "0" visible (?). BUT not sure how to handle multiple ED clients here. This seems simpler if the flow looks something like this: Client requests loco address AAAA for a specific throttle "x"Server responds with Mx+AAAAClient selects a "Route" which indicates server should control AAAAClient still shows AAAA, but any client speed/direction requests are ignored with message "Loco AAAA running under TPL"Server completes task and stops ignoring speed/direction for AAAA. This removes the need for the server to "guess" at which client and throttle. —You are receiving this because you were assigned.Reply to this email directly, view it on GitHub, or unsubscribe.