KingEdwardII

John, I fix the printouts to the baseboard directly and do a "first fix" of the track directly on that - making all the holes for point motors, droppers, etc and getting the alignments and track cutting done. Then lay and pin the track and fit the point motors. I then run trains, switch turnouts, etc, to check that all is good. Later I go back, lift the track in sections and put in the underlay (I use 2mm x 50mm width closed-cell foam tape), then relay it all ready for ballasting. Mike

Indeed - and what matters is not whether Peco produce accurate drawings of their turnouts, but that these software packages have accurate representations of the turnouts built-in, to enable accurate planning of any particular layout arrangement. And they do - and not only Peco, if you prefer products from other manufacturers. I plan out my layout with these tools (XTrackCad is my particular poison...) and get it all carefully laid out in cyberspace before transferring the plan to the baseboards. I use 1:1 printouts of the plan pinned accurately to the baseboards to achieve this, although you could take the alternative approach of reading out the positions of each item of track and marking them on the baseboards. Either way you get accuracy in laying out the track, knowing that it is all going to work. Yours, Mike.

Nigel, Thanks for the tip about the volume control for speed. I am still experimenting with speed - the default is for increments of 4, which is OK for 6023, but is actually too large for 7224 2-8-2T which has wonderfully low gearing. As for Function keys - at present they are of no use to me. I have fitted decoders with plenty of functions available, but at the moment they are not used for anything - another "todo" for the future. I don't have sound fitted at all. I noted the capability to set up the F keys in the roster - a tool for the future, I think. Mike.

So, moving from turnouts to trains - time to control locos via computer! First, JMRI offers on-screen throttle windows. Each window can control 1 loco and it is possible to have multiple locos each controlled via a separate window: The number of Function keys can be adjusted as needed. Forward/reverse and speed is controlled in the pane on the left. Simple and straightforward, but tied to the computer screen. JMRI also provides a WiThrottle server which supports handheld devices as throttles. I am using an Android smartphone (Samsung Galaxy Note) and choose Engine Driver as a throttle app to run there. Engine Driver searches for WiThrottle servers automatically (I have 2 - one on Pi400, one on MacBook): Connect to one server and select a loco: Drive! So - I can now control the layout (turnouts etc) and drive trains via computer - using wireless handheld to control the locos for maximum freedom.

I don't think that you have to go as far as adding the extra braces right along the whole of the building, although there is nothing wrong in that, just more work. Simply adding the braces to join up the points where the diagonal beams meet the cross beams (making 2 more triangles...) would be enough, I think - and it would make it look like the photo you posted. I note in that photo they were clever enough to use the wall plate beam on the far side to avoid the need for any extra timber there, but your building seems somewhat wider, so you won't be able to do that. Mike.

So I confirmed that it is possible to use both RocRail and JMRI on multiple computers simultaneously and to intermix using them both on any machine. The panels of all instances of both programs update whenever a turnout is switched using just one of the instances, for example. I am also pleased with the investment in the Iiyama touch screen attached to the Pi400 - I can change a turnout simply by pointing at the appropriate location on the screen. The longer term goal is to operate the layout just using the screen with no need for either the keyboard or the mouse. I note that the touchscreen is by far the most expensive item associated with the Pi400, which is otherwise a very cost effective way of getting computer control. At 22inches, it is perhaps comparable in size with conventional control panels, with the advantage of being flexible and reconfigurable. One other thing to note is that the Pi400 actually supports 2 HDMI monitors so that I could envisage separate monitors for different parts of the layout - perhaps one for the main through station and another for the branch terminus. I have the DR5000 controller connected to the house router via a wired Ethernet connection - this is required since the DR5000 WiFi is not configured to connect to a WiFi router. However, both the Pi400 and the MacBook are connected over 5MHz WiFi - which is great since it means that the computers are not constrained by Ethernet cables and can be placed anywhere convenient. The next stage is to investigate operating trains from a handheld - I have installed a couple of apps onto my smartphone and I'll try out a couple of alternative options - one with the app talking directly to the DR5000 via its WiFi, the other with the app talking to JMRI on the Pi400. I know that it is not possible to do these at the same time with one smartphone, since the DR5000 WiFi is completely separate from the house WiFi system and it is necessary to manually switch the phone between the two. Mike.

Great grandmother's second cousin... Mike

Nigel, That is very generous of you. I am not quite ready yet to delve into the JMRI Panel Editor as there are a few other things I need to get done before I spend time on that. I hope that I shall be able to call on your assistance at a later date. Many thanks, Mike.

OK, I finally got round to checking whether RocRail can connect to the DR5000 using the "LocoNet over TCP/IP LBServer" configuration as is used by JMRI. The answer is a resounding YES. So count me one happy camper - it is possible use both RocRail and JMRI on the connected computers without needing to mess with the configuration of the DR5000 system. I can further confirm that it is possible to run both RocRail and JMRI simultaneously connected to a single DR5000 using this configuration. It is possible to change a turnout using a RocRail panel and see the result reflected on the JMRI panel and vice-versa. Clearly, it is LocoNet response messages from the DR5000 that are being used to drive the changes in the panels, which is as it should be. I have not yet tried out my goal of running the software simultaneously on multiple computers, but I have every expectation that this is going to work. Mike.

Triangles. More Triangles. Engineers love triangles. So I suggest option B with the addition of 2 cross-braces parallel with the tracks - to make more triangles. I note that your photo of an original above has the 4 triangles arrangement... Yours, Mike.

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.