jamespetts

That is an interesting hypothesis - one way of testing it would be to compare the build-up of deposits on fiddle yard track which has been nailed down and is not ballasted to build-ups of deposits on scenic section track that has been glued in place with PVA and which has been ballasted using PVA.

This is a bizarre and frankly disturbing response. It is totally inappropriate and verging on the wilfully abusive. (This is not being reported to the moderators because the moderators on this site are also abusers who deliberately enable abuse of this sort by locking threads when there are abusive posts in them irrespective of who is responsible for them, taking no specific action against those responsible for the abuse themselves, thereby allowing people deliberately to stifle discussion of an issue by abusive behaviour). The post to which Robin linked specifically referred to a sample of the black deposits on track having been sent to a laboratory and spectrographically analysed, being found to constitute mostly nickel (III) oxide. Unless one were to think that what is stated in that post was a deliberate lie, for which there is no remotely plausible motivation, that describes a cogent and specific reason to believe that which is stated, viz. that the deposits on model railway track are principally composed of nickel (III) oxide. That is a long way from a bare assertion of the mechanism without any attempt to explain the reasoning. I have not doubted the truth of any descriptions of actual experiments carried out by anyone on this thread. If somebody here had claimed to have sent the results to a laboratory and described the result of a spectrographic analysis on this thread, I should not have suggested that the person was lying. You need urgently to change your attitude to critical thinking and questioning in a radically fundamental way.

I had not - but this is very interesting indeed! Thank you for that. (In summary: laboratory testing shows that the black accumulations are indeed nickel (III) oxide, a black, non-conductive substance which accumulates on track in patterns suggesting causation by micro-arcing.)

I am aware of the learning on polar vs. non-polar chemicals in this context, but the questions that I was asking were not about this specific topic, but rather about the specific other claims being made (e.g. that oxidation of nickel silver occurs in ambient conditions and that these oxides can be removed from the railhead by running trains). May I ask the reason that you posted a link relating only to polar vs. non-polar chemicals in response to this? Robin - I should be very interested indeed in any test results for the consequences of the use of graphite on track.

I simply ask because you appeared to have a very confident belief in some very specific claims (e.g. that the black deposits arise from particles blasted off wheels, that oxidation of nickel silver rail occurs over time without the running of trains and that the running of trains can mechanically remove the oxide deposits) and because you referred to a specific video in which a person whom you described as a research chemist had tested relevant claims. One would normally expect a very specific belief to a high level of confidence to arise only where there is strong specific evidence for that particular belief, so it is very much worthwhile, reasonable and to be expected for a person who is not aware of that evidence to want to ask about it to understand the topic in more detail. Incidentally, I did not suggest that you were being hostile so much as that you might incorrectly have believed that I was being hostile by asking the questions. If you or anyone else ever remembers the link to the video featuring the research chemist, incidentally, please do post it here: I should be very interested to see it.

I have already undertaken general research, which is what lead me to my current understanding. If somebody has a reason to believe that a different understanding is correct, then it is entirely reasonable to ask that person what that reason is. Either the person knows the answer to that question or he or she does not. It takes no effort to state which it is, and, if the answer is known, to state that answer. If the person does not know or will not answer the answer to the question of the evidence supporting her/his conclusion, then it is reasonable for another person not to change her/his view on the basis of the assertion of that conclusion unless and until such reason and evidence should become apparent.

I am not aware of any list in a single external source for all of the hardware requirements or considerations of automation. I and others on this thread have attempted to summarise the relevant hardware requirements as best we can. My own research a few years ago was able to piece together what was needed, although building a small automation test layout also helped. As to the DR4088 devices, Iain Morrison correctly summarises the types. One or two things to know about the S88 bus: first of all, this bus is supported by the DR5000 command station, so you can use this instead of the LocoNet bus if all that you want to use it for are occupancy sensors (implying using a DCC accessory bus for control of accessories such as points and signals). Secondly, it is a less capable bus than LocoNet. Thirdly, it can take one of two cabling types: a bespoke ribbon cable or an RJ45 network cable (at least when used with the DR4088s - I believe that the ribbon cable is the normal standard). Fourthly, its simpler nature may make it more prone to noise/unreliability if you have very long cable runs, although I have not found any problems. Fourthly, it is limited to 16 DR4088CS devices per node. Fifthly, the DR4088LN devices have an S88 bus output, so you can connect a DR4088LN to the LocoNet bus and then connect up to 16 daisy chained DR4088CS devices to each DR4088LN. Finally, the DR4088CS devices are cheaper (even taking into account the need to use slightly more expensive RJ45 cables) than DR4088LN devices. So, it can be helpful, if you need to cluster a few DR4088s together, to use a DR4088LN and connect a DR4088CS right next to it with the S88 bus. You do not need to do any of this and can use all DR4088LNs, but you might find that using a combination of LN and CS types will save a little money.

The reason that I ask for the specific video is because you mentioned that it was from a research chemist, which suggests that there might be a scientific basis for it, which would be very interesting indeed. That something is said in good faith does not make it true; many people genuinely believe things that turn out not to be correct. What I am interested in is thus what the evidence is for the particular mechanisms to which you refer. You refer to "bits of the wheel" being "blasted off" during micro-arcing - do you mean that these are simply fragments of nickel silver chemically unaltered, or are these indeed oxides? Or do you not know? What we do know is that the substance is black - if we file nickel silver, the filings that we get are shiny and grey in colour, suggesting that the deposits are chemically different from the metals from which they are formed (note that wheels on model trains are also made of nickel silver). Also - is there a particular reason that you think that the deposits come from the wheels alone rather than both from rail and wheel in circumstances where they are chemically identical and in contact or close proximity with one another during the micro-arcing events that give rise to the depositions? Or did you mean to state that they come from both? Also, you had mentioned in an earlier post the issue of ambient oxidation - I should be very interested in any research sources that you have on this (or, if you cannot remember specific links, keywords by which you found those research sources and some idea as to how I will know when I have found the specific research sources that you remember having found), as this is a potentially significant mechanism that might alter how best to deal with regular maintenance. I have heard it said elsewhere - without citation of evidence - that running trains can reduce ambient oxidation build up on rails, but, without anybody having tested this, I remain sceptical. It does not follow from the fact that running real trains on real rails prevents the tops of those rails from becoming rusty that the same will apply to oxidation of nickel silver on model railways. The mechanism on real railways is that the trains exert great forces on the rails physically abrading away the rust and effectively polishing the rail heads. I am doubtful that model trains are heavy enough to exert sufficient force to have any significant level of abrasion on the rail head surface. Certainly, one cannot safely assume, without testing, that the same mechanism will work at 1:76th or 1:148th the scale of a real railway, especially since the weight will (approximately) reduce by the cube root of the scale factor and that the wheels and rails are made of different types of metal than on real railways. It is possible that there is nonetheless something similar occurring - but it would be irrational to assume this without testing it. If anybody has actually tested this rigorously, this would be very interesting indeed. Incidentally, I think that you may be mistaking my inquiries for hostility whereas they are actually grounded in a desire to understand whether or not there is sufficient empirical evidence to alter my existing understanding of the subject based on a combination of my own experiments and such information as I can piece together from general knowledge and such research as I have been able to carry out. Obviously, real scientific research on this topic will be superior to that, which is why I am particularly interested in the video to which you refer. Can you not give any clue at all as to what it was called or how I would know if I had found it from a search result? Likewise, if you have conducted experiments or have undertaken research which contradicts the understanding that I have so far arrived at by the process described, then the results of those experiments and the substance of that research might be a good reason for me to update my understanding of the mechanism involved. This is why I ask for details: I am very keen to ensure that my understanding of the subject be as correct and complete as possible. If you are not able to provide those details, then I will have to conclude that I do not have sufficient reason to revise my current understanding. This is not intended as a personal criticism of you; but you should also likewise not be hostile if I continue to state publicly my current understanding despite you believing something different to be true in circumstances where the evidence to which you refer is incomplete or inconclusive.

I have started a new topic as suggested here.

Discussion continued from this thread. Perhaps I misunderstood your post - my apologies. What did you intend to say that the black deposits were made of if not oxides of nickel and copper? Or did you mean that deposits are indeed oxides of nickel and copper? As to the video - there are a huge number of videos on YouTube, and many of those about model railway track cleaning, and it will be extremely hard to find the one that you are referring to without some clue as to how I can identify it. A video by a research chemist sounds much more useful than a general track cleaning video, but I will need some clue as to how to locate it. As to rails going rusty, i.e., ambient oxidation, real rails go rusty because real rails are made of steel and steel rusts at room temperature in the presence of water, which is commonly encountered outdoors. I am not sure whether or not any sort of ambient oxidation occurs with nickel silver; any reliable sources on this would be very interesting (and this would suggest even more of a need for regular cleaning/stay alives than dynamic oxidation only). I am still not sure why you say that micro-arcing does not result in oxidation, however - can you elaborate?

Indeed - real railway grade point position feedback requires monitoring the tiebar, and that is the ideal way of doing it, but that is usually not practical in a small scale. I use feedbacks on the mount itself, which will detect most problems, such as a failed or disconnected servo, mechanical stickage at the mount or an electronic error causing the command not to be sent in the first place. It will not detect a disconnexion between the motor/mount and the tiebar, a failure of the tiebar or disconnexion between point blades and tiebar. I note from iTrain 5's manunal that it does not have point position control built in in the way that TrainController does, so this may be less useful, although this can be customised, I think, from Actions (although I have not investigated this fully - Actions in iTrain are much less powerful than macros in TrainController as iTrain has no user modifiable variables). As to oxidation, it would be interesting to see the video to which you refer. (Rust is a form of oxidation, but not all oxidisation is rust: rust is specifically oxidisation of iron, and model rail track and wheels do not normally contain iron, but rather copper and nickel). What are the keywords with which one can find it? I am not entirely sure that I follow what you mean when you write of the black deposits being pitting - how can a deposit be a pit? Do you mean that this is the material that was once in the pit? It is not shiny and metallic, but black, so presumably the stuff that was in what is now the pit has been oxidised, so these are indeed oxide deposits. I believe that you are correct about using non-ionised cleaning fluids or else risking greater oxide deposits. I do not use alcohol or water for this reason (and yet still get the black deposits as discussed above). Somebody I know has recommended WD40 contact cleaner (not WD40 penetrating oil - the names are very confusing) for this, but I have not tested this myself. I tend to clean the rails dry so far, but might well try WD40 contact cleaner if necessary.

It is slightly more complex than that. TrainController Gold allows for two systems of point position feedback: (1) electronic only; and (2) physical. The electronic only system works by checking to ensure that the correct command has actually been sent out on the relevant data bus, but does not check whether the unit has responded to it. The physical system, which I use on my layout, uses sensors (in my case, micro-switches) to detect whether the point mechanism has actually moved. The former system is of course less effective than the latter, but will at least check that the correct command has got to the relevant data bus. The latter system requires considerably more work to implement, but is more effective and simulates real life modern signalling, in which point position feedback is definitely a thing, more accurately. As to micro-arcing - can I ask how you reach the conclusion that this does not cause oxidation and that running trains does not cause oxidation? It is difficult to find much documented empirical research on this topic: if you are aware of any, I should be interested to read it. My own experiments strongly suggests that running trains does cause oxidation: running a train up and down a clean piece of track for circa 2 minutes will result in black deposits on a previously clean white microfibre cloth that were not there at the beginning of the experiment and are not on adjoining rails that have not had a train run on them. Places where more significant arcing occurs, such as at a spot where a derailment and short circuit has recently happened, causes very large black deposits to build up to the extent that these are visible on the rail head.

A stay alive will not rescue a locomotive that has already stalled: it prevents the locomotives from stalling in the first place. As to wiring, a fault caused by bad wiring will generally render such a large section of track dead that a stay alive will not assist - fixing and preventing these faults is generally much easier to achieve than not only perfectly clean track and wheels but also perfectly flat track.

I am not sure that I follow what you mean by "does not affect the automation" here - if the train not being under automatic control as a result of being stalled is not something that you considers affects the automation, how are you using the word "affect"? If there is a risk of needing to push a train to start it from a stop, then this is a sufficient reason to use stay-alives, since having to do this totally breaks automation by the very fact that starting trains cannot be reliably automatic. Incidentally, most stalls will take place when starting or stopping a train, as this is when the train is running at low speed and is thus most prone to stalling. My own experiments show that N gauge locomotives, even ones with very good pickups such as the Dapol class 50 (Co-Co, all wheel bearing pickup) will stall regularly, even when new, on recently cleaned straight plain track if run at a sufficiently slow speed. Fitting a stay alive completely cures this. Likewise, in 00 gauge, even a tender locomotive with decent weight and multiple pickups (e.g. a Hornby King Arthur) will stall fairly regularly on straight plain track if run at a sufficiently slow speed. Turnouts will tend to increase stalling. If you have a setup in which you are able to get trains to run very slowly over turnouts reliably for a whole exhibition without any stalling at all then that is interesting - but I am not sure how you quantify speed here (1km/h actual or scale?), nor what sort of track that you are using and what you have to to do get it to the state that you describe as "good", and what that state is in physical terms. Incidentally, wiring should not make a difference to this unless it be done very badly.

I do not think that this is entirely correct; first of all, a stall will, of course, affect the automation, as the train cannot be controlled by the computer once stalled, so needs human intervention to move it again, so it is no longer automated. Furthermore, a stall will mean that the computer will lose track of where the train is until it reaches the next occupancy sensor, so can be a major problem if it stalls during a coupling or uncoupling operation. As to stay-alives, their importance may vary depending on the scale; certainly, in N gauge, they are indispensable, especially if you want trains to be able to run at very low speeds (e.g. to accelerate slowly from a stand or when shunting). 00/H0/EM/P4 is likely to require stay-alives for anything other than improbably perfect track cleaned very frequently. 0 is another matter - I do not have experience with this scale, so cannot comment with certainty, but it may still be a worthwhile thing to have if there are locomotives with few axles (e.g. an 0-6-0 steam engine with no tender). Rails and wheels will accumulate not just dirt but oxidation very quickly - the act of running trains will cause oxidation, as, since current is collected from round wheels, only a truly tiny part of metal is in contact with the track at any one time, which can cause micro-arcing, inducing oxidation. This is why real railways do not collect current from the running rails with wheels, but use flat shoegear. The Volk's Electric Railway in Brighton originally collected current from the running rails through the wheels but before long converted to third rail operation. It is thus not practical in many, and possibly most, mechanically to keep the wheels and track sufficiently clean at all times totally to prevent all stalling without stay-alives, at least if not using stainless steel track (and possibly also wheels) or long trains with inter-connected pickups. One very useful feature of Zimo decoders, incidentally, is the function that all of them have when connected to a stay alive to stop the train in a place where track power is available. Without this, even with a very high capacity stay alive, if the train were to stop as commanded at a point which happens to have an accumulation of dirt and/or oxides sufficient to insulate all of the wheels on one side from the track, the train would not be able to start again without human intervention. With the Zimo system, the train would automatically keep moving a few millimetres until it found a piece of track where current is available, and stop at that point to ensure that it is able to move off again under computer command when required to do so.

As to RailCom - Michael is correct that you do not need RailCom sensors everywhere as iTrain or TrainController will keep track of the location of trains once it knows their initial locations. If you want to use RailCom, deploy it in places where you are likely physically to put new powered vehicles onto the layout. There is not much use in having it in lines leading from a fiddle yard into the scenic section if you are planning to be fully automated, since the software will need to know where in the fiddle yard that the train is before it starts to move the train. On my layout, I put RailCom in the fiddle yard storage roads, but not in the scenic part of the layout. However, if you might want to put trains directly onto parts of the scenic part of the layout, put RailCom sensors on those parts of the layout, too. However, RailCom is not essential: if you do not have it, you will just have to tell the software manually what train that you have just put on the layout and in what direction that it is facing. Another thing to consider is direction sensing. RailCom direction sensing works well with TrainController (although this is not well documented; but I have worked out how to make this work) and I believe that it also works with iTrain, but I have not tested this myself. This is actually quite an important feature for automation, since, if you do not have direction sensing, if you place a locomotive onto the track, the computer will not know which way that it is facing and might send it in the wrong direction. Direction sensing is something of a hack, but it does work. However, there are two different ways of doing direction sensing: in the locomotive address or in the block address. For TrainController, you need to use direction sensing in the locomotive address. For iTrain, you need to use direction sensing in the block address. Only some RailCom feedback sensors are compatible with direction sensing. I do not have a comprehensive list, but I know that the popular Digikeijs DR5088RC is compatible with this, as this is what I use on my layout. This unit can be configured to provide direction sensing in either block or locomotive address. What this does is to add a number to either the block or locomotive address if the locomotive is facing backwards (4096 in the case of locomotives). This means that, if you are using the locomotive addressing system, you need to mark the locomotive as facing backwards if its address is >= 4096. Using the block address system is simpler, but make sure that all of your blocks are below the number that is added (I am not sure that it is 4096 for blocks - you would have to investigate this). No automation software so far as I know makes use of any RailCom feature other than address and direction detection. JMRI can access other RailCom data in its scripting language, however, although there are reports of this other information not being very reliable in any event. For automation, all that you really need from RailCom is the address and direction sensing in any event, and both of those are convenience features rather than necessity, although they do add a lot of convenience when adding locomotives to the layout. Another important thing to consider so far as hardware is concerned is your choice of layout control data bus. You will need a means of getting, at minimum, occupancy sensing data back from your occupancy sensors to the computer. The DCC bus is incapable of doing this, so you will need another data bus to do this. This bus must, in turn, be compatible with the software that you want to use. So, for example, the MERG CBUS is in many ways very good, but it is not compatible with either iTrain or TrainController, and therefore is not really usable for automation unless you want to use JMRI (and do a lot of bespoke coding - effectively writing most of the automation part of the software from scratch in a scripting language, which would be a major undertaking). An obvious choice is the LocoNet bus, which is what I have used for my layout. It has a nice easy cabling protocol (RJ12) and is widely compatible: the Digikeijs feedback units (that is, DR5088RC and DR4088LN) all use LocoNet, many command stations use LocoNet, both TrainController and iTrain are compatible with LocoNet and there are a number of LocoNet compatible modules for IO and controlling servos. You will also need to choose a command station that is compatible with your choice of bus. The Digikeijs DR5000 seems in some ways to be a good choice, but I have had trouble with it being overwhelmed with signals from lots of Digikeijs feedback units on startup and not reliably remembering which occupancy sections are occupied or not, leading to the software becoming confused and falling into error. I use a self-assembly kit command station from the cottage industry supplier Hans Deloof, which does not seem to have this problem, but you will need to know (or to learn) how to do basic electronics soldering to build these kits. I also use the Hans Deloof LocoServo and LocoIO cards to control points and signals, meaning that I can use the LocoNet bus for these tasks rather than relying on the congested and possibly noisy track feed DCC bus (a bad idea for all but the smallest of layouts) or having to wire in a third bus (a DCC accessory bus) just to control points and signals. In terms of occupancy detection, you need to think carefully how you are going to organise the detection sections and the boundaries between them. The automation software (both iTrain and TrainController) use dead reckoning: that is, they know how fast that each locomotive will travel for any given speed step (because you will have profiled the locomotives one by one so that the software can measure this precisely), and then calculate how long that the locomotive has been running at a given speed in order to calculate a stopping distance from the point when any given occupancy sensor is triggered. This means that the closer that you put the break between one occupancy sensor and another and the place where you are likely to want trains to stop, the more accurate that the stopping position will be, as there is less room for error. Do not forget that an occupancy detection section is not the same as a "block" (in TrainController language; I am not sure whether the same term is used in iTrain), and you can have multiple occupancy sensors per "block". iTrain has a system of combining these multiple sensors to increase the accuracy of its speed measurements and therefore its stopping points. How accurate that you need your stopping points to be depends on whether you need the automation to do any coupling/uncoupling or not. If not, either because you are running the sort of layout that simply does not involve any coupling/uncoupling (e.g. a 21st century era layout, set in a time in which uncoupling has become rare outside depots), or because you want your layout to be semi-automated so that all operations involving coupling/uncoupling are done manually (as is done, for example, on the McKinley Railway - search Youtube for some very interesting videos about that), then you do not need the highest of accuracy: so long as the trains stop somewhere behind the signals and somewhere within the confines of the platform, and in any event not fouling the next set of points, all is well. If you are coupling/uncoupling, however, much more accuracy is required. The software can do this, but care needs to be taken to ensure that the occupancy sensor track breaks are near the places where you need to couple/uncouple. You will also need a way of detecting when a locomotive enters an already occupied section if you want automated coupling: I do this by having a short lead-in section at the beginning of each section in which I want coupling to occur: see my video here on PeerTube for details. For coupling/uncoupling, you will also need to select a suitable type of uncoupler and find a way that this can be controlled automatically by the computer. I use Dapol Easifit couplers on my N gauge layout for locomotives and the ends of fixed rakes (i.e., the parts that need to be coupled/uncoupled in service). These are the N gauge equivalents of Kadee couplers. This is explained in more detail in the video, as is the means of uncoupling them, including servo driven uncouplers, mounts from which are available from Dingo Servo. For automation, do try to use as high a quality decoder as possible. High quality does not necessarily mean expensive; for non-sound decoders, at least, you will not normally need to spend much more than £20 per decoder (not including stay alive - on which see below) to get good quality: I favour Zimo decoders, which I get from YouChoos as these decoders have good motor control and can accommodate stay alives well, but other good brands include ESU and Lenz. For ESU, make sure to use the automated motor settings tuning on each locomotive; for Zimo, do tune the decoders manually as recommended in the manual. It is important to prevent stalling for automation, as this will completely break automation whenever it occurs. This is likely to require the extensive use of stay alives: see here for my video on PeerTube about stay alives and alternatives in the context of automation for a full explanation. One optional thing that you might want to consider for automation is point position feedback. TrainController has a built in system for monitoring this, detecting that the points have failed and routing trains accordingly if they have. I am not sure whether iTrain has the same thing, but it is worth considering. It does add quite a bit of extra work to do this, however. You will definitely need resistive wheelsets as mentioned. I have found recently that resistive paint from Uhlenbrock can be a quicker way of doing this than glueing surface mount resistors to axles. I had earlier tried a different type of resistive paint, Aquadag, but found this ineffective as the conductivity would fail when the paint dried, possibly due to cracking. With paint, however, you need to be careful not to apply too much so that the resistance gets too low, or else your axles will heat up and, in the worst case, melt your bogies/underframe. Check with a multimeter that the resistance on each axle is, at the absolute minimum, 1k ohms, and preferably around 10k ohms. Finally, I would suggest installing some emergency stop buttons along the layout so that you can quickly bring things to a halt and prevent damage if you should have a derailment.

If you are thinking of automation, you will definitely want to be planning your next layout to incorporate automation from the outset, as it is much, much easier to automate a layout that has been designed for automation from the outset than one that has not been so designed.

I have only just spotted this topic: but in principle, with a lot of user customisation, this should be possible with TrainController (i.e., to display on a full sized computer screen). It is probably also possible with JMRI, but would probably require a very large amount of scripting.

A close up of the activity lavatorial from to-day's mini-exhibition at the MRC: Copenhagen Fields (York Road station) by James Petts, on Flickr

That's quite the match!

Excellent! At this point, we get, "The Cunard liner Queen Elizabeth boat train to Southampton Docks will leave from platform 11..." Also, at this point, we get, "Here is a special announcement. The steamship Victoria Castle boat train has been delayed and is now expected to arrive at 12.55." Slightly later, at this point, we get, "Steamship Victoria Castle boat train is now approaching platform 11." Here, we get, "...west of England train will leave from platform 10, calling at Andover Junction, Salisbury, Templecombe, Sherbourne, Yeovil Junction, Exeter Central, Exeter St. David's, ???, ???, North Taunton, Okehampton, Bridstow, Lidford, Brentall, Tavistock, Alston, St. Budoe, Devenport, Plymouth, Newton St. ???, Crediton, Copplestone, ???, Lapford, ???, ????, ???., Barnstaple Junction, Barnstaple Town, ????, Braunton..." Here, we have, "...3.20 to Bournemouth West and Weymouth will leave from platform 10. Passengers for Bournemouth West, travel in the rear portion. First and second class refreshments car facilities are available on this train." At this point, we get, "Her Majesty's Ship Oxfordshire's boat train is now approaching platform 11..." Here, we get, "Here is a special announcement. Will Mrs. Perry, who has lost her small son, Matthew, please go to the stationmaster's office, which is alongside platform 16. Calling Mrs. Perry, would you please go to the stationmaster's office, which is alongside platform 16."

On announcements: this video has a wonderful snippet of an announcement in London Waterloo in 1944 from which we can have some glimpse of how announcements worked in such distant times: "...the 10.24 for Camberly and Reading will leave from platform 21, calling at Richmond, Twickenham, Whitton..."

The announcer used inside trains on some lines in the early 2000s was nicknamed "Sonia" because the intonation pattern was very irritating. This was replaced after a few years with a different style, which is much less annoying.

Excellent - thank you for the link.

What I am doing in TrainController does not reach the level of accuracy of representation of an IECC as your work; but I use the customisability of the TrainController interface to make it look as much like an IECC as I can: TrainController signalling display by James Petts, on Flickr I should note that I have made some modifications since I posted the above. I have been able to get it to work such that I can have the trains running fully automatically with "ARS" enabled, and that they wait for routes to be set manually (click for the entry and exit of routes: like you, I could not get it to work by clicking on the signals, so I have to use the grey arrow heads) with it disabled by using block locking logic as described in the TrainController manual. Signal aspect logic is relatively straightforward using customisable trigger logic for signals. I have managed to work out how to set up approach locking with different timeouts by pressing "c" and then clicking on the entry symbol by running a macro (although unfortunately I cannot replicate the flashing red aspect shown on the signalling display in this case). I have replicated point failure indications by installing position detection microswitches on all of my turnouts and connecting these to the TrainController point position indication system, then setting a macro to run giving the IECC warning sound downloaded from the SimSig website and displaying a message. I have not yet worked out how to make overlaps work; I suspect that this may not be possible. I am currently working out how best to make work virtual extensions to the layout, which track a virtual version of trains on the layout before they enter and after they leave in each direction. I had used macros that store the state of virtual trains as they progress in early testing last year, but found that these stop running and do not save their state or resume running when quitting TrainController or even just stopping the layout (e.g. in the event of a derailment), so this system is very fragile.