[roeter]

VicenteIR, on 25 April 2015 - 07:45 AM, said:

In OR it does not work due to the fact that the signals behave differently unlike MSTS (functions enabled() and opp_sig...()).

There is a slight difference in the use of 'enabled' between MSTS and OR.
In OR, if a signal has no 'fixed path' (that is, there is at least one switch or cross-over between this and the next NORMAL signal), it will not clear when not enabled by a train, even if the state of 'enabled' is not tested.
That is because as long as no path is cleared over that switch by a train, the position of the switch is 'unknown' and a signal can not be cleared over a switch in that state.

I do not think this affects your situation as in your case the signals will be cleared by a train. Perhaps the difference in SignalNumClearAhead is affecting your situation - you might want to have a look at that, and check that the value for SNCA for the preceding main signal is set at a high enough value to clear the path as far as required.

The function opp_sig has been tested and shown to be working correctly.

Regards,
Rob Roeterdink

[raster]

I meant something else, not always possible to use your method. I am writing a script, that for proper operation needs one variable which will be remembered, and its value will not be associated with a signal state. I think not only for me that such a thing was helpful.
These all my ideas for signaling, they are ideas that would allow the creation of a well-functioning signaling system on Polish railways, especially maneuvering signals that are handled manually, not automatically, so it's hard to automate. The best solution would be the use of special points in the patch, which would began or ended with a new type of patch, and his type could be read from a script signal-this would introduce some element of manual operation and would work best. I described it once already.
Are any of these possible?
Regards:)

[VicenteIR]

ApproachControlSettings (PositionM ( 50 )) does not work in x3725. A signal is at danger, but when AI train passes previous signal, it opens regardless of what value of "position" is set

[eugenR]

VicenteIR, on 28 January 2017 - 01:47 PM, said:

ApproachControlSettings (PositionM ( 50 )) does not work in x3725. A signal is at danger, but when AI train passes previous signal, it opens regardless of what value of "position" is set

I have tried this morning with X3757, it was o.k.
You need also in the sigscr.dat something like:
if (!enabled || block_state() !=# BLOCK_CLEAR || !APPROACH_CONTROL_POSITION(Approach_Control_Req_Position) )
{
state = SIGASP_STOP;
draw_state = 0;
}
else

[VicenteIR]

It is work at another station. Thank you

[eugenR]

VicenteIR, on 28 January 2017 - 03:57 PM, said:

It is work at another station. Thank you

The distance between both signals has to be greater the controlled-Distance (here 50m)!
If the first signal is standing in the controlled-Distance the second signal can switch only to clear after the train was closing the first signal.

Do you have a special track-situation between the two signals, if so please show a printscreen from the trackviewer for this situation.

regards
EugenR

[VicenteIR]

eugenR, on 28 January 2017 - 11:57 PM, said:

Do you have a special track-situation between the two signals, if so please show a printscreen from the trackviewer for this situation.

It is not a special track situation in this case. I think the problem was the starting point of the AI path (outside the station, and the signal has aт approach control is an output signal). The SNCA value is too large on the Entrance signal. Because of all this, at the next station it worked.
I tested already, and in my case, it did not help me. However, the function itself is working correctly, thank you

[vitro]

Hello everyone. When I was trying to implement some Moscow Metro signaling features, it becomes a problem. I can't change draw states of signal with approach_control_* functions when signal is not enabled (have a waiting point before it). So I think it will be nice solution to implement this ability. Thanks.

[roeter]

There is no interaction between waiting points and signals. There are various types of waiting points and do not know how exactly this affects the rest of the train's path. But if a signal is not enabled it means - to that signal - there is no train approaching that signal, and so it is not possible to clear the signal based on the approach control condition (the condition is checked by the signal, not by the train).
The signal should clear as soon as the waiting point condition is lifted.
But - why do you want a signal to clear if you're going to stop that train on a waiting point anyway? That makes no sense.

Regards,
Rob Roeterdink

[vitro]

I don't want use an approach control for clearing disabled signal. I need to change draw_state of this signal with the same aspect.

In my case there is a signal which shows "Yellow and Red" until the train arrived to the station. Once the train stops, this signal becomes "Red" only. Then after 20 secs signal is cleared. Here's the real video: https://www.youtube....XmqTZ7-VI&t=41s

[Buttercup]

roeter, on 18 October 2014 - 09:31 AM, said:

TrainHasCallOn() is a function which can be used in the sigscr file to check if a train is allowed to 'call on' into a platform - that is it is allowed into a platform where there already is another train.
It is linked to the $CallOn command which can be used in timetables - this sets that a train is indeed allowed to 'call on'.

Is there an example where this function is used in a signal script?

[eugenR]

Buttercup, on 16 July 2017 - 08:49 AM, said:

Is there an example where this function is used in a signal script?

See manual Chapter 10.15.3 and ...4

[Buttercup]

eugenR, on 18 July 2017 - 01:10 PM, said:

See manual Chapter 10.15.3 and ...4

I need to see an actual signal script where it is used. I have not been able to get it to work.

[Jovet]

Buttercup, on 19 July 2017 - 05:09 AM, said:

I need to see an actual signal script where it is used. I have not been able to get it to work.

You could post your scripting attempt(s), if you want.

It seems to me, just from its description but not having tried it, that it should be part of the check of whether a signal should be at Danger. Like the enabled variable, it should be NOT-ted, since I'll presume it's non-zero when a train is called-on and the signal should be showing a call-on indication.

[roeter]

Buttercup, on 19 July 2017 - 05:09 AM, said:

I need to see an actual signal script where it is used. I have not been able to get it to work.

Here is a fairly straightforward script :

SCRIPT ChLEinffrei
// CHL Einfahrsignal
// freie Fahrt Fahrbegriff 1, wenn Signal enabled, Block frei und die Weichen für diese Route gestellt sind 

	extern float	block_state ();
	extern float	state;
	extern float	enabled;

	float			blockfrei;

	blockfrei = -1;
	if (block_state() ==# BLOCK_CLEAR )
	{
		blockfrei = 1;
	}
	else if (block_state() ==# BLOCK_OCCUPIED && TRAINHASCALLON_RESTRICTED() && APPROACH_CONTROL_POSITION(300))
	{
		blockfrei = 2;
	}

// If required, show the 'stop' indication.
        if (!enabled || !route_set() || blockfrei < 0)
	{
		state = SIGASP_STOP;
	}
// Signal is enabled and the block ahead is clear 
	else
	{
		state = SIGASP_CLEAR_2;
	}

This script uses TRAINHASCALLON_RESTRICTED() which has a number of advantages over TRAINHASCALLON() :

• The call-on test is only performed if the route from the signal leads into a platform.
  If signals of this type are also used on 'free line' locations (i.e. on normal running lines not leading into platforms), the behaviour at such locations is not affected.
  
• The call-on test is only linked to specific timetable commands ($callon, $attach, $pickup and $transfer), behaviour in activity mode is not affected.

In this example, the signal has no special aspect in case of call on, and so the actual value of 'blockfrei' (German for 'blockclear') is not used - there's only a check on <0.
If the signal does have a specific aspect, the actual value of 'blockfrei' can be used to set the normal 'clear' aspect (if blockfrei == 1) or the call-on aspect (if blockfrei == 2).
Because there is no special aspect, approach control is applied in case of calling-on with the signal held at danger until the train is at 300m. distance from the signal.

Regards,
Rob Roeterdink