Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
Search
Locked Dispatcher - SML - auto-allocation problem
|
Hi Mitchell
toggle quoted message
Show quoted text
I did nearly the same thing. I started by using a grade crossing in the centre of the double crossover for block 40 you had made it with two lines crossing so half of block 40 was unattached to anything. If you can get the each switch and the crossing into separate sections it will make life less complicated, currently the 2 west switches are in the same section. I set block 06B and 01 to a section each. What I was going to do next was to re do the transit flagging the new section for block 01 (with extra signals) as safe along with the S106:107 and S41:42. The first and last sections do not need to be flagged. This transit can then be allocated by safe sections , which will only allocate if all sections between the safe sections can be allocated at once, so it doesnt stop anywhere else. To do the job properly you will need to break up some of the larger sections, and internal signals cost you nothing. Steve G. ---------- Original Message ---------- |
|
Hi Steve,
Results!! I took your advice and separated all 5 points and the crossover into seperate blocks and each its own section. The crossover is now a level crossing as well. ive also added a few extra smaller sections around the layout, and now using Safe Sections. This seems to be working now. I auto-generated my SML and then manually built my sections. Because I don¡¯t have any more detection circuits, I¡¯ve done some logixs that trigger based on one sensor and the state of the turnouts, which triggers internal sensors that the blocks are assigned to. A seperate conditional for every possible train movement exists, as well as an ¡°off¡± conditional. The crossover is on an auto-reverser on one detection section, and the outer rails of it are on another detection section. I have made a Logix for this that if either of them are triggered it triggers the internal sensor for both blocks of the crossover. I thought about adding extra virtual signals, however if I added any between real signals it might detract from the realism of a yellow before a red on the real signals. signals 1 through to 24 are real signals, all others are virtual due to not being visable. Ive only tested this virtually, and I will report back tonight on the results of trains runnning. In theory I end up with 4 trains running around each other! -- Thanks Mitch |
|
Mitchell
toggle quoted message
Show quoted text
This is very good news. I wait with baited breath on the outcome. Steve G. On November 15, 2018 5:30:59 PM EST, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote: Hi Steve, --
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
Hi Steve
IT WORKS! had to do a few sensor-delay logix to make it really smooth and reliable going across smaller sections thar have multiple possible routes, but it's become quite solid! Been running around all day. I do seem to hit one problem where a train doesnt allocate next section but the train keeps running. I feel this is under the same catagory as when block tracking fails and the train becomes a run-away, although in this instance the block value is still changig correctly. However I will investigate more and make a new thread if need be. I do have ONE request for future JMRI releases. Starting off with when one train is allocated, and another is waiting for that train to pass so it can allocate. Once the allocated train has passed, and the sensor has gone INACTIVE and the block UNOCCUPIED, the second train allocates instantly. This "instantanious" allocation is a bit too guick for the GUI and the one section that WAS occupied, now shows un-occupied instead of allocated. The train works fine going through it, so i feel its more a graphical thing with the layout editor. But in my (simple) mind, maybe a few milliseconds between block un-ocupied and allocating blocks might smoothen this out a bit? Thank you for ALL of your help, Steve! -- Thanks Mitch |
|
Nevermind.. Found a new bug.
There's a on-off situation that happens where a train in block 41 is waiting to allocate across the crossover, and a train in block 07 wants to allocate to block 41 and beyond . The allocation can't switch the turnouts towards 41 because it is occupied, but the signal for the train in 07 is green to go through to block 09, so the train doesnt stop even though it hasnt allocated any further. Before all these changes I seem to remember signals staying red until allocated, which meant that train would wait at 07 at a red until it could allocate to 41 and beyond and then get a green for go . I do know that non of my sections have direction sensors anymore. They were always auto-generated, so maybe manually generating them will work? I am not sure how to start that process, however. Am I of the correct thinking here? or missing something? -- Thanks Mitch |
|
Hi Mitchell
toggle quoted message
Show quoted text
Directions sensors will definitely help. However will look as I thought we had a failsafe about trains entering section that weren't theirs. Steve G. On November 18, 2018 3:45:03 AM EST, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote: Nevermind.. Found a new bug. --
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
Hi Steve
I just read on the JMRI page that SML doesn¡¯t really use direction sensors, or at least that how it read to me. can you explain how they help? Might help be in adding them and testing to make sure they are doing what they are supposed to be doing. by failsafe you mean a signal being red if section ahead isn¡¯t allocated? I might re-upload my current file tonight for another look. after all the changes made. -- Thanks Mitch |
|
Hi Mitchel
toggle quoted message
Show quoted text
You add can add the directiion sensors to the SML manually under sensors. They are mainly used for single track running, but they will keep the signal red if you test for it ACTIVE, inactive means that section is allocated in the specified direction. Other things that can be added are checks conflicting signal masts, and any sensors you set up for other reasons. By fail safe I mean that the train doesn't enter the section ahead if its not allocated even if the signal is green. Steve G. ---------- Original Message ---------- |
|
Steve,
Yep that makes sense! I don't feel in this case it will help, as TECHNICALLY a train can go both closed and thrown routes from this position. (S04 can go to S92 OR S25) so the green isn't wrong, it's only wrong for that trains transit which isn't allocating do to the blockage of another train. Taking away the blockages and letting the train run around it has no problems. Yes I feel that's whats not happening. It does stop just after the signal in the next block.. and when the other train is out of the way, if I back the train up manually before the signal, it then allocates and all is well again. Sort of like a re-wind and try again. However if I "rewind" before the allocation is available, it will try and stop in the next block again. Very odd behaviour! The signal S04 is showing green for 08A(LT6 + curve) > 08B(LT4) > 08C(LT2) > 08D(LT1) > 09 to S25 The allocation wants from S04 to 08A>08B>08C>08D>41(Occupied) to S92 I have another spot on the layout that has two directions that one train can take (LT22) so I might try the same situation there and see if it fails or works correctly. That will isolate a global problem or a situational problem. I'll upload the file as it is now in a few hours when I have access again. -- Thanks Mitch |
|
Mitchell,
Following Steve's note above I've added the direction sensors to signal logic so that signals are set to danger when the section isn't allocated for my single track segments. ?It seems to work fine. ?Note that if you are checking the section protected by the signal as part of the SML, the check has to be for the sensor being INACTIVE (i.e allocated for the relevant direction). The conditions in the SML logic have to evaluate to TRUE to allow the signal to be set in accordance with the source mast. ?As Steve says the when the sensor is ACTIVE the signal is red. Paul |
|
Hi Mitchell
toggle quoted message
Show quoted text
I have downloaded your file and started to look at it. The to do list is a tad backlogged but hopefully will have more time this weekend. Steve G. On November 21, 2018 4:59:50 AM EST, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote: Unsucessful test on the other area that has the same situation. Signals stay green regardless of allocationm so the fail safe isnt working in this file. --
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
Steve,
Yes that makes sense, my loco stopped after the green signal S04 because it wasn¡¯t allocating any further. so in that case, I¡¯m I pretty much screwed on getting this to work? technically the signal SHOULD be green for both closed and thrown for LT1. A manual train has right of way for both if they are clear. its when LT1 thrown is not clear, so dispatcher doesn¡¯t assign the route, so the signal stays green for closed and it goes past until that failsafe kicks in. I¡¯m failing to see a workaround at this point apart from playing with direction sensors in SML. I just hope then when NOT using dispatcher, my signals stay clear and don¡¯t all turn red bexuse there¡¯s no allocations. -- Thanks Mitch |
|
Hi Mitchell
toggle quoted message
Show quoted text
If you are going to run dispatcher either manual or auto engineers, then the signals need to be set for that. Red unless allocated and clear. These don't have to be real signals. The real signals on the layout can be plunked down where you like and the logic set to show what ever you like. All the layouts I am involved in have at least 2 different layout panels depending on what's going on, but you can combine them and use a script to hide or show the signals you are using. Steve G. On November 29, 2018 4:26:18 PM EST, "Mitchell via Groups.Io" <mitchell.scott93@...> wrote: Steve, --
Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
Another option could be to set up a 'route'. ?The route would set all the relevant direction sensors that are referenced by SML to INACTIVE, ie. simulating the protected segment being allocated. ? When not using dispatcher use the route to set the sensors and the signals should show the aspect as determined by the rest of the SML. ?This suggestion comes with a health warning as I haven't tried it!
Paul |
|
Hey guys,
After reading the suggestions and playing around for a bit with different situations, a very simple yet effective solution came to me. at the specific location, a signal is showing green regardless of which of two directions it can go. This means the train is running past its allocation because the signal is still allowing it. in the transits, I have added a ¡°set sensor¡± action when the train enters the section before the signal. this sensor triggers a logix that puts the signal into held if certain criteria are met. If the route it clear, this clears the signal again and the train is on its way, resetting the logix ready for the next train.? Basically the logix is making the same decision as dispatcher is on when is appropriate to allocate, keeping the signal held until allocation happens. this probably isn¡¯t a conventional way to do things, kind of cheating in a way, but it works so I¡¯ll run with it for now. I like that we have a link between transit actions and logix. this got me thinking that it would be amazing to incorporate some decoder control by logix. ill start a new thread for my suggestions. -- Thanks Mitch |
to navigate to use esc to dismiss