How big a step to take with Z21 and iTrain, now or later?

[ITG]

Bear with me please, as I perhaps need to outline where I am now, and where I hope to get to. What I’m hoping for on this forum is input which may help me weigh up the pros and cons of when to do what.

 

I’m a DCC modeller, of about 3 years experience having learnt a lot in these few years. I’ve discovered that one of my favourite aspects of this hobby is  electronics and gadgets, as well as both train watching and shunting.

I currently have an (overcrowded!) 00 layout of approx 3.5m x 2m of a twin track circuit, with a reverse loop, storage loops and a high level branch. Locos are controlled by GM Prodigy Advance2, and points controlled by a DCC Concepts Alpha Switch D mimic panel. The latter was introduced because I found switching between loco and accessory functions on the Prodigy handheld control unit annoying. I also have Heathcote servo uncoupling ramps (for tension lock couplings) on a separate 12v DC circuit, controlled by push buttons on my panel.  I’ve a mix of ‘sensor’ gadgets, such as Heathcote IRDOT, DCC Concepts Legacy Sensors and a couple of car reversing cameras and screens. All these are really used to identify occupancy of hidden loops or tracks.

Going forward, I will be fortunate to acquire a new, additional railway space, in an inherited second home. Who knows if the two premises will be reduced to one in future? This new space is as yet not really defined as there will be some building work undertaken, which may result in this room being a similar size to the current one, or it may be an oversize single garage.

 

So, the real question is - at what point do I begin this journey towards at least part automation? The current layout is not wired in blocks and would be tricky to adapt for access reasons. But I could acquire the Z21 (I think that’s what I’ve identified as my preferred option) now to replace the Prodigy, but what benefit in experience terms would I gain in the use of Z21 and iTrain with the limitations of the current layout? If I went this route, the Z21 equipment would/could then be swapped to the new layout when ready to do so,

Or should I wait until the new layout before taking this first step, on the basis that without block sections, I wouldn’t gain much experience or operational benefit on the current layout?

 

I have begun viewing the excellent YouTube videos on iTrain so am learning anyway but of course without the new equipment and software, it is theory only.

So I guess the end destination is (hopefully) fairly clear, but it is how I get there, and at what pace by which route? Any comments most welcome.

thanks

Ian

[WIMorrison]

Ian

 

you are certainly heading the right way with a Z21 as that interfaces very reliably with ITrain.

 

I agree that you will not gain automation unless you create track feedbacks that provide communication back to ITrain which the IRDots and DCC Concepts stuff won’t do, however you can use ITrain to manually set up routes for turnouts, operate signals and several other things and run the trains manually using either the ITrain screen or the Z21 application.

 

I would also say that the sooner you jump the quicker you will gain experience and the desire to undertake the automation which doesn’t need to be expensive as you can achieve it for around £5 per feedback sensor currently!

 

let me know what help you want as I am very happy to help out. The author (Xander Berkhout) will grant you a fully featured and unlimited trial licence for 2 months during which you will get all the support required on the ITrain forum (much of it from me  )

[ITG]

On 05/12/2021 at 18:48, WIMorrison said:

I agree that you will not gain automation unless you create track feedbacks that provide communication back to ITrain which the IRDots and DCC Concepts stuff won’t do, however you can use ITrain to manually set up routes for turnouts, operate signals and several other things and run the trains manually using either the ITrain screen or the Z21 application.

Setting up routes would be an option, but I suspect it will render my Alpha Switch D mimic panel somewhat redundant, as when the points are changed using the Prodigy, the LED switches do not follow suit - so panel indicators are then incorrect. I’m thinking that setting routes (ie the points for) via the Z21 (instead of the Prodigy) would cause the same effect. Maybe this is another factor as to why I delay the change to the Z21, or only use it to support loco control via laptop/app. Or, alternatively, I could use use it for routes control for learning only, accepting that I’d have to reset the mimic panel afterwards.

As for signals, I haven’t started on them at all on current layout - been putting it off, as I didn’t make wiring provision early on (doh!).

 

I think I need to accept that any use of Z21/iTrain on this layout will be for learning and experience, as opposed to achieving an end result of any level of automation. That will have to come, on a new layout, be it a replacement for this one, or an additional new one elsewhere.

 

Iain, thanks for you helpful response, no doubt you’ll hear from me again, both as I consider next steps, and when I start to practically connect things up.

Ian

[jamespetts]

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.

[RobinofLoxley]

It would be really hard to wire a layout retrospectively for feedback. I think its inevitable once you switch over to control components that are designed with automation in mind that items such as mimic panels arent useful any more as functional elements, although one could be retained that simply took all its signals from the outputs driving the point motors, but didnt do any switching itself. 

 

I have a couple of large switching units that ran all my point motors on the previous layout that have no role in the one I'm building now.

 

Its funny that there is a very strong attachment here to analogue stuff when the hard wiring style became obsolete 40 years ago. Its an emotional attachment rather than a logical one in my view. So second layout, the objective is to have the minimum level of equipment and wiring, although the idea of minimum when one is building for block detection and high reliability, doesnt really fly.

[ITG]

44 minutes ago, jamespetts said:

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.

Yes, I do get that. As I said, if I do change the Prodigy for a Z21 and (very limited) iTrain usage, it will be pretty much to facilitate my learning, ahead of any new layout. Hopefully, that will make the automation planning easier.

[ITG]

15 minutes ago, RobinofLoxley said:

It would be really hard to wire a layout retrospectively for feedback. I think its inevitable once you switch over to control components that are designed with automation in mind that items such as mimic panels arent useful any more as functional elements, although one could be retained that simply took all its signals from the outputs driving the point motors, but didnt do any switching itself. 

 

I have a couple of large switching units that ran all my point motors on the previous layout that have no role in the one I'm building now.

 

Its funny that there is a very strong attachment here to analogue stuff when the hard wiring style became obsolete 40 years ago. Its an emotional attachment rather than a logical one in my view. So second layout, the objective is to have the minimum level of equipment and wiring, although the idea of minimum when one is building for block detection and high reliability, doesnt really fly.

Yes, agree. It is only a year ago that I felt at the cutting edge setting up my Alpha Switch D panel. To be fair, it’s not analogue, and it has added functional benefit in managing points, and in such a way that it limited wiring.

When it becomes clearer (a) how much space I’ll have for the additional layout and (b) what time scale that might develop in, I’ll have a big ‘weighing up of pros and cons’ of which of the two layouts will become the automated one, and which will use the technology I’ve already got. That said, I will have a conversation with DCC Concepts (who I’ve always found very helpful) about exploring potential links and usage of the current equipment with Z21/iTrain, even if only around the fringes.

[Michael Hodgson]

I think you've made a good choice, with both iTrain and the Z21.  It took me a long time to decide which hardware and software to go with, and I came to the conclusion that iTrain is one of the two best on the market, the other being produced by someone who seems to have problems with the UK.  The Z21 seems to have the greatest compatibility range as regards the the hardware that you might want to interface to it.

 

I also agree that the tutorials (which are still coming out!) are excellent.  Most of the functionality is in the manual somewhere, but finding it is not at all easy.  I know I still have a lot to learn, but I can do what I need to at present and can see the way forward for things I have yet to tackle.  As Iain says, the generous two month trial period that Xander allows you is enough to explore the software quite deeply before committing.  The more I get into iTrain, the more I think I've chosen the best product - it's one of those once in a generation technical products like the BBC Micro which just seem to have got so many things right.  My only doubt about the package is its dependence for support on one man - the author.  And as it works, if he ceases to be able to support it for any reason, well it should just carry on working as it is, so I can live with whatever bugs have not yet been discovered and fixed.

 

For driving point motors (mostly Seep/Peco) I have installed Digikeijs modules, but if I was starting from scratch I would go for one of the slow motion types of motor.  For detection, I came to the conclusion that the Digikeijs track occupancy detectors were the way to go but it does mean I will want to fit resistive axles to a number of vehicles - brake vans, basically anything that will be the back of a train, so that divided trains are detectable.  I have defined the geography of my layout in iTrain, but I still have to do a lot of confuration and to wire up the detectors to the track - that is initially a case of substituting the new modules into existing sections instead of the current (analogue) controllers, a pain to do as it's got to be done upside down under the baseboard, and of course I've got a lot of locos that need to be fitted with decoders, which will take a while because of the cost.   If your investment in Irdots etc is significant, you might want to look at whether they can be made to interface with the Z21.    

 

With iTrain, you don't need a control panel to set the route, you get the computer to do it - however I will probably also set up a control panel which talks to the layout via iTrain.

 

One question you will still need to decide is whether or not you want Railcom support - it will affect your choice of detection modules, and the decoders in your locos have to support it, which could be an issue if you already decoders in your locos.  I've decided I don't need it, because iTrain will keep track of what's where as log as I tell it in the first place.

 

 

 

[ITG]

8 hours ago, Michael Hodgson said:

One question you will still need to decide is whether or not you want Railcom support - it will affect your choice of detection modules, and the decoders in your locos have to support it, which could be an issue if you already decoders in your locos.  I've decided I don't need it, because iTrain will keep track of what's where as log as I tell it in the first place.

Mmm, what exactly is Railcom, and what are the wider implications of using it or not?
ian

[Nigelcliffe]

34 minutes ago, ITG said:

Mmm, what exactly is Railcom, and what are the wider implications of using it or not?
ian

 

A mechanism where a decoder can report its identity (and other things) back to the system.  So, at a basic level, when in a block with a detector, the loco reports "I am loco 4571".    This is detected by the system and used.    
There is other information which might be detectable (depends on hardware), and might be present (varies between decoders), such as the orientation of loco on the track (facing east, facing west), and other data such as loco actual speed, plus the ability to read CV values "on the main".  

 

 

Downsides: 

1 -  only supported by some decoder makers.  That support is mostly European:  ESU, Lenz, Zimo, D&H, etc.   Of the US decoders, I think only TCS support it  (last 5-8 years?).   
Other makers ignore it, and a few (usually old) decoders will run really badly in the presence of a RailCom signal on the track.   
Some accessory decoders have been reported to be problematic in the presence of the RailCom signal (they ought to be fine, RailCom is in the DCC standard, but the problems exist with some).      

 

2 - Only works with some command stations (usually European brands), can be retrospectively added to some others with third-party add-on devices, but some command stations are never going to be possible. 

 

3 -  other than the basic loco ID reporting, there's no real standard of information/features across a wide range of decoders and decoder makers.  Lenz and ESU have branched off on their own with RailCom+, but control it with their own licensing system.  The license terms really upset Zimo (read it on their website newsletters, several years ago), who haven't gone along with it.  

 

 

 

If you have compatible decoders (or very few locos where a secondary RailCom ID module is needed to be added), and a compatible command station,  then for automation, its probably worth using.   

It is possible to run very advanced and complex automation without it, various large layouts don't use it.  If you know the starting state of a layout, and all the turnout positions, you can track every loco around the layout (with either computer or human driving the loco), so know each loco's location at all times in the future.

 

 

- Nigel

 

[Michael Hodgson]

One approach to with Railcom might be to rely on iTrain to know where everything is but also to install one Railcom detector on a line most trains pass through, just to confirm that it still has the right data (at least, where the loco happens to be compatible), and cheaper non-Railcom detectors on the rest of the layout.  I see this as analogous to a commercial inventory control system, where your system knows what you should have because you are tracking all purchases and sales, but you still have to do a stock check from time to time to correct for with pilferage or mistakes.   iTrain should remember its data after power off, but it can't know about whatever you have been doing in the way of moving locos with the computer off or any hand-of-God activtity.  

 

I haven't done the experimentation necessary to confirm this, but one or two things I heave read lead me to suspect that if you are going to fit resistive axles to a lot of vehicles for the detectors, that Railcom needs a lower resistance, and therefore more current is drawn through these axles - but even if that is correct, I don't see it as causing problems, just a factor to consider when doing the axles.

 

I haven't enough DCC experience yet, but I get the impression that differences between manufacturers approach to some CVs makes it a good idea to standardise on one brand of loco decoder, though it probably doesn't matter if you have a few exceptions.  Cost of Railcom compatible decoders would potentially be an issue, but all the Zimo ones are compatible, and it's only an issue if you are using the cheapest (Lais) ones which a lot of modellers seem to dislike or those supplied installed on some locos sold as DCC fitted.  But I'm not going for sound effects, and will probably standardise on Zimo anyway for about £20 a time.

[ITG]

I may have mentioned previously that I’ve been generally fortunate enough to acquire all locos from pre-owned sources, most with sound. (One DMU I have had converted to sound). I did dispose of one or two that didn’t perform well, but now I’m more than happy with the movement (speed, acceleration, deceleration etc) and sound of all, so at the moment I’d probably be reluctant to embark on wholesale standardisation of decoders. I haven’t got the data to hand, but from memory I recall a number of factory-fit Bachmann, an ESU or two and a Zimo or two, but which exact types escapes me.

 

The recent mentions on this thread of resistant axles to detect stock, was the first time that had sunk into my consciousness. Another thing to think about. I am gradually working my way (in a theoretical sense as I have no iTrain kit yet) through the excellent YouTube videos, but haven’t yet found a comprehensive list of physical items one needs to consider, such as creation of blocks, decoder compatibility and now, resistant axles. I understand that one may not need all these (especially it seems if not going down the Railcomm route) but does such a checklist exist?

Ian

[peach james]

How to design around feedback on a future layout...


How long is a piece of string?  I think Z21 implies using RS-Bus as the primary bus for the outside modules.  I use Digitrax, but that's because I'm in North America, and NCE isn't as forthcoming even though most equipment is also available in a NCE style here too.  Digitrax when I started made the most sense for the hardware part of my layout.  The choices I am aware of are Digitrax, Lenz, NCE & Z21.  All are workable, and equally, not compatible with one another...

Detection on a future layout- I would start with a fixed design length for detection sections- probably 1 to 1.5m track length, unless you run a lot of shorter trains.  (this is assuming OO, rather than N- in N, go with about 1/2 that, I'd think...).  Plan around running ALL the turnout motors off a separate supply of some form- there are several ways to do so.  Put the turnouts that are physically  together to detect them as well...but remember that you need to allow for time for them to change state when you are looking at them.  (this is to ensure that the computer, which is just as smart as you make it be, knows when the brake van is left behind off the goods in front of the express passenger train due through at 70 MPH on the outside track, right next to the plunge to the concrete floor.  If that isn't experience, I don't know what would be !)

Style of operation will to some extent determine how you want to automate.  If you want to be a train driver, then basically ALL the turnouts will need to be automated.  If you want to do shunting in an intermediate station, then having the turnouts in a lever frame(ish) system can make it a lot more entertaining for you.  I'd be loath to sell on kit until you get to where you know it isn't going to fit with what you are doing.  Remember too, there is more than one way to skin a cat- for example, if you are currently using solenoid point motors controlled by a mimic panel, you can continue to do so, and fit the 2nd switch to the point motor (if Peco), feeding into the computerized side.  Operational style is important, and I (along with most other sane people) prefer something other than using handsets to change turnout positions.  I don't have local control panels, but 95% of the time, the computer is controlling the turnouts not me with a handheld.

One area to think of is that the space you are filling likely will cost more than what you are filling it with- think what it costs per square foot for the house, and think what it is going to cost to build the layout...though the layout tends to be financed on your income, rather than against a bank loan.  (I don't even think HLJ is financed against a bank loan...).  It's something that has come up in another thread I have been involved in- and even with my own Long Marton, that the cost per square foot to fill the space is far less than the cost to BUY the space.  My cost in rural Canada was about $110/sq ft to build space, and even though I have been fairly lavish with track and detection sections, it actually takes a fair amount of determination to spend more on filling the space than on buying it.  (that's for layout, not for stock...stock cupboards can cost a LOT more than that to fill...).  Especially given that a lot of Long Marton is plain double track, and DS 64 & BD4 work out at about $150 per, at 6' each...so every 12' (*3' wide...$3960 worth of floor space...).  I do have a bunch of track where the detection sections are a lot shorter than 6' (down to perhaps 6" in places), but that tends to be where things get "complicated" and I want to have the computer SPAD the section on a detection to prevent increase the time between spectacular collisions.  

DSC_0040 by Peach James, on Flickr

A lot of this is "how long is a piece of string" for answers- read what Beast and TTG have written, and watch some videos of layouts that are DCC with automation.  I'm not convinced that for a fixed layout at home, everything MUST go through the computer- but if the computer doesn't know, then it can't control...

James


"other being produced by someone who seems to have problems with the UK"

  Ha !  that's the understatement of the week award winner there...
(actually, I think he's just a something or other...and yes, I own a license for my copy !)

Count me as one of the people who would suggest that ITrain or JMRI are both probably better choices...

 

[jamespetts]

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.

Edited December 9, 2021 by jamespetts

[WIMorrison]

Ian

 

a rather shorter post than others to correct a few myths and incorrect statements.

 

the Z21 will work with RBus, Loconet and XPressnet feedback detectors and there are lots of suppliers out there. Currently Digikeijs is the most affordable but when the component shortage goes there will be another that is more cost effective and more reliable.

 

with regard to Railcom it has advantages giving positive identification of the train to the software, however the software will work equally well using assumptive identification. If a train has left block A and one appears in block b then Railcom would positively identify the loco, without Railcom the software assumes that what left block is what has arrived in block b.

 

you also get reading and writing of loco CVs using Railcom.

 

lastly, you do not need stayalives fitting into any stock or locos. What you need is good track laying and wiring. A loco stall, whether on turnouts or on the track, will not affect the automation.

[jamespetts]

5 minutes ago, WIMorrison said:

...

 

lastly, you do not need stayalives fitting into any stock or locos. What you need is good track laying and wiring. A loco stall, whether on turnouts or on the track, will not affect the automation.

 

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.

[WIMorrison]

I repeat, good track work and proper wiring negates the need for stayalives and a train stalling does not affect the automation. Yes, it may need the hand of god to start the train, but that is the case irrespective of a stay alive being fitted, and a train will only stall once moving if your track work is bad.

 

I model is H0e and do not suffer any stalling anywhere in the layouts and I do have any stayalives fitted - but I do have good track work and proper wiring. My trains can all traverse turnouts at 1kph without any issue.

 

I can easily run for 2 days at an exhibition with zero issues, and I only clean the track every couple of months or so. Locos get cleaned before an exhibition, otherwise they are just left to run.

[jamespetts]

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.

Edited December 9, 2021 by jamespetts

[WIMorrison]

3 hours ago, jamespetts said:

 

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.

 

...

 

The automation software should not lose the train because it has stalled, not should it affect the automation - all that will happen is the loco and train will stop until you give it a nudge, but with good track work and wiring you won't need to give it a nudge

 

[Michael Hodgson]

1 hour ago, jamespetts said:

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.

......

 

Incidentally, wiring should not make a difference to this unless it be done very badly.

A stay-alive helps you overcome temporary interruptions to power supply, which can happen as a result of dead frogs or dirty track.  There are some impressive demos videos about of a loco continuing to run over a piece of paper laid across the rails isolating it from its pickups.  But I don't see how a stay alive will help you start a stationary loco, as it isn't charged.  I accept however the point you were making about Zimo that well-designed decoder logic can selectively choose as its stopping place somewhere that its pickups are working, so reducing the need for finger poking to start.    

 

I see Iain's comments about decent wiring as meaning that he removes problems with dead frogs etc, and that he ensures there are plenty of dropper wires rather than relying on fishplates for electrical continuity.  There does seem to be more of an issue of voltage drop with DCC than with analogue control if you are using wires of too thin a gauge.

[grriff]

My experience with stay alives on my small layout and my neighbour's extensive layout, both Peco OO Setrack, is that locos with sprung axles don't require stay alives but those without, such as my Hornby Thomases, do. 

On the subject of controllers, have you considered using a SPROG in conjunction with MERG kits and JMRI?  It's not a solution as elegant as the Z21 and iTrain, and it involves more work but it's an option 

[jamespetts]

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.

[Andymsa]

6 hours ago, jamespetts said:

 

 

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.

 

 

introducing point position feedback is only affective for a physical system of monitoring, a electrical one would be totally ineffective because of mechanical failure. 

[Andymsa]

5 hours ago, jamespetts said:

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.

running trains in itself does not cause oxidation, there are many factors involved, but micro arcing does not cause oxidation.

 

as to the pickup from the running rail, this is strictly not quite correct as the rail forms part of the return circuit..  Additionally the rails have a small voltage running through them in any case for track circuiting purposes.

[jamespetts]

9 minutes ago, Andymsa said:

 

introducing point position feedback is only affective for a physical system of monitoring, a electrical one would be totally ineffective because of mechanical failure. 

 

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.