Additional accessory definition commands (Turnouts)

[Asbelos]

By defining turnout wiring to the command station, rather than an external (JMRI, RocRail etc) we give the following user advantages:

1. Turnout commands issued directly to the CommandStation by throttles such as EXWebThrottle, EngineDriver can be understood and actioned. This is not possible if JMRI for example directly jiggles pins or sends opaque DCC messages.

2. A wider range of hardware connection methods can be supported (at least at the logic level), including remote nodes.

3. Use of EEPROM can be reduced if these commands are automatically issued at startup (with another feature already proposed)

4. RMFT automation can operate on turnouts etc without JMRI present.

5. JMRI could be simplified so that ALL turnout activate/deactivate commands that go through the command station just use the
   < T id activate> command.

Suggested commands:
< T id DCC dccaddr dccsubaddr> DCC connected to main track (= existing DCC++ type)
< T id PROGDCC dccaddr dccsubaddr> DCC connected to prog track channel of waveform
< T id PIN pin HIGH/LOW> HIGH/LOW determines what to set pin to for "Activated"
< T id I2CPIN pin HIGH/LOW>
< T id PULSE pin1 pin2 duration>
< T id I2CPULSE pin1 pin2 duration> as PULSE but over I2C expander
< T id SERVO angle1 angle2 duration>
< T id I2CSERVO angle1 angle2 duration>
< T id LCN node> //passes request to an external node (node hardware configured elsewhere)

Each of the above commands would create a Turnout object (or a subclass thereof) so that turnout activate/deactivate and enumeration can be common.

[matt-vdv]

@Asbelos sounds like an excellent idea!
Should we wait until this is sorted before implementing turnouts on Webthrottle-EX?

[grbba]

One question where do i define the id and how is the id build ? Would that be stored in the eeprom afterwards ?

[Asbelos]

No need to wait to do webthrottle because webthrottle will never need to know about the turnout technology... it will only need to know the list of ids and how to issue the existing turnout throw command < T id 1|0 >

[Asbelos]

id is a positive integer, chosen by the user to uniquely identify a turnout... so when something wants to throw, it only needs the id

Eeprom saving is similar to the existing system but IMHO completely unnecessary

[grbba]

So in case of a lcn network how would you know to which node to send the command ? I guess you can’t deduce from the id the node to whom to send the command, or can you ? Le jeu. 7 janv. 2021 à 17:35, Asbelos <[email protected]> a écrit :

id is a positive integer, chosen by the user to uniquely identify a turnout... so when something wants to throw, it only needs the id — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#115 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABB72C2JWCRUVPKBPO6AT3TSYXPFRANCNFSM4VY5S73Q> .

-- *Gregor Baues* 15 Voie des Gouttins, 91530 Le Val Saint Germain, France [email protected] - Tel. 0630452309

[matt-vdv]

So how would a user set up a new turnout? Would this be done when the code is compiled or later using commands?

[Asbelos]

My understanding is that the Lcn master would know where to send the message. If not, we could add the node to the command.

[Asbelos]

These commands, like all the others, can be injected at any time, by hand, by jmri or (with the benefit of a separate auto-startup feature) from the sketch.

[matt-vdv]

Ok thanks!

[FrightRisk]

What does this mean for the accessories command? Anything?

[FrightRisk]

So if I am following, we define all the different types inside the CS. It is refreshed at startup. Then we need to know what kind of device is on each turnout ID and the front end software sends the same command it always has and things behind the scenes (us or LCN, etc.) just says "go" and that's a servo spins or a switch flips?

[Asbelos]

Thats one way.... otherwise the jmri/rocrail has to understand all the combinations.
The easier way, Imho, is to pretend to jmri and rocrail that we ONLY support dcc turnouts (and we dont keep a list) and have the cs able to intercept accessory packets and jiggle pins or servos instead.