KingEdwardII

One thing I discovered about DR5000 LAN (Ethernet) support in RocRail & JMRI is that these two control software packages have different default configurations of the DR5000 and as a result, it is not possible to use them together, nor to flip between them on the computer. For some reason, RocRail requires the DR5000 LocoNet to be configured as 'LocoNet over TCP/IP Binary" while JMRI requires the DR5000 configured to use "LocoNet over TCP/IP LBServer". These are not compatible and switching between them implies reconfiguring the DR5000 - a real pain. So far, I have got both RocRail and JMRI to work with my DR5000 over Ethernet, but only at the cost of reconfiguring the DR5000. I'm not happy with this and I'm puzzled as to why the configuration needs to be different. I found this page in the RocRail documentation relating to LocoNet: https://wiki.rocrail.net/doku.php?id=lbserver-en This implies that RocRail can support the "LocoNet over TCP/IP LBServer" configuration on the command station - ironically, that page seems to imply that the command station involved in the configuration shown in the menu is actually a DR5000! So, I shall give this alternative configuration of RocRail a trial and see if it works - if it works, then I shall use it going forward. Note also that this page implies that the LBServer configuration is supposed to be capable of handling multiple clients across the network - desirable from my perspective. One thing I want is to have the main control of the layout from my Raspberry Pi400, which is permanently in the railway room, but to do development work on new versions of panels, etc, from my MacBook Pro which moves around with me. This will be much easier if I can run the control software on both at the same time...

Nigel, Thanks for your comments about JMRI. I have not yet got my head around the Panel Editor, although it may be more suitable for some of my purposes. However, the Panel Editor definitely has a steeper learning curve which is why I started with the Layout Editor. My initial goal is to have an on-screen system for controlling turnouts, followed by the idea of having a set of routes that can be selected and which will enable the setting of a group of turnouts in one go. Having fully powered all my turnouts, I rapidly found that handheld controllers are not a great way of operating turnouts and that some form of touchscreen operation is likely to be far better. The idea of an old-style physical control panel with buttons/switches/lights does not appeal and neither am I hankering after reproducing the look and feel of a signalbox lever frame. I'll seek out your tutorials and hope to learn a lot more about JMRI Panels. Yours, Mike. PS Any idea why JMRI does not implement 3-way turnouts as a first-class concept? This seemed odd to me given that JMRI has support for crossovers as a concept. I only have one 3-way on my layout, but it looks as if I'll have to write a script of some kind to control the two point motors involved.

Ian, Yes, I am contemplating joining MERG. However, getting my head around RocRail, JMRI and the potential of iTrain is keeping me busy for the present. Plus building all the other aspects of my layout, of course Yours, Mike.

Yes, that is one reason why I am an enthusiast for open source software - the important thing is not that it is free, but that anyone has the ability to take the existing work and alter or extend as they see fit. And that their modifications are available to all in return. I like the analogy you make to scratchbuilding - but expecting everything to be scratchbuilt is a hard demand on many modellers and many make the compromise to use RTR models, or to take RTR models and tweak them (weathering, cut-and-shut modifications, etc), or to kitbuild, again with modifications. I make the same analogy with software - it is often far too much to expect the average modeller to write all their own code. Some folks are happy with the RTR commercial software like iTrain, whereas those who are prepared to tinker can choose packages like JMRI knowing that they have a good foundation and where it does not meet their needs, they can extend or tweak as needed. Even good commercial software is wise to provide extension points that allow purchasers to add or modify functionality - this was the foundation for success for spreadsheets, for example, with their macro and scripting languages. RocRail unfortunately falls down a crack here - not fully commercial but not open source and so not providing the natural approach of tweak and extend available to open source projects. This rears its head painfully in the RocRail documentation which is lamentable at best.

As well as RocRail, I have been working on a JMRI implementation for my layout - slower going as it turned out. Here is my first attempt at a Layout Panel, kind of equivalent to the RocRail control panel in my earlier posting: Here, the circles represent turnouts of one kind or another - with Green representing turnouts in the "straight" position and Red representing turnouts in the "thrown" position. JMRI differs from RocRail in a number of respects including: It models crossovers directly and covers my case where I have a single DCC turnout address for both point motors Clicking in the circles changes the related turnout position It does not model 3-way points at all, requiring you to use a pair of RH & LH points instead - this is disappointing simply because not all 4 combinations of point positions are allowed in practice and I shall have to use some form of. script to implement this limitation instead JMRI models both single slip and double slip diamond crossings. However, editing the on-screen icon is tricky and unreliable, hence the weird shape on my double slip in the bottom centre of the panel In some respects, the schematic approach taken by RocRail is easier to get to grips with although the final diagram is more faithful to the layout in JMRI. JMRI also stores data about the "physical" turnouts separate from that of the representations in the panel. This leads to more work since you have to define things in two places. This separation may be better in the long run, but it makes starting a slower process.

Keeps me amused while I do unarmed combat with JMRI...

USB 3.0 Flash drive vs USB 3.0 SSD is not a straightforward choice and it took me quite a while to select the MyMemory flash drive that I eventually purchased. The SSDs are undoubtedly faster, but they are much bulkier and more expensive, also requiring an adapter cable of some kind. I have an SSD but I have now used this as a network storage device (NAS) attached to my main broadband router, which serves all the devices in my home for backup and for file sharing. So I use the Flash drive on the Pi400 as a compromise between small size, cost and speed - way faster than the original SD card but slower and cheaper than an SSD would be. I selected the particular Flash drive based on it having relatively high speeds. As for WiFi, I am still experimenting as to the best configuration. I could use the Pi400 as an access point as you suggest, but I'm starting by using the WiFi on my main router. The main router gives a very strong WiFi signal in the railway room and the handheld devices I'm using are multi-purpose and need good internet access as well as connectivity to the Pi400 for controlling trains. If I start to use dedicated handheld devices as throttles, I may change this setup. The DR5000 command station is also Ethernet connected to the main router - its WiFi has limitations on how it can be used and since the DR5000 is static, running an Ethernet cable to it is simple. One choice I have made is to use 5GHz WiFi - faster, and with much less interference than the 2.4GHz.

Philip, If you go down the XTrackCad route that Chris used above, you can do all the hard work on the computer and simply print out the result at 1:1 scale. No need for tricky measurements and the track can all be spot on by sticking the printouts down on your baseboard and laying the track on top. It can even help you get the baseboard cuts right, especially the curved ones. That's the approach I take with my layout - and the only tricky thing is to make sure the printout sheets are all laid square and true. XTrackCad provides registration marks and rulers on the printouts to help with that - just add some care and patience! Yours, Mike.

Adding the Touchscreen My aim is to display a control panel on a screen attached to the Pi400 and to control aspects of the layout from that screen using touch - clicking directly on representations of points, etc. So I need a suitable touchscreen monitor attached to the Pi400. After some research I decided to opt for the Iiyama Prolite T2252MSC monitor. This is a 22 inch LCD monitor with HD resolution (1920 x 1080). It has 10 point capacitative touch capabilities and, most importantly, can mimic a mouse on the Linux operating system as used on the Pi400. The video output to the monitor is via a standard HDMI cable from the Pi400 - and can include sound since the montor has built-in speakers, should the need arise. The touch input from the monitor is supplied via a USB cable - which I attached via the USB 2.0 port vacated by the Pi mouse. So, I attached the monitor and now have a complete system ready to run model railway control software... Note that the USB Flash drive is so compact that you can't see it attached at the rear of the Pi400 keyboard in this picture... Yours, Mike.

Another change I made was to replace the wired Raspberry Pi mouse that arrived in the bundle with the Pi400 with a wireless Bluetooth mouse. In the railway room, the fewer the wires the better. I hope to use the mouse as little as possible, by using a touch screen monitor. However, I can see cases where a mouse is likely to be easier to use. In that case, being able to use the mouse anywhere, without worrying about a cable, is a better approach. Fortunately I already had a Bluetooth mouse lying idle, so it got "repurposed"

Install large USB drive This step slowed me up considerably in the end - since I ordered a 256Gb Flash drive from MyMemory which got caught up in the frenzy of deliveries ahead of Christmas and I only received it on Jan 2nd. The reason for needing a large USB drive is simple - the supplied Raspbian SD card is relatively small (16Gb) and is impractical for a system where you intend to install and run a lot of complex software. Initially I considered adding a 2.5inch SSD, but one of my sons showed me his USB flash drive which was physically tiny but with huge storage. I had to admit that this was a much neater solution. So I opted for this 256Gb Flash drive from MyMemory: This slots into one of the USB 3.0 slots in the Pi400 and is barely visible. I then decided to make the Flash drive the boot drive and to remove the Raspbian SD card that was supplied with the Pi400. First, the Flash drive is considerably faster than the SD card. Secondly, it is just much simpler having one drive than two. So I cloned the Raspbian installation from the SD card to the Flash drive, removed the SD card to a drawer for safe keeping and have used the Flash drive ever since. Once the operating system was installed on the Flash drive, I found that I had 207Gb of space free - that should be plenty unless I start downloading many hours of video onto the Pi400. Yours, Mike.

Further steps... configure networking install large USB drive attach touch screen monitor Configure Networking The Pi400 has an Ethernet port and also WiFi. Ethernet supports up to 1Gb LAN speeds. WiFi supports both 2.4GHz and 5GHz bands. Enabling Ethernet is trivially easy - simply plug in a Cat 5e or Cat 6 cable with an RJ45 connector which connects to your router. To check the speed of the connection, use ethtool eth0 This shows a 1Gb LAN speed for my connection. Enabling the WiFI is straightforward - you need to know the SSID and security credentials of the Router, separately for the 2.4Ghz and 5Ghz bands. To check the speed of teh connction use wavemon I encountered a problem at this point - I connected the Pi400 over both 2.4GHz and 5GHz bands, but the connection speeds were very disappointing, especially for the 5GHz band. After some discussion on the Raspberry Pi forums, it turned out that there was an issue with the WiFi drivers and I had to download and install a new driver file: brcmfmac43456-sdio.clm_blob Once this driver was installed, WiFi speeds were acceptable although not as fast as some of my other devices using the same networks. Mike.

Let me ask a couple of questions relating to the Patriot and the shorting. What do you mean when you say "Points are Peco modified"? Which modifications have you carried out? In particular, have you cut the connections to the switch blades? Second, is it clear that the short occurs with the loco at a particular place on the point? Is it typically the same place? I am trying to establish what exactly is being shorted by the loco.

I controlled a train and switched some points on my layout from a computer for the first time yesterday. I know this is routine for many folk who post to these forums, but I still think it is a significant milestone for anyone building a model railway, since it is far from trivial to enable this. I am still experimenting, but my goals are clear: control the physical aspects of the layout from a large computer touch screen (points, signals, lights) instead of a physical control panel provide (semi) automation so that I can run multiple trains simultaneously on the layout control one or more trains from a wireless handheld Currently I am using a Digikeijs DR5000 as the command station, LAN (Ethernet) connected, with DR4018 accessory decoders driving MTB MP1 point motors. The computer is a Raspberry Pi 400 with a 22inch Iiyama touch screen, connected either via Ethernet or via WiFi, although I can run the same software on my MacBookPro. I am experimenting with both RocRail and JMRI. Mainly because they are a) free. b) support the computing platforms I use. (I don't have a Windows machine, although I do run Windows programs on my MacBook in VMs). RocRail has enabled me to produce a control panel for the layout and control the points from the touch screen, driving the DR5000 via the Loconet protocol over the LAN. It is also able to provide on-screen windows for driving trains. I attach my current RocRail control panel - a first attempt and probably containing mistakes aplenty, but you have to start somewhere! The yellow marked rectangles show the status of each point and you simply click on the alternative rectangle for a given point to throw the point. With crossovers, a single click moves both points. JMRI is harder work for creating the control panel, but I am an expert Java programmer and I suspect I shall use JMRI a lot more in the future simply because it is open source written in Java and so straightforward for me to tweak and extend as needed. I am interested to hear more of other folks' experiences in controlling their model railways from computers, especially with regard to the software and its configuration. I've read material about some of the commercial programs like iTrain, which certainly seem much more polished than RocRail and JMRI, but which have very healthy costs associated with them. Yours, Mike.

That bottom line in the coal depot involves some entertaining shunting operations! Potentially 4 reversals to get a truck in or out of there. I'm left scratching my head as to why it was designed like that. Yours, Mike.

"The floor ain't level" certainly occurred to me - nice shiny new set of baseboards constructed, with legs carefully constructed all to have the same length to get a nice level surface. Lay the track carefully. First time I ran a test goods train with lovely modern wheelsets - all went very well until I uncoupled the trucks. Then I discovered the downside of low friction metal wheels and watched as the trucks disappeared off into the buffers at the end of the siding. Much cursing and measuring with my long spirit level revealed that the builders who created our lovely attic bedroom conversion had thoughtfully put a slope of over 1 inch across the room. My trains were only too happy to show me what fun they could have with that. So I had yet more entertainment adding shims to the baseboard legs... As for "the room ain't square", I already knew about that before I started and made allowances in a few places.

Yes, Covid-19 has a few small advantages... ...another one is extra cash available for modelling since I can't spend it on much else Mike.

Keith, The present-day Richmond probably counts as Minories - the current arrangement is that the terminus District / Overground lines are entirely separate from the SWT through lines - there is no connection between them whatever. The present-day operations are a bit monotonous - 4 TfL trains in/out per hour plus up to 10 District line trains - busy but not much variation. The older trackplan in the map above is a very different story since all the tracks were connected and there were goods facilities on both the down & up sides of the station - much more variety possible, but it's a lot larger than the Minories plan. Yours, Mike.

Equally importantly - do all your measuring and then find that: - the railway room ain't square - the floor ain't level - you just covered up the power socket you need to use... Yours, Mike.

Attached is my OO layout plan - fitted into an Attic bedroom left free when the children moved out to their own homes. The room is an "L" shape and I have a space of 3.6 x 4.0 metre to use. The left hand and top of the diagram are under sloping ceilings so that the height of the baseboards is deliberately low at around 830mm and I operate sitting down in a chair on castors that I propel around the central well. I have a worktable that can be slid underneath the baseboards in one of a couple of locations. I decided on a roundy-roundy design with one station on the right hand side (platforms etc. not drawn in) and then a branch line with a terminus station on the left. The door is in the middle of the bottom of the diagram and I have a removable section / duckunder to get into the central well. Lots of track and not so much space for scenery! Mike.

Yes, pretty well the first thing I did with my PA2 system was to replace the short handset cable with something longer. I used a standard Ethernet Cat5e patch cable and it has worked well ever since. Since I work in the computer field, I didn't even have to buy the cable since I have a whole heap of them stored in a box - but they are cheap to buy in whatever length you need. Yours, Mike.

Sure, The discussion was about Ealing Broadway station in West London, which has a number of elements including a terminus of the District Line (one of the London Underground lines). A general introduction to Ealing Broadway station is available on Wikipedia here: https://en.wikipedia.org/wiki/Ealing_Broadway_station I can't promise that all the details are accurate on that page, but it should give you a general idea. The station has terminus facilities for both District Line and Central Line underground trains and through facilities for the Great Western main line running west from Paddington. There are other stations in the London suburbs with a similar flavour - terminus facilities for London local trains and through lines for trains destined for further afield. I think we started the discussion with Richmond station https://en.wikipedia.org/wiki/Richmond_station_(London) In the current era, these stations are extremely busy, not only serving their local communities, but also acting as interchange stations. I used to use Richmond as an interchange on a regular journey from Winchester to Gunnersbury via Clapham Junction. Yours, Mike.

Phil, I'm curious to see "Ashford Cables" on the drums rather than the more local "Aberdare Cables" - I was born a couple of miles away from their works. Yours, Mike.

Runners & Riders. So what should we cover in the set of Buses? Here is my starting list - I am sure that folks here can suggest others. I'm not suggesting that we cover all of these in any detail, but I'd like not to miss anything at the start. S88 / S88-N LocoNet (B and T variants) NMRA LCC BiDiB SSB B-Bus R-Bus RS-Bus XpressNet (plus X-Bus) CAN Bus Layout Control Bus That's already quite a list, but some of them are very specialized I think, at least with respect to Automation. Yours, Mike.

You might look at the Dremel 225 flexible shaft or equivalent, which has a much smaller diameter than the main Dremel multitool body: https://www.dremeleurope.com/general/en/dremel®flexibleshaft-223-ocs-p/ I use that for more hard-to-reach places. There are also cutting disks up to 38mm available for the Dremel, which give quite a deep cut. I suppose the other piece of kit I'd consider using if I have a need for deeper cuts is a jigsaw. I normally use one of those for slicing through plywood, but there are metal cutting blades available for jigsaws and I suspect it is going to be easier to keep a jigsaw in line with the desired cut than something like the Nanoblade, although I have no experience using a Nanoblade. Yours, Mike.