Elvas Tower: New signalling functions - 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 +
  • 1
  • 2
  • 3
  • Last »
  • You cannot start a new topic
  • You cannot reply to this topic

New signalling functions OR specific signalling functions added in version 2266 Rate Topic: -----

#1 User is offline   roeter 

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

Posted 31 May 2014 - 02:06 AM

The recently introduced option to have OR-specific sigcfg.dat and sigscr.dat files have opened up the possibility to create new, OR-specific signalling functions.
The first of such functions have now been created and are available in release 2266.

Here is a description of what these are and how they work.
First, for those who do not yet know, details of how to set OR-specific sigcfg.dat and sigscr.dat files.

How to set OR specific signal files.

The following steps will create OR-specific signal definition files :
  • Create a directory named OpenRails in the route's main directory.
  • Copy the existing sigcfg.dat file to this new OpenRails directory.
    Do not change the file name or extension.
  • Check the sigcfg.dat file for all required signal script files (defined in Scriptfiles statement at end of sigcfg.dat file).
    Copy all required script files to the OpenRails directory.
    Do not change the file name or extension.


Please note that the OR-files are full replacement files - these are not 'include' files or additional files, but the OR-specific files must contain all required definitions for signal types and signal shapes, as well as all required scripts.

Important note.
Because for route editing we still depend on the MSTS route editor, if any new signal types or signal shapes are introduced in the OR-specific files, similar named entries must also be included in the original MSTS files, otherwise these new signals can not be placed in the route.
If a new signal has an OR-specific signal function type, the definition in the MSTS files must be set to one of the original signal function types. When the route is still used in MSTS, care must be taken that this signal type does not conflict with existing signalling. If the route is no longer used in MSTS, then obviously this does not matter.

New signal types and signal functions will be detailed in the nexts set of posts.

Regards,
Rob Roeterdink

#2 User is offline   roeter 

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

Posted 31 May 2014 - 02:15 AM

SPEED signals - new signal function type

The SPEED signal function type allows a signal object marker to be used as a speed sign.

The advantages of such use are :
  • The signal object marker only applies to the track on which it is placed.
    Original speed signs always also affect any nearby lines, making it difficult and sometimes impossible to set a specific speed limit on just one track in complex areas.
  • As signal object, the SPEED signal can have multiple states defined and a script function to select the required state, e.g. based on route selection.
    This allows different speed limits to be defined for different routes through the area, e.g. no limit for the main line but specific limits for a number of diverging routes.


The SPEED signal is fully processed as a speed limit and not as a signal, it has no effect on any other signals.

Limitation : it is not possible to define different speeds related to type of train (passenger or freight).

Definition and usage
Definition is similar as for any other signal, with SignalFnType set to "SPEED".
It allows definition of drawstates and aspects like any other signal. Different speed values can be defined per aspect as normal.

An aspect can be set to not have an active speedlimit. If this aspect is active, the speed limit will not be changed. This can, for instance, be used if a route-linked speed limit is required. This aspect can then be set for a route for which no speed limit is required.
An aspect can also be set to not have an active speedlimit but with a special signal flag : OR_SPEEDRESET.
If this flag is set, the speed limit will be reset to the limit as set by the last speedlimit sign. This can be used to reset any limit imposed by a specific signal aspect. Note that this does not overrule any speed limits set by another SPEED signal as those limits are processed as if set by a speedlimit sign.

Example :

        SignalType ("SpeedSignal"
		SignalFnType ( SPEED )
		SignalLightTex ( "ltex" )

		SignalDrawStates ( 5
			SignalDrawState ( 0
				"speed25"
				)
			)
			SignalDrawState ( 1
				"speed40"
				)
			)
			SignalDrawState ( 2
				"speed50"
				)
			)
			SignalDrawState ( 3
				"speed60"
				)
			)
			SignalDrawState ( 4
				"speed70"
				)
			)
		)
		SignalAspects ( 5
			SignalAspect ( APPROACH_1	"speed25"	SpeedMPH ( 25 ) )
			SignalAspect ( APPROACH_2	"speed40"	SpeedMPH ( 40 ) )
			SignalAspect ( APPROACH_3	"speed50"	SpeedMPH ( 50 ) )
			SignalAspect ( CLEAR_1	 	"speed60"	SpeedMPH ( 60 ) )
			SignalAspect ( CLEAR_2	 	"speed70"	SpeedMPH ( 70 ) )
		)
		SignalNumClearAhead ( 2 )
        )


Notes :
  • The SignalNumClearAhead value must be included to satisfy syntax but has no function.
  • The actual speed can be set either using fixed aspect selection through user functions, or can be route linked.
    The actual use is defined in the related script and the related shape definition.


Example 2 :

        SignalType ( "SpeedReset"
                SignalFnType ( SPEED )
                SignalLightTex ( "ltex" )

                SignalDrawStates ( 1
                        SignalDrawState ( 0
                            "Red"
                        )
                )

                SignalAspects ( 1
                        SignalAspect ( STOP       "Red"  signalflags (OR_SPEEDRESET) )
                )
                SignalNumClearAhead ( 2 )
       )


This example resets the speed to the limit as set by the last speedsign, overruling any speed limits set by signal aspects.

Regards,
Rob Roeterdink

#3 User is offline   roeter 

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

Posted 31 May 2014 - 02:48 AM

Approach control functions.

Approach control signals are used, specifically in the UK, to keep a signal at 'danger' until the train is within a specific distance ahead of the signal, or has reduced its speed to a specific value. Such control is used for diverging routes, to ensure the speed of the train is reduced sufficiently to safely negotiate the switches onto the diverging route.

For use in OR, two script functions have been defined which can be used to control the signal until the train has reached a specific position or reduced its speed.

These functions are :

  • APPROACH_CONTROL_POSITION(position)
  • APPROACH_CONTROL_SPEED(position, speed)


These functions are Boolean functions, returned value is 'true' if a train is approaching the signal and is within required distance of the signal and, for APPROACH_CONTROL_SPEED, has reduced its speed below the required values.

Parameters :
position : required distance of train approaching the signal, in meter.
speed : required speed, in meter/sec.

Note that the speed is checked only when the train is within the defined distance.

Important note :
Allthough the script uses 'float' to define local variables, these are in fact all integers.
This is also true for the values used in these functions : if direct values are used, these must be integer values.

The values may be set directly in the signalscript, either as variables or as numbers in the function call.
However, it is also possible to define the required limits in the sigcfg.dat file as part of the signal definition.

The syntax definition for this is :

ApproachControlLimits ( <definitions> )

Allowed definitions :
  • Position :
    • Positionm : position in meter.
    • Positionkm : position in kilometer.
    • Positionmiles : position in miles.
    • Positionyd : position in yards.

  • Speed :
    • Speedkph : speed in km / hour.
    • Speedmph : speed in miles / hour.


These values are referenced in the script file using the following variable names :

  • Approach_Control_Req_Position
  • Appraoch_Control_Req_Speed


These variables must not be defined as floats etc., but can be used directly without prior definition.
Note that the values as defined in the sigcfg.dat file will be converted to meter and meter/sec and rounded to the nearest integer value.

Example.
This example is a three-head search light signal, which uses Approach Control if the route is set to the 'lower' head.
Route selection is through 'dummy' DISTANCE type route-selection signals.

Signal defintion :

	SignalType ( "SL_J_40_LAC"

		SignalFnType ( NORMAL )
		SignalLightTex ( "bltex" )
		SigFlashDuration ( 0.5 0.5 )

		SignalLights ( 8
			SignalLight ( 0 "Red Light"
				Position ( 0 6.3 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 1 "Amber Light"
				Position ( 0 6.3 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 2 "Green Light"
				Position ( 0 6.3 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 3 "Red Light"
				Position ( 0 4.5 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 4 "Amber Light"
				Position ( 0 4.5 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 5 "Green Light"
				Position ( 0 4.5 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 6 "Amber Light"
				Position ( 0 2.7 0.11 )
				Radius ( 0.125 )
			)
			SignalLight ( 7 "White Light"
				Position ( 0 2.7 0.11 )
				Radius ( 0.125 )
			)
		)
		SignalDrawStates ( 8
			SignalDrawState ( 0
				"Red"
				DrawLights ( 1
					DrawLight ( 0 )
				)
			)
			SignalDrawState ( 1
				"TopYellow"
				DrawLights ( 1
					DrawLight ( 1 )
				)
			)
			SignalDrawState ( 2
				"TopGreen"
				DrawLights ( 1
					DrawLight ( 2 )
				)
			)
			SignalDrawState ( 3
				"TopYellowMidGreen"
				DrawLights ( 2
					DrawLight ( 1 )
					DrawLight ( 5 )
				)
			)
			SignalDrawState ( 4
				"MidYellow"
				DrawLights ( 2
					DrawLight ( 0 )
					DrawLight ( 4 )
				)
			)
			SignalDrawState ( 5
				"MidGreen"
				DrawLights ( 2
					DrawLight ( 0 )
					DrawLight ( 5 )
				)
			)
			SignalDrawState ( 6
				"LowYellow"
				DrawLights ( 3
					DrawLight ( 0 )
					DrawLight ( 3 )
					DrawLight ( 6 )
				)
			)
			SignalDrawState ( 7
				"LowWhite"
				DrawLights ( 3
					DrawLight ( 0 )
					DrawLight ( 3 )
					DrawLight ( 7 SignalFlags ( FLASHING ))
				)
			)
		)
		SignalAspects ( 8
			SignalAspect ( STOP			    	"Red" )
			SignalAspect ( STOP_AND_PROCEED			"LowWhite" SpeedMPH(25) )
			SignalAspect ( RESTRICTING			"LowYellow" SpeedMPH(25) )
			SignalAspect ( APPROACH_1			"MidYellow" SpeedMPH(40) )
			SignalAspect ( APPROACH_2			"TopYellowMidGreen" )
			SignalAspect ( APPROACH_3			"TopYellow" )
			SignalAspect ( CLEAR_1				"MidGreen" SpeedMPH(40) )
			SignalAspect ( CLEAR_2				"TopGreen" )
		)

                ApproachControlSettings (
                        PositionM  ( 500 )
                        SpeedMpH   ( 10  )
                )

		SignalNumClearAhead ( 5 )
        )


Signal function (reduced to show use of approach control only).
This function uses approach control for the 'lower' route.

///////////////////////////////////////////////////////////////////////////////

SCRIPT SL_J_40_LAC

// Searchlight Top Main Junction
	extern float	block_state ();
	extern float	route_set ();
	extern float	def_draw_state ();
	extern float    next_sig_lr ();
	extern float    sig_feature ();
	extern float	state;
	extern float	draw_state;
	extern float	enabled;

//
// Returned states
// drawn :
//      SIGASP_STOP
//
//   Top Cleared :
//      SIGASP_APPROACH_3
//      SIGASP_APPROACH_2
//      SIGASP_CLEAR_2
//
//   Middle Cleared :
//      SIGASP_APPROACH_1
//      SIGASP_CLEAR_1
//
//   Lower Cleared :
//      SIGASP_RESTRICTING
//      SIGASP_STOP_AND_PROCEED
//
  
//
// User Flags
//
// USER1 : copy top approach
// USER2 : top approach junction
// USER3 : copy middle approach
// USER4 : no check block for lower
//

    float           clearstate;
    float           setstate;
    float           diststate;
    float           adiststate;
    float           nextstate;
    float           routestate;
    float           blockstate;

    blockstate = 0;
    clearstate = 0;
    routestate = 0;
    setstate   = 0;
    nextstate  = next_sig_lr(SIGFN_NORMAL);
    diststate  = next_sig_lr(SIGFN_DISTANCE);
    adiststate = diststate;

    if (diststate ==# SIGASP_CLEAR_1)
    {
       diststate = SIGASP_CLEAR_2;
    }
    if (diststate ==# SIGASP_APPROACH_1)
    {
       diststate = SIGASP_APPROACH_3;
    }

// get block state

   if (!enabled)
    {
        clearstate = -1;
    }

    if (block_state () ==# BLOCK_JN_OBSTRUCTED)
    {
        clearstate = -1;
    }

    if (block_state() ==# BLOCK_OCCUPIED)
    {
        blockstate = -1;
    }

// check if distant indicates correct route

    if (diststate ==# SIGASP_STOP)
    {
        clearstate = -1;
    }

// top route

    state = SIGASP_STOP;

    if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_CLEAR_2)
    {
        // aspect selection for top route (not shown)
        .......
    }

// middle route

    if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_APPROACH_3) 
    {
        // aspect selection for middle route (not shown)
        .......
    }

// lower route

    if (blockstate == 0 && clearstate == 0 && diststate ==# SIGASP_RESTRICTING) 
    {
        if (Approach_Control_Speed(Approach_Control_Req_Position, Approach_Control_Req_Speed))
        {
            state = SIGASP_RESTRICTING;
        }
    }

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


Regards,
Rob Roeterdink

#4 User is offline   roeter 

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

Posted 31 May 2014 - 03:07 AM

TrainHasCallOn function

This function is intended specifically to allow trains to 'call on' in Timetable mode when allowed to do so as defined in the timetable.
The use of this function allows a train to 'call on' into a platform in Timetable mode without jeopardizing the functionality in normal Activity mode.

It is a Boolean function and returns state as follows :

  • Activity Mode :
    • Returns true if :
      • Route from signal is not leading into a platform.

  • Timetable Mode :
    • Returns true if :
      • Route from signal is not leading into a platform.
      • Route from signal is leading into a platform and the train has a booked stop in that platform, and either of the following states is true :
        • Train has $CallOn command set for this station.
        • Train has $Attach command set for this station.
        • Train is part of RunRound command, and is to attach to the train presently in the platform.


The use of this function must be combined with a check for blockstate ==# BLOCK_OCCUPIED.

Note : this function must NOT be used in combination with blockstate ==# JN_OBSTRUCTED.
The state JN_OBSTRUCTED is used to indicate that the route is not accesible to the train (e.g. switch set against the train, opposite movement taking place etc.).
Some signal scripts allow signals to clear on blockstate ==# JN_OBSTRUCTED. This can lead to all kinds of incorrect situations.
These problems are not due to programming errors but to route signal script errors.

Example (part of script only) :

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


Regards,
Rob Roeterdink

#5 User is offline   Stefan PAITONI 

  • Fireman
  • Group: Posts: Active Member
  • Posts: 118
  • Joined: 26-February 13
  • Gender:Male
  • Location:Belgium,
  • Simulator:MSTS & OR
  • Country:

Posted 31 May 2014 - 03:50 AM

Hello Rob,
Good work Rob, I have some jobs to do in order to take care of those improvements.

Stef

#6 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Posts: Elite Member
  • Posts: 7,450
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 31 May 2014 - 11:03 AM

Good extension! Philosophy seems quite similar to the one I proposed some time ago... :)
I assume the .tdb file (and the world files) have also to be modified?

#7 User is offline   roeter 

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

Posted 31 May 2014 - 11:38 AM

View PostCsantucci, on 31 May 2014 - 11:03 AM, said:

But I assume the .tdb file (and the world files) have also to be modified?


If you properly alter the MSTS (original) sigcfg.dat file, such that the new signals you want are defined here as well (obviously without the OR specific functions), you can add the signals (or replace existing signals) using the MSTS route editor.
In that case there is no need to modify .tdb or worldfiles. The .tdb file references the SignalType name, the world files reference the SignalShape. The actual functions are derived from the sigcfg.dat file through these references, and so will automatically now load the OR specific functions.

If you simply want to add the new signalscript functions to existing signals there is even no need to edit these in the route editor.

Regards,
Rob Roeterdink

#8 User is offline   Howky 

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

Posted 02 June 2014 - 06:58 AM

Hi, I have one question. Fixes a bug in the new signaling multiplayers?
When I control lights do not work manually so as to have something new patch?

http://s26.postimg.org/ppsyphwt1/screen_1.jpg

http://s26.postimg.org/w283zbzv9/screen_2.jpg

#9 User is offline   roeter 

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

Posted 02 June 2014 - 08:30 AM

No, there are no changes to behaviour of signalling in multiplayer.

Regards,
Rob Roeterdink

#10 User is offline   Howky 

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

Posted 02 June 2014 - 08:32 AM

a will? or I have to go elsewhere?

#11 User is offline   Jovet 

  • Open Rails Developer
  • Group: Posts: Elite Member
  • Posts: 2,320
  • Joined: 14-January 08
  • Gender:Male
  • Location:Omaha, Nebraska.
  • Simulator:MSTS/Open Rails
  • Country:

Posted 10 June 2014 - 05:58 PM

Very interesting. :D A few comments:

For the "Speed" type signal, would it be better to be able to allow the number of "covered" tracks of the existing speedpost interactives to be, somehow, manually adjusted?

I see the new functions the scripts are calling do not have to be declared:
extern float newfunction()
Does this also mean none of the other function calls need to be declared? (Does OR care about such things?)

What further plans for expansion are in the near future?
Additional user options? (USER5, USER6, etc)
Additional detecting functions? (
for example, block_reverse_state() for detecting track state in front of the signal versus behind it, such as for approach lighting)
Additional indication states? (SIGASP_APPROACH_MEDIUM, SIGASP_CALL_ON, SIGASP_DIV_CLEAR etc)
Just curious. :)

#12 User is offline   roeter 

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

Posted 11 June 2014 - 12:53 AM

View Postjovet, on 10 June 2014 - 05:58 PM, said:

For the "Speed" type signal, would it be better to be able to allow the number of "covered" tracks of the existing speedpost interactives to be, somehow, manually adjusted?

The problem is that each track 'affected' by a speedpost is a separate speedpost item in the *.tdb file.
So changing which tracks are covered would require somehow changing the .tdb file. But, this carries the risk that if you edit the route again in the MSTS Route Editor, these changes are again reverted.
To avoid these risks, it has been agreed that no changes will be made to files which are automatically generated by MSTS tools, as long as these tools are still in general use. So changes to the .tdb are 'off limit'.

Quote

I see the new functions the scripts are calling do not have to be declared:
extern float newfunction()
Does this also mean none of the other function calls need to be declared? (Does OR care about such things?)

That is indeed so - "extern float" is quietly ignored by the OR script parser. Local floats do, ofcourse, have to be declared - allthough the word 'float' is very misleading as in fact all variables are integers (many are enumerations, actually).

Quote

What further plans for expansion are in the near future?
Additional user options? (USER5, USER6, etc)

Is on the list (somewhere) - could well be possible, depending on the use of the 'state word' : if there are any 'spare bits', these could be used. (To explain : all user options are collected as bits in a single word). One serious problem to overcome is, ofcourse, the limitation of the MSTS Route Editor to set additional fields.

Quote

Additional detecting functions? (for example, block_reverse_state() for detecting track state in front of the signal versus behind it, such as for approach lighting)

The 'internal' used blockstate already has many more states than the three basic states used in MSTS, so allowing the use of these additional states would be fairly easy.
As for approach lighting - could that not be set up already using the approach control function?

Quote

Additional indication states? (SIGASP_APPROACH_MEDIUM, SIGASP_CALL_ON, SIGASP_DIV_CLEAR etc)

That's more complicated. It would be quite an extensive program change, replacing enumeration types by a list or dictionary or something like that.
Also, the definition would become quite complex as for each state, a 'translation' to one of the basic states would still be required for processing of the states in the Track Monitor, cabviews etc.
It's not impossible, but it's a bit further down the list.

Regards,
Rob Roeterdink

#13 User is offline   Tve4 

  • Apprentice
  • Group: Posts: Switchman
  • Posts: 10
  • Joined: 26-April 14
  • Gender:Male
  • Simulator:OpenRails
  • Country:

Posted 25 June 2014 - 09:23 AM

Great! The speed signal is what I've been waiting for.

Now could we have a trigger signal as well, one that I mentioned somewhere... Basically a dummy (INFO or similar) signal which has a fixed function to operate as a SignalNumClearAhead Zero. Would be useful for longer lines without intermediate block signals, and if it were a simple separate signaltype I wouldn't have to edit a wide array of scripts to include ApproachControl, but instead I could drop a separate signaltype onto a route.

Basically this signal would be a trigger for the signal system to keep signals at a station at stop until an approaching train has passed the trigger. After passing the trigger, the signal script would operate as any normal MSTS or OR signal script. It would make the meets a bit realistic, when the trains would not have signals cleared into the station too early, but instead the first to arrive would get the siding (if passing paths are set). It would also be realistic operation since automatic dispatching aids support the trigger-type route setting, usually triggered by a presence of a train in a track circuit.

A question:
Can a NORMAL signal (within openrails signal script) be set to perform a query of the least favourable speedsignalstate between it and the next NORMAL signal, so that there would be no need to create signal links for both the NORMAL and SPEED signal (to show correct aspects)? If it is not yet a supported feature, I suggest that you do some research if it can be made. I have a situation where the train negotiates through a series of switches at different speeds. ATC enforces the speeds per turnout, but the entry signal displays the most restricting speed limit)

#14 User is offline   Howky 

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

Posted 29 June 2014 - 02:19 PM

I have question , how add into ORTS

APPROACH_2
APPROACH_3
CLEAR_1
CLEAR_2

and other?


you write : Signal function (reduced to show use of approach control only).
This function uses approach control for the 'lower' route.

#15 User is offline   StevenMasters 

  • Apprentice
  • Group: Posts: Active Member
  • Posts: 43
  • Joined: 14-October 13
  • Simulator:ORTS
  • Country:

Posted 29 June 2014 - 04:34 PM

View Postroeter, on 11 June 2014 - 12:53 AM, said:

Quote

What further plans for expansion are in the near future?
Additional indication states? (SIGASP_APPROACH_MEDIUM, SIGASP_CALL_ON, SIGASP_DIV_CLEAR etc)


That's more complicated. It would be quite an extensive program change, replacing enumeration types by a list or dictionary or something like that.
Also, the definition would become quite complex as for each state, a 'translation' to one of the basic states would still be required for processing of the states in the Track Monitor, cabviews etc.
It's not impossible, but it's a bit further down the list.

Regards,
Rob Roeterdink


The problem we have here with GCOR and CROR signals is that many of the indications also tell you what the second signal is. In CROR, MED to CLR (R/G/R) is next signal is MED and the signal following that (2nd signal) is CLR. There are enough signal enumerations now if we had access to a two dimensional array. The enumerations we have are 0-7 which use 3 bits, so there are 5 wasted bits even if you are using an unsigned byte to represent each signal state. How about the following:

0xNS - signal state

N - is the next signal state as we use it now

S - next signal state beyond the 'N'

cab_signal = signal_state >> 4;

This would preserve the current list of signal enumerations and allow for expansion in the future (aspect values of 8-15). Would this approach work?

  • 5 Pages +
  • 1
  • 2
  • 3
  • Last »
  • 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