Re: [Jmri-developers] Issue with an interlocking, blocks, and signals

[Ken C. <kca...@st...>]

Dick,

Very nice wording of something I had been suspecting and from other readings, not sure. Thanks for writing this down.

Yes by considering the OS as part of either block, based on the turnout position, insures you have achieved 'clearance' of the turnout in a way. Meaning if the OS is showing as occupied, some physical part of the train is in the way.

This does show how complicated it can be to look at things the right way. And that some of the 'usual' doesn't get it right when presented with a layout that tries to get it right. We have to figure our way around it, but will get there eventually.

Now the fact that many layouts are not built with all these features, that's a side issue. I'm working on a couple of layouts that 'want all the bells and whistles working' so that's how I ran into this set of issues that I hadn't run into on a couple of prior layouts I was signaling.

At this point I have pointers to the areas of Layout Editor that need work. What changes I'm going to make is something I'm starting to consider. One of the options I'm considering is a checkbox in the 'Set Signals' that would let you pick which block boundary you are placing the signals on, exit or entry. At least this would let the logical and visual signal placement match. Another idea would be offering separate signal entry boxes for entry vs exit, so you might end up with a turnout having up to 8, but I'm much less sure why.

At the moment, by using the convoluted case of short track segments and the 'facing point signal' we can make things work out for now on the signal logic. Some of the above ideas could be very weird to get the 'Set Logic' right, but doable I think.

The biggest thing I need to fix in Layout Editor, and do it before the end of month (we have an open house to show the layout), is what happens with the blocks and passing train ids when meeting at a passing siding. Current code doesn't reliably pass the id into the main/passing block when both trains are approaching at the same time. The issue as I recalled was 'what if the train jumped the points' or other bit about the turnout reporting as one way but the track working the other. Due to that 'possible' the current code doesn't make that last assignment of movement to the id. And that block id is what RT uses to follow the train movement. This is Walt's #3090676 issue as I seem to recall.

-ken cameron
Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
CNY Modelers http://www.cnymod.com/
mailto: kca...@st...
In the Upstate New York US area of the world