jamespetts

Njee20 - I can give a number of examples from my own layout project, still in progress, of what I can do with macros and variables. I have my layout set up to have a virtual extension to the layout that is entirely computer simulated. A series of macros are set up to progress trains along the virtual section of my layout. Once these trains reach the boundary between that and the real section, they trigger an actual train to come from the fiddle yard and take up where the virtual train leaves off. Announcements are played automatically if a train is running late at two separate timing points on the virtual layout, and further announcements are played when the train is in the physical part of the layout and just approaching the station. The announcement depends on the calling pattern of the train, its intended platform (of which there are a possible five) and whether it has been delayed. I also plan to have platform change announcements if a train is routed away from its booked platform, but have not implemented this yet. I plan to have a full week's timetable, so I could not sensibly program this individually one train at a time, so I have to use macros and announcement recordings that can be re-used for lots of different trains just by inserting different data. This is where variables come in. Variables are the fundamental currency of any sort of computer programming. Using variables, one can achieve far more than will ever be possible with a simple set of commands. To give a brief outline of how my system works: the timetable will call a macro for each train working (I have not got the timetable itself set up yet as I only have a few test workings: these are triggered by buttons). The initial macro is unique for each working, but is very short. What this initial macro does is set a number of private variables (that is, variables whose values are only visible to the current macro and other macros called by the current macro), including one for the train reporting number, another for the calling pattern (used for announcements), another for the booked platform, another for the "schedule" (i.e., pattern of train movements on the actual layout) that will be called when the working gets to the boundary with the real layout), and some more for the times at which timing points should be passed. Once these variables are set, this macro then calls another, general macro. This is a much longer and more complex macro, but it is not specific to each working: instead, there is one of these for each direction and line in question. This macro, in turn, sets some further variables, including the direction and the timing pattern (how long that the train should spend in each block in the virtual part of the layout: a task which I have yet to do is have this be modified depending on the signal states and possibly whether the train is trying to make up time), and then calls a delay/cancellation generator, which will (if I have enabled delays/cancellations using a button that I have created on the fiddle yard switch board) possibly make the service late by a certain amount, record the amount of delay in a private variable, and play an announcement. The announcement, in turn, is a sound file, the filename of which is determined by a number of variables (variables can be used as wildcards in specifying filenames) for the train's calling pattern and how late that it is, as well as its booked platform (e.g. "This is an announcement for passengers waiting on platform 5; we regret to announce that the service to Banbury has been delayed by approximately 10 minutes..."). If no delay is generated, the delay counter is set to zero. After generating the announcement, the delay macro does not terminate until the delay period has passed, and the main macro is set to wait for the delay macro to terminate before continuing. When the main macro does continue, it will set variables for what section that the train should enter next, and then call a further macro (which is even more general than the previous one, applying to all virtual train movements, not just on a specific line), and this sub-macro will actually trigger the train movements in the virtual sections with the appropriate timing delays generated by the timing data mentioned earlier, stored in variables. At certain points, timing point macros are called. This checks whether the train is within 2 minutes either way of the booked time for the timing point in question (stored, we will recall, in variables), and, if not, will display a message. If the train is late at the timing point by more than 2 minutes and the delay variable is zero (i.e., if the delay has first arisen on the virtual part of the layout), an announcement will be triggered announcing that the train is running late (in the same style as the example given previously). If, however, the delay variable is a non-zero value, indicating that there has already been a delay, the announcement triggered is different (e.g. "This is an announcement for passengers on platform 5 awaiting the delayed arrival from Banbury - this train is now passing Wolvercote Junction and is expected to arrive in approximately 4 minutes"). Once the virtual train reaches the boundary between the real and virtual sections of the layout, the schedule held in the private variable for this purpose and seeded by the very first macro to be called is then triggered, and some of the essential data contained in the variables of the virtual train (e.g. reporting number, calling pattern, booked platform) are transferred to the actual train on the layout. Then, when the actual train approaches the station, it triggers an action marker, in turn triggering an announcement that the train is approaching, and, again, the filename of the file containing the announcement audio is constructed from some base text, plus the variables for the booked platform, calling number and whether there is a delay or not. This is just one example of the power of variables. Once one knows how to use them, one would never want to go back to not having them available. It really makes a fundamental difference to what can be achieved.

When I last checked, iTrain did not have variables or macros, reducing the programming/customisation options considerably.

The week-end again? Gosh, it only seems like a week since the last one.

Yes, native is certainly nicer to work with than via a VM. I looked into iTrain and decided that it did not have the functionality that I needed (especially relating to variables/macros), so had to go for TrainController in a VM in the end.

I run TrainController on a Linux computer using VirtualBox with a Windows 10 guest.

I approve of square, especially with coal rails. That does look good.

High melt solder as in brass? That is not too bad. I had a go at a brass kit last year, albeit of a carriage. It was not as difficult as some suggest, and there is no possibility of melting the brass with the soldering iron. It is a different technique, so you might take a little time to get used to it, but I am sure that you will be fine. The difficult bit with brass kits is always forming flat brass into complex shapes with things other than clear angles, and fitting delicate parts into other delicate parts in precise ways, not the actual soldering. Just make sure to clean the brass carefully first and use plenty of !flux and you should be fine, especially if you can solder whitemetal as well as the pictures suggest.

Looking impressive!

Those stream photographs are a delight. It is a pity that one cannot model gnats and butterflies in 1:76 scale.

Interesting! I shall look forward to seeing this progress.

Goodness me, that is all a bit unfortunate. I hope that house repairs were successful and that self repairs were unnecessary.

Gosh, I hope that all is well?

DMU delights! It is splendid to see these old units in model form that I remember well from when I was a nipper. If you are interested, incidentally, I have a working timetable for this region of BR in the 1989-1990 period in case you want any information on operations in this period? I am working on a layout not too dissimilar in concept to this but in N gauge (but perhaps slightly farther out of London than yours is set - I infer that yours is intended to be on the Paddington to Reading stretch?). In any event, I shall look forward to any progress: this layout is a delight to watch being built.

That is a seriously impressive layout.

Also, I believe that we need a !bunnies command for this.

That is an eggcelent cargo.

In the circumstances, October is not too bad. I shall look forward to these 2Fs: they will go nicely with my cross country trains from the late 1980s.

I entirely agree.

Having the trains running now must be extremely satisfying!

I believe that the issue with the DR5088RC is that if you have anything connected to your layout's ground (either through the LocoNet bus or - possibly - the track feed), there might be a voltage potential between that and the USB cable's ground (more likely if you are connecting to a laptop which could easily have a floating ground, especially if its external PSU is not ideal), and a substantial current potentially at many tens of volts might flow in lots of places where it should not flow. Thus, it is really very important to disconnect or power off everything connected to the DR5088RC when connecting the USB cable to a computer. The DR5000 command station does not have this issue; presumably, the USB input is opto-isolated, unlike the DR5088RC.

I have fond memories of seeing these when I was a nipper and sometimes even travelling on them, a particular delight finding some corridor mk. 1 stock to ride on from Reading to Oxford and/or back. I am currently building a substantial layout in N gauge set in 1989 which will represent the latter days of the class 50s in the Thames valley.

What you need to do is to apply the transfers first and then apply (by airbrush or aerosol) a coat or two of matte varnish over the whole of the part of the model that is of the same colour as and contiguous with the polished area. Some transfers may additionally benefit from gloss varnish being applied to the area in question before the application of the transfers in order to reduce the possibility of the backing paper showing. I find that this is generally not necessary with Railtec or Fox transfers, but some other transfers that use thicker paper will show the backing more readily without a gloss varnish. Such a varnish should be left to dry before applying the transfers.

I use Brasso and an extra fine cotton bud. This will leave a polished area that will need varnishing. I use an aerosol for varnishing, but a bench vent and respirator mask are required for this unless doing this outdoors.

I had a go at making a video yesterday evening showing the technique that I use to rename N gauge models using etched plates: see here. Note that the video is hosted on PeerTube, which, unlike YouTube, is a fully decentralised system which cannot readily be controlled by any one corporation or government. I recommend that others use PeerTube instead of YouTube in the future. All of my railway modelling video content will be posted exclusively on PeerTube, and all will be available under Creative Commons licences.

Can I ask what version that you have? Also, are you referring to the "train identification" or the "contact indicator" dialogue boxes?