JMRI Model Railroad Interface

Walt,

About 3 - smoothing the throttle.

The three parameters for each signal head aspect (forgot to include doing signal masts, someday) are the throttle setting (0-100%), the inch/second at that speed, and the last is the distance covered to go from that speed to the next lower setting. So for Red, that last box is what the loco takes when running at the red speed to come to a stop.

That last value, time taken to drop from that to a lower speed, is time more appropriate or should it be a distance to change the speed. Using the Red example, if it was a distance then the time delay for entering a Red block would be ((BlockLength / InchPerSecond) - StopTime) * 0.90 which should give us a 10% safety factor for the time delays in the sensors and software.

Now if the value was instead the distance it takes to change speeds, the calculation would be ((BlockLength - StopDistance) / InchPerSecond) * 0.90 to get that same idea of having our nose at the 10% block left between us and the signal.

I guess my biggest question is which is easier to measure, time to stop moving, or distance covered?? Unfortunately this gets even harder to figure in the other speed changes as I see it, we only have the eyeball to tell if it finished changing speeds or not. Anybody have a scale radar gun?? In both cases above, we still have a bit more of a pad due to the real speed being something less that InchPerSecond as it comes to the stop.

Another thing I saw was that for a 75" block it was stopping about plus/minus 3" each time so a 6" spread. I figure that is a function of what else the LocoNet, Command Station and computer were doing at that moment. But this did enforce to me that you can't get very exact but generally close enough.

One thing writing it out this way I see about my calculation is I forgot to factor the time or distance it takes to come from yellow to red speed when you entered the block. So that will get added too.

About #4 - sensing the end of the train for stopping

Here the idea is a supplement to the timeout. It would stop the train based on the timer OR seeing the tail block go clear, whichever happened first. My thought here was for normal meets, it was more important to make sure you didn't overshoot the stop so once you knew your tail was clear, and then stopping would be ok.

-ken cameron
Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
CNY Modelers http://www.cnymod.com/
Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
Member JMRI Developer Team http://www.jrmi.org/
mailto: kcameron@...
In the Upstate New York US area of the world

-----Original Message-----
>From: Ken Cameron <kcameron@...>
>Sent: Feb 28, 2011 10:06 AM
>To: "Discussions about changes to the code, design, intent,	etc" <jmri-developers@...>
>Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
>
>Walt,
>
>About 3 - smoothing the throttle.
>
>The three parameters for each signal head aspect (forgot to include doing signal masts, someday) are the throttle setting (0-100%), the inch/second at that speed, and the last is the distance covered to go from that speed to the next lower setting. So for Red, that last box is what the loco takes when running at the red speed to come to a stop.
>
>That last value, time taken to drop from that to a lower speed, is time more appropriate or should it be a distance to change the speed. Using the Red example, if it was a distance then the time delay for entering a Red block would be ((BlockLength / InchPerSecond) - StopTime) * 0.90 which should give us a 10% safety factor for the time delays in the sensors and software.

This does not work because the speed we entered the block at was not Red Speed. For some amount of time we were traveling at Yellow speed .
>
>Now if the value was instead the distance it takes to change speeds, the calculation would be ((BlockLength - StopDistance) / InchPerSecond) * 0.90 to get that same idea of having our nose at the 10% block left between us and the signal.

This does not work because Distance is not time. The StopDistance takes some amount of time.


>
>I guess my biggest question is which is easier to measure, time to stop moving, or distance covered?? Unfortunately this gets even harder to figure in the other speed changes as I see it, we only have the eyeball to tell if it finished changing speeds or not. Anybody have a scale radar gun?? In both cases above, we still have a bit more of a pad due to the real speed being something less that InchPerSecond as it comes to the stop.

For the formula to be accurate both must be know. 
1. what is the distance covered for a loco to come to a stop if it is told to on entering a block? This is the Stop momentum of the loco and can easily be measured and set. In the block table set a block to zero length and with RT enter the block. How many inches did it cove from the start of the block until it stopped. That IMHO is the StopDistance. I have all my locos adjusted so this is 30". 

2. How long did it take the loco to stop(StopTime)? Now that we know the loco will stop in the above distance we need to adjust the StopTime for a block that longer than the stop distance so it stops at the correct spot. If we have the stop time as 0 it should stop about 30" before it should on my layout if the StopSpeed is correct. So just adjust the StopTime until it stops in the correct place.

If the locos have different StopDistance and different StopTimes than those fields need to be added for each loco.


>
>Another thing I saw was that for a 75" block it was stopping about plus/minus 3" each time so a 6" spread. I figure that is a function of what else the LocoNet, Command Station and computer were doing at that moment. But this did enforce to me that you can't get very exact but generally close enough.

In RT2 you had line 185 delay of 1000, if the loco was traveling at 10 "/sec at RedSpeed this caused a variance of 10". I changed that to 20. I see that in RT3 you have changed it to 100.
>
>One thing writing it out this way I see about my calculation is I forgot to factor the time or distance it takes to come from yellow to red speed when you entered the block. So that will get added too.
>
>About #4 - sensing the end of the train for stopping
>
>Here the idea is a supplement to the timeout. It would stop the train based on the timer OR seeing the tail block go clear, whichever happened first. My thought here was for normal meets, it was more important to make sure you didn't overshoot the stop so once you knew your tail was clear, and then stopping would be ok.

Again, if we can get the train to stop in the correct spot in relation to the signa, I expect 10" plus or minus 5", the end of train is were it is.

The 10% fudge factor gets progressively bigger the longer the block gets. If I leave that in the formula I have to increase my block lengths to compensate for it. So my block lengths are not truly the length of the block. Or how far I want to train to travel before it stops. (Different issue)

Try the formula I sent you. I find it works much better for various block lengths.
>
>-ken cameron
>Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
>CNY Modelers http://www.cnymod.com/
>Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
>Member JMRI Developer Team http://www.jrmi.org/
>mailto: kcameron@...
>In the Upstate New York US area of the world
>
>
>
>------------------------------------------------------------------------------
>Free Software Download: Index, Search & Analyze Logs and other IT data in 
>Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
>generated by your applications, servers and devices whether physical, virtual
>or in the cloud. Deliver compliance at lower cost and gain new business 
>insights. http://p.sf.net/sfu/splunk-dev2dev 
>_______________________________________________
>Jmri-developers mailing list
>Jmri-developers@...
>https://lists.sourceforge.net/lists/listinfo/jmri-developers


Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

>
>I'd suggest keeping it a the lowest common denominator which currently 
>is the "block" it already has the option for length, curvature.  I'm 
>already looking at putting a "speed limit" field in to go with the 
>SignalMast Logic to help determine mast appearance.
>
>Regards
>Kevin

Kevin:
Please, oh please, look at adding west/North length and East/South length fields.
If my train is approaching a Turnout from the points side I want to know that the block is shorter for stopping than if the turnout was at the start of the block when going the other direction. This would also help on grades where one direction is up and the other down.
Walt

Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

-----Original Message-----
>From: Kevin Dickerson <kev.public@...>
>Sent: Feb 28, 2011 11:27 AM
>To: "Discussions about changes to the code, design, intent,
>	etc" <jmri-developers@...>
>Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
>
>On 28/02/2011 17:04, Ken Cameron wrote:
>> Kevin,
>>
>> Glad to hear that. Now for the guesswork of what sort of units to use
>> for it!! And then how a loco should respond to it.
>>
>> I guess one of my general questions is how the speed limits vs
>> aspects go together. Like a clear signal, but on a block with a speed
>> limit equal to a limited aspect, should the loco be doing anything
>> different in response or is it identical, namely going a limited
>> speed?? In my mind these are cloudy ideas at the moment and will love
>> to see some further discussion about how these ideas interact.
>
>It is a cloudy issue, I think the speed has to be a numerical value, 
>rather than being a descriptive one such as approach slow, otherwise 
>there is no way in which you can mathematically work things out.
>
>The idea behind setting speeds on blocks for me is purely a method to 
>determine that the signal needs to display a specific aspect instead of 
>a different valid aspect through a junction rather, so it doesn't matter 
>what the units are.  However they would need to be coded into the 
>SignalMast appearance so some though needs to go into it.  The obvious 
>suggestion is to make it MPH, this would then need to be translated into 
>a speed step, but given each loco can have a different speed on the same 
>step, the mapping between MPH and speed step would be loco dependant.
>
>Regards
>Kevin
>
I didn't think a speed limit would affect the signal. A Green would still let you go at the top speed (speed limit)


I think we are getting into "how should the speed table be set up for decoders?"
Should max throttle be the top desired speed for that loco?
Should the speed curve give straight line speed changed? If 100% = 50 MPH must 50%= 25 MPH
Should all locos respond to the throttle with the same speed?
And does a speed limit just affect the top speed or does it reduce all speeds?
Walt

Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

One of the reasons I never used SSL is because I found it to be too US
oriented and I encounter the same problem when following this interesting
thread.
Please don't forget that JMRI is used all around the world :-)

Automation tools should likely deal with signal aspects (e.g. "diverging"),
rather than with appearances. A US "yellow" signal may correspond to a
"green-yellow" in Germany, "red-green" in Italy and so on.

Speeds cannot be expressed in MPH (what about Km/h?).  Moreover consider the
possibility of identifying speeds with names, rather than with numbers, i.e.
user defined strings like "slow", "20MPH", "30Km/k" and then matching them
to throttle settings (0. to 1.0) for each locomotive, taking into account
also the fact that the same signal aspect may impose different speed limits
to different trains. In Italy, for instance, there are 4 categories of
trains, which are allowed 4 different speed limits. See example:
http://www.ansaldo-sts.com/IT/Common/files/AnsaldoSTS_img_proj_big/proj_av_it_big.jpg

The same applies to turnouts.  A diverging turnout can impose, nowadays,
different speed limits depending on how it's build. On standard Italian
lines there are turnouts designed for 30, 60 and 100 Km/h. On high-speed
lines, limits can be higher.


Please, oh please, look at adding west/North length and East/South length
> fields.
> If my train is approaching a Turnout from the points side I want to know
> that the block is shorter for stopping than if the turnout was at the start
> of the block when going the other direction. This would also help on grades
> where one direction is up and the other down.
> Walt
>
> Walt, I think there is here some confusion between block length and braking
distance.  It's true that the length of a block can vary depending on where
the train enters and exits the block (think about a block containing all the
turnouts of a ladder), but the desired braking distance (in order to reach
the stop point) it's a different concept and should likely be kept
separate.  As far a I understand, you would like to use block lengths to
determine the stop point, but others may already use them for different
purposes (e.g. metering train speed or computing train mileage).

Ciao from Italy

Giorgio

Hi Giorgio,

On  1 Mar, Giorgio wrote:
> Automation tools should likely deal with signal aspects (e.g.
> "diverging"), rather than with appearances. A US "yellow" signal may
> correspond to a "green-yellow" in Germany, "red-green" in Italy and so
> on.

We have to deal with this in the US also.  There are US railroads where
two divisions connected end to end don't have the same signalling system
installed (more so in the past, but I know this is still the case in at
least a few places).

> Speeds cannot be expressed in MPH (what about Km/h?).  Moreover
> consider the possibility of identifying speeds with names, rather than
> with numbers, i.e. user defined strings like "slow", "20MPH", "30Km/k"

Here in the US, we generally (not always) use speed signalling.  That
means the signal indicates the maximum speed allowed on the next segment
of track.  The precise speed allowed is governed by track and weather
conditions.

As an example, a "Restricting" indication indicates the train must slow
so that it may stop for obstructions within half the field of view.
There may or may not be a maximum speed associated with a Restricting
indication.


> and then matching them to throttle settings (0. to 1.0) for each
> locomotive, taking into account also the fact that the same signal
> aspect may impose different speed limits to different trains. In
> Italy, for instance, there are 4 categories of trains, which are
> allowed 4 different speed limits. See example: 
> http://www.ansaldo-sts.com/IT/Common/files/AnsaldoSTS_img_proj_big/proj_av_it_big.jpg

In the US, different speed limits may apply as well.  Usually these
limits are based on the type of equipment operated (e.g. Intermodal will
sometimes run at a faster speed limit than general freight).

Paul
-- 
______________________________________________________________________________

	"Quality is a Characteristic of thought and statement that 
	is recognized by a nonthinking process. Because 
	definitions are a product of rigid formal thinking, 
	quality cannot be defined."
		Robert M. Pirsig
			Zen and The Art of Motorcycle Maintenance

<head><style>body{font-size:10pt;font-family:arial,sans-serif;background-color:#ffffff;color:black;}p{margin:0px;}</style></head><body><br><blockquote style="padding-left: 5px; margin-left: 0px; border-left: 2px solid rgb(0, 0, 255);"><xntcp.interface@... class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Please, oh please, look at adding west/North length and East/South length fields.<br>
If my train is approaching a Turnout from the points side I want to know that the block is shorter for stopping than if the turnout was at the start of the block when going the other direction. This would also help on grades where one direction is up and the other down.<br>

Walt<br>
<div><div></div><br></div></blockquote><div>Walt, I think there is here some confusion between block length and braking distance.&nbsp; It's true that the length of a block can vary depending on where the train enters and exits the block (think about a block containing all the turnouts of a ladder), but the desired braking distance (in order to reach the stop point) it's a different concept and should likely be kept separate.&nbsp; As far a I understand, you would like to use block lengths to determine the stop point, but others may already use them for different purposes (e.g. metering train speed or computing train mileage).<br>
<br>Ciao from Italy<br><br>Giorgio<br><br><br>
Giorgio<br>
<br>
Pie in the sky thought:<br>
If we had columns&nbsp; in, for example the block table, that could be named 
by the user and then accessed by that name. Something like 
Sysname-Username then&nbsp; be accesed by the UserName the User or the 
programmer could make use of them as desired. I would use them as Total 
Blk Length, East Block Length, West Blk Length. There could be one used 
as a Speed Limit, another for a Function to perform and so on,&nbsp; It could
 be an option under the View, "Add Column." Or maybe even an auto added,
 when the last Column has a UserName add another SysName column.<br>
<br>
I think that could be useful in a lot of places, like Auto Dispatcher 
for using more than one sensor to define a Block. If they are accessible
 by user name it would not matter what order they were added in as long 
as the UserName is what is being referenced.&nbsp; Signal heads could have 
more things added that would affect the Aspect being displayed. And so 
on.<br>
<br>
<br>
&nbsp;<br>
<br></div></div>
</jmri-developers@...>

Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859</pre>

I don't know if this helps - but let me explain how automated trains under warrants use signals.  Perhaps this scheme or a variant of it could be used by robot throttle.

The file, xml/signals/signalSpeeds.xml, has some names for speeds in the element, <aspectSpeeds>.  There is nothing particularly special about the names, with but one exception that will mention later.  Each name keys a number, which auto-trains use to be a percentage of the normal recorded speed.  For whatever Signal Mast system is used, the aspects.xml should be edited so that each aspect has an <speed> element keying one of the <aspectSpeeds> names.  For example in xml/signals/basic/aspects.xml:
    <aspect>
      <name>Approach</name>
      <indication>Proceed preparing to stop at next signal</indication>
      <speed>Medium</speed>
    </aspect>
where in xml/signals/signalSpeeds.xml:
  <aspectSpeeds>
    <Maximum>125</Maximum>
    <Normal>100</Normal>
    <Limited>75</Limited>
    <Medium>50</Medium>
    <Slow>25</Slow>
    <Restricted>15</Restricted>
    <Stop>0</Stop>
  </aspectSpeeds>
Also in xml/signals/signalSpeeds.xml is the element <appearanceSpeeds> whose members key Signal Head beanName appearances to the speed names. e.g.
    <SignalHeadStateRed>Stop</SignalHeadStateRed>

There is a class, jmri.implementation.SignalSpeedMap that will convert the file, xml/signals/signalSpeeds.xml to code and the public static method, jmri.jmrit.logix.Warrant.getSpeedMap() will fetch this class.

Code lines such as:
        String speed = Warrant.getSpeedMap().getAppearanceSpeed(signal.getAppearanceName(appearance));
and
        String speed = Warrant.getSpeedMap().getAspectSpeed(aspect, signal.getSignalSystem());
will get the speed name from Heads or Masts respectively.

And finally, a code like:
Warrant.getSpeedMap().getSpeed(speed );
will return the speed name number as a float.  This number could be a throttle setting or whatever might be useful to Robot Throttle.

For me, I divide by 100 and use it as a ratio of the normal recorded speed.  Also, there is a Logix action that can modify this ratio for when the consist is heavier or lighter or when different power is used.

There is some flexibility in this scheme in that new speed names can be added and defined in xml/signals/signalSpeeds.xml (and used in Signal Mast aspects.xml files).

Above I mentioned an exception to the speed naming.  The only hard coded names I use are "Normal" and "Stop".  This is for cases where blocks (entrance Portals) have no Head or Mast and I use the raw occupancy detection to control speed.

A limitation of the scheme is that the same ratios are used for all engines.  The ratios for a given engine could be part its description in the Roster.  For now, I would prefer to keep things simple.

PeteC


--- On Tue, 3/1/11, Giorgio <xntcp.interface@...> wrote:
One of the reasons I never used SSL is because I found it to be too US oriented and I encounter the same problem when following this interesting thread.
Please don't forget that JMRI is used all around the world :-)


Automation tools should likely deal with signal aspects (e.g. "diverging"), rather than with appearances. A US "yellow" signal may correspond to a "green-yellow" in Germany, "red-green" in Italy and so on.


Speeds cannot be expressed in MPH (what about Km/h?).  Moreover consider the possibility of identifying speeds with names, rather than with numbers, i.e. user defined strings like "slow", "20MPH", "30Km/k" and then matching them to throttle settings (0. to 1.0) for each locomotive, taking into account also the fact that the same signal aspect may impose different speed limits to different trains. In Italy, for instance, there are 4 categories of trains, which are allowed 4 different speed limits. See example: http://www.ansaldo-sts.com/IT/Common/files/AnsaldoSTS_img_proj_big/proj_av_it_big.jpg


The same applies to turnouts.  A diverging turnout can impose, nowadays, different speed limits depending on how it's build. On standard Italian lines there are turnouts designed for 30, 60 and 100 Km/h. On high-speed lines, limits can be higher.




Please, oh please, look at adding west/North length and East/South length fields.

If my train is approaching a Turnout from the points side I want to know that the block is shorter for stopping than if the turnout was at the start of the block when going the other direction. This would also help on grades where one direction is up and the other down.


Walt


Walt, I think there is here some confusion between block length and braking distance.  It's true that the length of a block can vary depending on where the train enters and exits the block (think about a block containing all the turnouts of a ladder), but the desired braking distance (in order to reach the stop point) it's a different concept and should likely be kept separate.  As far a I understand, you would like to use block lengths to determine the stop point, but others may already use them for different purposes (e.g. metering train speed or computing train mileage).


Ciao from Italy

Giorgio


-----Inline Attachment Follows-----

------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in 
Real-Time with Splunk. Collect, index and harness all the fast moving IT data 
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business 
insights. http://p.sf.net/sfu/splunk-dev2dev 
-----Inline Attachment Follows-----

_______________________________________________
Jmri-developers mailing list
Jmri-developers@...
https://lists.sourceforge.net/lists/listinfo/jmri-developers

One thing I noticed while working on it today is that aspects would be better to work with. But related to aspects, I see some things are needed by the script:

1. An ordered list of speeds and then each aspect would tie to one of these speeds.

2. A flag that the speed should take effect: immediately or before reaching the signal.

3. A order list of the aspects or should that be strictly the speed given from #1??

4. I'm not sure how to deal with the aspects that say you hold one speed until clear then change to another speed. Like the signals that say 'after you clear the interlock' resume normal speed. My issue is I'm in a new block after I pass the signal, etc...


-ken cameron
Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
CNY Modelers http://www.cnymod.com/
Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
Member JMRI Developer Team http://www.jrmi.org/
mailto: kcameron@...
In the Upstate New York US area of the world

Hi Paul,
  thank you for the clariications about US signaling.  Searching the
Internet I also got the impression that in the USA you have the to cope with
many different systems, dictated by the presence of different railroad
companies and technical advances, like here in Europe.  I didn't however see
them reflected in the ongoing thread that appeared focused on a single
prototype (probably a wrong interpretation on my side).

I think Ken captured the meaning of what I was trying to say: avoiding to
have rules, aspects, speeds and so on hard-coded in the software and letting
users define them in order to cope with the prototype they are modeling...
or with their taste :-)

Giorgio

On Tue, Mar 1, 2011 at 3:14 PM, <paul.bender@...> wrote:

> Hi Giorgio,
>
> On  1 Mar, Giorgio wrote:
> > Automation tools should likely deal with signal aspects (e.g.
> > "diverging"), rather than with appearances. A US "yellow" signal may
> > correspond to a "green-yellow" in Germany, "red-green" in Italy and so
> > on.
>
> We have to deal with this in the US also.  There are US railroads where
> two divisions connected end to end don't have the same signalling system
> installed (more so in the past, but I know this is still the case in at
> least a few places).
>
> > Speeds cannot be expressed in MPH (what about Km/h?).  Moreover
> > consider the possibility of identifying speeds with names, rather than
> > with numbers, i.e. user defined strings like "slow", "20MPH", "30Km/k"
>
> Here in the US, we generally (not always) use speed signalling.  That
> means the signal indicates the maximum speed allowed on the next segment
> of track.  The precise speed allowed is governed by track and weather
> conditions.
>
> As an example, a "Restricting" indication indicates the train must slow
> so that it may stop for obstructions within half the field of view.
> There may or may not be a maximum speed associated with a Restricting
> indication.
>
>
> > and then matching them to throttle settings (0. to 1.0) for each
> > locomotive, taking into account also the fact that the same signal
> > aspect may impose different speed limits to different trains. In
> > Italy, for instance, there are 4 categories of trains, which are
> > allowed 4 different speed limits. See example:
> >
> http://www.ansaldo-sts.com/IT/Common/files/AnsaldoSTS_img_proj_big/proj_av_it_big.jpg
>
> In the US, different speed limits may apply as well.  Usually these
> limits are based on the type of equipment operated (e.g. Intermodal will
> sometimes run at a faster speed limit than general freight).
>
> Paul
> --
>
> ______________________________________________________________________________
>
>        "Quality is a Characteristic of thought and statement that
>        is recognized by a nonthinking process. Because
>        definitions are a product of rigid formal thinking,
>        quality cannot be defined."
>                Robert M. Pirsig
>                        Zen and The Art of Motorcycle Maintenance
>
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers
>

Hi Ken,

Boy it would be great if you happened to get to the NMRA convention this
> year. The number of the people working on the different parts could all see
> and talk at the same time. But it is half around the world from you so very
> unlikely I’m guessing.
>

It's indeed a bit too far :-)
This does not exclude the possibility of a remote  connection!

ciao

Giorgio

Ken C.
#4. We need some way to remember what the signal was and then only reduce speed if the new block has a more restrictive aspect until end of the train has cleared the interlock. Knowing what the signal was when we passed it is more relevant than trying to know what signals are for block we have not entered yet.
Walt
-----Original Message-----
>From: Ken Cameron <kcameron@...>
>Sent: Mar 1, 2011 11:01 PM
>To: "paul.bender@..." <paul.bender@...>, "Discussions about changes
>	to the code, design, intent, etc" <jmri-developers@...>
>Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
>
>One thing I noticed while working on it today is that aspects would be better to work with. But related to aspects, I see some things are needed by the script:
>
>1. An ordered list of speeds and then each aspect would tie to one of these speeds.
>
>2. A flag that the speed should take effect: immediately or before reaching the signal.
>
>3. A order list of the aspects or should that be strictly the speed given from #1??
>
>4. I'm not sure how to deal with the aspects that say you hold one speed until clear then change to another speed. Like the signals that say 'after you clear the interlock' resume normal speed. My issue is I'm in a new block after I pass the signal, etc...
>
>
>-ken cameron
>Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
>CNY Modelers http://www.cnymod.com/
>Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
>Member JMRI Developer Team http://www.jrmi.org/
>mailto: kcameron@...
>In the Upstate New York US area of the world
>
>


Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

On Tue, Mar 1, 2011 at 9:01 PM, Ken Cameron
<kcameron@...> wrote:
> 4. I'm not sure how to deal with the aspects that say you hold one speed until clear then change to another speed. Like the signals that say 'after you clear the interlock' resume normal speed. My issue is I'm in a new block after I pass the signal, etc...

These all trigger on train length - when the block behind shows "no
track occupancy", you can transition to the new speed...

   -John

On 01/03/2011 20:05, Cressman wrote:
> I don't know if this helps - but let me explain how automated trains
> under warrants use signals. Perhaps this scheme or a variant of it could
> be used by robot throttle.
>
> The file, xml/signals/signalSpeeds.xml, has some names for speeds in the
> element, <aspectSpeeds>. There is nothing particularly special about the
> names, with but one exception that will mention later. Each name keys a
> number, which auto-trains use to be a percentage of the normal recorded
> speed. For whatever Signal Mast system is used, the aspects.xml should
> be edited so that each aspect has an <speed> element keying one of the
> <aspectSpeeds> names. For example in xml/signals/basic/aspects.xml:
> <aspect>
> <name>Approach</name>
> <indication>Proceed preparing to stop at next signal</indication>
> <speed>Medium</speed>
> </aspect>
> where in xml/signals/signalSpeeds.xml:
> <aspectSpeeds>
> <Maximum>125</Maximum>
> <Normal>100</Normal>
> <Limited>75</Limited>
> <Medium>50</Medium>
> <Slow>25</Slow>
> <Restricted>15</Restricted>
> <Stop>0</Stop>
> </aspectSpeeds>
> Also in xml/signals/signalSpeeds.xml is the element <appearanceSpeeds>
> whose members key Signal Head beanName appearances to the speed names. e.g.
> <SignalHeadStateRed>Stop</SignalHeadStateRed>
>
> There is a class, jmri.implementation.SignalSpeedMap that will convert
> the file, xml/signals/signalSpeeds.xml to code and the public static
> method, jmri.jmrit.logix.Warrant.getSpeedMap() will fetch this class.
>
> Code lines such as:
> String speed =
> Warrant.getSpeedMap().getAppearanceSpeed(signal.getAppearanceName(appearance));
> and
> String speed = Warrant.getSpeedMap().getAspectSpeed(aspect,
> signal.getSignalSystem());
> will get the speed name from Heads or Masts respectively.
>
> And finally, a code like:
> Warrant.getSpeedMap().getSpeed(speed );
> will return the speed name number as a float. This number could be a
> throttle setting or whatever might be useful to Robot Throttle.
>

Pete,

That helps me a bit in with the Aspect Signalling logic and knowing 
which signal aspect to display given the speed of a block.  As there is 
code I can potentially re-use.

A couple of questions is there a reason for creating a separate 
SignalSpeedMap.xml?  Could the mapping not be implemented in the 
aspect.xml file for each signalling system?  Or if it needs to be in a 
sperate file would it not be better for it to be located in the same 
directory as the signalling system so that we don't end up with one 
generic speed map for all systems.?

Regards
Kevin

>  
> 
> From: Giorgio <xntcp.interface@...>
> Date: March 2, 2011 4:19:23 AM PST
> Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
> 
> 
> Boy it would be great if you happened to get to the NMRA convention this year. The number of the people working on the different parts could all see and talk at the same time. But it is half around the world from you so very unlikely I’m guessing.
> 
> It's indeed a bit too far :-)
> This does not exclude the possibility of a remote  connection!
> 

On Mar 2, 2011, at 12:03 PM, Ken Cameron wrote:

> This is true. Bob J is the IT brain behind the convention as I understand it. So he would know if the hall will have connections etc… that we could do something like bring you in on Skype or something.
>  

Right now, the thinking is that the Convention is _not_ going to provide wireless for clinics, etc, as it's just too expensive.  The telecomm provider for the Convention center wants an obscene amount of money to give access.

But we may be able to work something out for specific clinics, e.g. the JMRI or perhaps the OpenLCB ones.  I'm still working on that.  It's amazing what Maxwell's equations and a few Pringles cans can do....

Bob

--
Bob Jacobsen, LBNL
Bob_Jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG

>That helps me a bit in with the Aspect Signalling logic and knowing 
which signal aspect to display given the speed of a block.  As there is 
code I can potentially re-use.

Seems backwards to have speed set aspect, but if the speed names were used judiciously, you could make an inverse map from the SpeedMap.

>A couple of questions is there a reason for creating a separate 
SignalSpeedMap.xml?  Could the mapping not be implemented in the 
aspect.xml file for each signalling system?  Or if it needs to be in a 
sperate file would it not be better for it to be located in the same 
directory as the signalling system so that we don't end up with one 
generic speed map for all systems.?

I think some indirection is desirable, but a speed setting could be done as a direct property in a signaling system.  If there is a consensus to change, I'll comply with it.

I doubt that there would be more than 10 or 15 entries for speeds, no matter how many signal systems were used by a layout.  If one used a speed name for each throttle setting that would be a maximum of 128.  Note that the SpeedMap only builds code for what is in the signalSpeeds.xml file.  The aspect.xml file of each signaling system just uses speed names (<speed>speedName</speed> that are looked up in the SpeedMap.

I have not implemented the case where the speed indication is an exit speed.  For now, I (incorrectly) assume in the absence of signal, it is resume normal speed. If there is a demand for this, it can be done with little effort.

Best Regards,
Pete

--- On Wed, 3/2/11, Ken Cameron <kcameron@...> wrote:
  >Yes, these are some good parts. In RT I’m using extra values in the roster to store the loco throttle settings for the different single head signal aspects. But I also keep the ‘inch/sec’ and ‘distance to drop to next speed’ values too.  >Now with a set of aspect speeds as a unit, a scale indication somewhere, I should have the guide for the throttle and ‘inch/sec’ rolled into one. The saved in the roster settings then become a set of throttle settings to match the aspects. The reason for the ‘distance to drop to next lower speed’ was for calculations to make sure we can drop speed before reaching a signal, like a stop.  What are your conventions when match throttle settings to signal aspects?  Perhaps I can use the same conventions.

PeteC

On Mar 2, 2011, at 7:51 PM, Ken Cameron wrote:

> If a block has one speed limit (high) and the loco can’t do that, it runs the speed it can. But for any lower speed limits, it will run those speeds if it can. It won’t “respond on the curve” so to speak, like if the top speed is only 60% of the speed limit, a slow speed wouldn’t be 60% of the slow speed. Or how does the prototype deal with trains of many speeds vs the many speed limits. I’m a bit tired so I don’t know if I said this right.

On many American prototypes, it's a Really Big Deal if a train can't maintain track speed.  A lot of trouble is put into making sure trains have enough power and/or are light enough to maintain speed, because a lot of planning that counts on that speed goes into getting lots of trains over the road. Somethings things go wrong, of course, but that's not the usual case.

People don't put that much effort into model railroad trains, and people tend to run trains at whatever speed seems "about right".

Bob

--
Bob Jacobsen, LBNL
Bob_Jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG

<head><style>body{font-size:10pt;font-family:arial,sans-serif;background-color:#ffffff;color:black;}p{margin:0px;}</style></head><body><font color="#000000"><font size="2"><font face="arial,sans-serif">Ken C:<br>http://en.wikipedia.org/wiki/Speed_limits_in_the_United_States_%28rail%29 and http://en.wikipedia.org/wiki/North_American_railway_signaling Have interesting info about speed limits.<br>Regards <br>Walt<br><br></font></font></font><blockquote style="padding-left: 5px; margin-left: 0px; border-left: 2px solid rgb(0, 0, 255);">-----Original Message-----
<br>From: Ken Cameron <kcameron@...>
<br>Sent: Mar 2, 2011 10:51 PM
<br>To: "Discussions about changes to the code,	design, intent, etc" <jmri-developers@...>
<br>Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show

<br><br><zzzhtml xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><zzzhead><zzzmeta http-equiv="Content-Type" content="text/html; charset=us-ascii"><zzzmeta name="Generator" content="Microsoft Word 12 (filtered medium)"><style><ZZZ!--
/* Font Definitions */
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:ZZZlink, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><zzz!--[if gte="" mso="" 9]=""><xml>
<o:shapedefaults v:ext="edit" spidmax="1026">
</o:shapedefaults><zzz![endif]--><zzz!--[if gte="" mso="" 9]=""><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1">
</o:idmap></o:shapelayout><zzz![endif]--></zzz![endif]--><zzzbody link="blue" vlink="purple" lang="EN-US"><div class="WordSection1"><p class="MsoNormal">Peter,<o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal">What I’m doing right now is a matrix of the 6 signal head aspects and the matching ‘throttle’ settings.<o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal">What I’m hoping is something that tells the speed (units not decided yet) for the block. Then a set of configuration values in the roster for the loco that does a speed translation. Key points are the ‘least speed’ throttle value (since a lot of locos aren’t reliable or smooth below some point) or equal to the speed to use when approaching a stop signal. Then I’m guessing some number of other data points. The key is each loco will have some limit for its high end speed too. Now we get into the shape of the curve between those points. I’m not there yet.<o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal">A big point is each loco will be different, and the throttle setting value has no general relation to anything. It’s the throttle setting for some speed.<o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal">Question ALL:<o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal">If a block has one speed limit (high) and the loco can’t do that, it runs the speed it can. But for any lower speed limits, it will run those speeds if it can. It won’t “respond on the curve” so to speak, like if the top speed is only 60% of the speed limit, a slow speed wouldn’t be 60% of the slow speed. Or how does the prototype deal with trains of many speeds vs the many speed limits. I’m a bit tired so I don’t know if I said this right.<o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal"><span style="font-size: 10pt;">-ken cameron<br>Syracuse Model Railroad Club <a target="_blank" href="http://www.syracusemodelrr.org/"><span style="color: blue;">http://www.SyracuseModelRr.org/</span></a><br>CNY Modelers <a target="_blank" href="http://www.cnymod.com/"><span style="color: blue;">http://www.cnymod.com/</span></a><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 10pt;">Finger Lakes Live Steamers <a target="_blank" href="http://www.fingerlakeslivesteamers.org/"><span style="color: blue;">http://www.fingerlakeslivesteamers.org/</span></a><o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 10pt;">Member JMRI Developer Team <a target="_blank" href="http://www.jrmi.org/"><span style="color: blue;">http://www.jrmi.org/</span></a><br>mailto: <a target="_blank" href="mailto:kcameron@... style="color: blue;">kcameron@... class="MsoNormal"><span style="font-size: 10pt;">In the Upstate New York US area of the world</span><o:p></o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p><p class="MsoNormal"><o:p>&nbsp;</o:p></p></div></zzzbody></xml></zzz!--[if></zzz![endif]--></xml></zzz!--[if></zzzmeta></zzzmeta></zzzhead></zzzhtml></jmri-developers@...>

On 03/03/2011 02:47, Pete Cressman wrote:
>
>
>      >That helps me a bit in with the Aspect Signalling logic and knowing
>     which signal aspect to display given the speed of a block. As there is
>     code I can potentially re-use.
>
>     Seems backwards to have speed set aspect, but if the speed names
>     were used judiciously, you could make an inverse map from the SpeedMap.

Yes and no, at the moment the idea is that the speed of the block would 
determine which appearance would be displayed if there are multiple 
possibilities given the state of the advanced signal.

As an example, if our advanced signal mast is displaying Stop, the 
signalmast we are currently looking at could be displaying "Approach" or 
"Diverging Approach" both of which I understand have different speed 
restrictions.  In theory we could just use the state of the turnouts as 
to whether they are set closed or thrown, however that may not be valid 
in all instances.  You can have turnouts that are speed rated at 100mph+.
Therefore by setting a speed on the appropriate block on the diverging 
route we can select the appropriate appearance.

The other example is that we can have multiple forms of Clear, eg 
"Limited Clear", "Medium Clear" and "Slow Clear".  How does the 
signalMast (or the logic driving it) know which one it should be set to? 
  If the logic knows that the block speed ahead is "Limited", then it 
can set the appropriate appearance.  I guess the answer to that is to 
assign the words "Limited", "Medium", "Slow" against a block.

>
>     I doubt that there would be more than 10 or 15 entries for speeds,
>     no matter how many signal systems were used by a layout. If one used
>     a speed name for each throttle setting that would be a maximum of
>     128. Note that the SpeedMap only builds code for what is in the
>     signalSpeeds.xml file. The aspect.xml file of each signaling system
>     just uses speed names (<speed>speedName</speed> that are looked up
>     in the SpeedMap.

Okay, given that, would it be possible and potentially better for the 
end user if the values supplied in the signalSpeeds.xml file are used as 
a default, but allow the user to change them and these can then get 
stored in the panel file?  just an idea.

Regards
Kevin

Kevin,

Thoughts about speeds:

1. Don't forget that the turnout itself may have a speed limit that is different from any of the 3 tracks attached to it. And I'm not sure if it is strictly a one speed (both ways) for the continuing and another speed (both ways or different each way??) for the diverging path. We need more prototype details here, plus more international details.

2. Is there much standardization on the different speeds and their names or is that a mess?? Again consideration of the whole planet is important, so Giorgio and Matt likely have to help here.

3. I know we need some way to tie things together, but I'm always suspect of using 'magic words' if you know what I mean. Now what to use so we don't get tripped up on the word, I'm not sure. Maybe there is enough of a standard we can draw from to use (remember the world) and names are ok.

Other detail for me:

Is there a way to say that for any two given two signal mast aspects, one is faster than, equal, or slower than another?? That's a key thing in what RT expects about signal changes.


-ken cameron
Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
CNY Modelers http://www.cnymod.com/
Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
Member JMRI Developer Team http://www.jrmi.org/
mailto: kcameron@...
In the Upstate New York US area of the world

On Thu, Mar 3, 2011 at 5:19 AM, Bob Jacobsen <bob_jacobsen@...> wrote:

>
> On Mar 2, 2011, at 7:51 PM, Ken Cameron wrote:
>
> > If a block has one speed limit (high) and the loco can’t do that, it runs
> the speed it can. But for any lower speed limits, it will run those speeds
> if it can. It won’t “respond on the curve” so to speak, like if the top
> speed is only 60% of the speed limit, a slow speed wouldn’t be 60% of the
> slow speed. Or how does the prototype deal with trains of many speeds vs the
> many speed limits. I’m a bit tired so I don’t know if I said this right.
>
> On many American prototypes, it's a Really Big Deal if a train can't
> maintain track speed.  A lot of trouble is put into making sure trains have
> enough power and/or are light enough to maintain speed, because a lot of
> planning that counts on that speed goes into getting lots of trains over the
> road. Somethings things go wrong, of course, but that's not the usual case.
>

Each train is governed by its time-table, which normally includes speed
prescriptions. In most cases these are the maximum speeds allowed by the
line (for that kind of train) or the maximum speed the train can reach (if
lower that the line speed limit).  The goal is occupying tracks as little
time as possible. Passenger trains are normally able of higher speeds than
freight. This is true for present days (at least in Europe, where some
passenger trains can reach 200 MPH, although they do not obey traditional
signals), but it was also in the past.

I'm modeling German steam era and  I set the maximum speed of each
locomotive in accordance to the prototype (thus, I cannot use the same
throttle setting for all trains). Locomotives employed for freight (e.g.
consolidation) had a maximum speed of 50-60 Km/h (30-40 MPH), while those
pulling passenger trains (e.g. pacific) could exceed 100 Km/h (60 MPH).
There was a strong competition among companies (both in Europe and USA, as
far as I know) to offer the fastest passenger trains!

Maximum speed is and was also limited by braking capabilities, especially in
those days when not all freight cars were equipped with vacuum brakes.
Before departing, the engineer (or the train master) must compute the ratio
between the weight of the train and the so-called "braked-weight" (i.e. the
sum of the braking ability of each car, expressed in tons or, nowadays, in
newton) and limit the maximum speed in accordance to the resulting value and
the characteristics of the line (based on the maximum grade). There are
tables, at least here in Italy, showing the maximum speed allowed in
accordance to the braked-weight/total-weight ratio:

http://www.see.it/ok/gfmib/gif/pesot-nrs.gif

(on the left column are listed line classes, on the top row the weight ratio
as percentage. Maximum speed for the same line, e.g. "Ia", can vary from 60
to 160 Km/h, i.e. 40-100 MPH).

An additional element is determining maximum speed nowadays, the
availability or lack of on-board electronics (e.g. cab signal repetition).
The higher the level of safety provided by electronics, the higher the speed
allowed.

Summarizing, the maximum speed depends upon:
1) Line (grade, radius, strength of rails);
2) Maximum speed of the locomotive;
3) Locomotive(s) power and train weight;
4) Maximum speed allowed for each car;
5) Braking power;
6) On-board electronics.

Signals do normally take into account only point 1 above.
A signal may thus show a limit of 60 MPH, but each train may run at its own
speed, provided it does not exceed 60 MPH.


ciao

Giorgio

Kevin,
Your examples of "Limited Clear", "Medium Clear" and "Slow Clear" are 
not setting different speeds ahead. They are setting different speeds at 
the start of the block. E.g. 'Limited Clear' means that the train must 
not exceed 'Limited' speed until it has passed the interlocking. (based 
the OS detection for our models) Once a train has cleared the OS, then 
it may proceed at 'Clear' speed until it becomes governed by the next 
signal. In like manner 'Slow Clear' means that the train must not exceed 
'Slow' speed until it has passed the OS, then it may accelerate to 
'Clear' speed. These different indications would be determined by the 
signal engineers when they install the signals, based on the turnout 
angle or other speed limiting factors. They wouldn't ever change from 
one aspect to another based on changing conditions during normal operations.

Dick :)


On 03/03/2011 08:14 AM, Kevin Dickerson wrote:
> On 03/03/2011 02:47, Pete Cressman wrote:
>>
>>       >That helps me a bit in with the Aspect Signalling logic and knowing
>>      which signal aspect to display given the speed of a block. As there is
>>      code I can potentially re-use.
>>
>>      Seems backwards to have speed set aspect, but if the speed names
>>      were used judiciously, you could make an inverse map from the SpeedMap.
> Yes and no, at the moment the idea is that the speed of the block would
> determine which appearance would be displayed if there are multiple
> possibilities given the state of the advanced signal.
>
> As an example, if our advanced signal mast is displaying Stop, the
> signalmast we are currently looking at could be displaying "Approach" or
> "Diverging Approach" both of which I understand have different speed
> restrictions.  In theory we could just use the state of the turnouts as
> to whether they are set closed or thrown, however that may not be valid
> in all instances.  You can have turnouts that are speed rated at 100mph+.
> Therefore by setting a speed on the appropriate block on the diverging
> route we can select the appropriate appearance.
>
> The other example is that we can have multiple forms of Clear, eg
> "Limited Clear", "Medium Clear" and "Slow Clear".  How does the
> signalMast (or the logic driving it) know which one it should be set to?
>    If the logic knows that the block speed ahead is "Limited", then it
> can set the appropriate appearance.  I guess the answer to that is to
> assign the words "Limited", "Medium", "Slow" against a block.
>
>>      I doubt that there would be more than 10 or 15 entries for speeds,
>>      no matter how many signal systems were used by a layout. If one used
>>      a speed name for each throttle setting that would be a maximum of
>>      128. Note that the SpeedMap only builds code for what is in the
>>      signalSpeeds.xml file. The aspect.xml file of each signaling system
>>      just uses speed names (<speed>speedName</speed>  that are looked up
>>      in the SpeedMap.
> Okay, given that, would it be possible and potentially better for the
> end user if the values supplied in the signalSpeeds.xml file are used as
> a default, but allow the user to change them and these can then get
> stored in the panel file?  just an idea.
>
> Regards
> Kevin
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers

Ken,
For what it is worth, I have adopted the following set of mast aspects 
for our new Control Point hardware. (taken from the decoder file) These 
are arranged in an approximation of speed.

<enumChoice choice="Stop"/>
<enumChoice choice="Take Siding"/>
<enumChoice choice="Stop-Orders"/>
<enumChoice choice="Stop-Proceed"/>
<enumChoice choice="Restricting"/>
<enumChoice choice="Permissive"/>
<enumChoice choice="Slow-Stop"/>
<enumChoice choice="Slow"/>
<enumChoice choice="Slow-Medium"/>
<enumChoice choice="Slow-Limited"/>
<enumChoice choice="Slow-Clear"/>
<enumChoice choice="Medium-Stop"/>
<enumChoice choice="Medium-Slow"/>
<enumChoice choice="Medium"/>
<enumChoice choice="Medium-Ltd"/>
<enumChoice choice="Medium-Clr"/>
<enumChoice choice="Limited-Stop"/>
<enumChoice choice="Limited-Slow"/>
<enumChoice choice="Limited-Med"/>
<enumChoice choice="Limited"/>
<enumChoice choice="Limited-Clear"/>
<enumChoice choice="Approach"/>
<enumChoice choice="Advance-Appr"/>
<enumChoice choice="Appr-Slow"/>
<enumChoice choice="Adv-Appr-Slow"/>
<enumChoice choice="Appr-Medium"/>
<enumChoice choice="Adv-Appr-Med"/>
<enumChoice choice="Appr-Limited"/>
<enumChoice choice="Adv-Appr-Ltd"/>
<enumChoice choice="Clear"/>
<enumChoice choice="Cab-Speed"/>
<enumChoice choice="Dark"/>

Obviously any particular mast will only need to show a small subset of 
these options, and some railroads will have something not shown here, or 
use different terms. Of course different railroads will show the above 
aspects with different light colors and combinations.

Dick :)

On 03/03/2011 08:33 AM, Ken Cameron wrote:
> Kevin,
>
> Thoughts about speeds:
>
> 1. Don't forget that the turnout itself may have a speed limit that is different from any of the 3 tracks attached to it. And I'm not sure if it is strictly a one speed (both ways) for the continuing and another speed (both ways or different each way??) for the diverging path. We need more prototype details here, plus more international details.
>
> 2. Is there much standardization on the different speeds and their names or is that a mess?? Again consideration of the whole planet is important, so Giorgio and Matt likely have to help here.
>
> 3. I know we need some way to tie things together, but I'm always suspect of using 'magic words' if you know what I mean. Now what to use so we don't get tripped up on the word, I'm not sure. Maybe there is enough of a standard we can draw from to use (remember the world) and names are ok.
>
> Other detail for me:
>
> Is there a way to say that for any two given two signal mast aspects, one is faster than, equal, or slower than another?? That's a key thing in what RT expects about signal changes.
>
>
> -ken cameron
> Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
> CNY Modelers http://www.cnymod.com/
> Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
> Member JMRI Developer Team http://www.jrmi.org/
> mailto: kcameron@...
> In the Upstate New York US area of the world
>
>
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
>
>
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers

For a Computer to control a train it need to know how the train responds to settings. Or the train need to respond the way the computer program expects the train to.

I use 4 aspect signals. I set the max speed of each loco at 100% throttle to be about 50MPH for passenger locos and around 40MPH for freight locos. Because my blocks are much shorter than prototype the momentum is set so that from 100% throttle(Green) the loco will stop in the shortest block length times three. The next restrictive aspect, Flash Yellow requires that the loco stop in twice the shortest block length,  the speed curve is adjusted to achieve that.   And when entering a block from a Yellow speed the loco must be able to stop in the shortest block and the Yellow speed is adjusted to achieve that..

Anytime the computer sees that the train is in a block that has a Green signal it runs the train at 100% throttle. If the signal is a more restrictive aspect the computer checks the table for that locos speed setting for that aspect and sends that speed cmd to the decoder.

So the speeds other than 100% are determined by the response of the locomotive.  Trains will never pass a signal at a higher speed than is indicated by the signal for that train. But trains can be moving at different speeds for each aspect.

The Speeds look good to me and the computer can control the trains by obeying the signals.

That may not be how the prototype determines speeds but we are playing with toys.  Bigboys would not be able to operate on our curves at all. Our acceleration and braking times would damage any cargo being carried, freight or passengers.




Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

Hi Ken,
    answering some questions posed in your messages.

A thrown turnout implies a speed restriction, while a closed one does not
(or implies a much higher speed limit).  This applies to both directions of
travel.

In the signal systems I know about there is a distinction between
"diverging" and "reduced speed" aspects.  Both imply a speed limitation
(sometimes the same), but "diverging" allows the engineer to resume normal
speed after clearing turnouts, while "reduced speed" aspect does not.

After encountering a "diverging" aspect, the engineer may don't know when
the train has cleared ALL turnouts (they may be far apart). For this reason
a board (or another sign) normally shows where higher speed can be resumed
(and recalls, often, how much "higher speed" is).

In Italy and Germany, the engineer must obey absolute signals before
reaching them. I.e. he must stop or reduce speed before the front of the
train reaches the signal. This is why each signal is preceded by an
"advanced" signal that may (or may not) be placed on the same mast as the
previous main signal. The "advanced" signal is normally placed approx. half
a mile before the main signal.
Permissive signals are another matter: they can be passed even when showing
red and some action must often be taken after passing them.  But we can
unlikely automate train behaviour in front of permissive signals :-)

Speeds.

1) My advise is to allow user to define how many speeds he needs and name
them as he likes.

2) Don't assume any implicit relationship between speed-names and scale
speeds. If knowing scale speeds is a requirement, they should be either
added by user, either computed by program (e.g. metering speed on a block of
known length). The better way would be to associate scale speeds with
throttle settings of each locomotive and not with defined speed-names (User
can decide to have each trains running at a different scale speed for the
same speed-name).

3) Don't assume any implicit relationship between speed-names and throttle
settings.  Allow user to specify throttle setting (and, if needed, scale
speed) for each speed-name and for each locomotive.

Signal masts.

1) Allow user to define how many signal aspects he needs and to name them as
he likes.

2) Signal aspects can be based on: setting of turnouts ahead, or aspect of
next signal, or both.

3) Allow user to define, for each signal mast (or signal mast type), a table
matching aspects and appearances, as well as speed restrictions (using
speed-names). This would allow user to create, for instance, signal masts
providing different appearances and different speed limits (depending on
maximum speed allowed by turnouts) for the same "diverging" aspect.

Summary:
1) User defines speed-names;
2) User defines signal aspects;
3) User defines signal masts, linking aspects with appearances and
speed-names;
4) User matches, for each locomotive, speed-names with throttle settings
(and scale speeds, if required).

By the way, this is the approach I tried to follow in AD2.

Did you ever think about testing RobotThrottle with AutoDispatcher?

It would require some adjustments (AD2 provides an interface for
user-written engineer scripts), but would likely solve some of the problems
you are facing.  Let me know if you are interested and I will send you all
needed info.

ciao

Giorgio

On 03/03/2011 15:17, Dick Bronson wrote:
> Kevin,
> Your examples of "Limited Clear", "Medium Clear" and "Slow Clear" are
> not setting different speeds ahead. They are setting different speeds at
> the start of the block. E.g. 'Limited Clear' means that the train must
> not exceed 'Limited' speed until it has passed the interlocking. (based
> the OS detection for our models)   Once a train has cleared the OS, then

Dick are we not simply talking about the same thing here but using 
slightly different wording.  ie the signalMast is located prior to/at 
the head/begin/start/etc of the block to which the speed restriction 
applies. Rather than it being a speed restriction 2 mile down the line.

> it may proceed at 'Clear' speed until it becomes governed by the next
> signal. In like manner 'Slow Clear' means that the train must not exceed
> 'Slow' speed until it has passed the OS, then it may accelerate to
> 'Clear' speed. These different indications would be determined by the
> signal engineers when they install the signals, based on the turnout
> angle or other speed limiting factors. They wouldn't ever change from
> one aspect to another based on changing conditions during normal operations.

So in this case we need to be able to set either the turnouts speed or 
the blocks speed appropriately so that the correct aspect is displayed.

Regards
Kevin

Kevin,
See below.

On 03/03/2011 03:23 PM, Kevin Dickerson wrote:
> On 03/03/2011 15:17, Dick Bronson wrote:
>> Kevin,
>> Your examples of "Limited Clear", "Medium Clear" and "Slow Clear" are
>> not setting different speeds ahead. They are setting different speeds at
>> the start of the block. E.g. 'Limited Clear' means that the train must
>> not exceed 'Limited' speed until it has passed the interlocking. (based
>> the OS detection for our models)   Once a train has cleared the OS, then
> Dick are we not simply talking about the same thing here but using
> slightly different wording.  ie the signalMast is located prior to/at
> the head/begin/start/etc of the block to which the speed restriction
> applies. Rather than it being a speed restriction 2 mile down the line.
The signal always tells you what to do while you are in the block that 
it protects, i.e. the one ahead. However it may tell you several things 
about what to do in the case of speed signaling. 1. Can you enter the 
block at all. 2. What speed do you need to go while you are still in the 
interlocking. 3. What speed do you need to go once you clear the 
interlocking. 4. What does the next signal currently indicate your speed 
will need to be when you get there. It may have changed to be less 
restrictive by the time you actually get there, but it should never 
become more restrictive. This is to cut down on the amount of swearing 
by the engineer. (Less swearing is always good.)

Dick :)
>> it may proceed at 'Clear' speed until it becomes governed by the next
>> signal. In like manner 'Slow Clear' means that the train must not exceed
>> 'Slow' speed until it has passed the OS, then it may accelerate to
>> 'Clear' speed. These different indications would be determined by the
>> signal engineers when they install the signals, based on the turnout
>> angle or other speed limiting factors. They wouldn't ever change from
>> one aspect to another based on changing conditions during normal operations.
> So in this case we need to be able to set either the turnouts speed or
> the blocks speed appropriately so that the correct aspect is displayed.
The correct aspect options are not "set", they are designed by the 
signal engineers to match the track conditions. In your three examples, 
any given interlocking would only use one of them.

Dick :)

> Regards
> Kevin
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search&  Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers

Dick has outlined 4 cases where a speed change may be required and in a previous email suggested a list of speed categories.  Below, let me take the computer's view and propose an implementation.

--- On Thu, 3/3/11, Dick Bronson <dick@...> wrote:
>Rather than it being a speed restriction 2 mile down the line.
The signal always tells you what to do while you are in the block that 
it protects, i.e. the one ahead. However it may tell you several things 
about what to do in the case of speed signaling. 1. Can you enter the 
block at all. 2. What speed do you need to go while you are still in the 
interlocking. 3.
 What speed do you need to go once you clear the 
interlocking. 4. What does the next signal currently indicate your speed 
will need to be when you get there. It may have changed to be less 
restrictive by the time you actually get there, but it should never 
become more restrictive. This is to cut down on the amount of swearing 
by the engineer. (Less swearing is always good.)

Please keep in mind this is for a model train with a computer engineer and not a robot engineer on prototype railroad.  Also I assume that every layout signal is placed at the entrance to the occupancy block that it protects.

 1. Can you enter the block at all. 
1a. Train is moving in the previous block.  There should have been an approach signal set at the entrance to the previous block.  However, being a model RR, perhaps not.  To simulate the swearing of the prototype engineer, the computer has looked ahead to next block and
 so it knows to bring the train to a stop before entering the block.  In fact when it entered the previous block it put a listener on the signal.  If the signal changed while in the previous block it can react appropriately to the new aspect.
1b. Train is stopped in the previous block.  Wait until the listener sends a new aspect. React appropriately to the new aspect.

4. What does the next signal currently indicate your speed will need
 to be when you get there. 
I jumped to 4, because the computer handles this the same as case 1. - The computer has looked ahead to next block and put a listener on its signal.  Again, being a model RR, perhaps there is no next signal, nevertheless the computer reacts to the current aspect.

 2. What speed do you need to go while you are still in the interlocking.
The computer handles this the same as case 1. with a slight modification.  If the signal at the next block (the listener) shows a more restrictive speed, the computer reacts to it,  If less restrictive, it makes no speed change.  

The computer might handle these 3 cases a bit more elegantly, delaying any speed changes in cases 1 and 2, so the required speed is attained just before entering the next block.  While for case 2, the speed change should occur when entering the block - if not already attained by reacting to an approach signal.

These
 three cases can done with a single <speed> element in the aspect.xml file of the signal system.  The computer reacts to these speedNames when the train enters the block - occupancy sensor goes active - and it reads the entrance signal aspect.

3. What speed do you need to go once you clear the interlocking. 
This needs a second speed name type, say <exitSpeed>, when the current occupancy sensor goes inactive - the tail of the train has left the block.  That is, when the train entered the block, the computer noted a pending speed change to execute when the block becomes unoccupied.

Both types of speed names can be looked up in the "speedMap" generated from signalSpeeds.xml and computer uses the result.  If a GUI is created to modify the entries in signalSpeeds.xml as Kevin suggested, so much the better.

The speed names proposed by Dick certainly seem fine enough for model railroading. I suggest they be used in signal system aspect.xml files and their translated speed numbers (floats) be the substance of signalSpeeds.xml.

Your thoughts?

PeteC

On 04/03/11 00:02, Dick Bronson wrote:

> The signal always tells you what to do while you are in the block that
> it protects, i.e. the one ahead. However it may tell you several things
> about what to do in the case of speed signaling. 1. Can you enter the
> block at all. 2. What speed do you need to go while you are still in the
> interlocking. 3. What speed do you need to go once you clear the
> interlocking. 4. What does the next signal currently indicate your speed
> will need to be when you get there. It may have changed to be less
> restrictive by the time you actually get there, but it should never
> become more restrictive. This is to cut down on the amount of swearing
> by the engineer. (Less swearing is always good.)
>
> Dick :)

Agree with your definitions, I guess the other slight or misleading term 
we have in JMRI is where the word Block is used, doesn't necessarily tie 
up correctly with the general understanding and correct description.

>>> it may proceed at 'Clear' speed until it becomes governed by the next
>>> signal. In like manner 'Slow Clear' means that the train must not exceed
>>> 'Slow' speed until it has passed the OS, then it may accelerate to
>>> 'Clear' speed. These different indications would be determined by the
>>> signal engineers when they install the signals, based on the turnout
>>> angle or other speed limiting factors. They wouldn't ever change from
>>> one aspect to another based on changing conditions during normal operations.
>> So in this case we need to be able to set either the turnouts speed or
>> the blocks speed appropriately so that the correct aspect is displayed.
> The correct aspect options are not "set", they are designed by the
> signal engineers to match the track conditions. In your three examples,
> any given interlocking would only use one of them.

I'm looking at this from the Signal engineers prospective and providing 
a method that the user can define the track conditions within JMRI, so 
then the correct aspect can be shown to the driver.

I know I have gone slightly off Ken original topic, but we both have 
different reasons for wanting to control or set speeds through blocks. 
Ideally we should have a single solution, rather than two.

Regards
Kevin

On 03/03/2011 17:12, Giorgio wrote:
> A thrown turnout implies a speed restriction, while a closed one does
> not (or implies a much higher speed limit).  This applies to both
> directions of travel.

Hi Giorgio,

Just picking up on your point above, would you find it sufficient if the 
block directly connected to the thrown position of a turnout has the 
speed restriction associated with it.  Or do you feel that the turnout 
should have the option of adding a speed restriction to it when in the 
thrown position?  I'm thinking about the fact that you can get turnouts 
and crossovers which do not have speed restrictions over them.

I think i'm going to answer my own question here by saying that 
cross-overs in the layout editor don't have individual blocks between 
the turnouts, so any speed restriction would need to be reflected in the 
turnout.

Regards
Kevin

Kevin,

I support that the turnout 'may' have its own speeds. Similar to my stand that where a signal on the throat needs to be reported is related to if it is a different block. While I think the block might be the right place to keep some of those things, I'm seeing more thoughts that the different segments that make up a block, turnouts and track segments, should be where things like speeds, lengths, curves, grades, etc... need to be. But I can also see the current idea which seems to say 'if you want it to be considered a separate area, you must make it a separate block'.  While it might be nicer to have the details in smaller units, there are very limited things you can do with that data without it being different blocks.

-ken cameron
Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
CNY Modelers http://www.cnymod.com/
Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
Member JMRI Developer Team http://www.jrmi.org/
mailto: kcameron@...
In the Upstate New York US area of the world

Ken C:
For RT's to use the smallest unit, which we are now calling a segment, there would need to be internal signals to tell the RT to do something different.

I think this is talking about increasing the restriction on a train when it is within a signaled block. This would result in an Engineer swearing. If the Engineer can not see the signal yet or any more because he has passed it how is he to know?

Now if we are talking about "in cab signals" when the train has entered a different "section", it get new signals and there are no block signals.

Walt 
-----Original Message-----
>From: Ken Cameron <kcameron@...>
>Sent: Mar 5, 2011 8:05 AM
>To: "Discussions about changes to the code, design, intent,	etc" <jmri-developers@...>
>Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
>
>Kevin,
>
>I support that the turnout 'may' have its own speeds. Similar to my stand that where a signal on the throat needs to be reported is related to if it is a different block. While I think the block might be the right place to keep some of those things, I'm seeing more thoughts that the different segments that make up a block, turnouts and track segments, should be where things like speeds, lengths, curves, grades, etc... need to be. But I can also see the current idea which seems to say 'if you want it to be considered a separate area, you must make it a separate block'.  While it might be nicer to have the details in smaller units, there are very limited things you can do with that data without it being different blocks.
>
>-ken cameron
>Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
>CNY Modelers http://www.cnymod.com/
>Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
>Member JMRI Developer Team http://www.jrmi.org/
>mailto: kcameron@...
>In the Upstate New York US area of the world
>
>


Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

Let's take a minute to sync up our terms with the prototype terms, as best I understand them. Track Circuit = A section of track with detection and Block = A section of track protected by a Signal. A Block can have more than one Track Circuit, for instance to monitor the occupancy directly over a switch at a passing siding or in the case of Intermediate Blocks to determine the direction of travel (I gather that Intermediate Blocks are typically composed of two Track Circuits). It seems in our discussions that we are moving towards using the term Segment to represent a Track Circuit and Block to represent, well, a Block. I think the term Segment might just do the trick, if others agree, we'll need to make changes in JMRI, and the LE in particular, to incorporate this term
 
If you have multiple Segments in a Block, and one of those Segments represents a switch, then as you point out you need to add Internal signals at the block boundaries for those Segments in order to get the SSL to work right. The physical Block signal that the engineer sees, then acts as a distant signal for the Segment signals and will reflect the most restrictive aspect within the Block. I don't quite understand how this creates the situation that you raise though, as the Block signal will drop to Red the moment the train crosses the gaps, this is no different if its protecting a single Segment or multiple Segments. If you are referring to something ahead of the next Block signal changing and throwing a Red up in front of the train, well this could happen just as easily with single segment blocks or multiple segment blocks. It only takes one train to pull out of a siding or spur without proper authorization from the Dispatcher
 
Looking at things from the RT's point of view. I gather it treats every Segment like a Block and expects to see a signal there. I'm inclined to think that the logic would work better if it simply acted like a real engineer and based it's current speed on the last signal it saw. If it goes 3 segments until it sees the next signal, no big deal. Yes, since the RT can see the Internal signals as well as the physical Block signals, it could get a Red thrown up in front of it mid-block, but the RT doesn't swear very loud so this shouldn't present a problem :-)
 
Steve Brooks
Lansing Model Railroad Club
 
 
> Date: Sat, 5 Mar 2011 13:22:33 -0500
> From: wsthompson@...
> To: jmri-developers@...
> Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
> 
> Ken C:
> For RT's to use the smallest unit, which we are now calling a segment, there would need to be internal signals to tell the RT to do something different.
> 
> I think this is talking about increasing the restriction on a train when it is within a signaled block. This would result in an Engineer swearing. If the Engineer can not see the signal yet or any more because he has passed it how is he to know?
> 
> Now if we are talking about "in cab signals" when the train has entered a different "section", it get new signals and there are no block signals.
> 
> Walt 
>

Hi Kevin,

On Sat, Mar 5, 2011 at 9:37 AM, Kevin Dickerson <kev.public@...:

> On 03/03/2011 17:12, Giorgio wrote:
> > A thrown turnout implies a speed restriction, while a closed one does
> > not (or implies a much higher speed limit).  This applies to both
> > directions of travel.
>
> Hi Giorgio,
>
> Just picking up on your point above, would you find it sufficient if the
> block directly connected to the thrown position of a turnout has the
> speed restriction associated with it.


This may not always work. There are instances where you may enter the same
block, in the same direction both with closed and thrown turnout, i.e. when
turnouts points are oriented towards block's center.

Or do you feel that the turnout
> should have the option of adding a speed restriction to it when in the
> thrown position?  I'm thinking about the fact that you can get turnouts
> and crossovers which do not have speed restrictions over them.
>

You may either associate a speed to every turnout (with the option of
omitting it) or you may consider all turnouts between present a next signal
and check if any of them is thrown.  This would trigger the appropriate
signal aspect (e.g. "diverging") and, when defining the signal mast, the
user may associate it with whatever speed he deems appropriate .

In this regard, please note that there may be more than one turnout between
two signals. This is at least the situation on this side of the pond, where
you find usually a single signal protecting all the turnouts at the entrance
of a station.

Giorgio

Steve,
Because 'Track Circuits' are called 'Track Circuits' by the railroads, 
then I would like to propose a somewhat radical idea. Lets call them 
'Track Circuits' in JMRI. It has nice ring as well as a distinct 
advantage over calling them 'Segments' because if someone sees the term 
he can easily do a lookup on the internet and find out what they are and 
how they work. If one was to look up "Railway segment" he would be 
utterly confused because that term seems to mean a section of the 
railroad that gets constructed at one time. E.g. "High speed rail line 
gets approval to build first segment."

If someone in the JMRI community says "This block consists of two track 
circuits" I would hazard a guess that folks might be able to figure out 
what was meant by that without the necessity of a clinic presentation. <G>

Maybe we could rename our BOD-8 boards to be TC-8, but that might be 
confusing with our TC-64 units.

Dick :)

On 03/05/2011 03:03 PM, Stephen Brooks wrote:
> Let's take a minute to sync up our terms with the prototype terms, as 
> best I understand them. Track Circuit = A section of track with 
> detection and Block = A section of track protected by a Signal. A 
> Block can have more than one Track Circuit, for instance to monitor 
> the occupancy directly over a switch at a passing siding or in the 
> case of Intermediate Blocks to determine the direction of travel (I 
> gather that Intermediate Blocks are typically composed of two Track 
> Circuits). It seems in our discussions that we are moving towards 
> using the term Segment to represent a Track Circuit and Block to 
> represent, well, a Block. I think the term Segment might just do the 
> trick, if others agree, we'll need to make changes in JMRI, and the LE 
> in particular, to incorporate this term
>
> If you have multiple Segments in a Block, and one of those Segments 
> represents a switch, then as you point out you need to add Internal 
> signals at the block boundaries for those Segments in order to get the 
> SSL to work right. The physical Block signal that the engineer sees, 
> then acts as a distant signal for the Segment signals and will reflect 
> the most restrictive aspect within the Block. I don't quite 
> understand how this creates the situation that you raise though, as 
> the Block signal will drop to Red the moment the train crosses the 
> gaps, this is no different if its protecting a single Segment 
> or multiple Segments. If you are referring to something ahead of the 
> next Block signal changing and throwing a Red up in front of the 
> train, well this could happen just as easily with single segment 
> blocks or multiple segment blocks. It only takes one train to pull out 
> of a siding or spur without proper authorization from the Dispatcher
>
> Looking at things from the RT's point of view. I gather it treats 
> every Segment like a Block and expects to see a signal there. I'm 
> inclined to think that the logic would work better if it simply acted 
> like a real engineer and based it's current speed on the last signal 
> it saw. If it goes 3 segments until it sees the next signal, no big 
> deal. Yes, since the RT can see the Internal signals as well as the 
> physical Block signals, it could get a Red thrown up in front of it 
> mid-block, but the RT doesn't swear very loud so this shouldn't 
> present a problem :-)
>
> Steve Brooks
> Lansing Model Railroad Club
>
>
> > Date: Sat, 5 Mar 2011 13:22:33 -0500
> > From: wsthompson@...
> > To: jmri-developers@...
> > Subject: Re: [Jmri-developers] Observations from using RT3 for a 
> weekend show
> >
> > Ken C:
> > For RT's to use the smallest unit, which we are now calling a 
> segment, there would need to be internal signals to tell the RT to do 
> something different.
> >
> > I think this is talking about increasing the restriction on a train 
> when it is within a signaled block. This would result in an Engineer 
> swearing. If the Engineer can not see the signal yet or any more 
> because he has passed it how is he to know?
> >
> > Now if we are talking about "in cab signals" when the train has 
> entered a different "section", it get new signals and there are no 
> block signals.
> >
> > Walt
> >
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
>
>
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers

Hi Dick,
 
I'm sympathetic to your view and it wouldn't take much arm twisting to get me to go along with it. Going back to the original post, I had a couple motivations for suggesting going with the term Segment ...
 
1) For whatever reason Bob floated the term Track Circuit and it didn't seem to catch on, where Ken's (I think) Segment did, and seemed to me an improvement over the term Block
 
2) I thought Segment might create a more immediate minds eye for folks who aren't into signal terminology, then again, like you point out, the term Track Circuit is very descriptive and it isn't hard to find out what it means. I Googled it and the Wikipedia entry that pops up first in the list does a nice job
 
Steve
 
 
> Date: Sat, 5 Mar 2011 15:40:13 -0500
> From: dick@...
> To: jmri-developers@...
> Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
> 
> Steve,
> Because 'Track Circuits' are called 'Track Circuits' by the railroads, 
> then I would like to propose a somewhat radical idea. Lets call them 
> 'Track Circuits' in JMRI. It has nice ring as well as a distinct 
> advantage over calling them 'Segments' because if someone sees the term 
> he can easily do a lookup on the internet and find out what they are and 
> how they work. If one was to look up "Railway segment" he would be 
> utterly confused because that term seems to mean a section of the 
> railroad that gets constructed at one time. E.g. "High speed rail line 
> gets approval to build first segment."
> 
> If someone in the JMRI community says "This block consists of two track 
> circuits" I would hazard a guess that folks might be able to figure out 
> what was meant by that without the necessity of a clinic presentation. <G>
> 
> Maybe we could rename our BOD-8 boards to be TC-8, but that might be 
> confusing with our TC-64 units.
> 
> Dick :)
>

Steve,
I think we need to stick with the proper terms unless there is some 
compelling reason to not do so. IMHO we should not attempt to "simplify" 
our terminology to accommodate someone that has no idea of what we are 
talking about in the first place. We need to use the correct terms in an 
attempt to educate those modelers as we go along. Consider your arm twisted.

Dick :)

On 03/05/2011 04:21 PM, Stephen Brooks wrote:
> Hi Dick,
>
> I'm sympathetic to your view and it wouldn't take much arm twisting to 
> get me to go along with it. Going back to the original post, I had a 
> couple motivations for suggesting going with the term Segment ...
>
> 1) For whatever reason Bob floated the term Track Circuit and it 
> didn't seem to catch on, where Ken's (I think) Segment did, and seemed 
> to me an improvement over the term Block
>
> 2) I thought Segment might create a more immediate minds eye for folks 
> who aren't into signal terminology, then again, like you point out, 
> the term Track Circuit is very descriptive and it isn't hard to find 
> out what it means. I Googled it and the Wikipedia entry that pops up 
> first in the list does a nice job
>
> Steve
>
>
> > Date: Sat, 5 Mar 2011 15:40:13 -0500
> > From: dick@...
> > To: jmri-developers@...
> > Subject: Re: [Jmri-developers] Observations from using RT3 for a 
> weekend show
> >
> > Steve,
> > Because 'Track Circuits' are called 'Track Circuits' by the railroads,
> > then I would like to propose a somewhat radical idea. Lets call them
> > 'Track Circuits' in JMRI. It has nice ring as well as a distinct
> > advantage over calling them 'Segments' because if someone sees the term
> > he can easily do a lookup on the internet and find out what they are 
> and
> > how they work. If one was to look up "Railway segment" he would be
> > utterly confused because that term seems to mean a section of the
> > railroad that gets constructed at one time. E.g. "High speed rail line
> > gets approval to build first segment."
> >
> > If someone in the JMRI community says "This block consists of two track
> > circuits" I would hazard a guess that folks might be able to figure out
> > what was meant by that without the necessity of a clinic 
> presentation. <G>
> >
> > Maybe we could rename our BOD-8 boards to be TC-8, but that might be
> > confusing with our TC-64 units.
> >
> > Dick :)
> >
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
>
>
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers

On Mar 5, 2011, at 1:40 PM, Dick Bronson wrote:

> Because 'Track Circuits' are called 'Track Circuits' by the railroads, 
> then I would like to propose a somewhat radical idea. Lets call them 
> 'Track Circuits' in JMRI. It has nice ring

Or, you can tie it even closer to what it really is on the model railroad, and call them "Detection Circuits".

> as well as a distinct 
> advantage over calling them 'Segments' because if someone sees the term 
> he can easily do a lookup on the internet and find out what they are and 
> how they work. If one was to look up "Railway segment" he would be 
> utterly confused because that term seems to mean a section of the 
> railroad that gets constructed at one time. E.g. "High speed rail line 
> gets approval to build first segment."
> 
> If someone in the JMRI community says "This block consists of two track 
> circuits" I would hazard a guess that folks might be able to figure out 
> what was meant by that without the necessity of a clinic presentation. <G>
> 

Agree completely.

Bob

--
Bob Jacobsen, LBNL
Bob_Jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG

"Track Circuit" is now part of my terminology, ouch, OK, I give!
I would take it to mean that area of track that is detected by some form of electronic sensing of occupied or unoccupied. I do get that Real world can sense if either rail is broken, plus if there is something connecting the ckt between the rails. (interesting idea for swing/lift bridges.)
Walt


-----Original Message-----
>From: Bob Jacobsen <bob_jacobsen@...>
>Sent: Mar 5, 2011 5:15 PM
>To: "Discussions about changes to the code, design, intent,
>	etc" <jmri-developers@...>
>Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
>
>
>On Mar 5, 2011, at 1:40 PM, Dick Bronson wrote:
>
>> Because 'Track Circuits' are called 'Track Circuits' by the railroads, 
>> then I would like to propose a somewhat radical idea. Lets call them 
>> 'Track Circuits' in JMRI. It has nice ring
>
>Or, you can tie it even closer to what it really is on the model railroad, and call them "Detection Circuits".
>
>> as well as a distinct 
>> advantage over calling them 'Segments' because if someone sees the term 
>> he can easily do a lookup on the internet and find out what they are and 
>> how they work. If one was to look up "Railway segment" he would be 
>> utterly confused because that term seems to mean a section of the 
>> railroad that gets constructed at one time. E.g. "High speed rail line 
>> gets approval to build first segment."
>> 
>> If someone in the JMRI community says "This block consists of two track 
>> circuits" I would hazard a guess that folks might be able to figure out 
>> what was meant by that without the necessity of a clinic presentation. <G>
>> 
>
>Agree completely.
>
>Bob
>
>--
>Bob Jacobsen, LBNL
>Bob_Jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG
>
>
>
>
>
>
>------------------------------------------------------------------------------
>What You Don't Know About Data Connectivity CAN Hurt You
>This paper provides an overview of data connectivity, details
>its effect on application quality, and explores various alternative
>solutions. http://p.sf.net/sfu/progress-d2d
>_______________________________________________
>Jmri-developers mailing list
>Jmri-developers@...
>https://lists.sourceforge.net/lists/listinfo/jmri-developers


Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

I don't care very much how they are called, probably because English is not
my mother tongue and I already had to learn JMRI terminology: turnout
(instead of switch), closed, thrown, etc.

What I find confusing is that users often assume JMRI-blocks to be the only
way to model prototype-blocks.  SSL, if I correctly understand it, is based
on this assumption and encourages this misunderstanding (e.g. the idea that
each JRMI-block must be "protected" by a signal, whether physical or
virtual). A prototype-block, as it was correctly noted, is a piece of track
between two signals. Sensors (i.e. JMRI-Blocks) placed within the block, may
serve to set the proper aspect of block signals (if any sensor is active,
the block is occupied), but don't require a separate signal for each of
them.

The German word for "track circuit" is "track current circuit"
(Gleissstromkreis), while the Italian word is... "track circuit" (cicuito di
binario) :-) Nonetheless, I would suggest that the new name (if any) should
include the word "detection", since this is the purpose of JMRI-blocks:
detecting that a segment of track (section or whatever you like to call it)
is occupied and allow  it to be highlighted on the panel.   There can be
several reason for using them: implementing OS sections, or simply detecting
that the train reached a spot where some action must be triggered (braking,
stopping, changing speed, operating a level crossing, playing the whistle,
etc.).

Including the "detection" (or "sensing") world in the name would make it
clear, also to not English users (or uneducated users), what they are,
without the need of searching a railroad dictionary.

By the way, I use JMRI-sections (introduced by Dave Duchamp) to model
prototype blocks. They have the advantage of being composed by one or more
JMRI-blocks (i.e. detection circuits) and offer, in addition, an unambiguous
indication of train direction.  They could perhaps be promoted from
"sections" to "blocks" or simply being indicated as one of the possible
tools to model prototype-blocks :-)

ciao from Italy

Giorgio


On Sun, Mar 6, 2011 at 12:15 AM, Bob Jacobsen <bob_jacobsen@...> wrote:

>
> On Mar 5, 2011, at 1:40 PM, Dick Bronson wrote:
>
> > Because 'Track Circuits' are called 'Track Circuits' by the railroads,
> > then I would like to propose a somewhat radical idea. Lets call them
> > 'Track Circuits' in JMRI. It has nice ring
>
> Or, you can tie it even closer to what it really is on the model railroad,
> and call them "Detection Circuits".
>
> > as well as a distinct
> > advantage over calling them 'Segments' because if someone sees the term
> > he can easily do a lookup on the internet and find out what they are and
> > how they work. If one was to look up "Railway segment" he would be
> > utterly confused because that term seems to mean a section of the
> > railroad that gets constructed at one time. E.g. "High speed rail line
> > gets approval to build first segment."
> >
> > If someone in the JMRI community says "This block consists of two track
> > circuits" I would hazard a guess that folks might be able to figure out
> > what was meant by that without the necessity of a clinic presentation.
> <G>
> >
>
> Agree completely.
>
> Bob
>
> --
> Bob Jacobsen, LBNL
> Bob_Jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype
> JacobsenRG
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers
>

Hi Giorgio,
 
I'm enjoying your participation in this discussion. It's opening my eyes to how we can make JMRI more friendly for users in other parts of the world
 
To clarify one point ... a SSL signal head can protect up to 5 Track Circuits, 2 Signal Heads and 1 Turnout. Accordingly, it can protect a group of Track Circuits without requiring virtual heads at each gap, however it does require a virtual signal at any Track Circuit which includes a turnout
 
I gather from previous comments that SSL doesn't quite match up with common European aspects. Would it help if instead of calling the aspects red, flashing red, yellow, flashing and green that we called them Stop, Restricting, Approach, Advance Approach and Clear and then had a table to match the desired appearance up with the appropriate aspect? By default it would use the typical US arrangement, so as not to mess up any existing panels, but folks from other parts of the world could easily modify things to match their countries standard ABS arrangement
 
Steve Brooks
Lansing Model Railroad Club
 


Date: Sun, 6 Mar 2011 11:09:00 +0100
From: xntcp.interface@...
To: jmri-developers@...
Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show

I don't care very much how they are called, probably because English is not my mother tongue and I already had to learn JMRI terminology: turnout (instead of switch), closed, thrown, etc.

What I find confusing is that users often assume JMRI-blocks to be the only way to model prototype-blocks.  SSL, if I correctly understand it, is based on this assumption and encourages this misunderstanding (e.g. the idea that each JRMI-block must be "protected" by a signal, whether physical or virtual). A prototype-block, as it was correctly noted, is a piece of track between two signals. Sensors (i.e. JMRI-Blocks) placed within the block, may serve to set the proper aspect of block signals (if any sensor is active, the block is occupied), but don't require a separate signal for each of them.

The German word for "track circuit" is "track current circuit" (Gleissstromkreis), while the Italian word is... "track circuit" (cicuito di binario) :-) Nonetheless, I would suggest that the new name (if any) should include the word "detection", since this is the purpose of JMRI-blocks: detecting that a segment of track (section or whatever you like to call it) is occupied and allow  it to be highlighted on the panel.   There can be several reason for using them: implementing OS sections, or simply detecting that the train reached a spot where some action must be triggered (braking, stopping, changing speed, operating a level crossing, playing the whistle, etc.).

Including the "detection" (or "sensing") world in the name would make it clear, also to not English users (or uneducated users), what they are, without the need of searching a railroad dictionary.

By the way, I use JMRI-sections (introduced by Dave Duchamp) to model prototype blocks. They have the advantage of being composed by one or more JMRI-blocks (i.e. detection circuits) and offer, in addition, an unambiguous indication of train direction.  They could perhaps be promoted from "sections" to "blocks" or simply being indicated as one of the possible tools to model prototype-blocks :-)

ciao from Italy

Giorgio



On Sun, Mar 6, 2011 at 12:15 AM, Bob Jacobsen <bob_jacobsen@...> wrote:



On Mar 5, 2011, at 1:40 PM, Dick Bronson wrote:

> Because 'Track Circuits' are called 'Track Circuits' by the railroads,
> then I would like to propose a somewhat radical idea. Lets call them
> 'Track Circuits' in JMRI. It has nice ring

Or, you can tie it even closer to what it really is on the model railroad, and call them "Detection Circuits".


> as well as a distinct
> advantage over calling them 'Segments' because if someone sees the term
> he can easily do a lookup on the internet and find out what they are and
> how they work. If one was to look up "Railway segment" he would be
> utterly confused because that term seems to mean a section of the
> railroad that gets constructed at one time. E.g. "High speed rail line
> gets approval to build first segment."
>
> If someone in the JMRI community says "This block consists of two track
> circuits" I would hazard a guess that folks might be able to figure out
> what was meant by that without the necessity of a clinic presentation. <G>
>

Agree completely.


Bob

--
Bob Jacobsen, LBNL
Bob_Jacobsen@... +1-510-486-7355 fax +1-510-643-8497 AIM, Skype JacobsenRG

I've been busy with an operating session so I've been trying to follow and catch up.

Track circuits are the right thought. And we could shorten to 'Circuits' as for the coding having single words makes life simpler in the coding. Another idea would be the other end from the 'OBlock' and 'CBlock' or 'TcBlock' as other ideas in the same vein.

As Bob said, naming does help a lot in getting things across to folk.

But my bigger thought is how would we translate from one to another?? Do we have a translator at some point?? Do we keep Blocks even though they and the 'new thing' really act a whole lot like each other?? Etc.... the how would we change from where we are to where we want to be??

Regardless of names, I think this is what we are getting close to:

1. SSL uses a thing that may be one or more of the sensor driven 'some things' to protect a section of track with a boundary of signals.
2. The layout editor will build the above if the details are available in the tables.
3. We need to have layout editor help with building all these parts.


-ken cameron
Syracuse Model Railroad Club http://www.SyracuseModelRr.org/
CNY Modelers http://www.cnymod.com/
Finger Lakes Live Steamers http://www.fingerlakeslivesteamers.org/
Member JMRI Developer Team http://www.jrmi.org/
mailto: kcameron@...
In the Upstate New York US area of the world

Hi Steven,
  many thanks for your interest in the views "from the other side of the
pond" :-)

On Sun, Mar 6, 2011 at 5:02 PM, Stephen Brooks <stevobrooks@...:

>  Hi Giorgio,
>
> I'm enjoying your participation in this discussion. It's opening my eyes to
> how we can make JMRI more friendly for users in other parts of the world
>
> To clarify one point ... a SSL signal head can protect up to 5 Track
> Circuits, 2 Signal Heads and 1 Turnout. Accordingly, it can protect a group
> of Track Circuits without requiring virtual heads at each gap, however it
> does require a virtual signal at any Track Circuit which includes a turnout
>

Having one signal in front of each turnout is probably the biggest
limitation of SSL I see. I don't know if it's actually a matter of
difference between European and US signaling. I find it difficult to believe
that, even in the USA, at the entrance or exit of a station where the train
meets a sequence of several turnouts, the engineer may look at so many
signals and obey them. Having signals spaced a few yards looks not only
rather expensive (both for a model layout and for the prototype) but even
useless, since the engineer may unlikely have time and space to react.

European railroads (or at least German Austrian and Italian) have,
generally, only one signal in front of a group of turnouts.
See example: http://www.mittenwaldbahn.de/plan/gleisplan-weilheim.jpg

Signal aspect is different from "stop and stay" only when the route from the
signal to next one is "set", "protected" and not occupied, i.e.:
A route from the signal to the next one is set and locked;
All track-circuits along the route are inactive (i.e. not occupied);
Any other signal providing access to the same tracks is showing "stop and
stay".

A signal, thus, don't shows simply how turnouts happen to be set and whether
tracks happen to be occupied or not, but assures the engineer that he can
safely proceed up to next signal and that no turnout can be operated and no
other train can cross his route after he passes the signal.


> I gather from previous comments that SSL doesn't quite match up with common
> European aspects. Would it help if instead of calling the aspects red,
> flashing red, yellow, flashing and green that we called them Stop,
> Restricting, Approach, Advance Approach and Clear and then had a table to
> match the desired appearance up with the appropriate aspect? By default it
> would use the typical US arrangement, so as not to mess up any existing
> panels, but folks from other parts of the world could easily modify things
> to match their countries standard ABS arrangement
>
>
Moving from hard-coded signal appearances, as it's now, to signal aspects
that user could mach to desired appearances would certainly be a great
improvement (and would likely allow SSL to work with signal masts). Allowing
users to choose even aspect names (e.g. HP0 instead of stop, for a German
signal) would be a further possible step.





Ciao from Italy

Giorgio

PS: A suggestion.  Why not making SSL even simpler? User can place signals
where he likes and LayoutEditor determines their aspects by recursively
examining all track elements ahead until another signal (or a turnout not
properly set) is found.

-----Original Message-----

From: Giorgio 



Having one signal in front of each turnout is probably the biggest limitation of SSL I see. I don't know if it's actually a matter of difference between European and US signaling. I find it difficult to believe that, even in the USA, at the entrance or exit of a station where the train meets a sequence of several turnouts, the engineer may look at so many signals and obey them. Having signals spaced a few yards looks not only rather expensive (both for a model layout and for the prototype) but even useless, since the engineer may unlikely have time and space to react.
 
Ciao from Italy

Giorgio

Hello Giorgio:
I use the signal at each turnout only for creating the logic need for the signal at the start of the ladder. I use Distant signals and Internal signals to accomplish that. If you look at the WaltLayoutEditorPanel-lights.xml in 
Files*Problems Being Worked On*WaltsStuff in the upper left are a number of examples.

Maybe we could take up a collection to get you over here for the national. Its a three to four day trip for me on the MC.

Ciao from Minnesota
Walt

Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

Hi Walt,

I use the signal at each turnout only for creating the logic need for the
> signal at the start of the ladder. I use Distant signals and Internal
> signals to accomplish that.
>

When you write "logic" do you mean logix? I suspect this goes beyond SSL.


> Maybe we could take up a collection to get you over here for the national.
> Its a three to four day trip for me on the MC.
>

Thank you for the generous offer!  A remote connection would however be
easier and cheaper :-)

Giorgio

PS: This does not exclude the possibility of a future meeting, if I happen
to be in the States at the right time :-)

The last paragraph of Giorgio's would cover a couple of bases, a translation between signal heads and masts. If we can figure this out we can gain a number of things. Conversion of tools that know heads into masts, many things gain.
-ken cameron
Excuse me, this was sent from my BlackBerry.

From: Giorgio [mailto:xntcp.interface@...]
Sent: Sunday, March 06, 2011 04:31 PM
To: Discussions about changes to the code, design, intent, etc <jmri-developers@...>
Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show

Hi Steven,
  many thanks for your interest in the views "from the other side of the pond" :-)

On Sun, Mar 6, 2011 at 5:02 PM, Stephen Brooks <stevobrooks@...>> wrote:
Hi Giorgio,

I'm enjoying your participation in this discussion. It's opening my eyes to how we can make JMRI more friendly for users in other parts of the world

To clarify one point ... a SSL signal head can protect up to 5 Track Circuits, 2 Signal Heads and 1 Turnout. Accordingly, it can protect a group of Track Circuits without requiring virtual heads at each gap, however it does require a virtual signal at any Track Circuit which includes a turnout

Having one signal in front of each turnout is probably the biggest limitation of SSL I see. I don't know if it's actually a matter of difference between European and US signaling. I find it difficult to believe that, even in the USA, at the entrance or exit of a station where the train meets a sequence of several turnouts, the engineer may look at so many signals and obey them. Having signals spaced a few yards looks not only rather expensive (both for a model layout and for the prototype) but even useless, since the engineer may unlikely have time and space to react.

European railroads (or at least German Austrian and Italian) have, generally, only one signal in front of a group of turnouts.
See example: http://www.mittenwaldbahn.de/plan/gleisplan-weilheim.jpg

Signal aspect is different from "stop and stay" only when the route from the signal to next one is "set", "protected" and not occupied, i.e.:
A route from the signal to the next one is set and locked;
All track-circuits along the route are inactive (i.e. not occupied);
Any other signal providing access to the same tracks is showing "stop and stay".

A signal, thus, don't shows simply how turnouts happen to be set and whether tracks happen to be occupied or not, but assures the engineer that he can safely proceed up to next signal and that no turnout can be operated and no other train can cross his route after he passes the signal.


I gather from previous comments that SSL doesn't quite match up with common European aspects. Would it help if instead of calling the aspects red, flashing red, yellow, flashing and green that we called them Stop, Restricting, Approach, Advance Approach and Clear and then had a table to match the desired appearance up with the appropriate aspect? By default it would use the typical US arrangement, so as not to mess up any existing panels, but folks from other parts of the world could easily modify things to match their countries standard ABS arrangement


Moving from hard-coded signal appearances, as it's now, to signal aspects that user could mach to desired appearances would certainly be a great improvement (and would likely allow SSL to work with signal masts). Allowing users to choose even aspect names (e.g. HP0 instead of stop, for a German signal) would be a further possible step.





Ciao from Italy

Giorgio

PS: A suggestion.  Why not making SSL even simpler? User can place signals where he likes and LayoutEditor determines their aspects by recursively examining all track elements ahead until another signal (or a turnout not properly set) is found.

I might be able to add something to the topic of how to connect
signals, based on my experiences in writing CATS.  This is not
prototypical, but seems to be working with 7 years of use behind
it. The executive summary is that CATS connects signals together
by "following the tracks". 

In CATS, every signal has some "signal logic" underneath it.  To be
brief, I will abbreviate "signal logic" as SL.  Each SL has a
predecessor SL and a successor SL (except for signals near
the end of signaled territory).  The predecessor SL is
"downstream" in the traffic flow - a train passes the predecessor
signal before passing the SL's signal.  The SL feeds the predecessor
SL its state and receives the successor (next in the traffic flow)
SL's state.  An SL needs to be concerned only about knowing the
predecessor SL.  It need not know the successor SL because the
successor knows it.  For the computer science folks, this is a
simple linked list

CATS mistakenly calls a "track circuit" a "block".  For this
discussion, I will use "track circuit" to mean all the tracks
attached to a single occupancy detector.  A "signal block" is all
the track circuits between two signals, facing in the same
direction of travel.  To create an indication for its associated
signal, an SL needs two pieces of information - the state of the
track circuits between it and its successor ("myIndication")
and the indication of its successor ("nextIndication").  There is
an SL on the end of each track on the ends of each traffic circuit.
These form the linked lists.  Thus, like electrons flow opposite
the current in electricity, signal indications flow opposite the
direction a train is traveling.

An SL may have a signal or not.  Those that do, add their indication
to the "nextIndication" field of the information passed to their
predecessor.  Those that do not, simply pass along the
"nextIndication" field.  Those that do not have associated signals
look at the "myIndication" field being passed along.  If the state
of the track circuit being protected is more restrictive than the
ones that precede it, it amends "myIndication".  If any track circuit
upstream is more restrictive, the SL does not touch "myIndication".
Eventually, "myIndication" and "nextIndication" propagate through
the signal block, each traffic circuit contributing it's piece,
as needed.  The SL associated with signals compute the indication
based on "myIndication" and "nextIndication" and the signal object
uses a look up table to determine the aspect.

As the discussion thread has shown, turnouts complicate things.
Switch points in the direction of travel create a fork.  Frogs
in the direction of travel create a merge.  Consequently, the
predecessor SL link varies, depending upon the alignment of the
points.

The way CATS handles this is by introducing two derived forms
of SLs: an OSSignal and a FrogSignal.  Neither has a signal
associated with it.  They exist solely to dynamically redirect
the information flow at the points.  The OSSignal faces the "wrong"
way at the points.  It protects against exiting the points, rather
than entering the points.  It has two (or three) predecessors - the
SLs out at the ends of the tracks that make up the points.  It will
"feed" one the SLs the indication of what it receives from its
successor (the signal seen by a train exiting the points into the
approach track).  It will feed its other predecessor(s) a
"myIndication" set to "fouling".

There is one FrogSignal SL on each track that forms the points.  Its
successor is away from the frog on the branch out of the turnout.  If
the points are aligned for that path, then its predecessor is the SL
that protects entry into the points (Note: contrary to the natural
way of thinking about points, its predecessor is NOT the OSSignal).
If the points are not aligned for the track holding the FrogSignal
SL, then it has no predecessor.  This is OK because the flow of its
signal information is from the frog to the points end of the turnout
and the points are not aligned for it.

Because OSSignals and FrogSignals are derived from SLs, they are full
partners in the SL linked list.  Thus, they can feed other OSSignals
and FrogSignals, allowing arbitrary connections between tracks.

What information is propagated from one SL to its predecessor?
The indication of its successor and the most restrictive
condition of any track circuit between the SL and its successor are
sent.  In CATS, each "rail" is given a speed, which contributes to
the condition.  Thus, switch points are composed of two (or three)
"rails", but only one will be traversed.  The one that is traversed
is on the "connected" linked list.  The speeds of the non-aligned
"rails" are ignored until the points are aligned differently.  The
slowest speed dominates because it is most restrictive.  Of course
occupied track, fouling track, etc. are the most restrictive
conditions that supercede the defined speed.

Can this be used to automatically fill out SSL?  Beats me.  Probably
not.  But, there may also be easier ways of doing things, as well.

Sorry for the length of this, but I wanted to provide an example of
one way of automatically figuring out which signals protect which
track circuits and how they compute their indications.  If you
thought this was bad, just wait until crossings are explored!

 Rodney Black

Giorgio,
How about "Track detection circuits"?

Dick :)

On 03/06/2011 05:09 AM, Giorgio wrote:
> I don't care very much how they are called, probably because English 
> is not my mother tongue and I already had to learn JMRI terminology: 
> turnout (instead of switch), closed, thrown, etc.
>
> What I find confusing is that users often assume JMRI-blocks to be the 
> only way to model prototype-blocks.  SSL, if I correctly understand 
> it, is based on this assumption and encourages this misunderstanding 
> (e.g. the idea that each JRMI-block must be "protected" by a signal, 
> whether physical or virtual). A prototype-block, as it was correctly 
> noted, is a piece of track between two signals. Sensors (i.e. 
> JMRI-Blocks) placed within the block, may serve to set the proper 
> aspect of block signals (if any sensor is active, the block is 
> occupied), but don't require a separate signal for each of them.
>
> The German word for "track circuit" is "track current circuit" 
> (Gleissstromkreis), while the Italian word is... "track circuit" 
> (cicuito di binario) :-) Nonetheless, I would suggest that the new 
> name (if any) should include the word "detection", since this is the 
> purpose of JMRI-blocks: detecting that a segment of track (section or 
> whatever you like to call it) is occupied and allow  it to be 
> highlighted on the panel.   There can be several reason for using 
> them: implementing OS sections, or simply detecting that the train 
> reached a spot where some action must be triggered (braking, stopping, 
> changing speed, operating a level crossing, playing the whistle, etc.).
>
> Including the "detection" (or "sensing") world in the name would make 
> it clear, also to not English users (or uneducated users), what they 
> are, without the need of searching a railroad dictionary.
>
> By the way, I use JMRI-sections (introduced by Dave Duchamp) to model 
> prototype blocks. They have the advantage of being composed by one or 
> more JMRI-blocks (i.e. detection circuits) and offer, in addition, an 
> unambiguous indication of train direction.  They could perhaps be 
> promoted from "sections" to "blocks" or simply being indicated as one 
> of the possible tools to model prototype-blocks :-)
>
> ciao from Italy
>
> Giorgio
>
>
> On Sun, Mar 6, 2011 at 12:15 AM, Bob Jacobsen <bob_jacobsen@... 
> <mailto:bob_jacobsen@...>> wrote:
>
>
>     On Mar 5, 2011, at 1:40 PM, Dick Bronson wrote:
>
>     > Because 'Track Circuits' are called 'Track Circuits' by the
>     railroads,
>     > then I would like to propose a somewhat radical idea. Lets call them
>     > 'Track Circuits' in JMRI. It has nice ring
>
>     Or, you can tie it even closer to what it really is on the model
>     railroad, and call them "Detection Circuits".
>
>     > as well as a distinct
>     > advantage over calling them 'Segments' because if someone sees
>     the term
>     > he can easily do a lookup on the internet and find out what they
>     are and
>     > how they work. If one was to look up "Railway segment" he would be
>     > utterly confused because that term seems to mean a section of the
>     > railroad that gets constructed at one time. E.g. "High speed
>     rail line
>     > gets approval to build first segment."
>     >
>     > If someone in the JMRI community says "This block consists of
>     two track
>     > circuits" I would hazard a guess that folks might be able to
>     figure out
>     > what was meant by that without the necessity of a clinic
>     presentation. <G>
>     >
>
>     Agree completely.
>
>     Bob
>
>     --
>     Bob Jacobsen, LBNL
>     Bob_Jacobsen@... <mailto:Bob_Jacobsen@...> +1-510-486-7355
>     fax +1-510-643-8497 AIM, Skype JacobsenRG
>
>
>
>
>
>
>     ------------------------------------------------------------------------------
>     What You Don't Know About Data Connectivity CAN Hurt You
>     This paper provides an overview of data connectivity, details
>     its effect on application quality, and explores various alternative
>     solutions. http://p.sf.net/sfu/progress-d2d
>     _______________________________________________
>     Jmri-developers mailing list
>     Jmri-developers@...
>     <mailto:Jmri-developers@...>
>     https://lists.sourceforge.net/lists/listinfo/jmri-developers
>
>
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
>
>
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers

What about other kinds of detection, like photo cells?
Walt


-----Original Message-----
>From: Dick Bronson <dick@...>
>Sent: Mar 7, 2011 12:12 AM
>To: "Discussions about changes to the code, design, intent,
>	etc" <jmri-developers@...>
>Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show
>
>Giorgio,
>How about "Track detection circuits"?
>
>Dick :)
>
>On 03/06/2011 05:09 AM, Giorgio wrote:
>> I don't care very much how they are called, probably because English 
>> is not my mother tongue and I already had to learn JMRI terminology: 
>> turnout (instead of switch), closed, thrown, etc.
>>
>> What I find confusing is that users often assume JMRI-blocks to be the 
>> only way to model prototype-blocks.  SSL, if I correctly understand 
>> it, is based on this assumption and encourages this misunderstanding 
>> (e.g. the idea that each JRMI-block must be "protected" by a signal, 
>> whether physical or virtual). A prototype-block, as it was correctly 
>> noted, is a piece of track between two signals. Sensors (i.e. 
>> JMRI-Blocks) placed within the block, may serve to set the proper 
>> aspect of block signals (if any sensor is active, the block is 
>> occupied), but don't require a separate signal for each of them.
>>
>> The German word for "track circuit" is "track current circuit" 
>> (Gleissstromkreis), while the Italian word is... "track circuit" 
>> (cicuito di binario) :-) Nonetheless, I would suggest that the new 
>> name (if any) should include the word "detection", since this is the 
>> purpose of JMRI-blocks: detecting that a segment of track (section or 
>> whatever you like to call it) is occupied and allow  it to be 
>> highlighted on the panel.   There can be several reason for using 
>> them: implementing OS sections, or simply detecting that the train 
>> reached a spot where some action must be triggered (braking, stopping, 
>> changing speed, operating a level crossing, playing the whistle, etc.).
>>
>> Including the "detection" (or "sensing") world in the name would make 
>> it clear, also to not English users (or uneducated users), what they 
>> are, without the need of searching a railroad dictionary.
>>
>> By the way, I use JMRI-sections (introduced by Dave Duchamp) to model 
>> prototype blocks. They have the advantage of being composed by one or 
>> more JMRI-blocks (i.e. detection circuits) and offer, in addition, an 
>> unambiguous indication of train direction.  They could perhaps be 
>> promoted from "sections" to "blocks" or simply being indicated as one 
>> of the possible tools to model prototype-blocks :-)
>>
>> ciao from Italy
>>
>> Giorgio
>>
>>
>> On Sun, Mar 6, 2011 at 12:15 AM, Bob Jacobsen <bob_jacobsen@... 
>> <mailto:bob_jacobsen@...>> wrote:
>>
>>
>>     On Mar 5, 2011, at 1:40 PM, Dick Bronson wrote:
>>
>>     > Because 'Track Circuits' are called 'Track Circuits' by the
>>     railroads,
>>     > then I would like to propose a somewhat radical idea. Lets call them
>>     > 'Track Circuits' in JMRI. It has nice ring
>>
>>     Or, you can tie it even closer to what it really is on the model
>>     railroad, and call them "Detection Circuits".
>>
>>     > as well as a distinct
>>     > advantage over calling them 'Segments' because if someone sees
>>     the term
>>     > he can easily do a lookup on the internet and find out what they
>>     are and
>>     > how they work. If one was to look up "Railway segment" he would be
>>     > utterly confused because that term seems to mean a section of the
>>     > railroad that gets constructed at one time. E.g. "High speed
>>     rail line
>>     > gets approval to build first segment."
>>     >
>>     > If someone in the JMRI community says "This block consists of
>>     two track
>>     > circuits" I would hazard a guess that folks might be able to
>>     figure out
>>     > what was meant by that without the necessity of a clinic
>>     presentation. <G>
>>     >
>>
>>     Agree completely.
>>
>>     Bob
>>
>>     --
>>     Bob Jacobsen, LBNL
>>     Bob_Jacobsen@... <mailto:Bob_Jacobsen@...> +1-510-486-7355
>>     fax +1-510-643-8497 AIM, Skype JacobsenRG
>>
>>
>>
>>
>>
>>
>>     ------------------------------------------------------------------------------
>>     What You Don't Know About Data Connectivity CAN Hurt You
>>     This paper provides an overview of data connectivity, details
>>     its effect on application quality, and explores various alternative
>>     solutions. http://p.sf.net/sfu/progress-d2d
>>     _______________________________________________
>>     Jmri-developers mailing list
>>     Jmri-developers@...
>>     <mailto:Jmri-developers@...>
>>     https://lists.sourceforge.net/lists/listinfo/jmri-developers
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What You Don't Know About Data Connectivity CAN Hurt You
>> This paper provides an overview of data connectivity, details
>> its effect on application quality, and explores various alternative
>> solutions. http://p.sf.net/sfu/progress-d2d
>>
>>
>> _______________________________________________
>> Jmri-developers mailing list
>> Jmri-developers@...
>> https://lists.sourceforge.net/lists/listinfo/jmri-developers
>
>
>------------------------------------------------------------------------------
>What You Don't Know About Data Connectivity CAN Hurt You
>This paper provides an overview of data connectivity, details
>its effect on application quality, and explores various alternative
>solutions. http://p.sf.net/sfu/progress-d2d
>_______________________________________________
>Jmri-developers mailing list
>Jmri-developers@...
>https://lists.sourceforge.net/lists/listinfo/jmri-developers

Hi Dick.

On Mon, Mar 7, 2011 at 7:12 AM, Dick Bronson <dick@...> wrote:

> Giorgio,
> How about "Track detection circuits"?
>
> This would be great!

Clearly understandable both from experts and illiterates :-)

Coming to the implementation aspects:
JMRI-blocks could be easily renamed "Track detection circuits" (or whatever
else you like);
Paths, currently connecting blocks, would connect "Track detection
circuits"; and
Sections would be composed by "Track detection circuits".

Blocks would thus... disappear, unless Sections are renamed Blocks or a new
class is introduced (which would however duplicate most of Section's
features).

I don't know what impact the change would have on SSL and other JMRI tools
(OBlocks, etc.)

ciao from Italy

Giorgio

Hi Steve,

 ...folks from other parts of the world could easily modify things to match
> their countries standard ABS arrangement
>
> In my previous message I forgot to mention, that, at least in Italy, ABS is
employed only on two-track lines (and only outside stations). In a station
(whether manned or not) entry/exit signal are controlled by CTC, as are
single track lines (which are short, since  stations are usually close).
There is no APB and having trains that follow each other on single track is
rather unusual.  You can think of the whole single track line between two
stations as a single block that can be used only by one train at the time.

In small/medium layouts, thus, the possibility of using ABS is rather
limited.

In the past (and in some stations, I suspect, still nowadays), traffic on
single-track lines was coordinated by means of control boxes placed in the
two stations.

http://farm4.static.flickr.com/3209/3052455002_53cd6aaa81_o.jpg

The "sending" station master set its turnouts and turned a lever to ask
"permission to send". The "receiving" master set ists turnouts and turned
its lever to "grant permission". Only at this point, the "sender" could
clear the signal and the whole system was locked until the train triggered a
pedal placed after the entry signal of the "receiving" station.  I guess you
likely had similar systems in the USA... many years ago :-)

Giorgio

--- On Sun, 3/6/11, Giorgio <xntcp.interface@...> wrote:
>European railroads (or at least German Austrian and Italian) have, generally, only one signal in front of a group of turnouts. 
See example: http://www.mittenwaldbahn.de/plan/gleisplan-weilheim.jpg


>Signal aspect is different from "stop and stay" only when the route from the signal to next one is "set", "protected" and not occupied, i.e.:
A route from the signal to the next one is set and locked;

All track-circuits along the route are inactive (i.e. not occupied);
Any other signal providing access to the same tracks is showing "stop and stay".

>A signal, thus, don't shows simply how turnouts happen to be set and whether tracks happen to be occupied or not, but assures the engineer that he can safely proceed up to next signal and that no turnout can be operated and no other train can cross his route after he passes the signal.


I believe a signal system meeting Giorgio's requirements can be derived from the current OBlocK/Portal/OPath classes.  As others pointed out, a name change is needed, so let me call an OBlock, which has but one detection sensor, a detection circuit "DCBlock".

A prototype block, should have a signal at every entrance to it - otherwise there is no protection.  A prototype block  can be represented as a class, ("PBlock"), containing a set of "DCBlocks".   Each entrance to the PBlock is a DCBock with a Portal containing a protecting signal.

Portals contain the paths (OPaths) through their blocks and each OPath contains the turnouts and their settings needed to set its path.  Crossing diamonds and their settings must be added to OPaths.  Currently they are no mentioned as being required to define a path in OPaths.

When ever a turnout in the PBlock changes, a check for each entrance is made to
 see whether there is a route set through the PBlock. From the entrance, walk each path, Portal to Portal, checking OPaths until a turnout set is found set against the route. If so, set the entrance signal to Stop and Stay aspect.  If not and all
 turnouts are closed, then it is a
 potential Clear aspect.  If a turnout in the route is diverging, it is a potential Diverge aspect.  Next, at the exit Portal, query the entrance signal to the adjacent PBlock. etc.

One additional thing to be determined is the direction of the route, since the signal protecting the entrance that is the exit of the above signal, has also found this route through the PBlock.  One of these signals must set to Stop.

An advantage of an interlock implemented this way is that if other signal pairs in the PBlock find routes they can safely be set to allow another train to run through the block.  (When two sets of route turnouts/crossings are disjoint,  the two routes are non-intersecting.)

Implementation:
In Layout Editor, LayoutBlocks contain Jmri.Block by composition. An OBlock is a subclass of Jmri.Block, so a LayoutBlock could contain an OBlock.  Wherever LE connects blocks, it would need to create
 Portals and OPaths.  Perhaps Sections could be converted to be the PBlock class mentioned above.

I am looking into generating OBlocks, Portals and OPaths from track diagrams in Control Panel Editor.

Regards,
Pete C.

Does a real Dispatcher Panel show all the signals that the Engineer sees? Or does it just show what the Dispatcher controls? Could it be that all the track segments have signals for the Engineer but the dispatcher doesn't car about them?

Walt Thompson
1405 Portland Ave
Saint Paul, MN
55104
Ph 651-644-8673

Moderator, Yahoo JMRIusers group
TLR, TCD
NMRA #136859

On 07/03/2011 19:41, Pete Cressman wrote:
>
> --- On *Sun, 3/6/11, Giorgio /<xntcp.interface@...>/* wrote:
>
>     Implementation:
>     In Layout Editor, LayoutBlocks contain Jmri.Block by composition. An
>     OBlock is a subclass of Jmri.Block, so a LayoutBlock could contain
>     an OBlock. Wherever LE connects blocks, it would need to create
>     Portals and OPaths. Perhaps Sections could be converted to be the
>     PBlock class mentioned above.
>
>     I am looking into generating OBlocks, Portals and OPaths from track
>     diagrams in Control Panel Editor.
>
>     Regards,
>     Pete C.

Pete,

You may want to wait a little while, I'm just about to start some 
initial testing with Steve which will do what Giorgio requires using the 
layout editor as a base.  This covers, full interlocking, block 
reservation and setting the turnouts and Signal Masts appropriately.  It 
also has an entry exit mechanism for station areas, along with automatic 
signalling where required on main lines.

Regards
Kevin

Hi Pete,

Implementation:
> In Layout Editor, LayoutBlocks contain Jmri.Block by composition. An OBlock
> is a subclass of Jmri.Block, so a LayoutBlock could contain an OBlock.
> Wherever LE connects blocks, it would need to create Portals and OPaths.
> Perhaps Sections could be converted to be the PBlock class mentioned above.
>
> When OPath appeared I got the impression that they were somehow a duplicate
of Paths created by LayoutEditor, the main difference being that OPaths were
created manually and LE Paths automatically.

I think it would be rather easy to create OBlocks from LE Blocks and OPaths
(and Portals) starting from LE Paths.  They likely contain the same
relationships. The main problem I see is maintaining the synchronization
between Paths and Opaths. As far as I understand, the first ones get
re-created each time the panel is loaded (this helps overcoming problems due
to changes).  Furthermore, if the panel is changed, LE creates/modifies
paths (should this changes be automatically reflected in Opaths, where user
may have manually added/modified data?).

It's a typical problem of synchronization between data automatically created
and those manually entered :-)

Probably, creation of OBlocks, etc. from LE data should be manually
triggered by user and, in case previous data (OBlocks, etc.) are found and
do not match, differences should be listed letting user decide what to do.

I am looking into generating OBlocks, Portals and OPaths from track diagrams
> in Control Panel Edito
>
>
Converging data created by LE and those created/used by Panel Editor (Or
Control Panel Editor) into a unique structure would allow users to employ
the same automation tools irrelevant from the chosen editor.


ciao

Giorgio

Walt,
The classic dispatchers panel doesn't show the individual signals at 
all. It shows the block occupancy between inter-lockings and/or in the 
inter-lockings. (not each individual track detection circuit) It also 
shows the turnout position within the interlocking and indicates if the 
home signals are set to stop or not. (It does not indicate exactly what 
they are set to other than stop or proceed.) There is no indication at 
all about the state of any intermediate signals. I.e. the dispatcher and 
engineer see pretty much different views of things.

The dispatcher is concerned with setting up the permissions for a train 
to use a section of track in a given direction. The engineer is 
concerned with knowing what the conditions are ahead of him and what 
speed he is expected to be going.

Dick :)

On 03/07/2011 03:06 PM, Walter Thompson wrote:
> Does a real Dispatcher Panel show all the signals that the Engineer sees? Or does it just show what the Dispatcher controls? Could it be that all the track segments have signals for the Engineer but the dispatcher doesn't car about them?
>
> Walt Thompson
> 1405 Portland Ave
> Saint Paul, MN
> 55104
> Ph 651-644-8673
>
> Moderator, Yahoo JMRIusers group
> TLR, TCD
> NMRA #136859
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Jmri-developers mailing list
> Jmri-developers@...
> https://lists.sourceforge.net/lists/listinfo/jmri-developers

Walt,

> Does a real Dispatcher Panel show all the signals that the Engineer  sees? Or 
>does it just show what the Dispatcher controls? Could it be  that all the track 
>segments have signals for the Engineer but the  dispatcher doesn't car about 
>them?

Not to be picky, but it does depend a little upon the kind of dispatcher panel.  
As Dick replied, a classic (US&S, GRE, "knobs and switches", etc.) panel does 
not show field signals at all.  A modern dispatcher panel has icons tha look 
like signals, but those icons are essentially a replacement for the "traffic" 
lever of a classic panel.  It just so happens that there tends to be a tight 
correlation between the icons and field signals.  Some railroads call those 
signals "control points" because the dispatcher has control over them.  In 
between those field signals can be other signals often called "intermediates".  
The primary function of the intermediates is to prevent one train from running 
into the rear end of a train ahead of it, traveling in the same direction.  In 
CTC, the intermediates are based on "automatic signaling".  Thus, the signals at 
control points are under direct dispatcher control (i.e. have an appearance on 
the dispatcher panel) and the intermediate signals do not have an appearance on 
the dispatcher panel, but are set based on ABS or APB (or some derivative) 
rules.  Automatic signaling requires some form of train detection, which 
historically has meant multiple track circuits.  The converse need not be true.  
A track circuit does not require a dedicated field signal.

I would answer your questions as no, yes, maybe.

 Rodney Black

<head><style>body{font-size:10pt;font-family:arial,sans-serif;background-color:#ffffff;color:black;}p{margin:0px;}</style></head><body><font color="#000000"><font size="2"><font face="arial,sans-serif">Rodney:<br>Your answer made me chuckle.&nbsp; It seems that is the real answer to all question about signals and Panels. There is no hard and fast rule that is in use, but there are hard and fast rules for each situation. Even "you can not pass a Red signal" is not always true. <br>Regards/Ciao<br>Walt<br></font></font></font><blockquote style="padding-left: 5px; margin-left: 0px; border-left: 2px solid rgb(0, 0, 255);">-----Original Message-----
<br>From: Rodney Black <rodneyblack2000@...>
<br>Sent: Mar 8, 2011 9:28 AM
<br>To: jmri-developers@...
<br>Subject: Re: [Jmri-developers] Observations from using RT3 for a weekend show

<br><br><zzzhtml><zzzhead><style type="text/css"><ZZZ!-- DIV {margin:0px;} --></style></zzzhead><zzzbody><div style="font-family: times new roman,new york,times,serif; font-size: 12pt; color: rgb(0, 0, 0);">Walt,<br><br>&gt; Does a real Dispatcher Panel show all the signals that the Engineer 
sees? Or does it just show what the Dispatcher controls? Could it be 
that all the track segments have signals for the Engineer but the 
dispatcher doesn't car about them?<br><br>Not to be picky, but it does depend a little upon the kind of dispatcher panel.&nbsp; As Dick replied, a classic (US&amp;S, GRE, "knobs and switches", etc.) panel does not show field signals at all.&nbsp; A modern dispatcher panel has icons tha look like signals, but those icons are essentially a replacement for the "traffic" lever of a classic panel.&nbsp; It just so happens that there tends to be a tight correlation between the icons and field signals.&nbsp; Some railroads call those signals "control points" because the dispatcher has control over them.&nbsp; In between those field signals can be other signals often called "intermediates".&nbsp; The primary function of the intermediates is to prevent one train from running into the rear end of a train ahead of it, traveling in the same direction.&nbsp; In CTC, the intermediates are based on "automatic signaling".&nbsp; Thus, the signals at control points are
 under direct dispatcher control (i.e. have an appearance on the dispatcher panel) and the intermediate signals do not have an appearance on the dispatcher panel, but are set based on ABS or APB (or some derivative) rules.&nbsp; Automatic signaling requires some form of train detection, which historically has meant multiple track circuits.&nbsp; The converse need not be true.&nbsp; A track circuit does not require a dedicated field signal.<br><br>I would answer your questions as no, yes, maybe.<br><div>&nbsp;</div>Rodney Black<div><br></div>
</div><br>







      </zzzbody></zzzhtml></rodneyblack2000@...>