Elvas Tower: Update Timetable Mode & Signalling - Elvas Tower

Jump to content

Posting Rules

All new threads will be started by members of the Open Rails team, Staff, and/or Admins. Existing threads started in other forums may get moved here when it makes sense to do so.

Once a thread is started any member may post replies to it.
  • 5 Pages +
  • « First
  • 3
  • 4
  • 5
  • You cannot start a new topic
  • You cannot reply to this topic

Update Timetable Mode & Signalling Update now committed

#41 User is offline   oliver2 

  • Hostler
  • Group: Status: Active Member
  • Posts: 51
  • Joined: 29-January 15
  • Gender:Male
  • Simulator:OR
  • Country:

Posted 05 January 2018 - 07:58 PM

View Postoliver2, on 04 January 2018 - 12:53 AM, said:

Greetings to All,

These days I'm trying to add helper operations to my timetable. According to the info I found on the web, MILW used mid-train helpers on the heavy grades. After a time I managed to simulate the helper pickup at Piedmont station, with cutting off the end of the train, reversing to the siding to pickup the helper, and then backing up to the cutoff string of cars. My only problem is that the reversing takes too much time. I mean, the train waits approx. 5 minutes before backing up. While there's 2 reversing operation, the whole thing takes ~15 minutes.

I'm not very familiar with real US Railroads, as I've never been there so I really have no idea how fast is a helper pickup in real life. Should I be satisfied with that 15min time?

Or is there maybe a way to reduce the reversing time in OR? Interestingly, in the same timetable when trains switch power from electric to diesel at Harlowton, reversing engines don't wait 5 minutes before backing up to the train...

Thank You: Peter



Thank You, it works fine!

However, here's another thing: if player train tries to perform the pickup, train parts run through each other. Not in all cases, e.g. as shown in the screenshot, at the siding I picked up the Boxcab helper engine as player with no issue, but when backing up to the main to pickup the rest of the train, the runthrough happens... Even when tried at really slow speed (under 2MPH). Anyone had this problem before?

Attached Image: 1.jpg

#42 User is online   VicenteIR 

  • Hostler
  • Group: Status: Active Member
  • Posts: 82
  • Joined: 24-April 15
  • Gender:Male
  • Location:Dimona, Israel
  • Simulator:Open Rails
  • Country:

Posted 25 May 2020 - 02:20 AM

View PosteugenR, on 30 December 2017 - 02:24 AM, said:

Does somebody know what I can do (modify the signal-files?) so, that OR alternate the train-diractions at singletrack-impasses? I have tried also the function "approach_control_lock_claim()" (see post #1), Additional signal script functions) but I don't know exactly how it is to use?

Does somebody know more?

I also need to know how to use this function.
My question is in the thread of Timetable questions describes the problem I encountered. Several tests performed showed that the case is signalling logic and I need to modify the signal files. Using of this function looks like a solution to fix the problem.

#43 User is offline   roeter 

  • Vice President
  • Group: Status: Elite Member
  • Posts: 2,072
  • Joined: 25-October 11
  • Gender:Male
  • Country:

Posted 26 May 2020 - 12:45 AM

Whenever a train approaches a signal which is at danger, it will try to clear its path beyond that signal in order to try and clear it. It therefor checks all sections beyond that signal up to the next signal, and will 'reserve' all sections which are clear. But if a train is approaching a signal which has approach control, this is of limited use as, even if the full route beyond the signal becomes available, the signal still would not clear until the train fullfills the approach control conditions. Reserving the sections beyond the signal could lock out other trains which might otherwise have passed this location before the signal could have been cleared.
The function "approach_control_lock_claim" prevents the train from reserving sections beyond the signal as long as it does not fullfill the approach control conditions.

Regards,
Rob Roeterdink

#44 User is online   VicenteIR 

  • Hostler
  • Group: Status: Active Member
  • Posts: 82
  • Joined: 24-April 15
  • Gender:Male
  • Location:Dimona, Israel
  • Simulator:Open Rails
  • Country:

Posted 26 May 2020 - 02:05 AM

Did I understand correctly that nothing can be done with this function in signal files and the function will take effect when ApproachControlSet is TRUE?

My tests showed that the problem is occurring only when the block is occupied by train with no power units. I already implemented an approach_control_position to the logic of Entrance signal.
			if (block_state() ==# BLOCK_CLEAR)
			{
				next_state = next_sig_lr (SIGFN_NORMAL);
				if ((next_state ==# SIGASP_STOP) || (next_state ==# SIGASP_RESTRICTING) || (!Approach_Control_Position(Approach_Control_Req_Position)))
				{
					state = SIGASP_STOP;
				}
				else
				{
					state = SIGASP_APPROACH_2;
				}
			}
			draw_state = def_draw_state (state);

It solves the problem of reserving sections beyond the signal but makes another one of course))) The signal is stay at danger until the train passing a previous interval signal even if the platform ahead is clear. I would appreciate if you showed me a different application method of approach position control.
In another words is it possible to set approach position only if next signal is at RESTRICTING aspect and if so - does the program "will remove" already reserved sections?

Thanks
Oleg

P.S.
Of course, the ideal solution would be if the program was take in account a static consists without power units are occupied the block and trains was not reserved sections "through" those consists )))

#45 User is online   VicenteIR 

  • Hostler
  • Group: Status: Active Member
  • Posts: 82
  • Joined: 24-April 15
  • Gender:Male
  • Location:Dimona, Israel
  • Simulator:Open Rails
  • Country:

Posted 02 June 2020 - 05:27 PM

View Postroeter, on 12 June 2017 - 01:14 PM, said:

Two new signalling functions :
  • Activate_Timing_Trigger() : activates a timing trigger.
  • Check_Timing_Trigger(n) : checks the timing trigger, and returns true if it was set more than n seconds ago.

These two functions allow time-triggered actions on signals, e.g. a fixed time-triggered delay on clearing etc.

Hi
A fixed time delay on clearing works great when Activity running. But something fails when the activity loads. AI trains are stuck before the first signal with these functions at start time, and the signal is cleared only 45 seconds after the start of activity The logic in the sigscr:
	if (enabled && (block_state() ==# BLOCK_CLEAR) && route_set() )
	{
		next_state = next_sig_lr (SIGFN_NORMAL);
		sigid = next_sig_id (SIGFN_NORMAL);
		if (!train_requires_next_signal(sigid,1) || (next_state ==# SIGASP_STOP_AND_PROCEED) || (next_state ==# SIGASP_RESTRICTING))
		{
			state = SIGASP_RESTRICTING;
		}
		else if (check_timing_trigger (45))
		{
			state = SIGASP_APPROACH_2;
		}
                else
		{
			state = SIGASP_STOP;
		}
	}
	else
	{	
		state = SIGASP_STOP;
		activate_timing_trigger ();
	}
	draw_state = def_draw_state (state);
	if ((state >=# SIGASP_APPROACH_1) && (next_state ># SIGASP_RESTRICTING))
	{
		draw_state = 2;
	}
	if ((state == SIGASP_STOP) && (this_sig_lr (SIGFN_NORMAL) ># SIGASP_STOP))
	{
		draw_state = 4;
	}

Please tall me what am I doing wrong?

  • 5 Pages +
  • « First
  • 3
  • 4
  • 5
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users