Hello,?
i am new on this forum and a new user of JMRI. I find huge difficulties for putting signals for managing the turnouts of a marshalling yard with 8 tracks. As I wish to use dispatcher to send my train to my yard, I wonder which method I have to use to put signals. Putting signals directly at every turnout, or mast signals or a feather signal ? Do I have to have separate blocks for each turnout or a global block for all is ok ? I already did the TCO completed., and put sensors on each track and this part is working fine.?
thank you for your help?
|
Hi
First thing I noticed was the dispatcher option was for signal heads SSL, and
the layout uses Signal Masts.
STeve G.
toggle quoted message
Show quoted text
---------- Original Message ----------
From: simon.berry@...
Date: April 8, 2020 at 2:26 PM
Hi
I have a simple back and forth layout for testing purposes. With some help
from Dave Sands in another post, and studying his back and forth demo for
dispatcher I have managed to get it working, of sorts....
There are embedded infra red sensors at either end of the track in order that
the train can reverse direction at that location (there are similar ones in
the middle to mark where the train should pause at the station).? However, the
train "ignores" these sensors and just keeps going!? I've set up these sensors
in the appropriate Section as Stopping Sensors, but maybe that's not the
correct place?
I've uploaded my files under Simon Berry in t4h ProblemsBeingWorkedOn folder,
any help most appreciated.
Simon
|
Hi
I have a simple back and forth layout for testing purposes. With some help from Dave Sands in another post, and studying his back and forth demo for dispatcher I have managed to get it working, of sorts....
There are embedded infra red sensors at either end of the track in order that the train can reverse direction at that location (there are similar ones in the middle to mark where the train should pause at the station).? However, the train "ignores" these sensors and just keeps going!? I've set up these sensors in the appropriate Section as Stopping Sensors, but maybe that's not the correct place?
I've uploaded my files under Simon Berry in t4h ProblemsBeingWorkedOn folder, any help most appreciated.
Simon
|
See Digitrax Manual v2 p56-57, sections 9.3.6 and 9.3.7.
--
Alain LM
|
Gents,
All decoders have PWM support for the motor: this is the basis of DCC!
This being said, the question is whether the decoder SW allows to configure dimming for outputs. As I wrote in the first response to this thread, Digitrax has very limited capabilities wrt dimming. Please RTFM, I indicated the references below. JMRI will not do anything more than the decoder can do.
--
Alain LM
|
For the flashing not to be visible, it needs to be done about 50 or more times a second. Then, the effect becomes dimming, not flashing. For 10 brightness steps, then, the flash circuit needs to divide each second into 500 or more parts: ten for each of those 50 or more flashes. For 100 brightness steps, 5,000 or more parts per second are needed. That's why a dedicated PWM function is needed: trying to control the pulses otherwise isn't possible or eats up too much of a processor's operations per second.
Don
|
I think nobody from RailModeller Pro mentioned it to us, so nobody here knew to add it to the list. If a program is exporting the right format, JMRI doesn¡¯t need to know that the program exists; JMRI just imports the file. We add a mention to our web site just so people can find that program. The RMP release notes seems to say a bit about it: (Google also found a discussion that indicates the RMP people have put some real effort into doing this right: ) Has anybody tried it? Happy to add it to the web site, but it would be nice to have at least a minimal test first. Bob On Apr 8, 2020, at 7:04 AM, Don Stafford <donstaff1@...> wrote:
I see that RailModeller Pro as of version 6.1 can export to JMRI to be used inPanel Pro, but this does not show up in JMRI as one of the programs that JMRI can import. What am I missing? -- Bob Jacobsen rgj1927@...
|
Railroads make a distinction between ¡°vital¡± and ¡°non-vital¡± aspects of their control (i.e. signaling) operations. Vital signaling is just that: Its proper operation prevents the accidents and the loss of life. For about the last 100 years, these systems have been carefully designed and built to avoid collision when properly maintained and operated. Mistakes happen (particularly on model railroads, where rules exams are uncommon) but a _lot_ of work has gone into reducing those. Lit signals can be part of the vital signaling. But they might not be the only part. They might not even be present. For example, a Time Table and Train Order (TT&TO) railroad doesn¡¯t have to have lit signals at all. It can operate safely using just the Time Table and Train Orders. Signals were often added to TT&TO railroads as an additional layer of safety, and/or an efficiency improvement (more of that below) On the other hand, a modern CTC railroad with signals around mainline switches (¡°Control Points¡±) and Automatic Permissive Block (APB) signals along the mainline has a complete, automatic set of vital lit signals. Obey those, and your train is safe from other trains also obeying them. So what more is needed? The vital signals keep you safe. One way to do that is to never let a train move. That¡¯s certainly safe, but also inefficient; not a way to run the railroad! You need a method to tell which trains to move where and when. This is usually called ¡°dispatching¡±. On the TT&TO railroad, the Time Table gives a basic framework for efficient running, and the person dispatching (¡°the dispatcher¡±) can use Train Orders to add more efficiency by overriding or adding to that basic framework. But if there are signals, they operate independently to still provide vital protection. If the dispatcher sends a train along a mainline behind another without waiting for the first to arrive at the next station, and the first train gets stopped for some reason, vital signals will prevent a rear-end collision. That vital protection is necessary if you want to run more efficiently by putting more than one train on the line at the same time. But note that (at least for the early lit signaling systems called ABS), the lit signals do not reliably prevent a head to head collision: That part of the vital protection has to come from the TT&TO system. On the CTC and APB railroad, you have a much more granular level of control so you can be more efficient. The underlying lit signal system _completely_ covers safety; with post-1940 USS CTC systems, the dispatcher¡¯s operations on the panel can¡¯t enable a collision. The dispatcher can be very inefficient; an important train can get stuck in a siding while the dispatcher does other things. But the vital aspect has been removed from human operations. To make that happen, the CTC and APB system has to remove all race conditions. That requires covering lots of cases, but of course there were a lot of serious people working on getting it right. Carsten Lundsten¡¯s web site has a lot of tutorial examples on all of this: Bob On Apr 8, 2020, at 5:00 AM, matt peeler <mtler1930@...> wrote:
Reading Ken's historical response made me wonder wouldn't a real dispatcher have made a time table calculation that no two trains would hit opposing (on the single track) "at the same time"?? Even miles apart, it would be a given that if both trains got to their control point and "cleared" to enter the single track that inevitably there would be a collision since both trains were allowed on the track with probably the authority to travel at best possible speed. Wouldn't they have staggered the "arrival time" to be at that point at a different time so this wouldn't happen?
For train modeling, couldn't that be done as well or some concept like that in JMRI??
More of a point to ponder and not something JMRI would have to program but rather a way to avoid this. If the train doesn't get to its assigned control point at the proper time, it has to wait if early, or assume another train is in the block unless cleared by special communications from a dispatcher?? Might be showing my ignorance on dispatching as well but it would seem that not only automated dispatching as well as time tables would be needed for "real trains" that might not be as readily available for modeling?
On Tue, Apr 7, 2020 at 5:59 PM Ken Cameron <kcameron@...> wrote:
Don W,
Those race conditions are why something other than the signals had to
control who was supposed to move first. Some signal systems got in to
interesting ideas like biasing the two directions or something I recall
called 'double approach' but I don't recall the details well enough to say.
They were part of APB which tried to improve the safety over long single
tracks. APB uses a waterfall from one end to the other of the single track
so the distant signal would show stop to the opposing direction. There are
still races possible as I understand it, but I'm not sure how they handled
it. These were more popular in the US west which had many miles between
passing points and the dispatcher usually had a couple trains going one way
before opposing traffic would try coming the other way.
It all comes back to why the railroads used signals only for safety of not
running into another train. Only in CTC, where they were controlled to not
show the clear, until the dispatcher had decided who was supposed to move
first. Everyone else waited at the control point until the dispatcher
decided otherwise.
Can you automate some of the dispatching, yes but it isn't the simplest way
to do things. But for models, I've found way too many people 'fear being the
dispatcher'. I even did a clinic in 2014 with that as the subtitle.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org
-- Bob Jacobsen rgj1927@...
|
Hi David,
I can't really think of the use of more than one. If you choose to go with more than one, I fail to see how it would help to have two. Three might be useful as a stopping aid (engine has nearly reached 'danger zone', so stop now). But good automation should know about speed, length of the train and (importantly) the occupancy detection of the switch/turnout/points just passed over going 'free' to draw all the conclusions it needs. I'm planning on just the one. As I'm still in the planning stage, now would be a really excellent time to hear if I'm wrong, though!
Wouter
What would be the best number of detection zones between turnouts, especially on passing tracks, for good automation control, I am planning two, but should it be three. Not sure what the rule of thumb is, I am using jmri. Have a great day
Cheers David mitchell
|
David,
? ? ?Keep in mind for the train to stop in a passing siding the whole train has to fit in the one detection zone (or section).
Roger
|
Just a small note in case you are not aware - - PWM is Pulse Width Modulation. ?A method to alter the duty cycle of the voltage to the "load" or light. ?Check out youtube for arduino and pwm operation.
Bob s
|
I see that RailModeller Pro as of version 6.1 can export to JMRI to be used inPanel Pro, but this does not show up in JMRI as one of the programs that JMRI can import. ?What am I missing?
--
Donstaff
|
What would be the best number of detection zones between turnouts, especially on passing tracks, for good automation control, I am planning two, but should it be three. Not sure what the rule of thumb is, I am using jmri. Have a great day
Cheers David mitchell
|
Matt,
In the CTC dispatched track, for the DS to clear a signal for a direction
the logic within the CTC system would lock out being able to clear the other
direction.
In TT&TO, one train or the other would have 'right over' by class,
direction, or train order. It was never questionable as to who had right of
movement over another.
In TW, I'm not so sure. I always run it as find destination and work back to
the train to grant authority. The destination I pick always allows for
meeting a train safely. The base rule in TW is only one train in any
allocated piece of track.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org
|
Matt,
The can of worms that's been opened is a big one, and to the brim filled with creepy-crawlies. Your solutions seem to be going in the direction of people knowing what should happen. A fine recipe for disaster. Fortunately, in the world of model rail, we can get away with a lot more as we can mostly actually see what's happening int he adjacent station anyway. For the real world, not so much!
Solutions to single-track running often incorporated tokens that a driver had to have in his possession. Which placed severe restrictions on operations (two trains in the same direction would have to be split by an upcoming one bringing the token back), but it was pretty safe. The later method with signal boxes communicating with one another and actually agreeing on which train to let pass in what direction was a huge step forward, possible as soon as instantaneous communication became viable (telegraph, telephone).
It's that latter mechanism that I plan to model, and it's fun figuring out what to do to make it all (including timetables and signalling) work together.
Wouter
Reading Ken's historical response made me wonder wouldn't a real dispatcher have made a time table calculation that no two trains would hit opposing (on the single track) "at the same time"?? Even miles apart, it would be a given that if both trains got to their control point and "cleared" to enter the single track that inevitably there would be a collision since both trains were allowed on the track with probably the authority to travel at best possible speed.? Wouldn't they have staggered the "arrival time" to be at that point at a different time so this wouldn't happen?
For train modeling, couldn't that be done as well or some concept like that in JMRI?? More of a point to ponder and not something JMRI would have to program but rather a way to avoid this.? If the train doesn't get to its assigned control point at the proper time, it has to wait if early, or assume another train is in the block unless cleared by special communications from a dispatcher??? Might be showing my ignorance on dispatching as well but it would seem that not only automated dispatching as well as time tables would be needed for "real trains" that might not be as readily available for modeling?
On Tue, Apr 7, 2020 at 5:59 PM Ken Cameron < kcameron@...> wrote: Don W,
Those race conditions are why something other than the signals had to
control who was supposed to move first. Some signal systems got in to
interesting ideas like biasing the two directions or something I recall
called 'double approach' but I don't recall the details well enough to say.
They were part of APB which tried to improve the safety over long single
tracks. APB uses a waterfall from one end to the other of the single track
so the distant signal would show stop to the opposing direction. There are
still races possible as I understand it, but I'm not sure how they handled
it. These were more popular in the US west which had many miles between
passing points and the dispatcher usually had a couple trains going one way
before opposing traffic would try coming the other way.
It all comes back to why the railroads used signals only for safety of not
running into another train. Only in CTC, where they were controlled to not
show the clear, until the dispatcher had decided who was supposed to move
first. Everyone else waited at the control point until the dispatcher
decided otherwise.
Can you automate some of the dispatching, yes but it isn't the simplest way
to do things. But for models, I've found way too many people 'fear being the
dispatcher'. I even did a clinic in 2014 with that as the subtitle.
-Ken Cameron, Member JMRI Dev Team
|
Reading Ken's historical response made me wonder wouldn't a real dispatcher have made a time table calculation that no two trains would hit opposing (on the single track) "at the same time"?? Even miles apart, it would be a given that if both trains got to their control point and "cleared" to enter the single track that inevitably there would be a collision since both trains were allowed on the track with probably the authority to travel at best possible speed.? Wouldn't they have staggered the "arrival time" to be at that point at a different time so this wouldn't happen?
For train modeling, couldn't that be done as well or some concept like that in JMRI?? More of a point to ponder and not something JMRI would have to program but rather a way to avoid this.? If the train doesn't get to its assigned control point at the proper time, it has to wait if early, or assume another train is in the block unless cleared by special communications from a dispatcher??? Might be showing my ignorance on dispatching as well but it would seem that not only automated dispatching as well as time tables would be needed for "real trains" that might not be as readily available for modeling?
On Tue, Apr 7, 2020 at 5:59 PM Ken Cameron < kcameron@...> wrote: Don W,
Those race conditions are why something other than the signals had to
control who was supposed to move first. Some signal systems got in to
interesting ideas like biasing the two directions or something I recall
called 'double approach' but I don't recall the details well enough to say.
They were part of APB which tried to improve the safety over long single
tracks. APB uses a waterfall from one end to the other of the single track
so the distant signal would show stop to the opposing direction. There are
still races possible as I understand it, but I'm not sure how they handled
it. These were more popular in the US west which had many miles between
passing points and the dispatcher usually had a couple trains going one way
before opposing traffic would try coming the other way.
It all comes back to why the railroads used signals only for safety of not
running into another train. Only in CTC, where they were controlled to not
show the clear, until the dispatcher had decided who was supposed to move
first. Everyone else waited at the control point until the dispatcher
decided otherwise.
Can you automate some of the dispatching, yes but it isn't the simplest way
to do things. But for models, I've found way too many people 'fear being the
dispatcher'. I even did a clinic in 2014 with that as the subtitle.
-Ken Cameron, Member JMRI Dev Team
|
Unless the decoder has a PWM device in you will not dim an LED. I tried and all I got was a flashing?light.
Dennis
Thank you all for your replies and good suggestions. Nobody commented on the 'fantom' decoder list so I'm wondering if I saw it somewhere unrelated to Digitrax/JMRI. Perhaps TCS Decoders. Anyway, thanks again.
? ? ? ?Bob
-- Dennis G Edgar Lead Auditor? 133839 mobile: 083 6470569
|
With some trepidation concerning the possible double hijacking of a thread, a lot of useful prototype information can be found at:
concerning the possibility of opposing trains entering a single track at the same time.
Unfortunately for us modelers, extensive distance between sidings on our layouts is not a problem that we get to puzzle with. It is interesting to see even a simple example show up as a JMRI issue.
Cliff in Baja SoCal
|
Locked
Re: Signal Heads without Turnouts
Absolutely, and I'm thinking of doing that to make it possible to apparently run convoys of very slow rack railway trains prototypically!
Wouter
The other advantage of more signals than turnouts (dividing a single track into multiple signaled parts) is one train could follow another more closely. Extreme example: a single block mainline on an transcontinental route: only one train allowed on the whole 3,000 miles of track!
Don Weigt Connecticut
|
Don W,
Those race conditions are why something other than the signals had to
control who was supposed to move first. Some signal systems got in to
interesting ideas like biasing the two directions or something I recall
called 'double approach' but I don't recall the details well enough to say.
They were part of APB which tried to improve the safety over long single
tracks. APB uses a waterfall from one end to the other of the single track
so the distant signal would show stop to the opposing direction. There are
still races possible as I understand it, but I'm not sure how they handled
it. These were more popular in the US west which had many miles between
passing points and the dispatcher usually had a couple trains going one way
before opposing traffic would try coming the other way.
It all comes back to why the railroads used signals only for safety of not
running into another train. Only in CTC, where they were controlled to not
show the clear, until the dispatcher had decided who was supposed to move
first. Everyone else waited at the control point until the dispatcher
decided otherwise.
Can you automate some of the dispatching, yes but it isn't the simplest way
to do things. But for models, I've found way too many people 'fear being the
dispatcher'. I even did a clinic in 2014 with that as the subtitle.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.org
www.syracusemodelrr.org
|
Bob Jacobsen
Roger Merritt
Don Stafford
Ken Cameron
dennisedgar7