¿ªÔÆÌåÓý

Locked Re: Locobuffer locking up from data overload?


 

Just for completeness, one more possibility is to use an _internal_ SignalHead driven by the layout status, and then write a script that watches that SignalHead and sends the right commands to the layout. The jython//FollowSE8c.py script could be a starting point.

Bob

On Jul 27, 2017, at 9:59 PM, jawhugrps@... [jmriusers] <jmriusers@...> wrote:

Steve,

I don't think that it will be easy with existing JMRI signal head "type" definitions.

The SE8c uses an odd encoding of two turnout addresses and both states of each turnout. It uses a "last turnout command" determines the output state. JMRI's SE8c signal head type understands this behavior. Other JMRI signal types may or may not be able to handle this type of operation.

One that seems promising is the LDT LS-DEC signal head type. With this signal head type, you may define a unique specific turnout and its state for each of the possible color/flashing/dark possibility. If one defines "bogus" turnouts, such as "internal" turnouts, for those aspects which are not reachable on a given SE8c, then one might "get lucky". One would also need to define a custom "JMRI signaling system" that matches the available aspects.

(For the "bogus" turnouts, I would recommend a unique "internal" turnout+state for each "unwanted" aspect, so that a wayward change on one signal head does not confuse other signal heads.)

None of the other JMRI "signal head type"s seem to come close to the requirements of the SE8c board.

If this JMRI "signal head type" cannot fit the bill, then it will be necessary to code up a new signal head type to support the SE8c in "fourth aspect is flashing red" mode. A new JMRI "signal head type" would be the "ideal" way, especially if the code would strictly limit use to "JMRI signal systems" which did not include any "dark" or "flashing green" or "flashing yellow" aspects.
--
Bob Jacobsen
rgj1927@...

Join [email protected] to automatically receive all group messages.