[rickloader]

Glad it is some use Ebner! I think for developing your route the decision will be between "TrainHasCallOn" and "TrainHasCallOn_Restricted" (see manual P150). Rob says that "TrainHasCallOn" is for USA style permissive working. But I got a cornfield meet on a free line, so it needs care. However, if "TrainHasCallOn_Restricted" is safer and more appropriate for the UK, it is confined to station platforms. A WIP routebuilder can add platforms as required : for timetables in existing routes the required platforms may not be present.

Thanks for the discussion on signals Joseph. I`m ignorant of USA signals, and your description and signal charts are very helpful.
I think part of the difference between OR timetables and real life is that to a timetable,a couple of wagons in a siding returns a block occupied and a stop indication. So Rob`s explanation that callon is required for pickup etc is crucial. In the real railway a shunting signal would be cleared for a local move to pickup a few wagons in a siding. In MSTS to be any use, such shunting signals will be absolute stop signals. So shunt signals need callon capability to allow shunt moves in timetables.
Thanks also for the revised script. However, i think the callon section -

if (TrainHasCallOn()) // clear on CallOn
needs to test also for block occupied -
if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn() )

If the active pickup train arrives first, before the passive donor train, it will precede the donor train and not be able to make the pickup. With the block_occupied test, the pickup train should halt at the signal joining the track set for the approaching donor train.
When the donor train is in position the pickup train then gets the callon indication.
This works in testing, and is really neat to see!
I`m now testing with stop and shunt signals on my own WIP route timetable.
rick

[Jovet]

rickloader, on 07 October 2017 - 02:49 AM, said:

Thanks for the discussion on signals Joseph. I`m ignorant of USA signals, and your description and signal charts are very helpful.

Happy to help. An archive of a definitive explanation of how to philosophically interpret US signaling can be found here. A compilation of an excellent explanation of how discreet applications of US signaling work can be found here.

rickloader, on 07 October 2017 - 02:49 AM, said:

In the real railway a shunting signal would be cleared for a local move to pickup a few wagons in a siding. In MSTS to be any use, such shunting signals will be absolute stop signals. So shunt signals need callon capability to allow shunt moves in timetables.

In the real world, Shunting signals take care of all of this. Shunting signals are a kind of "call on" signal in concept but there are also important differences, as I described above. A proper solution for OR would not "require" that "shunting" signals have "call-on" capability. MSTS/OR has no good way to properly implement Shunting signals as they should be operated as on the prototype, so any current tries to have them will have to fall short.

rickloader, on 07 October 2017 - 02:49 AM, said:

Thanks also for the revised script. However, i think the callon section -
if (TrainHasCallOn()) // clear on CallOn
needs to test also for block occupied -
if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn() )
If the active pickup train arrives first, before the passive donor train, it will precede the donor train and not be able to make the pickup. With the block_occupied test, the pickup train should halt at the signal joining the track set for the approaching donor train.

Well, my script-writing also makes assumptions about how timetable mode works. It assumes that "call-ons" are only shown to the appropriate train [if OR is playing dispatcher, then it needs to know what is going on!], and that they reset as soon as that train accepts (passes) the signal. It also assumes that "call-ons" are only shown on absolute signals, and are not shown/needed to enter an unoccupied signal block—since otherwise spoils the purpose in the first place. But if you find that additional condition works better for you in practice, go for it! I just suggest you get rid of that # since it's extraneous.

[roeter]

Jovet, on 11 October 2017 - 04:37 AM, said:

In the real world, Shunting signals take care of all of this. Shunting signals are a kind of "call on" signal in concept but there are also important differences, as I described above. A proper solution for OR would not "require" that "shunting" signals have "call-on" capability. MSTS/OR has no good way to properly implement Shunting signals as they should be operated as on the prototype, so any current tries to have them will have to fall short.

I'm sorry but I completely disagree with the above statement. Neither MSTS nor OR implement any actual signal logic. Both only provide basic building blocks from which the logic can be build using the signal scripting. So, if no proper shunt signals do presently exist, it is because no script writer has been able to define the correct logic.
It may be that some specific 'building block' to define such logic is missing. But, upto now, I have not received any request from any writer of USA-based signal scripts to provide such a specific function. I have received such requests from a number of writers of Europe-based signal scripts, indicating specific situations or specific logic which could not be implemented and requests and suggestions for additional functions to overcome these problems, which have indeed been created allowing the signals to work as required. But, as I said, I have not received any such requests for USA-based signal scripts.
So, in my view, the fact that no proper (USA) shunt signals exist is not because of limitations in OR, but because of a lack of effort by the script-writers to provide the proper logic for such signals. There is a small excuse for this : MSTS could not handle situations with multiple non-player trains (AI or STATIC) on a single section of track, and so for MSTS there was never any need to create proper shunt signals. But OR can handle such situations perfectly well.
If any functionality to provide proper shunt signal logic is indeed still missing I would be interested to hear of this.

Quote

Well, my script-writing also makes assumptions about how timetable mode works. It assumes that "call-ons" are only shown to the appropriate train [if OR is playing dispatcher, then it needs to know what is going on!], and that they reset as soon as that train accepts (passes) the signal. It also assumes that "call-ons" are only shown on absolute signals, and are not shown/needed to enter an unoccupied signal block—since otherwise spoils the purpose in the first place. But if you find that additional condition works better for you in practice, go for it! I just suggest you get rid of that # since it's extraneous.

The call-on function as such has nothing to do with timetable mode - it could work just as well for activities provided there was some way that the necessary information could be added to the activity definition.
But as for its function : the call-on functions only test if the train which is requesting the signal to clear should be allowed to pass that signal, based on commands set for that train and the actual train ahead. The function does not check if the path to the train ahead is actually clear - that information is available through the blockstate function. So, indeed, one must always check on BLOCK_JN_OBSTRUCTED as a signal should never be allowed to clear on that blockstate.
The logic as shown, using BLOCK_OCCUPIED in combination with the call-on function, is an equivalent way to properly handle the blockstate.
So it's not that the test on BLOCK_OCCUPIED is required as otherwise the signal would not clear, it is required to avoid that the signals clears on blockstate BLOCK_JN_OBSTRUCTED.

Regards,
Rob Roeterdink

[Jovet]

roeter, on 11 October 2017 - 08:11 AM, said:

I'm sorry but I completely disagree with the above statement. Neither MSTS nor OR implement any actual signal logic. Both only provide basic building blocks from which the logic can be build using the signal scripting. So, if no proper shunt signals do presently exist, it is because no script writer has been able to define the correct logic.
It may be that some specific 'building block' to define such logic is missing. But, upto now, I have not received any request from any writer of USA-based signal scripts to provide such a specific function. I have received such requests from a number of writers of Europe-based signal scripts, indicating specific situations or specific logic which could not be implemented and requests and suggestions for additional functions to overcome these problems, which have indeed been created allowing the signals to work as required. But, as I said, I have not received any such requests for USA-based signal scripts.
So, in my view, the fact that no proper (USA) shunt signals exist is not because of limitations in OR, but because of a lack of effort by the script-writers to provide the proper logic for such signals. There is a small excuse for this : MSTS could not handle situations with multiple non-player trains (AI or STATIC) on a single section of track, and so for MSTS there was never any need to create proper shunt signals. But OR can handle such situations perfectly well.
If any functionality to provide proper shunt signal logic is indeed still missing I would be interested to hear of this.

Rob, I am not talking about North American signaling at all. There's no such thing as a Shunting signal here, at all; the concept is foreign. Call-ons can be used in lieu, where needed and available.

I'm also not, in any way, suggesting that OR (or MSTS) has or should have built-in signal logic—deciding which aspects show on signals, when. Not sure how you read these things into my post, but...

My point was that the necessary prototype conditions of Shunting signals is above and beyond the framework provided by MSTS. For example, only NORMAL signals can govern trains. Shunting signals must be able to govern trains, but only during shunting operations. I'd be happy to be pointed to some examples where users of and extensions to OR have addressed these problems. But the finest solution, in my mind, is a new type of signal type that only matters to trains part of the time, as defined by new parameters of an activity, and which only shows on the Track monitor when needed; to my knowledge this solution does not exist, and is far above anything MSTS ever dreamed of.

[ebnertra000]

I wonder if you couldn't define a train as being under the authority of a shunting signal in an activity file? Though making that jive with other signals could be difficult

[Jovet]

ebnertra000, on 12 October 2017 - 06:02 AM, said:

I wonder if you couldn't define a train as being under the authority of a shunting signal in an activity file? Though making that jive with other signals could be difficult

That's the kind of thing I've had in mind. This is far off topic for this thread, I suppose, but like a train path or something (which spiders out to all the tracks it touches, versus a single line like path) setup by the activity creator which can be activated/deactivated during an activity as a dispatcher would do. Shunting signals inside this "area", when active, would be "enabled" or whatever, and would show on the Track Monitor. Main signals would be disregarded if they're near (10m?) a permitting shunting signal—not matter to trains, and not show on the Track Monitor. The first shunting signal outside this area on each track would show on the Track Monitor as Stop, as would Main signals without a permitting shunting signal. There could be other caveats of shunting signals or operations of which I'm not aware (I don't claim to be an expert on European/Asian/Australian/African signaling) but I think this would be the most realistic to my knowledge.

[ebnertra000]

That sounds about right... I'm not really an expert either, but I could take a crack at translating some signal rules I have from a few countries that are known to have them if this idea takes off.

That would be for a different thread, I think, as it is a little off-topic for this thread

[rickloader]

ebnertra000, on 12 October 2017 - 06:02 AM, said:

I wonder if you couldn't define a train as being under the authority of a shunting signal in an activity file? Though making that jive with other signals could be difficult

Well, in timetable mode $pickup$transfer etc set the flag "has callon" (i think), so perhaps Rob could make a "$userdefined" command that would give a train a "user defined" flag. The signal script author could then make this fit the requirements of his particular railway.

Returning to my last signal script, this works fine with single signal heads. But with 2 head signals having callon, both heads clear, and sometimes unexpected signals off path also clear. So I need to experiment with multi headed signals. Maybe we need 2 signal types - normal "stop" , and "stopwithcallon". The latter would apply to multi headed signals.
Happily for my uk route, most ground (shunting) signals are single headed, and so the 3 aspects stop, callon, and clear work. Although they aren`t exactly callon signals they do frequently apply to a backward move to collect stock. ( which in OR needs a callon).

rick

[Jovet]

rickloader, on 26 October 2017 - 03:42 PM, said:

Returning to my last signal script, this works fine with single signal heads. But with 2 head signals having callon, both heads clear, and sometimes unexpected signals off path also clear.

Both signal heads use the same SignalType? The practical solution here is to have each signal head/arm be different SignalTypes, and then only program one to utilize the Call-on programing.

[rickloader]

Yes, thanks Joseph, you are right! I will use separate SignalTypes for multi headed signals. It was the ones with junction links giving problems, and also the UK combined home/distant. In many cases there is a main stop arm with a subsidiary arm, and the subsidiary can do the call on for shunting. In some cases the subsidiary arm was an actual "call on" arm (in railway terms as well as OR).
Thanks for your help as a signal expert. I know I`m going on a lot in this thread, but I was hoping a timetable expert would swoop in and rescue me!
I think a lot of ORTS timetables deal with block, multiple unit trains, whereas my 1950`s steam era had an amazing amount of loco changes.
My historical timetable is starting to come together at last, and it is very satisfying when trains operate as the official "Engine Working Notice"
We are lucky Rob has given us these powerful timetable functions, and it is just a matter of learning how to apply them.
rick

[rickloader]

Multi headed signals

Following Joseph`s suggestion I have made a 2 headed junction signal with types "LSWRMainstop" normal stop type for the main route, and "LSWRStopBranchCallon" for the diverging route. The latter having "callon_restricted" in its script.
Both signal types have "SignalFlags ( DEFAULT JN_LINK ) " in the sigcfg, and the links are set in MSTS RE.

In timetable mode both signals clear together.

In both scripts there is the check for the route set
!route_set()) // Switch not set as per link?
{
state = SIGASP_STOP;

So I don`t understand why one signal of both, is clearing when the "switch not set as per link?" = true.
A frequent timetable move is for a loco to switch from the main route onto a diverging set of sidings to pickup stock. Callon is needed to prevent stopped trains blocking the main line and causing a "log jam".
Work continues........
rick

[Jovet]

rickloader, on 02 November 2017 - 02:24 AM, said:

In both scripts there is the check for the route set
!route_set()) // Switch not set as per link?

You could post the entire scripts for these signals, if you want.

[rickloader]

Thanks for your continuing help Joseph.
These are 2 head junction signals .First LSWRMainstop.This is intended to be a normal stop for the main route, no callon.

SCRIPT LSWRMainstop.

// mainroute
extern float block_state ();
extern float route_set ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float enabled;

if (!enabled ||
// Not enabled/cleared to show natural state?
block_state() !=# BLOCK_CLEAR ||
// Block ahead not clear?
!route_set()) // Switch not set as per link?
{
state = SIGASP_STOP;
}
else
{
state = SIGASP_CLEAR_2;
}

// Get draw state
draw_state = def_draw_state (state);
/////////////////////////////////////////////////////////////////////////
and LSWRStopBranchCallon. This is to be the diverging route giving entry to a yard, and having callon, to enable picking up stock.


SCRIPT LSWRStopBranchCallon

// Branch Stop Callon

extern float block_state ();
extern float route_set ();
extern float def_draw_state ();
extern float state;
extern float draw_state;
extern float enabled;
extern float TrainHasCallOn_Restricted();

if (enabled && route_set() )
{
if (block_state == #BLOCK_CLEAR)
{
// normal clear, e.g.
state = #SIGASP_CLEAR_1;
}
else if (block_state == #BLOCK_OCCUPIED && TrainHasCallOn_Restricted() )
{
// clear on occupied track and CallOn allowed
state = #SIGASP_RESTRICTING;
}
else
{
// track is not clear or CallOn not allowed
state = #SIGASP_STOP;
}
}


// Get draw state
draw_state = def_draw_state (state);

[rickloader]

Here is the sigcfg

Attached File(s)

•  SigcfgJctCallonSig.txt (2.39K)
  Number of downloads: 120

[rickloader]

Update! The above scripts are, in fact, nearly working. I was misled by getting the .tdb out of sync. Either I did not save my deleted signal, or MSTS RE didn`t. I have now trashed the test route! Can you believe, with my main route backed up on different media and computers, I don`t have a backup of my test route?http://www.elvastower.com/forums/public/style_emoticons/default/blush.gif
The signal type is, of course written to the .tdb, so changing signaltypes alters the saved route. Whereas just changing the scripting (same signaltype) can be applied to an existing save of a route.
I will try again, when I`ve rebuilt the test route, and maybe we need some screen shots. I will change the callon aspect to violet, as purple is hard to distinguish from red.
rick