¿ªÔÆÌåÓý

  1. Jmriusers
  2. Topics

Locked Dispatcher - SML - auto-allocation problem

 

Hello everyone again. Sorry to spam the group.

i have a location on my layout that can be a little
troublesome.

i have a double crossover/scissor (4 turnouts) with a 5th on one of the legs that bring two lines together to enter the scissor.

im finding if I have two trains, both wanting to allocate the same block after the scissor but coming from seperate blocks before the scissor (one train from main line, one from the fiddle yard) that the train with higher priority gets allocated, but the train with lower priority allocates I¡¯ve the top. This clash then has some behaviour that seems like dispatcher has no idea what to do.

both trains are allocating 3 sections ahead, one is at priority 7 and the other is at priority 4.

this problem can be resolved by only allowing one of the trains to allocate 2 sections ahead however this means the train will slow down a lot with the size of my layout and blocking. It¡¯s only happening ONE way, not the other.
or rather it¡¯s always train 2 that allocates over the top, train 1 is always the victim.

im happy to provide my file or a video of it happening, just let me know how you¡¯d like to see it..

im not sure how to edit the default ICF file to debug dispatcher.?

--
Thanks
Mitch
 

Edit** allocates OVER the top, not I¡¯ve the top.
--
Thanks
Mitch
 

Hi Mitchell
The scissor it self needs to be a separate section containing one block. Most dispatcher conflicts are done at section not block.
Steve G.



On October 29, 2018 5:07:53 PM EDT, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote:
Hello everyone again. Sorry to spam the group.

i have a location on my layout that can be a little
troublesome.

i have a double crossover/scissor (4 turnouts) with a 5th on one of the legs that bring two lines together to enter the scissor.

im finding if I have two trains, both wanting to allocate the same block after the scissor but coming from seperate blocks before the scissor (one train from main line, one from the fiddle yard) that the train with higher priority gets allocated, but the train with lower priority allocates I¡¯ve the top. This clash then has some behaviour that seems like dispatcher has no idea what to do.

both trains are allocating 3 sections ahead, one is at priority 7 and the other is at priority 4.

this problem can be resolved by only allowing one of the trains to allocate 2 sections ahead however this means the train will slow down a lot with the size of my layout and blocking. It¡¯s only happening ONE way, not the other.
or rather it¡¯s always train 2 that allocates over the top, train 1 is always the victim.

im happy to provide my file or a video of it happening, just let me know how you¡¯d like to see it..

im not sure how to edit the default ICF file to debug dispatcher.?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
 

Hi Steve,

At the moment, one side of the scissor is wired for one block, the other side for another block, and then the centre crossover part is it's own block on an auto-reverser (Live frog)
Are you saying that the centre crossover should be it's own section? or should the whole crossover mechanism (4x turnouts) be one section, with some LOGIX making the 3 separate sensors one internal sensor for the block to reference for the section?
--
Thanks
Mitch
 

Hi Mitchell
Only the cross over/diamond in the middle needs to be it's own unique section so that it cannot be allocated to multiple trains at the same instance.
Steve G.
 

Hi Steve,

I have uploaded some photos to explain my situation a little better as I'm not sure I've done a good job of it.

Mitchell Scott Examples

First photo shows where the trains are trying to allocate when they clash (Sorry, it's rough)

Step 1 = Started all 3 auto trains (70000, 50037, 37254). 70000 is running a cont circle around clockwise on the outer. 50037 is a cont circle running anti-clockwise on the inner. 37254 is a train running between two reversing loops via both of the up and down lines (around the world)
37254 waits for the S01 > S6 to clear before proceeding. S06 is end of platform, and start/finish for up/down line transits. 37254 is sitting in the "around the world" transit start position. All trains set to allocate 3 sections ahead.

Step 2 = 70000 & 50037 halfway through one cycle.

Step 3 = 70000 & 50037 allocated back to starting position.

Step 4 = 70000 clears crossover area, and 50037 has allocated to signal S02 but not across the crossover area yet. 37254 has "right of way" due to higher priority, and will allocate to S06 across the crossover.

Step 5 = 37254 allocates to S06, but before the turnouts can finish moving, 50037 allocates over the top and switches one of the turnouts back to allow it to S06 instead. Both trains stop at the crossover and wait for me to cancel both transits.

The above situation is avoided if I only set 50037 to allocate 2 sections ahead, forcing it to take longer for it to allocate, when 37254 is already occupying the crossver/turnouts.

Blocking example also provided for track cirtcuits to better describe what sections are made up of.

My panel file is also here:? ?Panel File

I hope this gives a better detailed explination of my situation. Also, if you notice any other silly things, please let me know. This is probably the only automation bug I have left before it's running flawlessly for my needs, and I do feel it is something like the way my sections are set out as you mentioned above. I'm just not sure if it's the crossover or the turnout that is the issue.

--
Thanks
Mitch
 

Hi Mitchell
You are using the auto generate, this it creates multiple section names
containing the same block, even fwd and rev. The dispatcher only uses the
sections for allocating. Basically "Is the section free" yes - allocate and use.
First try "Lock Turnouts when Signal Mast Logic Active". If you had signals at
the crossover then the allocation would not be a problem as only one signal
could be go, as the, diamond, switches would show occupied.
If you manually created the sections, then you would only have one name for a
block, but you would have to add the signal mast logic manually as it wants only
one section between masts, in the layouts I am involved in, we do all manual and
it works really well.
I will look at in more detail later as I have a rain free day....
Steve G.

---------- Original Message ----------
From: "Mitchell via Groups.Io" <mitchell.scott93@...>
Date: October 30, 2018 at 8:11 AM


Hi Steve,

I have uploaded some photos to explain my situation a little better as I'm not
sure I've done a good job of it.

Mitchell Scott Examples ( /g/jmriusers/album?id=77180 )

First photo shows where the trains are trying to allocate when they clash
(Sorry, it's rough)

Step 1 = Started all 3 auto trains (70000, 50037, 37254). 70000 is running a
cont circle around clockwise on the outer. 50037 is a cont circle running
anti-clockwise on the inner. 37254 is a train running between two reversing
loops via both of the up and down lines (around the world)
37254 waits for the S01 > S6 to clear before proceeding. S06 is end of
platform, and start/finish for up/down line transits. 37254 is sitting in the
"around the world" transit start position. All trains set to allocate 3
sections ahead.

Step 2 = 70000 & 50037 halfway through one cycle.

Step 3 = 70000 & 50037 allocated back to starting position.

Step 4 = 70000 clears crossover area, and 50037 has allocated to signal S02
but not across the crossover area yet. 37254 has "right of way" due to higher
priority, and will allocate to S06 across the crossover.

Step 5 = 37254 allocates to S06, but before the turnouts can finish moving,
50037 allocates over the top and switches one of the turnouts back to allow it
to S06 instead. Both trains stop at the crossover and wait for me to cancel
both transits.

The above situation is avoided if I only set 50037 to allocate 2 sections
ahead, forcing it to take longer for it to allocate, when 37254 is already
occupying the crossver/turnouts.

Blocking example also provided for track cirtcuits to better describe what
sections are made up of.

My panel file is also here:? ?Panel File (
/g/jmriusers/files/ProblemsBeingWorkedOn/Mitchell%20Scott%20Examples
)

I hope this gives a better detailed explination of my situation. Also, if you
notice any other silly things, please let me know. This is probably the only
automation bug I have left before it's running flawlessly for my needs, and I
do feel it is something like the way my sections are set out as you mentioned
above. I'm just not sure if it's the crossover or the turnout that is the
issue.

--
Thanks
Mitch
 

Hi Steve,

here in Australia we celebrate the rain more than the sun.. haha

Locking Turnouts didn't seem to have any effect, the same scenario happened.

I did not use the Double X-over turnout type when building my panel.. I used 4x LH/RH turnouts, and track segments to join the legs. I have one sensor for the middle crossover part, and then a logix to make that one sensor trigger two seperate internal sensors. These then trigger the two blocks on the panel (the two legs of the X).

So IN THEORY the crossover may not be the problem, but the converging of two trains coming in on one turnout for the same block, as it's only the one turnout that's getting conflicted rather than the whole crossover.

I'm a little lost on what you mean with the signalling/section on the crossover, as I do have a signal protecting the crossover from each of the legs a train can come from. The issue is that both signals are getting a "go" one right after the other and over-lapping almost, however it works fine if one of them is slightly delayed. so it's only when they happen simutainiously.

I can definitely try and manually do my SML and sections from scratch though and see if that helps!
--
Thanks
Mitch
 

Hi Steve,

TI re-built my SML and sections manually, and the same result occurs.

Did you get a chance to look through my panel file?
--
Thanks
Mitch
 

Hi Mitchell
As far as I can tell the only thing that I can see is that there is a stopping sensor that never gets fired for 50037 so it rolls on into the crossover. Try removing the stopping sensors from the sections.
I tried emailing you last week but it was returned as undeliverable.
Steve G.


On November 5, 2018 8:28:00 AM EST, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote:
Hi Steve,

TI re-built my SML and sections manually, and the same result occurs.

Did you get a chance to look through my panel file?

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
 

Hi steve,

I think I have witnessed this once before. I have IR relays for stop sensors. Whenever this odd re-allocate thing happens I hear the relay fire but it doesn¡¯t stop the loco because it has a yellow. By the time it reaches?the crossover the turnout has changed back to closed to allow it through, even though 37254 was already allocated across the crossover and through that turnout.

my email Mitchell.scott93@...

I might try and make a video of the situation occurring from both a panel perspective and a layout perspective.

i still dont know how to get a detailed log of how dispatcher is allocating, what¡¯s the best way to log that?
ive heard of adding a debug line into a default file of some kind..
--
Thanks
Mitch
 

Hi Mitchell
For debugging messages you are looking for a default.lcf file. In Linux its in
your home directory /.jmri (~/.jmri) under windows if think its in home/JMRI.
If its not there first copy it from the jmri program directory and put it there,
then it wont get overwritten during an update. Having got that far add the line,
without the quotes, "log4j.category.jmri.jmrit.dispatcher=DEBUG". The messages
will be displayed on the console and written to the session log (in that jmri
directory in home).

The signals should be at stop/danger/red/halt by default, also all sensors need
to be active/ inactive state rather than an "unknown", else some funny stuff can
happen.

I would first try removing the sensors from the sections and running with a
train length greater than the largest block. This causes a halt as soon as the
train enters the block when stopping. It makes seeing the train try and stop a
lot easier. Using the simulator I cannot get the trains to allocate over one
another. You do have all wheel resistors, or is the block going
active/inactive/active as a train goes thru a short block?

Steve G.

---------- Original Message ----------
From: "Mitchell via Groups.Io" <mitchell.scott93@...>
Date: November 8, 2018 at 4:01 PM


Hi steve,

I think I have witnessed this once before. I have IR relays for stop sensors.
Whenever this odd re-allocate thing happens I hear the relay fire but it
doesn¡¯t stop the loco because it has a yellow. By the time it reaches?the
crossover the turnout has changed back to closed to allow it through, even
though 37254 was already allocated across the crossover and through that
turnout.

my email Mitchell.scott93@...

I might try and make a video of the situation occurring from both a panel
perspective and a layout perspective.

i still dont know how to get a detailed log of how dispatcher is allocating,
what¡¯s the best way to log that?
ive heard of adding a debug line into a default file of some kind..
--
Thanks
Mitch
 

Thanks Steve,

is there any particular program I can use on Windows to edit the file? I seem to remember notepad gives a very weird format.

I will take out all the stop sensors from the sections and see how the layout reacts.

My trains are varying between block length and half block length of the main running lines, excluding smaller turnout blocks etc obviously. usually loco + 4-5 coaches.
all wheel are resistance wheels, track is cleaned regularly.

i don¡¯t think the sensors are going active/inactive/active, however I do have one block that goes inactive even though the BDL168 sensor is still active (I suspect one of my Logix has a mis-informed conditional, even my turnout controlled turntable moves occasionally). This block is no-where near the problem area, though.
I feel it¡¯s unrelated because I don¡¯t see sensors change state when the overlap occurs, I¡¯ve repeated it every time I¡¯ve run dispatcher watching sensors, blocks etc to see any oddities and I¡¯ve been dumbfounded trying to find evidence of why, which is what I¡¯m sure you¡¯re experiencing too.

I will also try a ¡°disconnected¡± version of my panel file. Loconet simulator and panel sensors to emulate blocks being occupied, and attempt to cause it manually.

Failing that, I¡¯ll edit the default file, however I do that, and debug it and do a video as well just to prove I¡¯m not crazy


although we are all a little crazy, let¡¯s be honest.

thanks! Sorry this has been such a pain.

--
Thanks
Mitch
 

As I recall notepad should work, turning off line wrap helps.
Otherwise there is notepad++ that can be found here

Steve G.


On November 9, 2018 9:27:23 AM EST, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote:
Thanks Steve,

is there any particular program I can use on Windows to edit the file? I seem to remember notepad gives a very weird format.

I will take out all the stop sensors from the sections and see how the layout reacts.

My trains are varying between block length and half block length of the main running lines, excluding smaller turnout blocks etc obviously. usually loco + 4-5 coaches.
all wheel are resistance wheels, track is cleaned regularly.

i don¡¯t think the sensors are going active/inactive/active, however I do have one block that goes inactive even though the BDL168 sensor is still active (I suspect one of my Logix has a mis-informed conditional, even my turnout controlled turntable moves occasionally). This block is no-where near the problem area, though.
I feel it¡¯s unrelated because I don¡¯t see sensors change state when the overlap occurs, I¡¯ve repeated it every time I¡¯ve run dispatcher watching sensors, blocks etc to see any oddities and I¡¯ve been dumbfounded trying to find evidence of why, which is what I¡¯m sure you¡¯re experiencing too.

I will also try a ¡°disconnected¡± version of my panel file. Loconet simulator and panel sensors to emulate blocks being occupied, and attempt to cause it manually.

Failing that, I¡¯ll edit the default file, however I do that, and debug it and do a video as well just to prove I¡¯m not crazy


although we are all a little crazy, let¡¯s be honest.

thanks! Sorry this has been such a pain.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
 

Yep, just worked it out as you replied.. haha

Okay, I added sensors to my panel for simulating trains running around the inner circle and coming across the crossover into the inner circle.

Setting starting sensors to active, creating auto-active trains for each train, and then clicking through the route of 50037 from block 01 to block 05

As soon as block 01 goes in-active, 37254 allocates to S06. And then 50037 allocates over the top. If I keep 50037 going, the both legs of a turnout that they depart using the same route, both go allocated for their seperate transits, showign that they are both deffinitely allocating at the same time and continuing on to their seperate destintions.

When the initial overlap happens at LT5, JMRI system console spits out the following:
?
118089 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118102 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118105 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118309 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118310 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118311 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118313 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118315 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118316 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118317 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118318 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118319 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09

I think this is telling me that it was EXPECTING 37254 but 50037 allocated anyway, or the other way around.. either way it is logging the conflict we are seeing. In a way, I am relived I'm not crazy!

--
Thanks
Mitch
 

¿ªÔÆÌåÓý

NotePad doesn't work well with many JMRI files. It doesn't understand the Mac/UNIX style LF line terminators we use, expecting the Windows CRLF style. As a result, all the file may show on a very long first line.

WordPad is fine, but I'm sure NotePad++ has better features for JMRI work.

--?
Dave in Australia


On 10 Nov 2018, at 12:12 PM, Steve_G <RailRodder@...> wrote:

As I recall notepad should work, turning off line wrap helps.
Otherwise there is notepad++ that can be found here

 

Hi Mitchell
I cannot get these messages. When the anti clockwise train reaches the stop signal, it stops when I fire the stopping sensor. I don't hit any more occupied sensors until the signal is not red, which doesn't happen until the ramp train clears the next section.
The basic problem is that the conflicting blocks are in 2 different sections.
Tomorrow, which could be Sunday, Monday or Tuesday depending on the earth's rotation relative to where you are....you have to love Antarctica, 24 time zones all the same time. I will endeavour to set up some manual sections/transits based on 1 section per block to see if that helps.
Steve G.



On November 9, 2018 8:32:50 PM EST, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote:
Yep, just worked it out as you replied.. haha

Okay, I added sensors to my panel for simulating trains running around the inner circle and coming across the crossover into the inner circle.

Setting starting sensors to active, creating auto-active trains for each train, and then clicking through the route of 50037 from block 01 to block 05

As soon as block 01 goes in-active, 37254 allocates to S06. And then 50037 allocates over the top. If I keep 50037 going, the both legs of a turnout that they depart using the same route, both go allocated for their seperate transits, showign that they are both deffinitely allocating at the same time and continuing on to their seperate destintions.

When the initial overlap happens at LT5, JMRI system console spits out the following:
?
118089 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118102 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118105 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118309 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118310 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118311 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118313 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118315 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118316 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09
118317 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Allocation request section does not match active train next section to allocate
118318 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Section to allocate S01:S06
118319 [AWT-EventQueue-0] ERROR jmri.jmrit.dispatcher.AutoAllocate? - Active Train expected S06:S09

I think this is telling me that it was EXPECTING 37254 but 50037 allocated anyway, or the other way around.. either way it is logging the conflict we are seeing. In a way, I am relived I'm not crazy!

--
Thanks
Mitch

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
 

Hi Steve,

Wow! Maybe I should just transport my layout to your computer haha

Some of my block sensors are internal sensors, and from a logixs are triggered by the actual sensor. This was more about timing and ¡°if sensor is active turnout is closed, set internal sensor to inactive¡± to smoothen out or delay dispatcher allocation. The only thing I haven¡¯t tried is disabling the Logix associated with that crossover.
But then again, you have the same file so in theory they are working as expected rather than causing issues.

I have two computers running the same panel via drop box (one for editing in the office and one in the garage running the layout, 3 screens in the office makes editing much easier. I only run one at a time though)
both computers exhibit the same errors, one with PR3 into a DCS200 and the other only using Loconet simulator.

I might also try a brand new panel from scratch (it¡¯s an export from Anyrail from years ago, and since there¡¯s been new block assignment updates to the anyrail> JMRI import I might give it a go and then import my Logix.

please do let me know if adjusting the sections work out!
--
Thanks
Mitch
 

Hi Mitchell

It didn't rain today. Its been a couple of weeks since that happened. When
people pray for rain they should be very specific about where they want it
delivered....:)

I am working on the assumption that sensor LS74 (user name 10) is a real sensor
for Block user name 06, and all the other around about the cross over are just,
well, real.

I have every confidence that it can be solved by only messing with sections
around that spot.

I can solve the problem programatically but the collateral damage to anyone
running a single line with passing places would be pretty messy.

Steve G.

---------- Original Message ----------
From: "Mitchell via Groups.Io" <mitchell.scott93@...>
Date: November 11, 2018 at 3:49 PM


Hi Steve,

Wow! Maybe I should just transport my layout to your computer haha

Some of my block sensors are internal sensors, and from a logixs are triggered
by the actual sensor. This was more about timing and ¡°if sensor is active
turnout is closed, set internal sensor to inactive¡± to smoothen out or delay
dispatcher allocation. The only thing I haven¡¯t tried is disabling the Logix
associated with that crossover.
But then again, you have the same file so in theory they are working as
expected rather than causing issues.

I have two computers running the same panel via drop box (one for editing in
the office and one in the garage running the layout, 3 screens in the office
makes editing much easier. I only run one at a time though)
both computers exhibit the same errors, one with PR3 into a DCS200 and the
other only using Loconet simulator.

I might also try a brand new panel from scratch (it¡¯s an export from Anyrail
from years ago, and since there¡¯s been new block assignment updates to the
anyrail> JMRI import I might give it a go and then import my Logix.

please do let me know if adjusting the sections work out!
--
Thanks
Mitch
 

Hi steve,

Cheering! If you could send some of your missing rain this way, that would be fabulous.. haha

I deleted all of my SML and sections, auto-regenerated and then deleted sections S01:S06 and S02:S06.

I then created a sections
S01:BLOCK40 (Blocks 08B & 40)
S02:BLOCK6 (Block 06)
BLOCK6B:S06 (Block 06B & 01)

In theory this is seperating the LT5 turnout from both of the blocks coming into it.

This solved the problem of overlapping, however now the train at S01 allocates to across the crossover TO LT5 (BLOCK6:S06 boundary) and prevents the outer circle train allocating, even though the S01 train has a red signal.

Am I on the right track but havent gone deep enough yet? or am I skewing away from what you beleive could be the answer?

In a perfect world, the two up and down lines would allocate freely, and then when 37254 sees an "opening" or free path to S06 it allocates across and the other two trains wait for the crossover and anything head to be clear.
I'd have thought choosing a Priority in auto train creation would decide which train gets the allocation when they want the same section, But I've never seen it come into effect.

I do feel like if we are having opposite experiences while testing the same file with the same sequence of events and sensors, there has to be an inconsistancy between us that could be the clue to the problem, maybe I have an issue with my JMRI that you do not?

--
Thanks
Mitch

1 - 20 of 39