Elvas Tower: Custom dispatching application - Elvas Tower

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

Custom dispatching application Custom dispatching application Rate Topic: -----

#11 User is offline   roeter 

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

Posted 30 May 2018 - 03:29 PM

Hello,

first of all - apologies, for this is going to be a long post, I fear.
I had intended to ask a series of questions about how various items of your control are set up, but I'm afraid I just didn't get round to it. Your info shown above has provided me with some answers and I think it's now time to comment on this before you've headed down too far on this road.
I very much appreciate what you're trying to achieve, but in my opinion you are setting this up using the wrong data.
I do have a bit of knowledge regarding the data - you may not know this, but I actually designed and created most of the logic for the present signalling functions in OR.

First, I will discuss the use of data, both track data and signalling data.
Next, I will discuss the actual signal control.

As for data, the tdb-information is not very usefull - or in fact quite useless - for signal control. The reason is that the track sections in the tdb completely disregard the position of signals. As a further complication, track sections also disregard track crossings.
This means that the tdb track sections, as they stand, cannot be used to determine which signal sections a train is occupying, neither can it be used to determine what sections are locked when a signal is cleared, in particular if those sections contain crossovers.
In order to have proper signal control, the tdb sections would have to be split in sections bounded by signals.
Obviously this can all be worked out, but just as obviously this processing is already done in OR.
When OR is started, tdb information on tracks and signals is used to create a new database out of the tracksections, known as 'track circuits'. That name has been chosen deliberately as the way the track is split is close to the way track circuits are set up in real life.
All train and signalling control in OR is done through these track circuits, the tdb track sections are not used in this logic at all.
My advice would be to use the track circuit information as derived in OR for your control rather than the tdb information.
The tdb information is not required at all, for the actual train position is not relevant. What is relevant is what track circuits a train is occupying, and this information is available both in the track circuit data as well as through the train data (each train has a list of trackcircuits it is occupying). Building the track display of your control is far easier using trackcircuits as each section between signals, between a signal and a switch, between switches etc. all correspond to a unique track circuit, so the information to show the state of a track circuit (occupied, cleared, free etc.) can be derived directly from the track circuit data or the train data without any need for any kind of calculation. You would never be able to do this in such an easy way using tdb track sections.

Signal information in the tdb has a similar problem. Each signal item in the tdb does not refer to a signal but to a signal head only. There is no indication in the tdb which signal heads form an actual signal. That information is only held in the worldfiles, in the relevant signal entry. The world file also holds information on important flags for that signal (such as backface information - a signal head which is directed in reverse).
Again, on startup of OR all this info is processed and a full signal object is created which holds all the information as required.
Again, I would suggest to use this signal object information rather than the tdb information.
As for the relation of signal states and lights shown, this is held in the signal's cfg information - per signal head.
It's not so easy to set the correct aspect for a signal simply based on it's state as the relation between state and aspect is also defined in the related signal script - again per signal head. Again, the combined signal object does have the overall state as well as the actual drawstate per signal head, which is the information you require.

So far about the data, and now to the actual control itself.
Modern systems do not actually control the signals - they set up the routes, and the signals clear to the related aspects for that route through the signal interlocking equipment (either relais or solid state). Most of the displays do not even actually show the aspect but just whether a signal is cleared or not. (Old mechanical boxes controlling semaphore signals work quite differently - I leave those out of this discussion).
The same can be done with your control - it would be, in fact, far easier and more versatile to set things up that way.
It is actually the way the signalling works in OR. When a train requires a signal to clear, it clears the route (track circuits) beyond the signal. When a signal finds it's required route is fully available, it will automatically clear to the relevant aspect as defined through the signal script.
This same logic can be used in your control. When you manually clear a route, you can set the route details as the signals required route and set the correct state for all track circuits within that route. The signal will now 'follow' this action and will clear to the proper aspect. There is no need for any special actions on setting a particular aspect as that is handled automatically through the defined conditions for that signal as set in the signal script. You do not need to bother with setting actual aspect for each signal head. As said, this makes this control much more versatile as the control can work for any type of modern signal, without the need to adapt the control for each different signal type.

I hope this all makes a bit of sense to you. I can help you locate the correct data and explain its use, if you want me to.

So, to round this off, my advice in a nutshell :
  • do not use tdb info, but instead use track circuits and signal object data as derived in the signal logic
  • do not set signals directly, but clear the route and let the existing signal logic work out the actual signal aspect


Regards,
Rob Roeterdink

#12 User is offline   Howky 

  • Fireman
  • Group: Status: Active Member
  • Posts: 247
  • Joined: 14-February 13
  • Gender:Male
  • Location:Czech Republic
  • Simulator:Open Rails
  • Country:

Posted 30 May 2018 - 08:41 PM

thank you for the comprehensive letter
we can discuss it together, I will be glad
here is video from original system JOP

I originally planned,I will set all the necessary signals at the start of the game to the stop signal.
After switching the switches, a command to switch the status of the signal would come.
I wanted to use the manual mode to control the lights.

#13 User is offline   Howky 

  • Fireman
  • Group: Status: Active Member
  • Posts: 247
  • Joined: 14-February 13
  • Gender:Male
  • Location:Czech Republic
  • Simulator:Open Rails
  • Country:

Posted 30 May 2018 - 08:44 PM

here is video original system JOP
https://www.youtube....h?v=fKnT8WLc3-A

#14 User is offline   Howky 

  • Fireman
  • Group: Status: Active Member
  • Posts: 247
  • Joined: 14-February 13
  • Gender:Male
  • Location:Czech Republic
  • Simulator:Open Rails
  • Country:

Posted 31 May 2018 - 04:19 AM

Another thing about railroad crossings

I wanted to modify them on the behavior of mechanical lights, and lay them on an invisible track and have the possibility of manual control.

  • 2 Pages +
  • 1
  • 2
  • 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