A few years ago I reported an error in the light function settings in the TCS function decoders, today I found the same error is still in place so am reporting it once again. I don't remember if at the time I checked the other settings, but the ones I needed at the time and are still incorrect are for ditch lights. The result is one ditch light is the ditch light of the opposite phase, the other result is a constant dim light instead of the 2nd ditch light. I haven't evaluated what other function settings might be incorrect

copied from the original post:
In the TCS FL4and FL2 function decoders, one of the values to make a function perform as a ditch light is incorrect. The CV value choices should be 10 or 11 for forward operation, 25 and 26 for reverse, and 41 and 42 for non-directional operation. The present values are a value of one too low, making one output non-operational when one uses a value of 9, 24, or 40 that are stored in the DecoderPro files.

Lyle Dowell

On 7 Jun 2019, at 12:46, Ken Cameron <kcameron@...> wrote:

John P,

You are correct. Real world signal systems tend to have someone around in
charge. So things like a reverse move would be known and effectively the
system is told that's what is going on. Unfortunately a number of model
implementations try to work out how to not have that extra human around. To
some, where a simple solution might be a handy 'block reset' button for when
you made a set of moves that confused the logic, they would whine about the
need for the extra button or 'what if they forgot'.

One easy example is the normal interlocking rule that you must never make a
reverse move inside an interlocking plant. To make things manageable, and
safe, the train was required to finish the move to the far side first, then
it could make the return move. The logic to deal with that was much simpler
since it used two normal moves: going one way, second move, going the other
way. Some of that was also related to it releasing parts of the route
through the interlock as the train progressed. It would allow other moves to
progress if valid and not interfering with each other.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

On 4 Jun 2019, at 12:58, Ken Cameron <kcameron@...> wrote:

Maybe borrowing from the prototype might help. As I understand it, some
country's prototype railroads use optic sensors. Here a sensor spot is
really two sensors very close together. The result is that it knows which
direction (and speed) the train is passing. It then is doing an axle
counting to tell if a train has finished passing or not. So if 50 axles
passed into a block, it doesn't consider the block empty until 50 have left.
These might not be just optic sensors but what I read said it was a place on
the track to determine when the block was clear or not by doing the axle
counting.

The worst case to figure out is when a train stops over the sensor spot,
then the train goes into reverse. Give it some thought and you would see
getting it right every time is not simple.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

On Jun 6, 2019, at 6:40 AM, Andy Reichert <andy_r@...> wrote:

Why use any toggle switches to set turnouts at all? . Touch or mechanical). You are relying on being able to clearly see (or know) all the relevant turnout settings immediately prior. Which is not always obvious. If you want touch panel switches, just have separate closed and thrown ones. then you won't accidentally change a correctly set turnout.

Andy