System Overview

General
1

Hello all!
This is not a feature request, more of a “I need a picture of how the Traintastic software is supposed to fit in”

Or, what information, commands, requests flows in what direction? What entity is responsible of what?

Let me try to explain; You have a model railway, tracks, turnouts, signals etc.. You also have a Command-Station, it is hooked up to the tracks. you also have a bus for your throttles, the bus connects directly to the Command-station. You might also have a bus for sensors feedback. And a Wifi connected trottle as well.
This is your DCC layout.

Now you want to add Traintastic to the mix. In my opinion the only “thing” talking to the Command-station should be Traintastic! A trottle must interface to Traintastic not to the Command-station! The trottle just sends a humble request to start loco #42 forward, target speed 30. This request is sent to Traintastic - not to the Command-station. If everything is safe and all, then Traintastic sends the commands to the Command-station. This is how I imagine this to work. But I notice that I can change a turnout from the loconet directly connected to the Commandstation, Traintastic will see this and update state, same for signals. It reacts to messages. It is not in command.

What am I missing?

2

Hi,

Ideally Traintastic is between the user(s) and the model railway and everything passes through Traintastic. That also makes it possible to manually drive between automatically controlled trains as Traintastic can limit the user controller train speed/direction. This is by far the best and most reliable solution.

Many users however have a throttle that is connected directly to the command station, this makes it much harder as it may collide with the commands Traintastic is sending.

For turnout command Traintastic currently tries to keep in sync with the command station, so if some sets a turnout using a throttle Traintastic will update its status unless the turnout is part of a reserved path, the Traintastic will log a warning and immediately send a command to correct it.

For locomotives is is a bit harder depending on the protocol used, for some protocols is hard to tell who send the command, especially when accelerating/decelerating, then many commands are send in a short period of time, if the response a bit slow, which makes it hard to determine if it is a Traintastic response or another throttle. Currently this isn’t handled properly.

Traintastic can run a WLANmaus/Z21app and/or WiThrottle server, the all commands pass through Traintastic.
Traintastic also has its own webbased throttle “WebThrottle”, checkout: http://127.0.0.1:5740/throttle (if server is running on localhost)

WiThrottle and Traintastic’s WebThrottle support Aquire/Release/Steal, the WLANmaus/Z21 protocol has no support for it however.

Traintastic internally uses the Aquire/Release/Steal meganism, so only ONE throttle is in control of a train. (There is also a ScriptTrhottle for controlling a train from Lua :slight_smile:)

For automatic driving my idea is to have a “Auto pilot throttle” that takes control of a train.

Hope this helps a bit, it is not fully worked out yet so ideas are welcome. If anything is unclear, please ask.

Regards,
Reinder

1 Like
3

Thank you for taking the time for this excellent explanation! It is highly appreciated.
Naturally the base problem here is not Traintastic, any software of this type faces the
same problems. This is the first clear description I have ever seen.

Once again. thanks.