Turnout technologies

[Asbelos]

TPL needs to be able to refer to turnouts by simple id. There is no place for the bizarre mixture of commands that JMRI uses to transparently handle turnouts without the knowledge of the command station. Nor is there any sense in defining these dynamically.

TPL code currently provides support for the following turnout hardware configurations:

1. DCC Accessory (equivalent to old )
2. Servo connected to servo control board over I2C
3. 2-Pin switch on native CPU pin
4. 2-pin switch on I2C pin expander board

Others may be added as required.

The issue is "how to construct turnout control code such that the old commands work if TPL is not in use and TPL code is not built into the executable when its not used. "

[Asbelos]

We should also take consideration of the situation where a DCC based turnout is switched while the track power is off... This should not flip any status and should return or something is this is attempted from a command.

Also note the other improvement possibilities where DCC accessory messages are sent down channel B ... so make sure which track is powered.

[davidcutting42]

Make sure that you also include:

5. Turnouts on the accessory buses

[davidcutting42]

Also, TPL needs to go in and set all of the DCC/accessory bus turnouts at startup instead of assuming anything. Better yet, set the turnouts at the beginning of every route just to be sure.

[Asbelos]

I anticipate Tpl will be able to restore after restart using eeprom.  All routes should be written to set turnouts on the way.. and at the appropriate time... which is not necessarily at the start.  Remember routes may cross over or share tracks with other routes and have to use RESERVE/FREE to ensure they have permission to proceed at certain positions. They may also loop or return down the same track or take random decisions about where to go next.  On 21 Nov 2020 05:19, Dave Cutting <[email protected]> wrote: Also, TPL needs to go in and set all of the DCC/accessory bus turnouts at startup instead of assuming anything. Better yet, set the turnouts at the beginning of every route just to be sure. —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[FrightRisk]

I've asked Marada1 to join us here on this issue (or the TPL channel on Discord), but he posted this: "Quick question concerning this situation. If turnouts are all set for a route at the beginning wouldn't that limit operation to just one train since another might need turnouts in a different position? Seems to me to defeat the purpose. In my mind seems it would have to work in conjunction with block detection or some other detection or software analytic."

[FrightRisk]

We have EEPROM and SDCards to be able to save to. The question remains how to handle something manually changed when the power is off. So a pie in the sky question is, do we require sensors? Do we have own hardware that devices need to be attached to? Do we need our own (or existing) bus structure with bi-directional communication? We have 2 possible busses, the DCC signal on the tracks and a separate direct control bus. How do we handle those? And do we have a "reset state" where we don't take anything for granted, we read what it was supposed to be from the last save and just force everything to that state?

[Asbelos]

Turnouts are set when you ask them to... anywhere during a journey... On 21 Nov 2020 18:46, Fred <[email protected]> wrote: I've asked Marada1 to join us here on this issue (or the TPL channel on Discord), but he posted this: "Quick question concerning this situation. If turnouts are all set for a route at the beginning wouldn't that limit operation to just one train since another might need turnouts in a different position? Seems to me to defeat the purpose. In my mind seems it would have to work in conjunction with block detection or some other detection or software analytic." —You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or unsubscribe.

[marada1]

Whether it is TPL or LCN, (nrf network), ethernet or serial, for Command Station to become a defacto standard it will have to do something that DCC does not and that Command Station can achieve. That is 2-way communication. I do not think that for future needs eeprom would be an answer. Going to have to be something like an SD Card or flash memory. Have it so that any of the control systems through DCC++ update a file and when I command is received, the file can be referenced to determine position in the case of a turnout. After the turnout is moved, Command Station is notified of the movement and updates the file or memory. That also could work to the benefit of Command Station. CS concentrates on controlling engines and communicating with say Engine Driver and whatever will connect to Command Station to process instructions. So a seperate not for Ethernet, LCN, TPL, whatever. They can communicate via serial communications. Also prevents software bloat. The more you have one program try to do the odds increase that things will go wrong. This would also allow for upward compatibility. Someone starting out with DC can move up and they can. Also allows for future advances that have not been thought of yet such as RFID or even GPS for just the layout. Thoughts?