^(i)^This is the HELP FILE for CARLOS dated 11 jan 00 This file is designed to be read by CARLOS. It can be read by a conventional editor or web browser, but contains a number of 'internal' control characters that will appear as nonsense if read this way. However this should not materially affect the readability, though some text will appear that is not part of the help file and cannot be read visibly by CARLOS. DO NOT ATTEMPT TO EDIT ANY PART OF THIS FILE IF YOU EXPECT IT TO WORK WITH CARLOS, FOR WHICH IT WAS SPECIFICALLY DESIGNED [c12]This version is still being written, at present it is incomplete, contains badly formatted blocks of text [c12] and has hyperlinks that may point to the wrong target, abandon all hope all who enter here (well, [c12]quite a lot of it anyhow!) [c12]If the topic you need does not appear, it may be only a matter of days before an upgrade appears, [c12]so please be patient. Use the mouse on the blue hyperlinks to navigate around this help file. This help file is designed to work with CARLOS released 11 Jan 00 Go to {9.6}UPGRADES# for details relating to downloading this release ^*********************************************************************** READ THE PARAGRAPH BELOW IF YOU CANNOT GET CARLOS TO START AND YOU ARE USING A CONVENTIONAL EDITOR TO READ THIS HELP FILE Note that for CARLOS to operate correctly CARLOS.EXE, CARLOS.HLP and any example files with a .CAR extension must all be in the same directory. CARLOS is optimised to operate in a DOS environment, with a mouse driver loaded in LOW memory. Mouse drivers such as MOUSE.SYS or GMOUSE.SYS must be called in a CONFIG.SYS file using a line DEVICE=MOUSE.SYS (and NOT "DEVICEHIGH=MOUSE.SYS"). Mouse drivers such as MOUSE.COM may be called in your AUTOEXEC.BAT file using a line MOUSE.COM (but NOT "LH MOUSE.COM" or "LOADHIGH MOUSE.COM"). Mouse drivers such as MOUSE.DRV are not suitable, being designed to operate in a Windows environment. Operation from Windows 3.1 can be performed in a DOS window provided the mouse driver is properly installed. Operation from Windows 95 can be performed by restarting in DOS. At present the best way to operate in Window 98 is not to! Instead, make a bootable floppy, and boot from the A: drive. In order to "boot from the A: drive", you must change your PCs CMOS setup. Before your PC loads. Windows, it will briefly show text, often with a phrase like "SETUP=f5", or, perhaps, "Press DEL for SETUP", do as instructed and change the so-called boot sequence to A: C: from the more usual C: A:. Remember to reverse the process when you want to return to normal operation. The floppy must contain an appropriate mouse driver, CARLOS.EXE and CARLOS.HLP. A CONFIG.SYS file and (if a .COM mouse driver is being used), an AUTOEXEC.BAT file should be prepared. If all of the above is gobbledy-gook, or for help in difficult installation, write to the to the the author and supplier of this software who is: JOHN DOWN 3 BRYNHYFRYD TERRACE PENTWYN ABERSYCHAN TORFAEN SOUTH WALES NP4 7TB ...enclosing a suitably stamped SAE if you anticipate a reply If you have the facility, you may prefer to e-mail on: yogidown@aol.com. E-mail is the preferred method LATEST VERSIONS OF THE SOFTWARE ARE DIRECTLY AVAILABLE FROM THE CARLOS SITE AT: http://www.railwaycontrol.co.uk If this site is overlaid by a message from the site's host UK2.NET simply close, move or minimise that page and look at what is underneath. Latest versions are also available from: http://home.freeuk.net/merg/ If you reach this latter site, select hyperlink LINKS, then scroll down for hyperlink CARLOS, this will provide links to the latest copies of the CARLOS files, as well as links to comprehensive information on the RPC system. ***********************************************************************^ ^0.0^GENERAL {0.1}The role of CARLOS#~~{0.1.1}What CARLOS cannot do# {0.2}Layout STYLES#~~{0.3}Layout SIZES#~~{0.4}The three phases of CARLOS# {0.5}The E-file#~~{0.6}The O and I Vectors# THE INTERFACE {1.0}Sign-on message#~~{1.1}REGISTRATION#~~{1.2}Using menus# {1.3}DIALOGUE BOXES#~~{1.4}INFORMATION boxes#~~{1.5}Warning boxes# {1.6}Error boxes#~~{1.7}Fileopen and Filesave boxes#~~{1.8}SETUP box# {1.9}COMMS SETUP box# PLANNING {2.1}PLANNING-Introduction#~~{2.2}CONTROLS AND INDICATIONS# {2.3}PLANNING TECHNIQUES#~~{2.4}EDITING# {2.5}THE DATA PANEL#~~{2.6}PRE-PLANNING#~~{2.7}THE INPUT-OUTPUT TABLE# {3.1}CONNECTION#~~{3.2}CONNECTION SUB-MENU# {4.1}OPERATION#~~{4.4}EMULATION# {5.1}FILEHANDLING# {6.1}DEVICES# {9.1}PERSONAL SUPPORT#~~{9.2}RPC HARDWARE#~~{9.6}UPGRADES# {9.3}MERG#~~{9.4}GORDON HOPKINS#~~{9.5}JOHN DOWN# ^0.1^THE ROLE OF CARLOS - What CARLOS does! CARLOS and its RPC hardware replaces a conventional control panel which usually consists of a thin wooden panel on which are mounted indicator lamps and switches etc. and very often a diagram of the layout itself. It is designed to replace lever frames, or switch banks, and to provide a fully illuminated layout diagram, echoing track circuits and traction status, together with point and signal settings..CARLOS provides for automatic signalling, and can provide anything from no interlocking to a comprehensive interlocking scheme. f Generally (though not always) it provides the link between the user and the Remote Panel Control (RPC) system. When operating a layout, the chain is: USER-----------CARLOS------------RPCstack--------------LAYOUT Information flows in both directions between any of the components. In some environments, it is possible to replace the RPC hardware, which handles data in serial fashion, with parallel, or indeed another serial system. However CARLOS is optimised to work with the RPC system. Although it is the user who provides the commands, all of the interlocking and other routine functions are handled by CARLOS, the RPC hardware simply providing a link between CARLOS and the layout. How does CARLOS obtain the intelligence to handle a layout? For this CARLOS is used in {2.1}PLAN# and {3.1}CONNECT# mode. During this time the user plans the shape and functionality of a layout, CARLOS maintains a record of the planning as an internal file, which can the be transferred to disc whilst planning proceeds, or, of course, when it is complete. CARLOS maintains the users layout in a special file called the {0.5}E-FILE#. It also maintains other data for transmission to and from layouts as data structures, structured for input and output, called the {0.6}I-VECTOR# and {0.6}O-VECTOR#. The user can read the E-file back and work on it some more as he chooses. There is no practical limit to the number of different layouts a user can design. A user new to CARLOS may spend considerable time here, playing with the various features that CARLOS offers, before settling down and preparing the file to operate his final layout. At this stage CARLOS needs neither RPC hardware nor a layout. It is even possible to {4.4}EMULATE A LAYOUT# in a clumsy sort of way, in order to check that CARLOS will operate the layout as planned. CARLOS can draw layouts in {0.3}TWO SIZES# and in {0.2}THREE STYLES#. Each of these styles is represented by different appearance, and very different operating methods. CARLOS cannot do everything, see {0.1.1}WHAT CARLOS CANNOT DO# ^0.1.1^WHAT CARLOS CANNOT DO. These comments were written in November 1999, and development continues constantly. What may be true now, may not be true in the months and years to come. The complexity of CARLOS coupled with the wide-ranging freedom offered during the planning stage means that, despite the presence of comprehensive error trapping mechanisms, it is not possible to guarantee that CARLOS will not behave erratically, indicate an unexpected fatal error, or, worst of all, completely crash. For this reason it is not sensible to introduce obviously incorrect or quirky layouts during the PLAN stage. For example, signals should not be positioned in the middle of the track, nor, say, should text be allowed to flow through active devices. It is unwise also to mix RPC and conventional devices together. Generally CARLOS is not optimised to provide CONTROLLERS / THROTTLES, although a rudimentaryfacility is included to provide, effectively, six channels of control. RPC controllers have been demonstrated, but are not yet generally available CARLOS is not a DCC sytem, nor does it allow for any multi-train operation beyond that provided by conventional control systems. The necessary RPC hardware has been developed, but, again, is not generally available. The necessary code has not yet been written, though initial examination shows that such exercise would present few difficulties. CARLOS does not provide for operation without an operator, though automatic systems have been investigated during the development of CARLOS, and successfully demonstrated. This area may see development in the very new future. CARLOS has no facilities to operate such diverse signalling devices as, for example, train describers or tablets. There are, doubtless, many operators who would like work semi- or fully-automatic layouts. Where CARLOS fails to provide what is needed, the answer maybe a BESPOKE system. These are specially built pieces of software. They may not be cheap, but may be considerably less costly than looking for a hardware solution. Contact {9.5}JOHN DOWN# if you would like to discuss such systems further. ^0.2^THREE LAYOUT STYLES CARLOS has the capacity to control layouts at three levels of sophistication. Each level carries with it implications relating to style and design, so that it is important to decide which you need at an early stage. CARLOS also needs to know what style you are using, and an early visit to the {1.8}SETUP# panel is advised. In all three cases buttons are available for use where there is a simple one-to-one correspondence between the button and the 'outside' device. This is obviously true for such things as accessories (eg yard lamps, motorised windmills) and is also true where there is no interlocking implications, such in cases where perhaps, a line to buffer stops has a 'dead-end' which needs energising only temporarily for such things as loco release. LEVER FRAME STYLE At the first level, for those that prefer the simple lever frame approach, or whose layout depicts the steam era when semaphores were the norm, 'glass' levers are available. In this case levers operate points and operate traction feeds in much the same way as on a conventional layout. The mouse is used to operate levers. Point blades are seen to switch, and track sections are seen to respond correctly. Facilities for interlocking are provided as is a rudimentary form of Automatic Train Control. Signals (which may, within limits, be both MAS and semaphore) are included. The signals are essentially fully automatic, levers can be used to forcibly restore and lock a signal to red, however a neater method of control is afforded by the mouse which can do the same thing and indicates thus by showing a red 'carre' board on the 'on-screen' signal post. MOUSE CONTROL The second stage of sophistication dispenses with levers and buttons. Movement of points and switching of track sections is accomplished using only the mouse, which is swept across the appropriate track element to exert control. In all other respects it behaves as a level one type layout..A level two scheme does generate a remarkably compact and clutter-free display and is remarkably easy to set up. NXB or 'PANEL' CONTROL For the masochist however we have the all-singing all-dancing level three. The level three approach has required a quantum leap both in volume and sophistication of the software. Operation is characterised by NX buttons on the screen. The mouse is used to turn a button to initiate a route. Available sections of track illuminate on-screen as appropriate The second button serves to describe the end point, whereupon, with appropriate flashing and changes of colour, a route is threaded through the layout, and subject to the points setting correctly, the route will 'set' and signals (both on screen and 'outside') will show the appropriate aspects. Routes may be extended or cancelled, and the movement of trains will be characterised by changes in colour of on-screen track sections. Conflicting routes cannot be set up so that a degree of interlocking is intrinsic to the system. This is the most comprehensive style that CARLOS offers, and probably the most exciting. However it also imposes some limitations on style, and is the most likely style to provoke erratic behaviour (on both the part of CARLOS and the user!). ^0.3^TWO LAYOUT SIZES CARLOS builds the visible representation of the layout on screen from {6.1}DEVICES#. The user can select these devices to be either large or small. Not surprisingly, layouts built from large devices are, themselves, appear large, and, of course, vice versa. Which to use depends on how big your layout is, and your eyesight! As an example, Pendon Museum's Dartmoor layout can be comfortably accommodated on a single screen using small devices. For most, simpler, layouts, large (the default) devices are recommended. Perhaps of more interest is the fact that large and small layout devices may be mixed, which, at first sight opens up the possibility of a narrow gauge feeder to a standard 'large' size layout, but is probably more useful in allowing for 'small' signals to serve as subsidiary or shunting on 'large' layouts ^0.4^THE THREE EXECUTION PHASES - PLAN, CONNECT, OPERATE CARLOS provides the interface between the human operator and the RPC hardware. Broadly speaking the RPC activity is confined to passing data back and forth between CARLOS and the layout. All of the intelligence relating to control and interlocking is contained within CARLOS. CARLOS works in THREE different phases, each phase serving as a step to the next. They are: {2.1}PLAN# During planning {6.1}DEVICES# are positioned which establish the shape and geographical features of the layout to be operated. Using ther devices in various ways allows for three different {0.2}LAYOUT STYLES# to be planned, which appear differently and behave very differently. Even greater flexibility can be achieved since devices can be chosen in {0.3}TWO SIZES# {3.1}CONNECT# The connect phase allows the functionality of the controls to be established by connecting the various devices to ports within the RPC stack, and, sometimes to each other. {4.1}OPERATE# The operate phase is, of course just what it says. The finished product, which allows operation of your layout to proceed direct from your PC. Options allow you to examine the output bits, and switch input bits, even if no real layout exists, so that you can effectively {4.4}EMULATE a layout. ^0.5^THE E-FILE Layout diagram data is stored internally in what amounts effectively to a spreadsheet. Each device which is 'fixed'. forms an entry to the spreadsheet, which grows by one row for each device. In addition to the device rows, a. preamble of three rows is used to hold data arising from choices made during {1.8}SETUP# and {1.9}COMMS SETUP# For entirely historical reasons, the data structure is known as the E-file. The E-file is stored on disc as a text file and can be read by any text editor, although there are one or two control characters that may be rendered in a somewhat confusing fashion. CARLOS is however optimised to both read and edit the E-file. Editing the E-file using a conventional editor is only recommended if you habitually undertake brain surgery with a hammer and a corkscrew! The E-file is a two dimensional data structure of an indeterminate number of rows, each row is stored internally as twelve integers followed by a text string. Externally the row is stored as a text string, each integer is seperated by a delimiter character, though in each row the second integer is replaced by a text string. Except in the case of the pre-amble, each integer characterises the attributes of the device described in the row. There is a relationship between the position of the integers and the attribute described, however there are many exceptions to this pattern, and the only reliable way of determining the relationship is to edit a file with the 'caption' switch on. There are some reliable relationships: 1 This is the ID number of a device, each device is numbered from one upwards 2 This value describes the device, it never appears to the user other than as descriptive text 3 This value always decribes the X co-ordinate of the start-point of the device 4 This value always decribes the Y co-ordinate of the start point of the device 5 This value decribes the angle of all rotatable devices, but is also used for other purposes The text string at the end of each row is only formally used in two cases, and that is for the text, when the device is TEXT and for codified text used to describe the enviroment of signals at junctions. In all other cases the user is free to use it as he wishes - though this is seldom of much use! When stored to disc, four lines of 'padding' precede this array. This space allows for visible system data to be added relating to: the version of CARLOS that produced the file. details relating to filename and related details an essentially spare row a caption row designed to provide limited guidance as to what the E-file contains A final paddding row appears at the end of the array ^0.6^I-VECTORS and O-VECTORS These are not explicitly visible to the user, but they do relate closely to the shape and function of the RPC stack Although it is possible to operate layouts using hardware which is driven via a parallel interface, the majority of layouts are expected to use the serial interface in order to make use of the RPC hardware. Signals to and from the RPI are in serial format, or in other words 'strings'. In the case of signals to the RPI, CARLOS, having regard for the controls set by the user, and in consideration of the various input signals, assembles data ready to be 'marched out'. This process occurs on a repetitive basis. The place where signals are assembled prior to 'march out' as it were is a string of bytes referred to as the O vector. Now, importantly, the length of this vector (ie how many bytes it contains) must generally equal the total number of output elements in the RPI stack. If it is too short some of the elements a long way down the stack will never get 'refreshed' as it were, if, on the other hand, the O vector is too long then data will be pushed beyond the stack and 'pushed off the end'. Generally there will be one byte per element, though 'double' and 'quad' devices will obviously need two or four respectively. A similar argument holds for the I vector which is the place where input data is examined by CARLOS having been 'marched in' by the RPI. The size, or, rather, length of the I and O vectors is established automatically. ^1.0^SIGN-ON MESSAGE The sign-on message appears as CARLOS is loading. The sign-on page presents a three-aspect signal head and the legend 'CARLOS' together with a sign-on box. The sign-on box shows the version number and release date. You will be asked for this information if you call for help. Write it down, as you will be asked for it, and you should include it in any communication. If you are a regular CARLOS user, and the sign-on message becomes an irritation then you can reduce the time. spent here by hitting any key to step through each of the signal aspects. The main program CARLOS.EXE must share it's directory with CARLOS.HLP. Without it CARLOS will not sign on, but will give a fatal error message and sign-off. Any demonstration layout files (which have filenames in the form DEM???.CAR) must also be in the same directory if CARLOS is to read them. ^1.1^ REGISTRATION CARLOS is generally distributed as freeware, however such copies are crippled, so that the all important connection to the outside layout (either by a serial or parallel connection) is cut. Every other feature is fully functional including planning, connection and filehandling, even operation is permitted in a somewhat limited emulation mode. Accordingly potential registrants have a full opportunity to satisfy themselves that CARLOS should meet their needs. To get the full version it is necessary to register. Identify the PC that you intend to operate your layout, instal CARLOS, select 'Operate', and set up the comms to connect to a layout. CARLOS will then display a machine ID which is unique to the machine on which it is installed. Note the Machine ID (it's a five-figure number) and then contact {9.5}JOHN DOWN# in order to register. Upon receipt of your registration fee you will be advised of your Personal Identifier Number (PIN), which will then allow to to proceed to full operation. There is however nothing to stop you spending as long as you wish getting to know CARLOS in its freeware form, doing everything you wish except actually operating a layout, and installing CARLOS on as many PCs as you want. At January 2000 the registration fee is: œ38.00 TO {9.3}MERG# MEMBERS AND œ53.00 TO NON-MEMBERS The PIN number is unique to the machine on which CARLOS is intended to run, and must be entered everytime CARLOS is used to operate a layout. Accordingly you should only run CARLOS on the machine you intend to use for layout control, in order to that the PIN is valid. Generally, if you change the 'layout' machine, a new PIN will be provided on demand, provided that there is no risk of security being compromised. It is suggested that the registered user keeps track with upgrades on the internet. Registered users without web access will be supplied with upgrade discs on demand. ^1.2^The CARLOS interface So far as is possible the user-machine interface has been made as consistent as possible. Navigation around CARLOS can be undertaken, in nearly every case, with either the mouse or the keyboard. Although much of CARLOS's presentation is made in a style reminiscent of Windows, CARLOS is NOT Windows-based. From a technical standpoint, CARLOSs is essentially self-contained, it needs no support files outside its own directory (other than a mouse driver) and doesn't clutter up your c:/WINDOWS/SYSTEM/ directory with a lot of useless .DLL files. Operation of CARLOS is undertaken through a number of full-screen 'pages', and smaller {1.3}DIALOGUE BOXES#. which appear in the middle of the current screen pages. To a large extent, pages are arranged heirarchically, rather like the branches of a tree. The 'trunk' as it were is the PLAN page, and all excursions to other pages start and return here, via a MENU or BUTTON. CARLOS presents screen buttons and screen menus which are operated with the mouse. Screen buttons generally operate upon release of the mouse button. This technique allows the user to 'escape' from a screen button pressed in error, by 'sliding' the mouse off the screen button. Menus are operated in much the same way as the familiar Windows menus, solittle more need be said here. Certain two-state features are toggled by means of the menu. Where a feature is off, a small open rectangle precedes the caption. When the feature is enabled the rectangle is infilled in black. In contrast, and unlike Windows buttons (but reminiscent of Windows radio buttons), buttons installed on a layout for use at at 'operate' time, go down on a left hand (LH) mouse button, and up on a right hand (RH) button. This allows for banks of buttons, arranged for use as lever frames or otherwise in ranks, to be 'set' or 'reset' in bulk, by sweeping the mouse across them with the LH or RH button pressed. Screen buttons usually provide the means to move from page to page. In most cases an excursion starts from the PLAN page via a menu. Thereafter screen buttons marked with captions such as 'OK', 'Continue', 'Exit', 'Cancel', 'Yes', and 'No' allow the user to go forward or backward within the pages. Excursions can also be performed with the keyboard. Commands 'OK', 'Continue' and 'Yes' are signalled by the keyboard 'enter' key (sometimes called 'carriage return' or CR). Commands 'Exit' and 'Cancel' are signalled by the keyboard key 'escape' (usually marked 'esc' and in the top left hand corner of the keyboard). 'Yes' is additionally signalled using 'Y' or 'y', and 'No' is uniquely signalled using 'N' or 'n'. In essence, from the keyboard, 'enter' progresses, 'esc' goes back. Related to buttons are MENUs. These are discussed under the section {2.2}PLANNING CONTROLS# Screen buttons and menus also provide for all sorts of other functions, usually the name of the function appears on the body of the button or menu as a caption. Usually a single letter appears, after the caption, in paraentheses on buttons, and by itself on menus. Often this is the first letter of the caption, though sometimes, in order to avoid duplication it appears as something else. Very often this different letter is contrived to bear some sort of relationship to the function - but, as often it does not! The purpose of these letters is to identify a keyboard letter which has th same function as the screen button. This allows the user to use the keyboard rather than the mouse, and for experienced users allows for very rapid navigation around CARLOS. Very often two- and three-letter (and sometimes four-letter) sequences, can allow for exceptionally rapid progress, and it is rarely very long before these codes come naturally to hand. All letters are case insensitive (that is, you can use either upper or lower case). As a special dispensation to Windows users who cannot shake off the habit of pressing 'Alt' before each letter code, CARLOS permits this also. For example, opening a file from the plan page can be 'FO', 'fo', 'Alt-FO', 'Alt-F,Alt-F' -or several other combinations! During PLAN the mouse is used to move {6.1}DEVICES# around the screen. For fine control the cursor keys (the key cluster with legends in the form of arrows, to the lower RH of the keyboard) can be used to 'inch' a. DEVICE around the screen. Note that these are the 'isolated' cursor keys, not those appearing on the numeric key cluster. It is also possible to use the cursor keys to scroll left to right and up and down when lists or tables are displayed, especially where data entry is required. CARLOS displays a number of variables. Most are numeric, though DEVICE type and FILENAME are not. These are displayed in YELLOW boxes. However, when a variable can be altered by the user by means of keyboard entry, then the variable is shown in a white box. When several white boxes appear, the question arises as to what box keyboard input will be directed. The answer is provided by a red bar which appears in the bottom of the white box which is ready to receive input. Usually it is possible to select which white box is to receive input, using either the mouse or cursor keys. Finally (and not obviously) the Page Up, and Page Down keys can be used to scroll more quickly when editing a file, using the File-Edit (FE) facility. ^1.3^DIALOGUE BOXES Whenever CARLOS wishes to interrupt the flow of things it will do so by presenting a small message box in the middle of the screen. The caption bar of this box is: blue for {1.4}INFORMATION BOXES# yellow for {1.5}WARNING MESSAGE BOXES# and red for {1.6}FATAL ERROR MESSAGE BOXES# During filehandling {1.7}FILEOPEN and FILESAVE# boxes appear. During planning, certain 'global' values can be set up using the {1.8}SETUP BOX# Prior to operating, communications and other variables are set using the {1.9}COMMS SETUP BOX# The appearance of most message boxes halts progress until the user signals his acceptance, usually by pressing any key (or pressing any mouse button). A few message boxes contain either two or three buttons, and these can be operated by either mouse or keyboard. ^1.4^INFORMATION BOXES Information boxes have blue caption bars, and provide 'neutral' but, hopefully, useful information. Usually progress is made by pressing any key. Certain information (along with the current filename, if any, and, if selected, the clock) appears in the title bar that accompanies all of the 'pages'. In one or two cases 'busy' messages appear only when some lengthy process is progress, such as a long data sort, or disc operation. Often these latter will be only visible on old Pcs, flashing by too quickly to be read on faster machines. ^1.5^WARNING MESSAGE BOXES Most warning boxes provide gentle warnings regarding the the layout you are planning or connecting. More serious warnings are sometimes issued. These are characterised by showing an error code. In the case these warnings are issued, (usually as a result of disc operations), then usually the fault can be corrected. If the fault persists then you should record the error code and and call for {9.1}PERSONAL SUPPORT#. ^1.6^FATAL ERROR MESSAGE BOXES Message boxes with red caption bars are reserved for fatal errors. In a fatal error sequence, two message boxes are shown. The first will display an error code. If the fault persists then you should record the error code and and call for {9.1}PERSONAL SUPPORT#. Under most circumstances this is followed by a larger message box which provides the user with information necessary to re-enter CARLOS following a fatal error. It is designed to allow the user to do no more than save his work in a file before leaving CARLOS in a controlled fashion, and starting again from scratch. It may even be possible that the file on which you are working has itself become damaged, in which case you should save it under an unused filename. Immediately the user saves his current workfile, CARLOS will sign off. ^1.7^FILEOPEN and FILESAVE BOXES. The FILEOPEN box and FILESAVE box appear in response to user commands to open or save files. The dialogue boxes associated with these functions are rather larger than info, warning or error boxes, but otherwise behave similarly. FILEOPEN BOX Note at the top is a blue banner, proclaiming OPEN, that is, the function with which this panel is associated. Immediately below the banner is an input box. Note that it is underlined in red, indicating that it is ready to receive input. It will usually contain a filename at this stage, but this is not always so, nor necessary. Any filename can be removed by using the backspace key repeatedly, or by simply using 'delete'. There are a number of ways in which a different filename can be selected. Below the input box is a selection box. Any of the names in the selection box can be chosen by clicking the mouse on the chosen name. The red frame will move accordingly and the chosen name will be echoed in the input box. Where there are a large number of available filenames, then the slider controls can be used to alter the area in the list from which the selection box takes its names. Alternatively clicking on the up- or down-arrow provides the user with greater finesse by single stepping through the list. Finally, if you wish, you can simply type in the filename you need. FILESAVE BOX This is similar to the FILEOPEN box, except that the banner proclaims SAVE. Unlike the FILEOPEN box, the controls are simpler. A simple input box allows the user to enter the required filename, or modify that which already appears. Any existing filename will echo the current filename. The normal 'OK' and 'Cancel' buttons, complete the ensemble. However the box will sometimes contain a message advising that the file contains the default SETUP values. This situation occurs if no visit has been made to the {1.8}SETUP# dialogue box. In the case that an attempt is made to store a file with a filename that already exists then a warning is issued. This and other filehandling matters are described more completely in {5.1}FILEHANDLING# ^1.8^ SETUP DIALOGUE BOX This dialogue box consists of four parts: COMMS OPTIONS. Contains a five position slide switch which allows the user to select which port of four, he wishes to use for serial comms with the RPC equipment and hence the layout. Most PCs tend to use COM1 for the mouse and this port cannot therefore be used, some PCs which use 'bus' mice (for example, the IBM PS/2) have a special channel for the mouse and therefore leave all four ports free. If, when running a layout, your mouse seems unable to move or moves in large jumps, suspect that CARLOS and your mouse are trying to share a port. (If your mouse jumps during planning, then suspect you have the wrong mouse driver). Take care that no other device is sharing any of your serial ports (eg modems). Select PARALLEL only if you have a special internal card fitted to your PC, and you are using specialist equipment to interface to the layout. The default value for this feature is COM2. CONTROL STYLE A three-way slide switch allows the user to select his layout style - either lever frame, mouse driven, or NX button styles. These are described in{0.2}LAYOUT STYLES#. The default style is NX button style A two-way slide switch allows the user to select the correct signal driver. Four aspect signals need four bits to control them, however, Gordon Hopkins can provide a two-bit decoded version in the RPC hardware, and if this type is used, then CARLOS must know about it. SET COLOURS This simply allows the user to alter the background colour of the display over a vitrtually indefinite range of shades, using three slider controls. The default colour (with RGB values set to 40:60:40) produces the default willow green, which is similar to the colour used by British Railways 'panel' boxes. However this is not to everybody's taste, and the three slider controls permit an almost infinite range of colours - including bright purple -ughh! SET NUMBERS Every active device has one or more internal numbers related to it, and during the planning stage it can be ueful to. see one or more sets of them. They can also be shown during the operate phase. All the same, it is much more likely that the user will wish to use his own, which he would apply using the text device. The dialogue box allows each device type to show or hide its internal numbering. The default value for this feature is all but FEEDs to have their device numbers hidden. When a file is saved, it contains the values established through this dialog. If the user has not visited this dialogue box, then the default values are saved, in which case the {1.7}FILESAVE dialogue box, will draw the user's attention to the fact. ^1.9^COMMS SETUP This dialogue box appears when COMMS is selected from the OPERATE page, and consists of three parts: OUTPUT CONFIGURATION. An on-off switch (with red or green indicators), allows CARLOS to connect to its serial output driver. If you want to operate a real layout then this switch must, of course, be on. For all other purpose, such as emulating a layout or 'just playing' then it is better set to the off position. During full operation CARLOS is continuously scanning the serial port, as well as doing all its 'internal' things. The serial scanning process is, relatively, quite long-winded, and so, response speed is improved without it. A second on-off switch allows the bottom row of red/grey indicators to the left of the control area (when in the operate page), and relating to what CARLOS is sending outwards to be indicated. The indicators signal 'off' (grey) or 'on' (red). These indicators are very useful to confirm that bits are where you think they are, and doing what you think they are. They can be left active during regular operations, it's simply a matter of personal preference, and the behaviour of CARLOS is unaffected by the choice. INPUT CONFIGURATION A two-way slide switch allows the user to select whether CARLOS reads from the serial port or copies input from a row of 'glass' push buttons, which will appear on the top row of buttons and indicators to the left of the control area. These buttons allow the user to emulate input data as if it came from a layout. If you are able to identify which bit and byte relates to which function on the layout, then it is possible to emulate the behaviour of a layout. See {4.4}EMULATION# for further details. A second on-off switch allows the middle row of yellow indicators to the left of the control area, and relating to what CARLOS is receiving (either from the RPC or from the 'glass' switches, according to how the switch above is set) to be indicated..The position of this switch is entirely a matter of personal choice, and does not affect the behaviour of CARLOS, though it is very useful during when trying to emulate a layout. Whilst connected to a 'real' RPC system, it provides a first-hand check that Track Circuit Detectors are behaving themslelves. USE OF KEY CODES. Use of this dialogue box can be accelerated considerably using key codes if you continuously use the same settings, and this is a good example of the use of key-equivalents. For example the key string CIJA , from the OPERATE page will set CARLOS for emulation / messing about with no layout, and will arm all buttons and display all indicators. ^2.1^PLANNING Planning in its widest sense covers all the activities needed to prepare CARLOS to operate a layout. {2.2}PLANNING PAGE CONTROLS# need to be studied if you are new to CARLOS or need to revise. {2.3}PLANNING TECHNIQUES# explains how the controls are used to generate a layout. {2.4}EDITING ON THE PLAN PAGE# goes on to more advanced techniques. {2.5}USING THE DATA PANEL# shows how this feature can be used to access CONNECT features from the PLAN page. {2.6}PRE-PLANNING# is vital if you are now confident with CARLOS and want CARLOS to operate a real layout ^2.2^ PLANNING PAGE CONTROLS Note that the page is divided into an upper, larger area, the WORKSPACE, and below, a smaller area containing the. controls, the CONTROL AREA. The workpace accommodates the layout diagram under construction which will go on. to become the operating diagram. A narrow caption bar appears above the workpace, this tells what 'page' is in use, and also provides a space for the current filename, the clock (if selected) and sometimes s used to provide a space for brief messages nd status information. In the Control Area we will describe the controls, broadly from right to left. BUTTON CLUSTER On the right we see a cluster of buttons, together with two yellow indicator box. The button on the extreme right marked 'File' allows access to all the various facilities described under {5.1}FILEHANDLING#. Briefly this allows the user to manipulate files which contain data that he is planning, or has planned (or, indeed, anyone else has planned). Below this the current filename is shown in a yellow box. This filename is also echoed in the top caption bar. The 'Device' button selects a menu from which some fourteen {6.1}DEVICES# may be selected. Each device can then be installed into the plan. The current device selected is shown below the button is shown in a yellow box, below the button. In the case of one certain device a sub-menu is brought-up, allowing the user to further specify the device. Next comes the 'Setup' button. Pressing this brings up the {1.8}SETUP DIALOGUE BOX#, which allows the user to set up permanent and semi-permanent features related to his plan. Below that the {3.1}CONNECT# button opens a new section of the program. A user with an almost complete layout plan can press CONNECT in order to establish how his devices work and link together, and, in particular, to what bit of the RPC they are connected. The lowest of the three buttons, when pressed, takes the user to the {4.1}OPERATE# part of the program. RIGHT MENU PANEL To the left of the button cluster is a menu panel and is arranged to allow a number of features to be toggled on or off. It contains four functions, namely HELP, TIME, PAINT, REDRAW..HELP replaces the planning page with a full page image of the launch page of an extensive, hyperlinked help file (you must know that or you would not be here!). With TIME selected a clock appears in the extreme lower right of the screen. Action of the clock can cause some visual interference on slow PCs and accordingly the option to switch it 'off' is provided. Feeds, amongst other things, provide colour injection points to rail sections. The PAINT function allows all feeds to inject the colour grey during PLAN. This provides a visually potent method of viewing a near-complete layout, and, perhaps more importantly, exposes very clearly any sections that need feeds. Unfortunately unless all track areas are 'closed' with JOINTS, BUFFs or other pieces of track cutting across them, painting causes 'flooding' to occur. CARLOS will detect this quickly and automatically toggle the PAINT control off. The layout plan is more or less frequently completely redrawn (for example at every file operation). Occasionally a set of circumstances conspire to corrupt a small part of the display. REDRAW does just what is says and removes any quirks as it does so. LEFT MENU PANEL Yet further to the left is another menu panel. This panel allow the user to toggle four fuynctions, namely GRID imposes a grid on the layout to which devices will snap. Unlike most grids, this grid works only in the horizontal plane and is a useful tool in setting up the 'six foot way'. There is little or no need for a vertical grid and accordingly, it is not provided. SIZE alters the 'largeness' attribute of a device. The default is large, but small device may be toggled at will. It is use of this control that provides the two layout size capability. PANEL provides a method of setting up the functionality of a device without entering the CONNECT phase. See {2.5}DATA PANEL#. FEEDS allows all feeds to be made invisible - or visible. This is useful when constructiong complex junctions since a large number of FEEDS can congregate, making for a very cluttered diagram. CURRENT PANEL This panel, to the left of the menu panels, contains data relating to the position of the mouse, to the position of the currently 'free' device, to the attitude of the current device, to the size of the file holding the layout, and to the number of bytes in the {0.6}O-VECTOR# (or the I-VECTOR in the exceptional case of this being the larger of the two). LENGTH and ANGLE CONTROLS In the left hand corner are two pairs of buttons. These control the length and angle attributes for devices, where devices have these attributes as variable. Length is variable in the case of TRACK and LINE, however this control is also used to to control the size of BUTTONS and to set the number of aspects of SIGNALS. The angle control is used to turn TRACK, BENDS, JOINTS, BUFFERS, LINES, SIGNALS, and NX buttons. The angle is adjustable in 45 deg increments. The angle control is also used to set the shaft colour for LEVERS and to select the style of INDICATORS. Whilst there is no doubt that these last two are a little quirky, it does simplify the planning page a little. ^2.3^PLANNING TECHNIQUES Planning techniques are probably best illustrated initially with a short test-run, so to speak. Before we do so, note that moving the mouse causes the pointer (or cursor) to move around the screen. Note that as you do so, the current panel marked Mouse x:y indicates the position of the mouse in the work area (but not in the control area). This feature is useful if particularly fine work is needed on a layout Select FILE and from the second pop-up menu OPEN (or simply, on the keyboard, FO). The {1.7}FILEOPEN# box will open up in the centre of the screen. Many dialogues with CARLOS will be conducted through panels like this, so it is worth looking at its features in some detail. In many respects it is similar to a Windows window but there are a number of detail differences. Once a filename is selected then clicking on either OK or CANCEL will open the file, or return from whence you came. This OPEN dialogue panel only provides listing and control of .CAR files (that is, layout files). To continue, at OPEN select DEMNXB (the full filename for this file is DEMNXB.CAR). You may very briefly see a 'busy' warning, but immediately after a layout will appear on the screen. This is a layout fragment in PLAN format. The layout consists of a complex of trackwork, plus a series of controls in the lower part of the workspace. Imposed thereon are a number of eNtrance-eXit buttons (NXB), which typifies this layout as an NXB style layout. At the left hand end the track is 'plugged' with a JOINT. As we progress to the right there is a passing loop before the layout splits three ways into tracks (TRACK), each of which terminates in a bufferstop (BUFF). Four points structures and two further joints complete the layout. The trackwork is 'filled' or 'painted' in dark grey. Note that the menu panel shows that the PAINT attribute is ON. This attribute was previously off, but it was switched on as the layout was loaded, as indeed were certain other attributes. Note then that layout files carry most of the attribute data with them when they are saved and opened. Try toggling it on and off, and note the effect. Clarity is much improved if the track is painted. The PAINT function allows all feeds to inject the colour grey during PLAN. This provides a visually potent method of viewing a near-complete layout, and, perhaps more importantly, exposes very clearly any sections that need feeds. Unfortunately unless all track areas are 'closed' with JOINTS, BUFFs or other pieces of track cutting across them, painting causes 'flooding' to occur. CARLOS will detect this quickly and automatically toggle the PAINT control off. Distributed around the layout are a series of small yellow diamonds. Close to each one is a number or number-pair. These yellow diamonds are FEEDs, and they play an extremely important role in CARLOS. There is an important distinction to be made between FEEDs (which are concerned with CARLOS and its internal control manipulation), and TRACK CIRCUITS (not track sections) which are lengths of track in the outside world. In conventional layouts, such a length would be fed by a controller, probably via a section switch (or what US modellers refer to as a 'block toggle') and on hi-tech layouts, might well be fitted with a track-circuit detector (TCD). In CARLOS a FEED must be installed for every identifiably different piece of track , that is track section (whether seperated from its neighbour by a joint, point structure, NXB or anything else, and which we will refer to as a track section). FEEDs are centrally involved in illuminating various track sections in various colours during the OPERATE stage. Generally one track circuit is represented by several feeds..It is often the case however that one track circuit can be represented by one feed, and this one-to-one relationship can lead to the temptation of assuming that a FEED is the same as a track circuit feeder, which carries traction power to the rails. The assumption is incorrect, and the temptation must be resisted, if enormous confusion is not to arise. Now, go back and read the previous paragraph again, this is the most difficult point to understand in CARLOS, but once understood, everything else should be plain sailing. Until now, we have not mentioned points, except as point structures. See {6.1.3}POINTS# for a full explanation. In the lower part of the workspace are a number of layout control features in skeletal form (these skeletons come to life when the layout enters the 'operate' phase). To the left is a group of four LEVERs, which are aligned to form a short frame. Next come six buttons, aligned as an array, followed by a few circular devices which are one of the several forms of INDICATOR. At the end of this display is a three-aspect multiple aspect signal (MAS). Let's now start some real action, a lot is going to happen in the next few seconds....! In the control area check the middle panel. If the 'Panel' is shown 'on' then switch it off. Now, using the mouse select 'Device' then 'Track', or if you are using the keyboard, simply type DT. Two things happen immediately. Firstly the yellow status box under the 'device' button will read 'track' whilst on the diagram a number of small blue squares will appear. Each one identifies the so-called 'start-point' of various pieces of track on the existing diagram. Now bring you mouse over an uncluttered area of the workspace and press the left-hand mouse button (LHB). Immediately a short length of track appears from the mouse pointer. Keeping LHB pressed, move the mouse around the screen. The track will follow smoothly. In the control space both 'Device x:y' and 'Mouse x:y' will be seen to track the device on the screen. Now briefly hit the W key. Note that the track will step round anticlockwise by 45 degs. Repeat the process and after seven presses, you will have returned to the start point. Note how the parameter pair 'ang/len' change. Note also that by holding down the W key the track will spin - amusing, but of absolutely no use at all! Pressing the A key will cause clockwise rotation. Now try pressing and holding the Q key. Pressing the spacebar at this time has the same effect as pressing the W key. This is in order to achieve some level of compatibility with commercial CAD programs You will notice the red image extending. The image is completely redrawn for each pixel of extension so that on some slow PCs, this process may be rather irksome. Another way is to press the LHB, and simultaneously press the RHB, this process is much quicker. There a several other ways of extending the length of a piece of track, some of which we will return to later. It is, of course, possible to create a length of track from several smaller pieces. The Q key will shorten the length. If you have a three-button mouse then pressing LHB and the middle-button will also shorten the length of the image. Remember that the Q,A,W,and S buttons fall naturally to the first and second fingers of the left hand, and you should try to become proficient in these operations, since they are common to nearly all devices, this will leave the right-hand for mouse operation. Having tired of pulling an isolated piece of track around the screen then press the RHB alone, or hit the 'enter' key. Very quickly the section of track turns black with its start-point marked with a small blue square. This item is now 'fixed', and we can proceed to add more devices. One option is another piece of track, and this is easily achieved by simply pressing LHB again. Before doing so however, select GRID (X) from the panel. If you now press LHB again, a new piece of track will appear, but, instead of smoothly following mouse, the image will 'snap' to a horizontal grid. Stop here for a moment and select 'Size' (L). The letter L in this context is used to suggest 'large', by selecting (L) the marker disappears, and you will notice that the red length of track is much thinner than hitherto. Specifically, the 'large' attribute is switched off and the device appears small. Toggling 'size' again will restore the 'large' attribute, and the track length will return to its original size. Inaddition to TRACKs, BENDs, JOINTs, BUFFERs, SIGNALs and NXBs can all be switched between large and small. This gives rise to several opportunities. Relatively simple layouts are best drawn large, and, indeed, this is the default setting. This could allow a narrow gauge feeder to exist alongside a 'standard' gauge lane. Or possibly, small MAS signals could be used to represent subsidiary or calling-on signals. Complex layouts are best drawn small. Unfortunately this then prevents the use of narrow gauge features and subsidiary signals, though this is unlikely to inconvenience many people. We now return to the matter of the snap grid, and note that, unusually, this grid is in the horizontal plane only. This permits horizontal lengths of track to be neatly spaced. It also works for all other devices, except RPC items, which follow their own rules. We will see later that two 'grids' spaces track to give an effective 'six-foot way', and allows for the neat fabrication of crossovers. Fix this second length of track using RHB or 'enter'. Now deselect grid (X), and then select BEND from the DEVICE menu (DE), and move this around the screen. Note at this time that the blue squares on the track disappear, and the yellow reporting box now announces BEND. Bends have all the attributes of TRACK except that the length of bends is fixed. You may like to attach a bend to the end of a length of track and fix it there. Alternatively you make like to try fixing a bend somewhere along the length of a piece of track, thus forming a rudimentary turnout. Another bend attached to the first bend can be angled to turn the route parallel to the original tength of track. Whilst doing this exercise, try selecting a few BUFFs (bufferstops, (DU). Bufferstops and bends behave identically, and using just track, bends and bufferstops, it is possible to assemble quite extensive layouts in a few minutes. The final positioning of some of these devices can be fiddly, especially if you are not a regular mouse user. Grid (X) can help in many cases, but the cursor keys (ie the cluster of four arrows on the keyboard) provide another method. With no mouse buttons pressed, briefly hitting any of the the cursor keys will move the device one pixel in the direction of the arrow, and repeated 'stabbing' will soon shunt the device to the required location. Pressing a cursor key for a longer time moves the device continuously but slowly over a short distance and then speeds up. A short period of practise will soon yield mastery in this technique. Whilst practising with these devices, try LINE (DL). In many ways these are similar to TRACK, except that they consist of one 'rail' as it were. They are not designed for this purpose however, but can be used singly and in groups to represent things such as platforms, bridge parapets, tunnel mouths, and almost anything else, particularly in the representation of civil engineering features. Note that lines can be changed both in respect of length and angle. Now try JOINTs (DJ), in like manner to bends, only the ANG attribute is variable. Note that joints are designed to split lengths of track into parts. Work on getting them to sit neatly between the rails, in a length of track. Using the cursor keys if need be. Now try TEXT (DX). On selecting TEXT a short red cursor will appear on the screen which can be dragged around the screen in the normal manner. Once TEXT is selected, keyboard commands are suspended until some other device is selected. Instead, every keyboard stroke is echoed onto the screen in red, in order to allow devices and features on the screen to be captioned, lettered or numbered. The text string thus formed can be dragged round the screen, and fixed in the same way as the devices described so far. Dragging text round the screen in an extremely intensive graphics operation, and the response on some slow '286s may be rather sluggish. All of the 'passive'devices have been discussed, so this is a convenient point to discuss {2.4}EDITING# before we move on to {6.1.2}ACTIVE DEVICES# ^2.4^EDITING ON THE PLAN PAGE We have seen that once a red 'floating' device is in its correct position, it is 'fixed' using either the RHB or 'return',. whereupon it turns black with its start point marked with a blue square. What if we wish to reverse the process? Can. we refloat a device from black to red? The answer is yes - and very simply too. Once a device type is selected, then all the devices of that type on the screen will indicate their start points with a blue square. Push the cursor into the blue start square, press LHB and the device will refloat in red. Any existing device in red will disappear. This provides a rather neat and speedy way of erasing one or even a number of devices. But what if you want to erase a device which is floating (ie in red). Simply pressing REDRAW will do the trick and deselect any device in the process. You may be surprised to see that certain devices have their blue squares rendered in red. This little trick is used by active devices whose geometric attributes have been set, but as yet have no functionality installed. This means that the user needs to take steps to connect them up, either by using the {3.1}CONNECT# page or, for the more proficient user, by using the {2.5}DATA PANEL# It is not intended that each device is connected aas soon as it is established, the main use is to identify the odd device that has been overlooked during the CONNECT phase. ^2.5^THE DATA PANEL With a number of different devices on the screen, CARLOS arranges that for each device selected, the start point is. identified by means of a blue square. This square now allows us to to explore the DATA PANEL or simply PANEL. feature. If the mouse cursor, with no button pressed, is moved into one of these blue square then a largish data. panel appears, on the lower left of the screen. It is possible that this screen can obstruct the very thing you want to. look at. Hitting the cursor keys will toggle the data panel from the left hand edge of the screen to the right hand edge. of the screen and vice-versa.. In a typical example of a data panel, the left hand edge contains a variety of captions. The first two captions, 'Entry'. and 'ID' relate to the manner in which the device is stored internally. Below that is full width panel describing the. device presented, this is a repeat of the device description appearing below the 'device' button. Lower still are ten. rows, the first five rows are captioned 'X,Y, ANG, LEN,and ANG' and further rows are captioned according to which. device is represented. Inspection of the values down the right hand column will reveal that obviously relate to the. device into whose blue square the mouse has its nose! At the bottom of the panel is a full width white area, at the. bottom of which is a red cursor. Hitting the up and down cursor keys will move the red cursor within the panel. With. the red cursor opposite, for example, the caption 'X', any numerical input via the keyboard can be used to modify the. position of the device described. In order to do this, completely erase the current value using the 'Delete' key, or use. the 'Backspace' key to erase the existing characters one at a time, then type in a new value. As soon as the mouse. pointer is moved out of the blue square then the device will jump to a new position. This is neither the easiest, nor most conventional way to alter the geometric attributes of a device, however the. values lower down the panel generally refer to the functionality of the device, and it is often convenient to edit these. here. Although the captions here are terse, very experienced users will find this a very rapid way of 'connecting up'. devices, and indeed, by these means it is possible to completely avoid the CONNECT phase, though for the vast. majority of uers the CONNECT phase is the right and proper way to go. ^2.6^PRE PLANNING Once you feel that you are more or less proficient with CARLOS, the time has arrived to start planning for the real layout that you want to control. There is naturally a temptation to start this stage too early, with the chance that problems may arise. No matter, solving problems that CARLOS throws up is a sure way to learn more about the system. There are two stages to pre-planning. The first task is to prepare a pictorial diagram of your existing hardware (or proposed hardware) layout on a large sheet of paper, using a line for each rail (rather than for each length of track). Scenery can, of course, be left out, as can such things as check rails. At this stage NX buttons, ordinary buttons and levers should be left until later. The important thing now is to consider how your track is to be divided into sections. Basically, on a stretch of unbroken track, each section is controlled by one signal. At present CARLOS's Automatic Train Control function is limited to switching the traction supply to complete sections. The notion behind this thinking was the cost and complexity of installing berth track circuits facing signals, or overlap track circuits in advance of signals. How many sections do you need? This is largely a matter for the individuals, signal spacing has to 'look' prototypical. On the other hand, there may be positions where there are no signals (such as carriage sidings), but where a number of Track Circuit Detectors (TCDs) are justified. There is incidentally, no reason why there must be a one-to-one correspondence between track sections and TCDs. It is possible to use a single TCD for a number of track sections, and indeed the converse, though this situation is not general. There are very definite rules when it comes to {6.1.3}POINTS# and CARLOS will not function correctly unless these rules are followed: 1. For layouts with LEVER or MOUSE styles, each point must have two relatively short sections which serve as the point's 'blades'. One section will be identified as 'normal' and the other as 'reverse'. These may be chosen as you wish - the normal route need not be the 'straight ahead' if the functionality suggests otherwise. These short sections will appear as moving blades during the operate phase. 2. For layouts using the NXB style there is no need for a joint between any points and the next NXB button which itself serves as a joint. Moveable blades are not a feature of NXB style layouts. 3. Every point must have a unique and identifiable section containing a FEED to serve as it's 'toe'. This implies that points positioned 'toe-to-toe'must be seperated by a joint. THERE IS HOWEVER NO NEED for this joint to appear 'outside' and this is an obvious case where the number of FEEDS (which are 'virtual') exceed the number of track sections, which are connected to the RPC and are 'real'. 4. For layouts with LEVER and MOUSE style layouts, each of the three point components, be it toe, normal or reverse, must be separated by a joint, that is, for example, the toe of one point cannot appear as the reverse of another. This restriction does not apply NXB style layouts. 5. Care must be taken with running loops (that is, those that diverge from the main line, run generally parallel to it and then return to it some distance further on) that the reverse blade of the facing point is separated from the reverse blade of the trailing point. The same is true for the normal blades. In the case of NXB style layouts, proper control cannot be exerted without at least one NXB button in each 'road', and this serves as the joint. 6. For NXB style layouts, and in contrast to wiring conventional toe-fed point layouts where it is normal to instal a feed at the confluence of as many points as is usual, it is rare for an NXB to be installed at this position. Generally, NXBs are installed in the middle of unbroken stretches (unless, of course, the user has elected to subdivide these unbroken stretches for operational reasons. Now for every point on the diagram there must be a simple, but unique, numerical ID. In the case of three-way point, two Ids are needed, though for a crossover with two-motors that co-act effectively in parallel, only one is needed. When you are happy that the pictorial diagram is complete, it is time to move on to the second part of the exercise: the {2.7}INPUT-OUTPUT TABLE# ^2.7^THE INPUT-OUTPUT TABLE This is, essentially, an exercise in establishing what piece of the layout is connected to what part of the I/O structure. Usually this will be an RPC stack. The manner of these connections is then directly reflected in the {0.6}I and O VECTORS# Generally, for every track circuit there will be an output relay in the RPC stack, using either an DPR or QPR module, each of which provides for eight output channels. Each point motor will probably need one relay channel, though using Gordon Hopkins' CDUs will permit the use of SRO4 module which provided open-collector outputs. Each signal aspect will need a channel from an SRO4, though, again, using a Hopkins decoding module allows for four-aspect signals to be driven from only two-channels. Other accessories will need one-channel of either a relay or open-coleector output as the user sees fit. It is usual to start counting the number of track sections since these are almost without exception, the most demanding in terms of i/o space. Note that output channel numbering starts from zero. Quite often there will be a one-to-one correspondence between TCDs and track sections. This is quite useful, since these can also be numbered from zero also, up the input channels and can simplify subsequent thinking processes substantially. For TCDs, SRI or SRI modules are indicated, if you are using your own design of TCDs (and here, a plug for the {9.5}JOHN DOWN# TCD type MR1071 or MR1072 seems in order!). Alternatively the RPC module FTC contains eight 'floating' track circuits built in. Returning to the outputs, we now need one channel for each point motor (or point motors with the same ID). Going on up, it is normal to come to signals which will need one output for each aspect, unless Hokpins decoders are used as just noted. This is likely to give rise to slight difficulties since relay outputs and open-collectors necessarily have their channel numbers (or 'addresses') on byte (or even four-byte) boundaries. This is fine if the number of track sections is a multiple of eight, but leads to redundancy under most conditions since signals are likely to use open-collector modules. It is however usually possible to soak up this redundancy with a few spare accessories that need driving from CARLOS, usually via vitual push buttons. After establishing the TCDs, the only other inputs likely to be needed are detectors used to 'prove' point blade positions, but this is by no means necessary for CARLOS to function. In a few cases additional detectors might need to be fitted, for example, to sense the position of a lifting bridge, so that track sections can be shut-off by CARLOS. Note that at this stage, it is probably uneccessary to number track sections or anything other than points. This can be left till later. Notwithstanding, what the i/o table produces is much important data for CARLOS, not to mention a 'shopping list' for RPC parts. ^3.1^CONNECTION Connection describes the process of connecting up the layout to CARLOS, and providing sufficient information for CARLOS to operate the various layout equipment in a coherent way. Connection is the most irksome and complex part of CARLOS, and nearly all errors introduced at this stage. Care at this stage is highly recommended. It is usual to connect up all of one device type at one go and then move onto the next device type. However, within that constraint, it will be shown that there are two of doing just that - one way is to completely characterise all the attributes of one device and then move onto the next, a second method is to set a single attribute of all the representatives of that device type before moving onto the next attribute of all of the representatives of that device type . In terms of the e-file this means working in rows or in columns. Once the user begins to see patterns in the e-file it is often quicker to connect by the second method. There are however a number ways to complete the connection phase, and each has its strengths and weaknesses. The normal method, especially for the novice user, is to select CONNECT from the plan page, this brings up a sub-menu containing the names of all active (and therefore connectable) devices. See {3.2}CONNECTION SUB-MENU# This essentially guides the novice user to completing all of one device type at a sitting. A second method is to invoke the {2.5} DATA PANEL# from the plan page. The data panel is made available by switching the PANEL (P) attribute on the plan page, control area, left menu panel. To connect or edit a device, its type is selected using DEVICE. It is then only necessary to push the mouse cursor into the square marking the start point of the device for the data panel to appear. If connection methods are fully understood then direct editing of the {0.5}E-FILE# is permissible, either by using the {5.2}VIEW E-FILE# facility(FV), or by using the {5.3}EDIT E-FILE# facility (FE). These facilities are similar but the VIEW E-FILE facility inspects the e-file in directly tabular form, whilst the EDIT E-FILE facility displays the e-file line at a time, with a corresponding diagram of the layout ^3.2^CONNECTION SUB-MENU This sub-menu points in turn to the active device connection pages for: {3.3}FEEDS# {3.4}SIGNALS# {3.5}LEVERS# {3.6}BUTTONS# {3.7}INDICATORS# {3.8}ROUTE INDICATORS# The connection pages have a very strong family likeness, and in many ways are similar to the main planning page. In the workspace the laypout diagram appears, which is rather similar to that presented by the plan page, there is an important difference, and this will be discussed very shortly. The control area is quite unlike the planning page. Its main function is to display values from one row of the {0.5}E-FILE# which concern the functionality of the device in question.To the right are a series of buttons 'Previous (p)', 'Next (n)', and the obligatory 'Exit'. The first two buttons allow the user to move up and down the e-file, allowing the contents of any row to be displayed. The keyboard up and down cursor keys also perform this function. The contents of e-file cocerning the device in question are displayed in a number of data boxes which stretch across the control area. Each box is headed by a caption which describes the function of the contents of the data boxes. The left hand two boxes are coloured yellow - they contain fixed data which is not alterable here by the user. The remainder are white. These values contained in these boxes can be altered by the user. Values entered via the keyboard are assigned to whichever data-box carries a red cursor bar. The cursor bar is shifted along the array of boxes using the left and right cursor keys. (See the last few sentences of {1.2}The CARLOS INTERFACE# for more details). The two left hand boxes are captioned 'Entry:' and 'ID:'. 'Entry refers to the devices position, that is, its row number in the e-file. 'ID' is the device's identifier in the e-file. The first appearance in the e-file is numbered one, and the value increases by one for each subsequent appearance of devices of the same type. ^3.3^FEED CONNECTION Feed connection is the both the most extensive and the most difficult of any the connection activities, and indeed, any CARLOS activity. Work steadily and methodically through FEED connection, and the rest of CARLOS connection phase will be simple by comparison. The workspace in the FEED CONNECTION page, contains a layout diagram in which all track sections are painted grey. Feeds are shown in yellow. However the position of the feed undergoing connection is highlighted in yellow so that signal undergoing connection is highlighted with a small red square - a carre - so that the feed being worked on can be readily identified. The diagram will update as a new row is selected. Apart for the yellow 'Entry:' and ID:' boxes there are FIVE data entry boxes. These are captioned thus: Tag in:~This allows the output to be driven from a numbered {6.1.4}TAG# and this could provide one of several ~methods by which, perhaps, buttons, might directly control track section power. TC OBN/Point OBN:~Here the user will usually enter the Output Bit Number (OBN) assigned to this FEED, this ~ will have been identified in your {2.7}INPUT-OUTPUT TABLE#, which will have been used ~to schedule what FEED is connected to what OBN, and thereby to which Track Circuit (TC). It is ~not uncommon to find circumstances in which several FEEDS are connected to a single TC via a ~Common OBN (COBN). This is true, for example, where points are joined toe-to-toe, and the virtual ~diagram must contain a joint between the points. Most areas of congested poitwork will contain more ~or less COBNs ~When the FEED is 'associated' with a point as a blade, then the REVERSE BLADE is charged with ~the job of operating the point motor, so that it is the Point OBN that needs to be defined, hence the ~alternative caption. TC IBN/Det IBN:~Generally this is where Track Circuit Detectors come in, often via FTCs in the RPC stack. ~Again the INPUT-OUTPUT TABLE will be used to make the assignment. ~When the FEED is 'associated' with a point as a blade, then the REVERSE BLADE is now charged ~with the job of reading any detector fitted to 'prove' the position of the points, so that it is the ~'Det OBN' that needs to be defined, hence the alternative caption. If there is no detector then this ~value may be left at zero. Point assocn:~Point association refers to the way in which FEEDS are associated with points. In all styles ~(lever, mouse or NXB), values must be entered STRICTLY in accordance with the following: ~TOE~1~...the toe or entrance to the points ~NORM~2~...the normal blade, usually, 'straight' blade through the points ~REV~3~...the reverse blade or diverging route through the points ~OTHERS~0~...all other normal feeds ~Remember, this rule also applies to NXB layouts. In the case the 'blades' are the route from the ~points to the next NXB button ~Point ID:~This is the ID number assigned to the points as drawn in the pictorial layout diagram ~~during the {2.6}PRE-PLANNING# phase. ~In summary, every conventional point needs three feeds, identified by a TOE, NML and REV feed ~with all three tied together with a common Point The FEED CONNECTION page has an extra feature, and that is a status box below the data boxes which identifies normal feeds, or, if they are part of a point, which part and to which point they are assigned. ^3.4^SIGNAL CONNECTION The workspace in the SIGNAL CONNECTION page, contains a layout diagram in which all track sections are unpainted. Feeds are shown in yellow. Signals are shown in plan form (that is, skeletal and non-working). However the position of the the signal undergoing connection is highlighted with a small red square - a carre - so that the signal being worked on can be readily identified. The diagram will update as a new row is selected. Apart for the yellow 'Entry:' and ID:' boxes there are FOUR data entry boxes. These are captioned thus: Tag in:~This allows the signal to be driven from a numbered {6.1.4}TAG# If zero is entered here then no ~tag is specified. If the user enters a non-zero number, then a real tag is called, and the value ON this ~tag (rather than the number OF this tag!) will exert control on the signal. The tag value will vary ~between 1or 0. If the value of the tag is zero then the signal is unaffected and will assume the ~'greenest' or least restrictive aspect that the the track circuit in advance, or the signal in advance ~(if any) will permit. The term 'in advance' is used in the proper signalling sense here, and means ~that a driver 'in advance' of a signal would have recently passed it, and, if he looked backwards, ~would see the back of the signal. Many layouts, especially in MOUSE and NXB styles, will make ~no use of TAGS. OBN for red:~This is the Output Bit Number (OBN) which is wired from the RPC to the red aspect. By CARLOS ~convention red takes the lowest bit, with yellow (if it exists), second yellow (if it exists), and green being ~driven by immediately subsequent bits. Only two bits will be needed if one of the Hopkins design ~decoders is being used, but again the lowest bit is assigned to red. No. feed in adv:~This specifies the Number of the Feed in Advance, and allows the signal to respond the Track ~Section (TC) in advance. There may be several Feeds relating to TC using a Common Output Bit ~Number (COBN). for the TC. Note that it is the Feed Number needed here - not the OBN No. sig. in adv:~This is the Number of Signal in Advance. This is the signal in advance along the normal route of ~travel and allows the current signal to respond correctly to the signal in advance. If there is no signal, ~for example, if the route ahead terminates in bufferstops, then the value entered here must be zero in ~order to invoke the correct behaviour from the signal. If the route ahead diverges, then it is the main ~route which should specify the next signal. If the route ahead diverges, then recourse must be made to a somewhat messy CARLOS feature - namely the 'Extend' facility. This is invoked by pressing the 'Extend' button. On so doing a further box, this time for text input, opens below the four data boxes. Apart from the case of the diverging route, there are several other cases where the extend facility can be used. Input is a short sequence of letters and numbers, and is stored in the e-file in the text string area. The strings are described here: Bn provides for the signal in question to serve as a repeater (a BANNER repeater) to the signal whose number is 'n'. For example B106 makes the signal in question a repeater of signal 106. This type of signalling is useful in London Transport lines, where S106 would be a two-aspect red-green signal. Its two-aspect repeater would then be yellow-green and CARLOS will arrange this automatically given the 'B' extension. Xn provides for the signal in question to give a red aspect if the Track Section for which the Feed (or any of its Feeds if there are several) whose number is 'n' is occupied. This artefact allows for the signal to respond to a Track Section that cuts across the line of travel. The obvious application for this is in the case of a double junction, where the line of travel involves travel over a diamond crossing. This situation will require that the appropriate signal responds to occupation of a Track Section other than the obvious 'Track Circuit in Advance'. The most complex text string relates to signals facing into a divergence, where the situation on the diverging route must be made to the controlling signal. The format is: Pn Sm Tq In this context P implies the Point ID follows, S means that the Number of the Signal in Advance on the diverging route follows, and T means that the next value is the (or any) Feed Number in Advance on the diverging route. Thus, in this string,'n' is the Point ID number, 'm' the Number of the Signal in Advance on the diverging route, and 'q' is the Feed Number in Advance on the diverging route. An example might be: P2 S107 T45. In all the cases above the letters are not case sensitive, so that the above example might be rendered as 'p2s107t45'. Any spaces are ignored, as are any non-significant letters. Spaces are recommended between groups in order to improve readability, but letters are not since they may give rise to subtle faults (for example B1 G9 may be interpreted as B19! Only signal extension and the device TEXT formally make use of the text string area in the e-file, users may use the text string area of any remaining devices for comments or as they wish. ^3.5^LEVER CONNECTION The workspace in the LEVER CONNECTION page, contains a skeletal layout diagram, with feeds shown in yellow. Levers are shown in skeletal form, except the lever which is being connected, which is shown in full operational frm, albeit non-working. Apart for the yellow 'Entry:' and ID:' boxes there are only THREE data entry boxes. These are captioned thus: OBN:~This is the Output Bit Number (OBN) which is wired from the RPC to whatever the lever controls. ~Very often this will be another lever, and by so doing, one lever can interlock another. In this simple ~example if, for example, lever A defines a Tag Out at 25 then lever B with Tag In defined as 25 will be ~locked 'normal' when lever A is reversed. The locked lever, unlike the prototype will show that it is ~locked by showing a small red indicator on the lever head. Tag Out:~This allows the lever to control a device that uses the Tag Out number as its Tag In number. ~Typically this might be another lever. See {6.1.4}TAGS# for more details ^3.6^BUTTON CONNECTION The workspace in the BUTTON CONNECTION page, contains a skeletal layout diagram, with feeds shown in yellow. Buttons are shown in skeletal form, except the button which is being connected, which is shown in full operational form, albeit non-working. Buttons are flexible devices, without any strictly pre-determined role. Accordingly they are useful for controlling such things as accessories. Apart for the yellow 'Entry:' and ID:' boxes there are just TWO data entry boxes. These are captioned thus: OBN:~This is the Output Bit Number (OBN) which is wired from the RPC to whatever the button controls, ~typically a signal or turnout. The user will have determine this value during the pre-planning phase. Tag Out:~This allows the button to control a device that uses the Tag Out number as its Tag In number. Typically this might be a feed, a lever, a signal or any other such device. See {6.1.4}TAGS# for more details ^3.7^INDICATOR CONNECTION The workspace in the INDICATOR CONNECTION page, contains a skeletal layout diagram, with feeds shown in yellow. Indicators are shown in skeletal form, except the indictor which being connected, which is shown coloured. This color changes so that the indicator flashes its OFF colour for about three timeslonger than its ON colour-both of which are alterable by the user at CONNECT time. Indicators are small, but they are far from insignificant. The angle attribute controls the style, there are six visible styles, but additionally the indicator may be invisible. This apparently useless mode hides what is perhaps the indicator's most useful feature - its Tag Out signal is the reverse of its Tag In value. What does this mean? It means that an indicator indicates its Tag In or IBN signal (visibly or not!), then inverts this signal before passing it to either the numbered Tag Out or OBN (or both!). This allows for comprehensive interlocking between devices, usually levers. See {6.1.4}TAGS for more information. Apart for the yellow 'Entry:' and ID:' boxes there are no less than SIX data entry boxes. This reflects the versatility of these devices. These are captioned thus: OFFcolour:~This is the indicator colour when signals from both Tag In (if specified) and the Input Bit Number ~(IBN) are both zero. The choice of colours and the number values that relate to them are shown ~below the data entry boxes. ON colour:~This is indicator colour when signals from either Tag In (if specified) or the Input Bit Number (IBN) ~are on. If either signal is on, then the indicator will also be on. Tag Out:~This allows the button to control a device that uses the Tag Out number as its Tag In number. ~Typically this might be a feed, a lever, a signal or any other such device. See {6.1.4}TAGS# for more details OBN:~This is the Output Bit Number (OBN) on the RPC stack. Often it will not be used, but is included ~since it allows a device to drive an output device via an inverting (usually invisible) indicator. It might, ~perhaps, be useful for allowing one turnout to be 'reversed', whilst allowing another to set 'normal'. Tag In:~This allows the indicator to be driven from a numbered tag, useful if you need some added indication ~relating to a function driven from a button or lever perhaps. IBN:~This allows the indicator to be driven directly from something out on the layout, via bit on the RPC. ^3.8^ROUTE INDICATORS In device boxes these are referred to as R/INDS for brevity, but describe route indicators or 'feathers'. Up to six route indicators may be attached to a single signal. The workspace in the ROUTE INDICATORS page, contains a layout diagram in which all track sections are unpainted. Feeds are shown in yellow. Position indicators are normally shown 'black'. However the position of the the position indicator undergoing connection is shown illuminated or 'white'. Apart for the yellow 'Entry:' and ID:' boxes there are FIVE data entry boxes. These are captioned thus: Related sig. no~This is simply the ID of the signal upon which the 'feathers' sit. The signal needs to be ~identified, so that, no matter what else influences the feathers, a red signal ensures that it is ~unilluminated (ie showing a 'black' aspect). Related feed No.~This is the ID of the feed which is associated with the REVERSE blade (or route in NXB layouts) ~of the points which give rise to a diversion of route, which in turn calls for the appearance of the ~feathers. OBN:~This is the OBN which earmarked to drive the lamps in the feathers in the 'outside' signal. Related feed No 2~In the majority of cases this will be set to zreo. However in the case that two points ~specify the diverging route (which may well be the case when more than one feather is attached to a ~particular signal), then this box allows for the input of the ID of the REVERSE blade for that second point. Related feed No 3~The use of this input is expected to be exceptionally unusual, and will be needed only ~ when THREE points specify a diverging route. In the very vast majority of cases this will be left at zero. ^4.1^OPERATING WITH CARLOS Operation, using the OPERATE page, is reached by pressing the OPERATE button in the PLAN page (or by hitting 'O'). CARLOS however does not pass directly to the operate phase, but makes checks on the E-File for possible errors. Many it can sort out without further ado, however, some it can't, and a schedule of suspect entries is reported on a special page - in particular double- and multiple-bookings to a single bit. This situation is usually concentrated around bit zero, where the user has forgotten to 'connect' up an active device. The user is invited to return to PLAN to sort them out, or accept them (this is justifiable where there are deliberate assignments to a single bit). If there are no suspect rows then this step is ignored. As in previous pages, CARLOS then presents a screen in similar fashion to that used in the PLAN and CONNECT phases. The workspace still contains the layout diagram, though all devices now appear in their operational form. An important factor is that once communications with the RPC is established, the diagram accurately reflects what is happening on the layout outside. In particular, track changes colour according as whether the related track section is idle, powered, occupied by a train, or powered and occupied. Where appropriate, point blades will be seen to move, and signal aspects will be seen to change. The RPC FTC units are used to feed back information relating to the occupation of track sections. At an early stage it was necessary to establish a standard for colouring track circuits. The following colours are used: grey-idle white-powered red-occupied yellow-powered and occupied The default background colour is a pale green, similar to that used by BR on its panel boxes which I have called 'willow'. This colour is also used for the 'unswitched' point blade (where appropriate) and parts of the layout outside CARLOS control (for example, little used yards). This colour is alterable using {1.8}SETUP# from the PLAN page if the user so wishes. Black is reserved to indicate transient or error states. For layouts running under NX control, routes set up as each NX button is turned, and during this time, routes are required to flash. No less than four shades of buff / grey are used for route setting applications. Before starting operations however, there is one more task to undertake and that is to set up proper communications, and to sort out a few other options. Pressing the {1.9}COMMS SETUP# button brings the dialogue box. Actual operation depends on the layout style chosen and has already been discussed under {0.2}LAYOUT STYLES# There are however a few other features in the control area that are worth mentioning. On the left is a 'glass' controller, with a six channel selector to its right. Controllers do not formally form part of the RPC range of equipment though such an item was demonstrated by Gordon Hopkins and John Down demonstrated one at Nottingham over five years ago. controllers is omitted here. The next item is an offset device. This allows the array of 64 buttons and indicators to be shifted along the i/o space to wherever it is required. A very necessary accesory for large systems. ^4.4^LAYOUT EMULATION In preparation ^5.1^ FILE HANDLING Before we discuss the FILE control, it is appropriate to say something about data structures, since they, in their turn, have a significant impact on the files stored on disc. Although there are many internal data structures manipulated by CARLOS, the only ones with significance to the user are the {0.5}E-FILE# and the {0.6}O and I VECTORS# The FILE control Pressing the FILE button leads to a menu of utilities that provide sufficient file handling capabilities to allow for complete flexibility in planning, connecting and operating CARLOS based systems. Mot of the options on this menu will be familiar to anyone who has used Windows-type environments. The options are, in order: NEW,OPEN, SAVE, VIEW, EDIT, DIRECTORY, OUTPUT MAP, INPUT MAP and EXIT. NEW allows for any existing file on which you are working to replaced with a virgin file. When entering CARLOS from the start, newness is implied, so there is no need to specifically select it. OPEN initiates a dialogue using the {1.7}FILEOPEN# box which allows previously completed (or part completed) layouts to be retrieved from hard disc. SAVE initiates a dialogue using the {1.7}FILESAVE# box which, generally, allows for existing work to be saved as a file with a .CAR extension. VIEW allows the {0.5}E-FILE# to be viewed with proper layout and formatting, together with means of undertaking very rapid editing. See {5.3}VIEW E-FILE# EDIT permits the user to directly edit rows in the the {0.5}E-FILE#. See {5.2}EDIT E-FILE# DIRECTORY simply lists all layout files (ie those with the extension .CAR) and their details. OUTPUT MAP is a facility that is useful late in the planning stage. It provides an at-a-glance view of what device or devices are allocated to what output bit. It is quite easy to 'double book' devices onto a single output bit, and such a situation is immediately obvious by looking at the map, since 'multiple bookings' or 'multiple assignments' are highlighted. It is quite easy to forget to assign an active device to a bit, with the result that it is quite easy for several devices to finish linked to the default bit which is bit zero. There are however certain circumstances where 'double booking' is not only acceptable but necessary. INPUT MAP, is, naturally enough, the counterpart to the output map facility, but directed towards the input vector. All the previous comments apply. EXIT allows the user to get back to the outside world, though not before some closing dialogue is undertaken, related. to saving files! ^5.2^VIEW E-FILE This function is reached from the PLAN page,using the menus and mouse or (FV). An {0.5}E-FILE# is always stored with a .CAR extension. Immediately it is possible to see that every device is stored in the form of twelve variables, and a text string, though many fields (especially that for text) are left blank, or are set to zero. Devices are stored so that all the examples of any one device are ranked together. This often allows patterns to be seen and errors tracked down. This is decidedly bandit country and considerable experience is needed before attempts are made to work in this area. It was originally included as a works 'maintenance' facility, but offers the experienced user great power and flexibility. Errors introduced here though can be very difficult to track down. ^5.3^EDIT E-FILE This function is reached from the PLAN page,using the menus and mouse or (FE), and allows essentially direct editing of the {0.5}E-FILE# to proceed. [c12]INCOMPLETE ^6.1^DEVICES. Devices are the building blocks which go to make up the layout as it appears on the screen.. Thirteen devices are available in total. Six of them are are {6.1.1}PASSIVE DEVICES#, these are completely specified by their geometry and have no 'working parts' during operation. They are described as TRACK, TEXT, BEND, JOINT, BUFF and LINE. The remainder are {6.1.2}ACTIVE DEVICES# and have more or less functionality when CARLOS is operating a layout. They are described as INDICATOR, SIGNAL, BUTTON, LEVER,NXB, FEED, ROUTE INDICATOR and RPC. {6.1.3}POINTS# are not devices in their own right, but are fabricated from track, bends and feeds. {6.1.4}TAGS# are 'invisible'devices capable of providing flexible linkage between many active devices ^6.1.1^PASSIVE DEVICES TEXT of course allows the user to add text to his layout diagrams. Text may only be presented horizontally. TEXT has obvious applications in providing such things a station names, but is probably more useful in providing signal and point numbers.. BEND provides a fixed size icon representing just what it says. It can be rotated to any 45 degree angle. It forms an important building block in the consruction of points.. JOINT provides a dividing piece so that unbroken lengths of track can be sectioned. BUFF provides for bufferstops, a neat and necessary requirement to terminate lengths of track. LINE is a most useful device. Lines can be used in multiple to represent platform edges, tunnel mouths, bridges and all manner of civil engineering structures. There is no limit to the uses of LINE, though its continued use to represent complex stuctures can be irksome.. ^6.1.2^ACTIVE DEVICES. . From the planning standpoint, ACTIVE devices are only marginally more complex than their passive cousins. The fact that they additionally have functionality is addressed during the CONNECT phase, though we shall see soon how it is possible to 'connect up' active devices direct from PLAN.. INDICATORS Indicators are small, but they are far from insignificant. The angle attribute controls the style, there are six visible styles, indicators may be square or circular, and of three different sizes, but additionally the indicator may be invisible. This apparently useless mode hides what is perhaps the indicator's most useful feature - its Tag Out signal is the reverse of its Tag In value, which allows an indicator to serve as a logical inverter. When worked in asociation with tags it is possible to produce interlocking schemes of some complexity. See {3.7}INDICATOR CONNECTION# for more details SIGNALS are, at present, only available as Multiple Aspect Signals (MAS), though semaphores are planned as an upgrade shortly. In addition to having the obvious geometric attributes, they use the length attribute to specify the number of apects, which can vary from one to four. On 'large' layouts it is possible to instal 'small' signals (using the L toggle on the menu block) to serve as shunting signals. See {3.4}SIGNAL CONNECTION# for more details. BUTT specifies button. These are used on the final layout diagram, and appear, during OPERATE, in a similar fashion to those currently displayed in the control area. They behave somewhat differently however, a LHS mouse button press sets them ON, whilst a RHS button press switches them OFF. The ON and OFF states are clearly visible as such. During PLAN the size of the button is controlled by adjusting the length attribute. During PLAN, buttons appear as skeletal squares, and are always aligned horizontally. See {3.6}BUTTON CONNECTION# for more details. LEVER presents a rectangle with longest face set vertically. The skeletal rectangle is split by a crossbar. The colour of this bar can be set by the angle attribute. During OPERATE, the device makes an attempt to behave like a signal box lever, though in truth, it is probably more like a slide switch. The stem of the lever now takes on the colour of the crossbar so that your 'levers' can bear some resemblance to semaphore lever frames. Red, yellow, black and blue are available. As yet brown for gates and stripes for detonator placers are something for the future! Something CARLOS levers have and prototypes do not, is an indicator which shows when a lever is locked. See {3.5}LEVER CONNECTION# for more details. NXB - eNtrance-eXit buttons are for exclusive use by NXB type layouts, and should not be used by lever-frame or mouse-driven layouts which contain points with visible blades. Large and Small NXBs are available. They can be set to lie at any multiple of 45 degrees. Fig.1 shows the appearance of NXBs during the PLAN stage. At the OPERATE stage they turn under the mouse, and do all sorts of other exciting things! NXBs essentially connect so there is no CONNECT phase related to them. FEED. Finally there is FEED, the most difficult of all the devices to understand, but these are a critically important part of CARLOS. FEEDS act as the 'colour' injectors for every identifiably different piece of track on the displayed layout. Now this need not necessarily coincide with the track sections outside, though it is likely that it will. More generally there will be more feeds than track sections, so that for many track sections there will be more than one feed. It is rare if not unknown to find the converse, that is, more than one track section to one feed. Installing the feeds needs to be quite accurate as they need to be fitted neatly between the rails, and an in-built 'inching' facility provides an easy way of getting feeds just where they need to be. There is a small margin of error here - if the centre of the diamond is within the black rails all will be well. If it lies on or outside the rails theCARLOS will not perform correctly. See {3.3}FEED CONNECTION# for more details ROUTE INDICATOR. Route indicators or 'feathers' can be installed on signals which need to indicate that a diverging route is set. When first installed on screen they look unassuming and a little messy. The angle attribute must be adjusted so that it matches the signal on which it is to be installed. At first the feather is set to route 1, and can be switched round to route 6, again quirkily, by the length control.attribute. By convention route 1 relates to the extreme left hand route, and calls for feathers pointing left and DOWNWARDS from the top of the signal. Thereafter routes are indicated by feathers pointing directly left, left upwards, right upwards, directly right, and right downwards. Routes 2 and 3 (left upper and right upper) are, by far, the most common, other routes only being called in the case of a multiplicity of divergences. As soon as the feathers are opened out with the length control to routes 2 and 3, they becomes a less messy and more like a route indicator. Up to six feathers may be fitted to a single signal head. Inevitably this will call for some nifty placement work - it is recommended that the user notes the x and y co-ordinates of the first feather, and then inches successive feathers into place using the cursor control - or, if all else fails, by using the data panel to perform a final edit. Where there are several route indicators on a signal, it is easier to instal the assembly of feathers and then instal the signal before finally inching the signal into place. Note that feathers can only exist in the 'large' format - they are difficult enough to see as it is. See {3.6}ROUTE INDICATOR CONNECTION# for more details. RPC - this option in turn produces another pop-up menu from which any one of ten RPC elements may be selected. These are SRO4, QRO4, DPR and QPR (output units with IC and relay outputs respectively), Input units SRI, SRI4 and the track circuit detector FTC, and finally the interface RPI and 'specials, LCD and DCC. This facility allows the user to select various RPC devices, and allows them to be stacked in like manner to the outside world. This facility allows for testing of RPC devices before a layout is set up. Usually the use of RPC devices means that no other devices will be used. Mixing RPC devices and layout devices is likely to lead to some unusual and unexpected results, and, whilst possible, is not recommended. In PLAN the various RPC devices are represented by skeletal rectangles. The user has no control over the positions of RPC devices- they stack up, as entered, but always with an RPI at the top. During the OPERATE phase, these images become fully functioning arrays of buttons and indicator lamps. ^6.1.3^POINTS Until now, we have not mentioned points, other than, briefly, as point structures. You may have also noticed that. points do not appear explicitly in the list of devices. This is because each point is fabricated from a length of track. and a bend (or exceptionally, two bends). Operation of points is secured by establishing FEEDs in appropriate. positions. This approach allows for considerable flexibility in layout design, which would not be the case if points. were highly stylised, as would happen if they were specific devices. It is quite possible to generate scissors. crossings, tandem and three way points, and other points by the method described. [c12]MORE INFORMATION IS IN PREPARATION... ^6.1.4^TAGS CARLOS has one very powerful but virtually hidden tool in its armoury,. and this is the TAG. Conceptually, TAG amounts to a long tag strip with several hundred connections, and to which any device may be connected. This tag strip exists only within CARLOS - there is no corresponding hardware. It is possible to drive certain devices fromTAGs (indicators are an obvious example). Other devices (such a signal. lever) may be arranged to both drive tags, and be driven by other tags. This permits interlocking of manual frames. [c12]UNFINISHED... ^9.1^TELEPHONE or E-MAIL SUPPORT Wherever possible reasonable levels of telephone or e-mail support will be provided. Having said that, the amount of time spent with unregistered users will rarely exceed fifteen minutes in total. In the case of registered users, it is not practical to spend much more than three or four hours in personal support, unless the user has stumbled upon a bug within the program. Unfortunately it is almost impossibly difficult to provide telephone support relating to layouts, without having a diagram of the layout to which reference can be made. Accordingly such support will not be offered, unless a diagram, complete with sufficient references to the various features is provided. This can be provided by mail, e- or otherwise. Material will not be returned without a suitable SAE. In the case that the diagram is in the form of the E-file saved as a .CAR file then e-mail is favoured over 3.5in. floppy disc. Low density discs provide better reliabilty. 5.25 or 8in. discs are unacceptable. Contact {9.5}JOHN DOWN# if you need personal support. ^9.2^RPC HARDWARE RPC hardware and information thereon is available from {9.4}GORDON HOPKINS# A schedule of available RPC stack components available is given below, with guideline prices applicable at January 2000 RPI RS485 Remote Panel Interface~~~œ17.50 DPR Double pole relay module (no relays)~~~œ7.50 SRO4 Four byte open-collector output~~~œ12.50 FTC Floating track circuit detector~~~œ12.00 SRI4 Four byte input module~~~œ10.00 QPR Quad-pole relay module~~~œ11.00 Also available are: PMD1 CDU point motor drivers~~~œ4.00 PMR1 Relay output point motor driver~~~œ5.50 RSA RSA module~~~œ9.00 SD4 Two to four bit decoder~~~œ2.20 PMD1 modules allow point motors to be driven from SRO4s SD4 modules permit three and four aspect signals to be driven by two bits from SRO4s All module are provided as kits, consisting of PCB and components, and are available at present only to {9.3}MERG# members. Estimates for pre-built modules are being obtained at present and are expected to be about three times the price quoted for kits. In the US the price of kits is expected to be twice the quoted number for Sterling, in US dollars. ^9.3^MERG MERG is acronym for the Model Electronic Railway Group, an international group of modellers, but based in the United Kingdom interested in the application of electronics to model railways. Meetings are held about six times a year, usually in London, but occasionally elsewhere. Technical Bulletins bulletins and newsletters are published about four times a year. Membership is about œ10 a year, but for up-to-date information write to: The Membership Secretary MERG 23 Chapel Street Yaxley Huntingdonshire PE7 3LW or e-mail: johnweal@merg.freeserve.co.uk MERG has a website at: http://home.freeuk.net/merg/ If you reach this site, select hyperlink LINKS, then scroll down for hyperlink CARLOS', this will provide links to the latest copies of the CARLOS files, as well as comprehensive information on the RPC system. MERG members correspond using: http://www.merg@egroups.com ^9.4^GORDON HOPKINS ...is the designer and supplier of the RPC system components If you need information or RPC equipment then write to him at: 24 CASTLE ROAD GRAYS ESSEX RM17 5YR or e-mail: ghopkins@mergrpc.freeserve.co.uk Alternatively, information is available from the {9.3}MERG# website Gordon is a leading member of MERG, and an expert on DCC and serial data systems. He is well known on the exhibition circuit since he often appears with the Nottingham (Bulwell) MRS with the Carstairs layout as well as on the MERG stand. Both stands draw considerable numbers when his Class 508 DMU with operating doors, 'doors closed' indicators and irritating prototypical bleeping is shown. See illustrations of RPC components _and_ the 508 on his website at: www.mergrpc.frreeserve.co.uk ^9.5^JOHN DOWN John Down is the author and supplier of this software You should contact him in order to register, or in order to get support by writing to: 3 BRYNHYFRYD TERRACE PENTWYN ABERSYCHAN TORFAEN SOUTH WALES NP4 7TB ... enclosing a suitably stamped SAE if you anticipate a reply or e-mail: yogidown@aol.com. Probably the best method is by e-mail; For the latest CARLOS software see {9.6}UPGRADES# John is the founder member and president of {9.3}MERG#, which he started in 1966. A retired nuclear engineer, his interest in model railway electronics ('moronics'), has included the development of probably the first PWM 'multivibrator' controller (1961), probably the first multi-channel train controller, which ran four channels using originally reed relays, and then tuned circuits (1964). The On-Board controller (1979), and a variety of Memory Wire devices for points and signals - and of course, many layout control panels centred on the IBM PC. Reports on most of his later daft creations appear as MERG Technical Bulletins. He is an unashamed BR(W) man, thinks LQ semaphores are wonderful, but has closet Southern Electric tendencies. He now spends most of his time on the Pontypool & Blaenavon Railway (search the web for it), because, he says, modelling at 12 inches to the foot scale is cheaper! ^9.6^UPGRADES LATEST VERSIONS OF THE SOFTWARE ARE DIRECTLY AVAILABLE FROM THE CARLOS SITE AT: http://www.railwaycontrol.co.uk If this site is overlaid by a message from the site's host UK2.NET simply close, move or minimise that page and look at what is underneath. Latest versions are also available from: http://home.freeuk.net/merg/ If you reach this latter site, select hyperlink LINKS, then scroll down for hyperlink CARLOS, this will provide links to the latest copies of the CARLOS files, as well as links to comprehensive information on the RPC system. ^100^WELCOME TO CARLOS.... ^101^COMPUTER AIDED RAILWAY|LAYOUT OPERATING SYSTEM. ^102^This is Turbo Version 1.0|Release date:. ^103^CARLOS is freeware and may be copied freely for non-commercial use.. ^104^Most facilities are available, including planning and file handling.. ^105^However, in order to operate a layout (usually through the RPC system). ^106^you must register your copy. Ring John Down on 01495-760242 for further details. ^err0^No error. ^err1^NEXT without FOR. ^err2^Syntax error. ^err3^RETURN without GOSUB. ^err4^Out of DATA. ^err5^Illegal function call. ^err6^Overflow. ^err7^Out of memory. ^err8^Undefined line number. ^err9^Subscript out of range. ^err10^Duplicate Definition. ^err11^Division by zero. ^err12^Illegal direct. ^err13^Type mismatch. ^err14^Out of string space. ^err15^String too long. ^err16^String formula too complex. ^err17^Cannot continue. ^err18^Function not defined. ^err19^No RESUME. ^err20^RESUME without error. ^err24^Device timeout. ^err25^Device fault. ^err26^FOR without NEXT. ^err27^Out of paper. ^err29^WHILE without WEND. ^err30^WEND without WHILE. ^err33^Duplicate label. ^err35^Subprogram not defined. ^err37^Argument-count mismatch. ^err38^Array not defined. ^err39^CASE ELSE expected. ^err40^Variable required. ^err50^FIELD overflow. ^err51^Internal error. ^err52^Bad file number. ^err53^File not found. ^err54^Bad file mode. ^err55^File already open. ^err61^Disk full. ^err62^Input past end. ^err63^Bad record number. ^err64^Bad filename. ^err67^Too many files. ^err68^Device unavailable. ^err69^Communications buffer overflow. ^err70^Permission denied. ^err71^Disk not ready. ^err72^Disk - media error. ^err73^Adv.feature unavailable. ^err74^Rename across discs. ^err75^Path/File access. ^err76^Path not found. ^err80^Test error. ^err81^Input entered incorrectly. ^err93^Unrecognisable file. ^err94^Line not found in support file. ^err95^DOS version too old. ^err96^Improper execution. ^err97^Error during DOS call. ^err98^E-file fatally corrupted. ^err99^No identifiable error. ^err100^Indeterminate error. ^OPENING MESSAGE^ CARLOS is freeware and may be copied freely for non-commercial use. Unregistered versions will do everything except finally operate a layout, including planning, connection, filehandling and emulation However, in order to operate a layout (usually through the RPC system) you must register your copy. See HELP file for registration details ^QH1^COLUMN 1 This column contains the ID number of the device. This is effectively the Nth appearance of the device reading down the e-file There is litle to be gained by editing this value as CARLOS will promptly return it to the original, correct value ^QH2^COLUMN 2 This column generally contains a number in the range 0 to 17 The values have the following significance: 0 (none), ready fo use 1 LEVER 2 TRACK 3 FEED 4 TEXT 5 BEND 6 JOINT 7 BUFFERS 8 LINE 9 MAS (multiple aspect signal) 10 RPC 11 NXB ^QH3^COLUMN 3 ^QH4^COLUMN 4 ^QH5^COLUMN 5 ^QH6^COLUMN 6 ^QH7^COLUMN 7 ^QH8^COLUMN 8 ^QH9^COLUMN 9 ^QH10^COLUMN 10 ^QH11^COLUMN 11 ^QH12^COLUMN 12 ^PH0^QUICKHELP data for this area is still in preparation. Press {0.0}HERE# if you would like to go directly to the INDEX in main help file ^PH1^LENGTH CONTROL. QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH2^ANGLE CONTROL QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH3^CAPTIONS QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH4^MOUSE- AND DEVICE-POSITION QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH5^LEFT-HAND MENU BOX QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH6^RIGHT MENU PANEL To the left of the button cluster is a menu panel and is arranged to allow a number of features to be toggled on or off. It contains four functions, namely HELP, TIME, PAINT, REDRAW..HELP replaces the planning page with a full page image of the launch page of an extensive, hyperlinked help file (you must know that or you would not be here!). With TIME selected a clock appears in the extreme lower right of the screen. Action of the clock can cause some visual interference on slow PCs and accordingly the option to switch it 'off' is provided. Feeds, amongst other things, provide colour injection points to rail sections. The PAINT function allows all feeds to inject the colour grey during PLAN. This provides a visually potent method of viewing a near-complete layout, and, perhaps more importantly, exposes very clearly any sections that need feeds. Unfortunately unless all track areas are 'closed' with JOINTS, BUFFs or other pieces of track cutting across them, painting causes 'flooding' to occur. CARLOS will detect this quickly and automatically toggle the PAINT control off. The layout plan is more or less frequently completely redrawn (for example at every file operation). Occasionally a set of circumstances conspire to corrupt a small part of the display. REDRAW does just what is says and removes any quirks as it does so. Press {2.2}HERE# to go directly to the correct place in main help file ^PH7^SETUP BUTTON QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH8^CONNECT BUTTON QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH9^OPERATE BUTTON QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH10^DEVICE SELECT BUTTON QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH11^DEVICE SELECTED BOX QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH12^FILE BUTTON QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file ^PH13^FILENAME BOX QUICKHELP data for this area is still in preparation. Press {2.2}HERE# to go directly to the correct place in main help file BUTTON CLUSTER On the right we see a cluster of buttons, together with two yellow indicator box. The button on the extreme right marked 'File' allows access to all the various facilities described under {5.1}FILEHANDLING#. Briefly this allows the user to manipulate files which contain data that he is planning, or has planned (or, indeed, anyone else has planned). Below this the current filename is shown in a yellow box. The 'Device' button selects one of more than twenty 'devices' from a menu. Each device can then be installed into the plan. The current device selected is shown below the button is shown in a yellow box. Next comes the 'Setup' button. Pressing this brings up the {1.8}SETUP DIALOGUE BOX#, which allows the user to set up permanent and semi-permanent features related to his plan. Below that the {3.1}CONNECT# button opens a new section of the program. A user with an almost complete layout plan can press CONNECT in order to establish how his devices work and link together, and, in particular, to what bit of the RPC they are connected. The lowest of the three buttons, when pressed, takes the user to the {4.1}OPERATE# part of the program. LEFT MENU PANEL Yet further to the left is another menu panel. This panel allow the user to toggle four fuynctions, namely GRID imposes a grid on the layout to which devices will snap. Unlike most grids, this grid works only in the horizontal plane and is a useful tool in setting up the 'six foot way'. There is little or no need for a vertical grid and accordingly, it is not provided. SIZE alters the 'largeness' attribute of a device. The default is large, but small device may be toggled at will. It is use of this control that provides the two layout size capability. PANEL provides a method of setting up the functionality of a device without entering the CONNECT phase. See {2.5}DATA PANEL#. FEEDS allows all feeds to be made invisible - or visible. This is useful when constructiong complex junctions since a large number of FEEDS can congregate, making for a very cluttered diagram. CURRENT PANEL This panel, to the left of the menu panels, contains data relating to the position of the mouse, to the position of the currently 'free' device, to the attitude of the current device, to the size of the file holding the layout, and to the number of bytes in the {0.6}O-VECTOR# (or the I-VECTOR in the exceptional case of this being the larger of the two). LENGTH and ANGLE CONTROLS In the left hand corner are two pairs of buttons. These control the length and angle attributes for devices, where devices have these attributes as variable. Length is variable in the case of TRACK and LINE, however this control is also used to to control the size of BUTTONS and to set the number of aspects of SIGNALS. The angle control is used to turn TRACK, BENDS, JOINTS, BUFFERS, LINES, SIGNALS, and NX buttons. The angle is adjustable in 45 deg increments. The angle control is also used to set the shaft colour for LEVERS and to select the style of INDICATORS. Whilst there is no doubt that these last two are a little quirky, it does simplify the planning page a little. ^END^ END OF FILE -you should not be here Call 01495-760242.