Topics

Signal Mast Logic generation for path with two separate valid routes

Bob M.
 

It seems that the Signal Mast Logic discovery process (in 4.17.4 and perhaps
other versions) will only find one path from signal A to signal B when there
is more than one valid path.

Where this is needed is for a "lap interlocking" such as the one shown in
the attached image. The problem occurs for movements from block BL44 "in
approach to RA284" to block AP45. There are two separate, valid routes
between these points. One route is via 283 "Reversed" and 287 "Normal".
The other possible route is via 283 "Normal", 285 "Normal" and 287
"Reversed". In my 4.17.4 tests, SML "Discovery" only finds the path via 283
"Reversed". I am unable to "add" an additional bit of SML between RA284 and
LS284 because "that path" is already defined in SML.

Is this behavior intended? Is there any recommended workaround?

Regards,
Bob M.

Dave Sand
 

Bob,

The connection from RA284 to the mast beyond AP45 can only occur one time since duplicate signal mast pairs are not allowed.

The easiest workaround is to add a signal mast at the block boundary between OS283 and OSA287 on the diverging leg. If necessary you may need to have a short track segment attached to OS283 so that you can have an anchor point at the left end of OSA287 for attaching a signal mast protecting OSA287.

Dave Sand

----- Original message -----
From: "Bob M." <jawhugrps@...>
To: jmri@jmri-developers.groups.io
Subject: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
Date: Tuesday, October 22, 2019 8:26 PM

It seems that the Signal Mast Logic discovery process (in 4.17.4 and perhaps
other versions) will only find one path from signal A to signal B when there
is more than one valid path.

Where this is needed is for a "lap interlocking" such as the one shown in
the attached image. The problem occurs for movements from block BL44 "in
approach to RA284" to block AP45. There are two separate, valid routes
between these points. One route is via 283 "Reversed" and 287 "Normal".
The other possible route is via 283 "Normal", 285 "Normal" and 287
"Reversed". In my 4.17.4 tests, SML "Discovery" only finds the path via 283
"Reversed". I am unable to "add" an additional bit of SML between RA284 and
LS284 because "that path" is already defined in SML.

Is this behavior intended? Is there any recommended workaround?

Regards,
Bob M.




Attachments:
* Low Moor.png

Ken Cameron
 

Bob M,

At any given time, only one of those paths will be valid as the turnouts
would only be one or none of the possible paths. Or are you saying that it
is only finding one of the possible paths? The paths that are possible would
be :
1. WNR283 reversed and WNR287 normal
2. WNR283 normal and WNR285 normal and WNR287 reversed

Any other combination would not get from BL44 to AP45. I think the
distinction of possible paths is what the logic discovery would care about.
Then each of those would solve to valid or not based on the occupancy and
turnout positions. And only one of them could be valid at the same time.

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

Bob M.
 

Ken,

I am saying that the "discovery" will only find one of the two potential
routes.

Dave,

I will have to experiment with the additional "virtual" signal mast you've
recommended. Thanks for this idea!

It is unclear what other "tricks" I may need to play to get the correct
indications on RA284, though. I'm initially thinking that this virtual
signal may need to do something like "repeat" the signal in advance.

Regards,
Bob M.

Bob M.
 

Dave wrote:

"The connection from RA284 to the mast beyond AP45 can only occur one time
since duplicate signal mast pairs are not allowed."

Is there a particular reason for this? My _naive_ view of JMRI's Signal
Mast Logic seems to think that the "active" checkbox in the Signal Mast
Logic entry for the mast would allow having multiple physical paths between
a given pair of signal masts.

Regards,
Bob M.

Dave Sand
 

Bob,

I am not aware of any specific reason for unique signal mast pairs.  I do know that the Java data structures result in the unique requirement.  That may have been a side effect or intentional.

The Active checkboxes on the Signaling Mast Pairs window show the active destination mast, if any.  You cannot change them.

Dave Sand


----- Original message -----
From: "Bob M." <jawhugrps@...>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
Date: Wednesday, October 23, 2019 7:57 PM

Dave wrote:

"The connection from RA284 to the mast beyond AP45 can only occur one time
since duplicate signal mast pairs are not allowed."

Is there a particular reason for this?  My _naive_ view of JMRI's Signal
Mast Logic seems to think that the "active" checkbox in the Signal Mast
Logic entry for the mast would allow having multiple physical paths between
a given pair of signal masts.

Regards,
Bob M.




Bob M.
 

Dave,

Thanks for the explanation that the Java class and/or its data organization
is preventing the inclusion of multple paths.

My thought with respect to the checkboxes was that only one route can be
active at any time between any two signal masts, depending on points
positions. If more than one different routes were populated into the Signal
Mast Logic for a given pair of signals, then a max of one route could be
active at any given time, and would be identified by the checkbox.

To tackle the problem of getting multiple routes into the table, presumably
it would be necessary to use a different Java class, or provide a different
way to structure the data within the existing class, such that the table
could hold more than one path between a given pair of signals.

I'll have to give this coding problem a pass, at least for now, on account
of family pressures.

Regards,
Bob M.

Ken Cameron
 

Bob M,

I think this used to work. What I'm thinking might have changed is some of
the path logic to cure some of the odd cases a crossover creates. I could
see logically that this might be presenting a 'close enough' case to fool
the logic. I recall the issue was a pair of left and right crossovers with
the four signals outside the interlocking. It wasn't making the right
connections sometimes as there was the silly case of crossing and crossing
back before getting to the next signal.

I thought it would create the extra path that I'd then delete the one I
didn't want. But what you are getting it is not forming all the paths. Does
it work ok if you manually create the missing path?

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

Dave Sand
 

Ken,

The SML destinations for a mast are in a Hashtable with the destination mast name being the key, which must be unique, and an internal class structure being the value.    The structure contains the blocks, turnouts, sensors, and other signals that define a particular route.

The double cross-over scenario also applies but it also affects block routing,  which can result in missing SML definitions and impossible SML such as a 180º turn in a double cross-over.

When two blocks are used, whether a double cross-over or left and right cross-overs acting at a double cross-over, a pair of routes cannot be created.   This is caused by a similar duplicate key problem.

For the left/right cross-over scenario, the fix is easy:  use a third block.  This may also work for a true double cross-over but I have not tried it.

This results in valid block routing and auto discovery for signal mast logic.

Dave Sand



----- Original message -----
From: Ken Cameron <kcameron@...>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
Date: Thursday, October 24, 2019 10:11 AM

Bob M,

I think this used to work. What I'm thinking might have changed is some of
the path logic to cure some of the odd cases a crossover creates. I could
see logically that this might be presenting a 'close enough' case to fool
the logic. I recall the issue was a pair of left and right crossovers with
the four signals outside the interlocking. It wasn't making the right
connections sometimes as there was the silly case of crossing and crossing
back before getting to the next signal.

I thought it would create the extra path that I'd then delete the one I
didn't want. But what you are getting it is not forming all the paths. Does
it work ok if you manually create the missing path?

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





Bob M.
 

Dave,

Your "trick" for this awkward boundary condition sounds like something which could be useful to document somewhere in the SML "help" pages. I suspect others have run into this problem, and I expect one layout I know of _will_ experience this kind of problem in an on-going signaling install/development project.

Regards,
Bob M.

Dave Sand
 

Bob,

I have reviewed the SML help pages and the limitations are not discussed.

I will work on an update that includes the duplicate pair restrictions along with some other information on debugging unexpected SML aspect results.

Dave Sand

----- Original message -----
From: "Bob M." <jawhugrps@...>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
Date: Thursday, October 24, 2019 8:09 PM

Dave,

Your "trick" for this awkward boundary condition sounds like something which could be useful to document somewhere in the SML "help" pages. I suspect others have run into this problem, and I expect one layout I know of _will_ experience this kind of problem in an on-going signaling install/development project.

Regards,
Bob M.

Ken Cameron
 

Dave S,

Is that hashtable issue only on the discovery tool, or also apply if you
manually tried to create the missing path?

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

Dave Sand
 

Ken,

The hashtable is the data storage for the destination SML definitions for the current source mast. It is populated by XML loading, discovery and by manual SML creation.

Dave Sand

----- Original message -----
From: Ken Cameron <@KenC57>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
Date: Thursday, October 24, 2019 8:17 PM

Dave S,

Is that hashtable issue only on the discovery tool, or also apply if you
manually tried to create the missing path?

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

Bob M.
 

Dave,

If the hashtable key simply has the "destination mast" as key name, that poses a fundamental problem for any situation where there are multiple paths to a given destination mast.

Solving the the "multiple paths" problem would seem to require some different method for key name generation. Perhaps the content of the key could be changed to allow different keys to represent the multiple routes between a pair of signals. While it might be very verbose, the key could instead be of the form: "sourcemast"+"switch_and_direction/block"+"switch_and_direction/block"+"switch_and_direction/block"+...+"switch_and_direction/block"+"destinationmast".

That would allow unique key names for all cases, across different paths between two masts. Such a solution could enable a solution to the problem I have encountered, by allowing for a meaningful algorithm to find and store "multiple" paths between given pairs of signal masts.

I don't know how the hashmap's keyname is used within the code, so I cannot guess whether such a proposal makes any sense within the code structure of the remainder of the signal mast logic code.

Regards,
Bob M.

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
Sent: Thursday, October 24, 2019 1:31 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes

Ken,


The SML destinations for a mast are in a Hashtable with the destination mast name being the key, which must be unique, and an internal class structure being the value. The structure contains the blocks, turnouts, sensors, and other signals that define a particular route.


The double cross-over scenario also applies but it also affects block routing, which can result in missing SML definitions and impossible SML such as a 180º turn in a double cross-over.


When two blocks are used, whether a double cross-over or left and right cross-overs acting at a double cross-over, a pair of routes cannot be created. This is caused by a similar duplicate key problem.


For the left/right cross-over scenario, the fix is easy: use a third block. This may also work for a true double cross-over but I have not tried it.



This results in valid block routing and auto discovery for signal mast logic.


Dave Sand




----- Original message -----

From: Ken Cameron <@KenC57>

To: jmri@jmri-developers.groups.io

Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes

Date: Thursday, October 24, 2019 10:11 AM


Bob M,


I think this used to work. What I'm thinking might have changed is some of

the path logic to cure some of the odd cases a crossover creates. I could

see logically that this might be presenting a 'close enough' case to fool

the logic. I recall the issue was a pair of left and right crossovers with

the four signals outside the interlocking. It wasn't making the right

connections sometimes as there was the silly case of crossing and crossing

back before getting to the next signal.


I thought it would create the extra path that I'd then delete the one I

didn't want. But what you are getting it is not forming all the paths. Does

it work ok if you manually create the missing path?


-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.org

www.syracusemodelrr.org

Randall Wood
 

Alternately, the value could be a list or set of routes between the source and destination.

On Oct 28, 2019, at 17:10, Bob M. <jawhugrps@...> wrote:

Dave,

If the hashtable key simply has the "destination mast" as key name, that poses a fundamental problem for any situation where there are multiple paths to a given destination mast.

Solving the the "multiple paths" problem would seem to require some different method for key name generation. Perhaps the content of the key could be changed to allow different keys to represent the multiple routes between a pair of signals. While it might be very verbose, the key could instead be of the form: "sourcemast"+"switch_and_direction/block"+"switch_and_direction/block"+"switch_and_direction/block"+...+"switch_and_direction/block"+"destinationmast".

That would allow unique key names for all cases, across different paths between two masts. Such a solution could enable a solution to the problem I have encountered, by allowing for a meaningful algorithm to find and store "multiple" paths between given pairs of signal masts.

I don't know how the hashmap's keyname is used within the code, so I cannot guess whether such a proposal makes any sense within the code structure of the remainder of the signal mast logic code.

Regards,
Bob M.


-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
Sent: Thursday, October 24, 2019 1:31 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes

Ken,


The SML destinations for a mast are in a Hashtable with the destination mast name being the key, which must be unique, and an internal class structure being the value. The structure contains the blocks, turnouts, sensors, and other signals that define a particular route.


The double cross-over scenario also applies but it also affects block routing, which can result in missing SML definitions and impossible SML such as a 180º turn in a double cross-over.


When two blocks are used, whether a double cross-over or left and right cross-overs acting at a double cross-over, a pair of routes cannot be created. This is caused by a similar duplicate key problem.


For the left/right cross-over scenario, the fix is easy: use a third block. This may also work for a true double cross-over but I have not tried it.



This results in valid block routing and auto discovery for signal mast logic.


Dave Sand




----- Original message -----

From: Ken Cameron <@KenC57>

To: jmri@jmri-developers.groups.io

Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes

Date: Thursday, October 24, 2019 10:11 AM


Bob M,


I think this used to work. What I'm thinking might have changed is some of

the path logic to cure some of the odd cases a crossover creates. I could

see logically that this might be presenting a 'close enough' case to fool

the logic. I recall the issue was a pair of left and right crossovers with

the four signals outside the interlocking. It wasn't making the right

connections sometimes as there was the silly case of crossing and crossing

back before getting to the next signal.


I thought it would create the extra path that I'd then delete the one I

didn't want. But what you are getting it is not forming all the paths. Does

it work ok if you manually create the missing path?


-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.org

www.syracusemodelrr.org










Bob M.
 

The workaround for a mast at an intermediate point on the path from OS283
(directly, via 283 reversed) to OSA287, did not solve my problem:

- I am unwilling to implement such a physical signal on the railroad. The
prototype railroad didn't need a signal there, so I don't plan to have one
there either.

- I have not found any good way to make this "virtual" signal display an
aspect which is appropriate to give the correct apsect on RA284.

-- When the switch at OSA287 is reversed, the vritual mast displays "Stop"
and RA284 displays "Approach". But "Stop" is the only valid RA284 aspect
when the switch at OSA287 is reversed. Perhaps I need a virtual sensor that
is sensitive to the position of the switch at OSA287, and use that as a
user-addition to the signal mast logic for RA284.

-- When the switch at OSA287 is normal and the switch at OS283 is reversed,
I need RA284 to display an aspect suitable for protection of the signal
beyond AP45, not for protection of the virtual signal. One way to solve
this challenge might be to create a new signal system to use at this virtual
mast, with aspects carefully defined such that RA284 can give "correct"
aspects as if the virtual mast weren't there, even though SML is sensitive
to that virtual mast's aspect. But I don't think that I want to create a
new "signal system" for this one "boundary condition"...

Regards,
Bob M.

-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io]
On Behalf Of Dave Sand
Sent: Tuesday, October 22, 2019 10:08 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with
two separate valid routes

Bob,

The connection from RA284 to the mast beyond AP45 can only occur one time
since duplicate signal mast pairs are not allowed.

The easiest workaround is to add a signal mast at the block boundary between
OS283 and OSA287 on the diverging leg. If necessary you may need to have a
short track segment attached to OS283 so that you can have an anchor point
at the left end of OSA287 for attaching a signal mast protecting OSA287.

Dave Sand

Dave Sand
 

Replacing the hash table with a list would probably be the cleanest solution.

The scope of such a change, however, is significant. It would affect block routing, signal mast logic, LE based Entry/Exit, probably Dispatcher, existing scripts, etc. In fact, block routing has the same issue with unique keys.

When does risk exceed payback?

I can try the list approach. Unless we get really lucky, it will not be this year.


Dave Sand

----- Original message -----
From: "Randall Wood via Groups.Io" <rhwood=mac.com@groups.io>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
Date: Monday, October 28, 2019 4:13 PM

Alternately, the value could be a list or set of routes between the source and destination.
On Oct 28, 2019, at 17:10, Bob M. <jawhugrps@...> wrote:

Dave,

If the hashtable key simply has the "destination mast" as key name, that poses a fundamental problem for any situation where there are multiple paths to a given destination mast.

Solving the the "multiple paths" problem would seem to require some different method for key name generation. Perhaps the content of the key could be changed to allow different keys to represent the multiple routes between a pair of signals. While it might be very verbose, the key could instead be of the form: "sourcemast"+"switch_and_direction/block"+"switch_and_direction/block"+"switch_and_direction/block"+...+"switch_and_direction/block"+"destinationmast".

That would allow unique key names for all cases, across different paths between two masts. Such a solution could enable a solution to the problem I have encountered, by allowing for a meaningful algorithm to find and store "multiple" paths between given pairs of signal masts.

I don't know how the hashmap's keyname is used within the code, so I cannot guess whether such a proposal makes any sense within the code structure of the remainder of the signal mast logic code.

Regards,
Bob M.


-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
Sent: Thursday, October 24, 2019 1:31 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes

Ken,


The SML destinations for a mast are in a Hashtable with the destination mast name being the key, which must be unique, and an internal class structure being the value. The structure contains the blocks, turnouts, sensors, and other signals that define a particular route.


The double cross-over scenario also applies but it also affects block routing, which can result in missing SML definitions and impossible SML such as a 180º turn in a double cross-over.


When two blocks are used, whether a double cross-over or left and right cross-overs acting at a double cross-over, a pair of routes cannot be created. This is caused by a similar duplicate key problem.


For the left/right cross-over scenario, the fix is easy: use a third block. This may also work for a true double cross-over but I have not tried it.



This results in valid block routing and auto discovery for signal mast logic.


Dave Sand




----- Original message -----

From: Ken Cameron <@KenC57>

To: jmri@jmri-developers.groups.io

Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes

Date: Thursday, October 24, 2019 10:11 AM


Bob M,


I think this used to work. What I'm thinking might have changed is some of

the path logic to cure some of the odd cases a crossover creates. I could

see logically that this might be presenting a 'close enough' case to fool

the logic. I recall the issue was a pair of left and right crossovers with

the four signals outside the interlocking. It wasn't making the right

connections sometimes as there was the silly case of crossing and crossing

back before getting to the next signal.


I thought it would create the extra path that I'd then delete the one I

didn't want. But what you are getting it is not forming all the paths. Does

it work ok if you manually create the missing path?


-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.org

www.syracusemodelrr.org










Randall Wood
 

I meant the hashmap can contain a key that this is the destination signal and use a list of possible routes as the value for that key.

Randall

On Oct 28, 2019, at 17:54, Dave Sand <@davesand> wrote:

Replacing the hash table with a list would probably be the cleanest solution.

The scope of such a change, however, is significant. It would affect block routing, signal mast logic, LE based Entry/Exit, probably Dispatcher, existing scripts, etc. In fact, block routing has the same issue with unique keys.

When does risk exceed payback?

I can try the list approach. Unless we get really lucky, it will not be this year.


Dave Sand


----- Original message -----
From: "Randall Wood via Groups.Io" <rhwood=mac.com@groups.io>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
Date: Monday, October 28, 2019 4:13 PM

Alternately, the value could be a list or set of routes between the source and destination.
On Oct 28, 2019, at 17:10, Bob M. <jawhugrps@...> wrote:

Dave,

If the hashtable key simply has the "destination mast" as key name, that poses a fundamental problem for any situation where there are multiple paths to a given destination mast.

Solving the the "multiple paths" problem would seem to require some different method for key name generation. Perhaps the content of the key could be changed to allow different keys to represent the multiple routes between a pair of signals. While it might be very verbose, the key could instead be of the form: "sourcemast"+"switch_and_direction/block"+"switch_and_direction/block"+"switch_and_direction/block"+...+"switch_and_direction/block"+"destinationmast".

That would allow unique key names for all cases, across different paths between two masts. Such a solution could enable a solution to the problem I have encountered, by allowing for a meaningful algorithm to find and store "multiple" paths between given pairs of signal masts.

I don't know how the hashmap's keyname is used within the code, so I cannot guess whether such a proposal makes any sense within the code structure of the remainder of the signal mast logic code.

Regards,
Bob M.


-----Original Message-----
From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
Sent: Thursday, October 24, 2019 1:31 PM
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes

Ken,


The SML destinations for a mast are in a Hashtable with the destination mast name being the key, which must be unique, and an internal class structure being the value. The structure contains the blocks, turnouts, sensors, and other signals that define a particular route.


The double cross-over scenario also applies but it also affects block routing, which can result in missing SML definitions and impossible SML such as a 180º turn in a double cross-over.


When two blocks are used, whether a double cross-over or left and right cross-overs acting at a double cross-over, a pair of routes cannot be created. This is caused by a similar duplicate key problem.


For the left/right cross-over scenario, the fix is easy: use a third block. This may also work for a true double cross-over but I have not tried it.



This results in valid block routing and auto discovery for signal mast logic.


Dave Sand




----- Original message -----

From: Ken Cameron <@KenC57>

To: jmri@jmri-developers.groups.io

Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes

Date: Thursday, October 24, 2019 10:11 AM


Bob M,


I think this used to work. What I'm thinking might have changed is some of

the path logic to cure some of the odd cases a crossover creates. I could

see logically that this might be presenting a 'close enough' case to fool

the logic. I recall the issue was a pair of left and right crossovers with

the four signals outside the interlocking. It wasn't making the right

connections sometimes as there was the silly case of crossing and crossing

back before getting to the next signal.


I thought it would create the extra path that I'd then delete the one I

didn't want. But what you are getting it is not forming all the paths. Does

it work ok if you manually create the missing path?


-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.org

www.syracusemodelrr.org














Dave Sand
 

Currently the hash table value is an internal class that defines the turnouts, blocks, etc. that define the signal mast logic.  Making the value into a list of internal class instances should work but that does not hide the structure change from other components such as the xml store process.  Which then brings up the issue of identifying "which" internal class instance.
The goal is to have two routes to EB-AP45.  The internal class will probably need to include a sequence number that works as a secondary key.

Lots of things to think about.

Dave Sand



----- Original message -----
From: "Randall Wood via Groups.Io" <rhwood@...>
To: jmri@jmri-developers.groups.io
Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
Date: Monday, October 28, 2019 5:24 PM

I meant the hashmap can contain a key that this is the destination signal and use a list of possible routes as the value for that key.

Randall
> On Oct 28, 2019, at 17:54, Dave Sand <ds@...> wrote:

> Replacing the hash table with a list would probably be the cleanest solution.

> The scope of such a change, however, is significant.  It would affect block routing, signal mast logic, LE based Entry/Exit, probably Dispatcher, existing scripts, etc.  In fact, block routing has the same issue with unique keys.

> When does risk exceed payback?

> I can try the list approach.  Unless we get really lucky, it will not be this year.


> Dave Sand


> ----- Original message -----
> From: "Randall Wood via Groups.Io" <rhwood@...>
> To: jmri@jmri-developers.groups.io
> Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
> Date: Monday, October 28, 2019 4:13 PM

> Alternately, the value could be a list or set  of routes between the source and destination.
>> On Oct 28, 2019, at 17:10, Bob M. <jawhugrps@...> wrote:
>> 
>> Dave,
>> 
>> If the hashtable key simply has the "destination mast" as key name, that poses a fundamental problem for any situation where there are multiple paths to a given destination mast.
>> 
>> Solving the the "multiple paths" problem would seem to require some different method for key name generation.  Perhaps the content of the key could be changed to allow different keys to represent the multiple routes between a pair of signals.  While it might be very verbose, the key could instead be of the form: "sourcemast"+"switch_and_direction/block"+"switch_and_direction/block"+"switch_and_direction/block"+...+"switch_and_direction/block"+"destinationmast".
>> 
>> That would allow unique key names for all cases, across different paths between two masts.  Such a solution could enable a solution to the problem I have encountered, by allowing for a meaningful algorithm to find and store "multiple" paths between given pairs of signal masts.
>> 
>> I don't know how the hashmap's keyname is used within the code, so I cannot guess whether such a proposal makes any sense within the code structure of the remainder of the signal mast logic code.
>> 
>> Regards,
>> Bob M.
>> 
>> 
>> -----Original Message-----
>> From: jmri@jmri-developers.groups.io [mailto:jmri@jmri-developers.groups.io] On Behalf Of Dave Sand
>> Sent: Thursday, October 24, 2019 1:31 PM
>> To: jmri@jmri-developers.groups.io
>> Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
>> 
>> Ken,
>> 
>> 
>> The SML destinations for a mast are in a Hashtable with the destination mast name being the key, which must be unique, and an internal class structure being the value.    The structure contains the blocks, turnouts, sensors, and other signals that define a particular route.
>> 
>> 
>> The double cross-over scenario also applies but it also affects block routing,  which can result in missing SML definitions and impossible SML such as a 180º turn in a double cross-over.
>> 
>> 
>> When two blocks are used, whether a double cross-over or left and right cross-overs acting at a double cross-over, a pair of routes cannot be created.   This is caused by a similar duplicate key problem.
>> 
>> 
>> For the left/right cross-over scenario, the fix is easy:  use a third block.  This may also work for a true double cross-over but I have not tried it.
>> 
>> 
>> 
>> This results in valid block routing and auto discovery for signal mast logic.
>> 
>> 
>> Dave Sand
>> 
>> 
>> 
>> 
>> ----- Original message -----
>> 
>> From: Ken Cameron <kcameron@...>
>> 
>> To: jmri@jmri-developers.groups.io
>> 
>> Subject: Re: [jmri-developers] Signal Mast Logic generation for path with two separate valid routes
>> 
>> Date: Thursday, October 24, 2019 10:11 AM
>> 
>> 
>> Bob M,
>> 
>> 
>> I think this used to work. What I'm thinking might have changed is some of
>> 
>> the path logic to cure some of the odd cases a crossover creates. I could
>> 
>> see logically that this might be presenting a 'close enough' case to fool
>> 
>> the logic. I recall the issue was a pair of left and right crossovers with
>> 
>> the four signals outside the interlocking. It wasn't making the right
>> 
>> connections sometimes as there was the silly case of crossing and crossing
>> 
>> back before getting to the next signal.
>> 
>> 
>> I thought it would create the extra path that I'd then delete the one I
>> 
>> didn't want. But what you are getting it is not forming all the paths. Does
>> 
>> it work ok if you manually create the missing path?
>> 
>> 
>> -Ken Cameron, Member JMRI Dev Team
>> 
>> www.jmri.org
>> 
>> www.fingerlakeslivesteamers.org
>> 
>> www.cnymod.org
>> 
>> www.syracusemodelrr.org
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 









Dave Sand
 

Bob,

I have another workaround that works much better.  It does not have weird side effects from intermediate masts.

A virtual mast is logically placed next to the destination mast.  It does not need to be on the panel, but I do as a reminder that special handling is required.  The mast is set to hide when not in edit mode.

A manual signal mast logic route is defined between the source mast and the virtual mast.
Using Logix or a script the virtual mast is synchronized with the real mast in real time.

I generally use a script for repetitive logic.  Here is my test version.

import java
import jmri

mirrorMasts = []
mirrorMasts.append(('EB-AP45', 'VM-AP45'))

class MirrorMast(java.beans.PropertyChangeListener):
    def setup(self, source, alternate):
        self.srcMast = masts.getSignalMast(source)
        self.altMast = masts.getSignalMast(alternate)
        self.srcMast.addPropertyChangeListener(self)

    def propertyChange(self, event):
        print 'Event = {}'.format(event)
        if event.getPropertyName() == 'Aspect':
            self.altMast.setAspect(self.srcMast.getAspect())
        elif event.getPropertyName() == 'Held':
            self.altMast.setHeld(self.srcMast.getHeld())

for row in mirrorMasts:
    source, alternate = row
    mm = MirrorMast().setup(source, alternate)


Dave Sand