¿ªÔÆÌåÓý

Locked NX and signals query


 

Hi

I have been looking at setting up NX routes on my Layout Editor panel and see that there are three options:Turnouts only, Turnouts & Signal Masts and Full Interlock.

Turnouts only I quite understand but as I have my signalling set up with Signal Mast Logic then I see no difference between Turnouts only and Turnouts & Signals. Should there be a difference?

If I use Full Interlock the route sets, the track blocks that the route will follow go purple but all the signals along the route go to Danger and that looks very odd. As this is still a theoretical layout, I have a script that activates and deactivates the sensors in turn along the route to simulate the passage of a train and that clears the route correctly behind and all the correct signal aspects show behind the "train" so I'm quite happy with that. What is puzzling me here is how can a train proceed along the route against Danger signals? Am I missing something here? I'm using 4.14 and a modded version of BR2003 for my signalling.

Thanks

Fraser


 

Fraser,

I only use Full Interlocking. As far as I know, Turnouts and Signals is like full interlocking without the block allocation.

I have not had any issues with signaling when a route has been allocated. I assume you have the signal masts placed at block boundaries and that the signal mast logic is defined and functions properly when NX is not defined.

I can take a look at the configuration if you upload a zip file that contains the panel xml file and custom signal configuration. An easy way to create the zip file is to open PanelPro, use Help >> Locations and select Open Profile Location. That will open the OS file manager at the profile directory. Zip the directory and upload it.


Dave Sand

On May 26, 2019, at 5:18 PM, FRASER SMITH <fraser@...> wrote:

Hi

I have been looking at setting up NX routes on my Layout Editor panel and see that there are three options:Turnouts only, Turnouts & Signal Masts and Full Interlock.

Turnouts only I quite understand but as I have my signalling set up with Signal Mast Logic then I see no difference between Turnouts only and Turnouts & Signals. Should there be a difference?

If I use Full Interlock the route sets, the track blocks that the route will follow go purple but all the signals along the route go to Danger and that looks very odd. As this is still a theoretical layout, I have a script that activates and deactivates the sensors in turn along the route to simulate the passage of a train and that clears the route correctly behind and all the correct signal aspects show behind the "train" so I'm quite happy with that. What is puzzling me here is how can a train proceed along the route against Danger signals? Am I missing something here? I'm using 4.14 and a modded version of BR2003 for my signalling.

Thanks

Fraser


 

Hi Dave

Thanks for offering to look at this. Zip file uploaded to Fraser Smith folder in Problems Being Worked On. I have a few NX routes set up in there. Try from Plat 1 (sensor is in vee of SL7 to left of starter signal) to Fid5 (sensor just above left hand signal at mid height of fiddle yard. Another is Plat 5 (sensor just to left of signal at X2B) and Fid1 (sensor just below signal three lines in from right hand side of fiddle yeard). The opposite pairings are also set up.

Cheers

Fraser


 

Fraser,

Your zip file is also missing all of the custom icons located in the resources directory.

Dave Sand

On May 27, 2019, at 1:30 AM, FRASER SMITH <fraser@...> wrote:

Hi Dave

Thanks for offering to look at this. Zip file uploaded to Fraser Smith folder in Problems Being Worked On. I have a few NX routes set up in there. Try from Plat 1 (sensor is in vee of SL7 to left of starter signal) to Fid5 (sensor just above left hand signal at mid height of fiddle yard. Another is Plat 5 (sensor just to left of signal at X2B) and Fid1 (sensor just below signal three lines in from right hand side of fiddle yeard). The opposite pairings are also set up.

Cheers

Fraser


 

Whoops

Sorry Dave

New zip uploaded now.

Fraser


 

Fraser,

Try resetting the NX and SML definitions.
  1. Delete all of the entries in the NX table.
  2. Delete all of the entries in the Signal Mast Logic table.
  3. Save the panel xml file, stop and re-start PanelPro and load the saved xml file.
  4. Use Tools >> Auto Generate Signaling Pairs in the Signal Mast Table.
  5. Use Auto Generate Entry-Exit Pairs in LE Tools >> Entry Exit¡­. (Don¡¯t forget to select Full Interlock)

I have plat1dep to cc05enter working as expected in simulation mode on 4.15.6.

Dave Sand



On May 27, 2019, at 10:45 AM, FRASER SMITH <fraser@...> wrote:

Whoops

Sorry Dave

New zip uploaded now.

Fraser


 

Hi Dave

Thanks for your response. I have downloaded and installed 4.15.6 and have followed your instructions. Unfortunately I still seem to be having the same problem of all the signals along a route showing danger when the highlight is applied to the track. As I move the occupied block along the route the blocks clear to white (or grey for my reversing sections) and the signals behind the "train" clear to the correct aspect for the position of the train. Another thing I have noticed is that the first signal in each NX pair remains held after the "train" has passed and remains held after the sequence is completed.

You have mentioned simulation mode above. Is that the MERG simulation mode or is there some way of simulating the passage of a train that is different to my scripts?

Enough for me tonight. I'll come back and fight with it again tomorrow.

Thanks again

Fraser


 

Fraser,

Try this xml file:

/g/jmriusers/files/ProblemsBeingWorkedOn/dsand/37%20Heaven%20DS.xml

This file has a LRoute and Routes to initialize the sensors and turnouts during startup. The startup takes time due to the number of sensors and turnouts.

The signal mast logic and NX definitions were deleted and re-built. I have not tested all of the NX routes, mainly the plat1 and plat5 routes.

The connection is defined as MERG using CAN Simulation.


Dave Sand

On May 27, 2019, at 5:32 PM, FRASER SMITH <fraser@...> wrote:

Hi Dave

Thanks for your response. I have downloaded and installed 4.15.6 and have followed your instructions. Unfortunately I still seem to be having the same problem of all the signals along a route showing danger when the highlight is applied to the track. As I move the occupied block along the route the blocks clear to white (or grey for my reversing sections) and the signals behind the "train" clear to the correct aspect for the position of the train. Another thing I have noticed is that the first signal in each NX pair remains held after the "train" has passed and remains held after the sequence is completed.

You have mentioned simulation mode above. Is that the MERG simulation mode or is there some way of simulating the passage of a train that is different to my scripts?

Enough for me tonight. I'll come back and fight with it again tomorrow.

Thanks again

Fraser


 

Hi Dave

Thanks very, very much for doing that. Yes it works fine now on what I have tried so far. I see you are using the LRoute and routes to initialise the sensors and turnouts now. I was running a script at startup that set all my sensors to inactive and set all turnouts (just the points or switches) to closed that I forgot to mention because it's been in my startup preferences for so long now. I assume that won't be needed now?

I can see I'll have to look at LRoutes to see what they are all about.

Once again, thanks very much for this

Cheers

Fraser


 

Fraser,

I have been testing some of your other routes.

Due to your track plan and sensor placement, there is an issue for some routes such as cc07enter -> cc05enter.

Because the left fiddle yard has 4 paths without sensors, NX discovery was able to define a direct route between cc07enter and cc05enter. It also created a route from cc07enter to fid5arr and one from fid5arr to cc05enter.

When cc07enter and cc05enter are selected, the path is created using fid5 to get through the fiddle yard. Since this is technically not a multi segment route signal fid5b is not released. If either fid5 block is occupied, fid6 is selected and there is no issue.

If the cc07enter -> cc05enter NX route is deleted then the sensor pair creates a valid 2 segment route and fid5b is released. However, if either fid5 block is occupied, nothing happens since there is no longer an alternate route through the fiddle yard.


Dave Sand

On May 28, 2019, at 1:38 AM, FRASER SMITH <fraser@...> wrote:

Hi Dave

Thanks very, very much for doing that. Yes it works fine now on what I have tried so far. I see you are using the LRoute and routes to initialise the sensors and turnouts now. I was running a script at startup that set all my sensors to inactive and set all turnouts (just the points or switches) to closed that I forgot to mention because it's been in my startup preferences for so long now. I assume that won't be needed now?

I can see I'll have to look at LRoutes to see what they are all about.

Once again, thanks very much for this

Cheers

Fraser


 

Hi Dave

Thank you for your continued interest in my layout. I have moved on a bit since your last email to set up additional routes so your comments don't match up exactly with the NX sensors I now have. I have made additional NX sensors at the mid points of the fiddle yard split roads as that would be where trains would be sent out to. I have placed NX sensors on the exit tracks (left hand running) at the crossing at J1Y and also put one approaching SW29 to set direction of departing trains. I have also put them at SW30 & 31. At the moment I'm doing a bit of suck it and see to get to grips with this and it's becoming clearer where I need to have the sensors.

You have been of great help so far and I appreciate that but I think you could stand down now and I'll get back to you if/when I need more help. I think it might also be better for any further discussion to be off list as we are dealing with quite a specific situation. You can get me as my first name at cairntoul dot net.

Thanks again

Fraser


 

Hi Dave

Sorry to come back to you but I've noticed that several signals on the routes I have been trying out were not changing after the passage of my "train". I found they were showing as held in the signal mast table. I have gone back to the version you gave the link to in message 160238 and found that several signals were marked as held immediately after startup: CC07, Fid1b, Fid5b, Plat1 and Plat5.? I guess that should not be the case.

I have looked through the startup bits you added and see that the Routes set all the block sensors sensors to inactive and all the turnouts driving points to closed. I had a script running at startup that did similar (I think).

import jmri

def initSensor(sensor):
??? sen = sensors.provideSensor(sensor)
??? sen.setState(INACTIVE)
??? return
???
for x in sensors.getSystemNameList().toArray() :
??? initSensor(x)

turnouts.provideTurnout("SL1a").setState(CLOSED)
turnouts.provideTurnout("SL1b").setState(CLOSED)
turnouts.provideTurnout("SL2a").setState(CLOSED)
etc, etc

Would that have performed the same action as your routes? Does it matter that it would set all the sensors to inactive?

Cheers

Fraser


 

Fraser,

The Held signal masts are correct. Signals that are under NX control are held until the route has been released. This is standard CTC policy. The Entry/Exit pairs table shows the related signal mast in parens.

You did not include any scripts in your uploads so I created the Routes to do the same thing. There is no problem with the duplicate initialization. It just adds a bit to the startup duration.


Dave Sand

On May 30, 2019, at 11:08 AM, FRASER SMITH <fraser@...> wrote:

Hi Dave

Sorry to come back to you but I've noticed that several signals on the routes I have been trying out were not changing after the passage of my "train". I found they were showing as held in the signal mast table. I have gone back to the version you gave the link to in message 160238 and found that several signals were marked as held immediately after startup: CC07, Fid1b, Fid5b, Plat1 and Plat5. I guess that should not be the case.

I have looked through the startup bits you added and see that the Routes set all the block sensors sensors to inactive and all the turnouts driving points to closed. I had a script running at startup that did similar (I think).

import jmri

def initSensor(sensor):
sen = sensors.provideSensor(sensor)
sen.setState(INACTIVE)
return

for x in sensors.getSystemNameList().toArray() :
initSensor(x)

turnouts.provideTurnout("SL1a").setState(CLOSED)
turnouts.provideTurnout("SL1b").setState(CLOSED)
turnouts.provideTurnout("SL2a").setState(CLOSED)
etc, etc

Would that have performed the same action as your routes? Does it matter that it would set all the sensors to inactive?

Cheers

Fraser


 

Hi Dave

OK I see it now. The masts that have the NX associated with them are held until a route is set from them. All quite sensible.

Thanks for everything on this

Fraser