Full Computer control on N gauge

[melmerby]

36 minutes ago, WIMorrison said:

Keith

 

if you look at the link you posted then you will see that it is 128 locos but 256 Feedbacks not 128 as you state

 

You are doing down iTrains loco coverage. Locos in iTrain are 256 It's Blocks and Actions which are 128.

 

My Blocks alone currently count 108, previousy 110 (two of which have been combined) so I'm getting close to the 128 limit in non-pro version: "Number of blocks 128 128 128 Unlimited"

 

I only have 64 locos registered in TC but a lot more "Trains" than that with other vehicles.

 

[njee20]

Personally having considered both for years I’ve now totally discounted Train Controller as Herr Freiwald seems like a total loose cannon utterly undeserving of anyone’s cash! I’d not trust him to render the (ferociously expensive) software inoperable on a whim.  

[jamespetts]

I, too, am in the process of planning a fully computer controlled N gauge layout:

 

.

 

My plan is to have not only computer automated trains stopping at the stations and being selected from fiddle yards, but also shunting/reversing of terminating locomotive hauled trains and use of carriage sidings. As a result of this, I have looked into this in detail.

 

For my own purposes, I decided in the end to use the TrainController software. I did this after testing it against JMRI on a specially built automation test layout: see here for the PeerTube video of this in action.

 

I chose TrainController over JMRI because JMRI does not have sufficient built-in automation features (e.g. it has no built-in functions for schedules) to allow any real level of complexity robustly. It is possible in principle to make JMRI work for automation using scripts, but for any non-trivial case, this gets very complex very quickly and is either not robust or easily maintainable (e.g., you would need to do some major re-engineering of the code in your scripts to make a minor alteration to the schedule), or, if you added the necessary abstraction layers yourself, would amount to you having to code a substantial piece of complex software in a scripting language not suited to the task which could easily be broken by changes in updates (and this has already happened to something vaguely like this).

 

I did look into iTrain, but found that it also had insufficient abstraction features for my needs: in particular, it would not allow for choosing one of a set of trains to run from one of a set of places to one of a set of destinations, which of the sets in each case being chosen being algorithmic and either determinable by macros or randominsed (or some combination of both). iTrain also does not seem to allow the scripts/macros permitted by TrainController.

 

It is possible that the next version of iTrain will be better in this regard, but it is very difficult to judge this without knowing in more detail the actual features of this software. It is apparently due for release at the end of the year, but this has not been officially announced so far as I can tell, so this is far from certain.

 

There are other things to consider besides the software, including:

 

(1) DCC electrics;

(2) layout control electrics;

(3) feedback;

(4) coupling; and

(5) reliability and stay-alive capacitors.

 

DCC electrics

 

Building through hole electronic kits is not too difficult, but if you wish to avoid these, then I suspect that you would do well with the Roco Z21 command station. This is a sophisticated command station that works with many different types of bus (more on which below) and is known to be reliable. I have not used this type myself, however, as my N gauge layout is using a kit built unit from Hans Deloof (this unit's main drawback is that it does not allow computer controlled DCC programming, but I get around that by using the command station salvaged from the automation test layout for programming).

 

For my automation test layout, I chose the less expensive Digikeijs DR5000, which is capable, but, I found, less reliable: it has a tendency to freeze and ignore all commands of any sort until powered of and on again occasionally.

 

Layout control electrics

 

This need not be connected in any way to your DCC electrics, although a multi-bus compatible command station such as the Z21 makes using the same command station for both an attractive option.

 

Many accessories (such as point motors) are controlled using the DCC protocol, and can be controlled by using the same DCC bus as used for the track. However, this has two disadvantages:

 

(1) on anything other than a small layout, using the same bus as the that which powers the track can make for unreliable operation due to electrical interference; and

(2) the DCC bus does not allow for two way communication.

 

You can circumvent issue no. 1 either by having a very small layout (e.g. the size of the automation test layout in my video), or by using a separate bus for accessory control. This can either be a DCC bus, or an accessory specific bus, such as LocoNet. Beware that there are some accessory buses which are not compatible with TrainController or iTrain, such as the MERG CBus or the NRMA's new LCC, so bear this in mind when choosing a bus. I chose the LocoNet bus as this is widely supported in both software and hardware. The LocoNet bus also solves problem no. 2 as it is a two way protocol.

 

I chose to power my points using servos and Dingo servo mounts. These are robust and allow for reliable frog polarity switching using microswitches. Do not use frog juicers - these rely on detecting (rather then preventing) a short circuit and are inherently prone to difficulty.

 

Feedback

 

As you will probably have gathered by now, feedback (that is, hardware to detect where on your layout that your trains are and then communicate this to your computer) is essential for computer control. There are many different ways of doing feedback, from reed switches and magnets to infra-red sensors, but perhaps the most satisfactory is the current drop sensor. These detect whether anything is drawing current in a particular section of track and report this to the command station. Because of the need to communicate from the sensor to the command station (rather than the other way around), sensors for detecting trains cannot be connected using the DCC bus. I use the LocoNet bus, as set out above.

 

Digikeijs produce a good range of LocoNet compatible current sensors, which work (I am told) without problem with the Roco Z21 command station. They also work with TrainController. These connect using the LocoNet bus.

 

If you are doing feedback this way, you will need to make many more electrically isolated sections of track than would otherwise be necessary. Make sure that turnouts are fully isolated from every exit road (are effectively in their own section) and that a short section beyond the turnout be isolated separately from a main platform road if you are to do shunting so that the software can detect the presence of a locomotive entering the station even if there are already carriages in the platform. (If you did not do this, the locomotive would simply be entering another already occupied section, and the software would not know where it was and would fail to stop it in time).

 

One thing to consider with feedback is whether you want RailCom. RailCom is a system whereby the train detector circuit can read the DCC address (and sometimes the direction) of the locomotive in the section. (This is a limited exception to the general principle that DCC is a one way only data bus). Normally, once fed with the initial positions of locomotives, the computer will keep track of where everything is, so it is not necessary to have this system (which is more expensive than an ordinary feedback unit) installed in every section on the layout. However, where it can help is in the fiddle yard, where you might want manually to add and remove locomotives; this will save you the trouble of manually entering the data as to what train is in the section every time on the computer. Be aware that you need RailCom compatible decoders as well as RailCom compatible sensors for this to work, but it is feasible to have some sensors equipped with RailCom and some without.

 

If you are ever uncoupling your carriages from your locomotives, you will need a way of detecting carriages as, unless they have lighting bars or similar, they will not draw any current and not be detectable by current drop sensors. The normal way of dealing with this problem is to affix a 10k ohm resistor accross the axles of the front and rear carriage/brake van (and perhaps add to its weight a little to ensure good contact) so that some current is drawn when the carriages/wagons are in the section. If you are re-marshalling carriages or wagons, you may need the resistor on many of the carriages/wagons in the rake.

 

Accurate stopping is important for automation. TrainController and other packages do this by calibrating the speed of each of your locomotives by testing them using a piece of track of known length and running the locomotive between those two points at different speed steps, timing how long that it takes on each occasion. It then uses this data together with information about when a train entered a particular section to calculate when to stop a train in order to stop at a fixed distance beyond the entry of the section. Some members of MERG have tested and found that this can be made unreliable by inconsistent locomotive speeds depending on the temperature of the motor. There is not an easy solution to this. However, one thing that is important to ensuring that this works accurately is to use a decoder that is equipped with BEMF - this measures electrical signals generated by the motor when running to work out how fast that the motor is turning to ensure that it be kept at a constant actual speed for any given commanded speed.

 

Coupling

 

If you want to do any coupling/uncoupling, you will need to think carefully about how to automate this. The default couplings that come with UK N gauge rolling stock do not cope well with automatic uncoupling, and also look awful.

 

I have decided to use the Dapol EasiFit couplers. They can be uncoupled by a magnet (strictly, a pair of magnets, but the ones made by Dapol are in a single unit) under or on the track. They are also much smaller than the default couplers. The Dapol supplied magnets are bulky and sit above the trackl but it should be possible to use smaller rare earth magnets buried in the cork with a thin sheet of polystyrene ("Plastikard") between it and the track (and underneath the ballast) to hold them in place. Note that you will need a pair of these on opposide sides of the track with opposite polarities to work these couplers. This type of coupling is demonstrated in the video.

 

For any couplings that need not ever be uncoupled automatically, you can use either the default couplers, or, infinitely better looking, the Dapol NEMCoup dummy knuckle couplers, which are easy to use and inexpensive.

 

Reliability and stay-alive capacitors

 

Because you are running the layout from a computer that cannot intervene (or often even know) when things have gone wrong, it is important to make sure that your layout is reliable, so use good components and techniques and make sure that your track is well laid. This is not the place to give general reliability advice, but there is much to be found on various fora and elsewhere.

 

One particular aspect of reliability worth mentioning, however, is stay alive capacitors. Stay alive capacitors store a small amount of energy to allow a locomotive to keep going for a short time even if because of some dirt on the track or wheels or badly laid track there is no electrical power reaching the locomotive. Without doing this, locomotives may often stall and be unmoveable without a push, especially at lower speeds.

 

There is some very good information about stay alive capacitors from the retailer YouChoos here. For N gauge, I have had good results with the 470uF tantalum capacitors and the SACC16 charging circuit using Zimo DCC chips.

 

***

 

In any event, very best wishes with your project, and I shall look forward to updates.

[Andymsa]

9 hours ago, njee20 said:

Personally having considered both for years I’ve now totally discounted Train Controller as Herr Freiwald seems like a total loose cannon utterly undeserving of anyone’s cash! I’d not trust him to render the (ferociously expensive) software inoperable on a whim.  

 

Im not sure he could make it inoperable on a whim, in fact the way the license is set up you don't need internet access to make it function

[WIMorrison]

@jamespetts A pretty good summary of things to consider when planning automation that covers most of the points in the threads dotted around this forum.

 

Can I suggest though that rather than saying iTrain doesn’t do this or TC9 is better at this (and vice versa) we say that I couldn’t find how to do this in iTrain or I found it easier in TC9 and vice versa?

 

the only real similarity between these programs and the other alternatives is that they all run a train around the track automatically but how they all achieve that function is different in all of them and what you are familiar with will always seem easier - and inherently people want to justify their choice of product and expenditure whereas the OP and others want unbiased advice. 
 

[RFS]

2 hours ago, Andymsa said:

 

Im not sure he could make it inoperable on a whim, in fact the way the license is set up you don't need internet access to make it function

 

Indeed so, but you do need the USB licence stick to keep working which is its Achilles heel. Mine failed recently and it cost around £30 to get a replacement with Herr Freiwald saying it could take several weeks to process. I was worried for a time that it wasn't going to happen …. 

[Andymsa]

45 minutes ago, RFS said:

 

Indeed so, but you do need the USB licence stick to keep working which is its Achilles heel. Mine failed recently and it cost around £30 to get a replacement with Herr Freiwald saying it could take several weeks to process. I was worried for a time that it wasn't going to happen …. 

 

Yes I do agree with you on this. This is a very 80s way of doing things. Just curious how did our stick fail?

[RFS]

29 minutes ago, Andymsa said:

 

Yes I do agree with you on this. This is a very 80s way of doing things. Just curious how did our stick fail?

 

Every now and then I would start TC and it would say I was not licensed. Moving the stick to another USB port seemed to work. Then it would come up with the unlicensed message in mid-session. Eventually the stick was no longer recognized in any port and on any PC. I assumed therefore it was dead. Not sure how you would recover it other than via a replacement. 

 

Replacement involves Freiwald sending you a new stick that is deactivated. On receipt you tell Freiwald via your registered email address that you have the stick, and he then emails you a licence key to activate it. I assume it's done this way for security reasons. 

[Andymsa]

2 minutes ago, RFS said:

 

Every now and then I would start TC and it would say I was not licensed. Moving the stick to another USB port seemed to work. Then it would come up with the unlicensed message in mid-session. Eventually the stick was no longer recognized in any port and on any PC. I assumed therefore it was dead. Not sure how you would recover it other than via a replacement. 

 

Replacement involves Freiwald sending you a new stick that is deactivated. On receipt you tell Freiwald via your registered email address that you have the stick, and he then emails you a licence key to activate it. I assume it's done this way for security reasons. 

 

So there was no need to return the original stick. That was an intresting failure seemed odd it work for awhile in other ports and computers.

[RFS]

15 minutes ago, Andymsa said:

 

So there was no need to return the original stick. That was an intresting failure seemed odd it work for awhile in other ports and computers.

 

Yes it had to be returned since otherwise I would have ended up with two licence sticks, with the first one only a failure because I said so. 

[melmerby]

2 hours ago, RFS said:

 

but you do need the USB licence stick to keep working which is its Achilles heel.

 

2 hours ago, Andymsa said:

 

Yes I do agree with you on this. This is a very 80s way of doing things.

It does seem odd that multinational corporations can get awaywith 16 or 20 digit licence codes but Freiwald needs a stick, unless they can take the few hacked versions there will inevitably be around but Freiwald can't and considers a stick to be infallible.

Unfortunately for Freiwald there still are hacked versions of TC circulating on the web!

[jamespetts]

3 hours ago, WIMorrison said:

@jamespetts A pretty good summary of things to consider when planning automation that covers most of the points in the threads dotted around this forum.

 

Can I suggest though that rather than saying iTrain doesn’t do this or TC9 is better at this (and vice versa) we say that I couldn’t find how to do this in iTrain or I found it easier in TC9 and vice versa?

 

the only real similarity between these programs and the other alternatives is that they all run a train around the track automatically but how they all achieve that function is different in all of them and what you are familiar with will always seem easier - and inherently people want to justify their choice of product and expenditure whereas the OP and others want unbiased advice. 
 

 

I did look into this in some detail when first choosing the software to use, and chose TrainController over iTrain specifically because I concluded that iTrain could not do these things.

 

Do you think that there is a way of doing these things in iTrain? If so, I should be very interested indeed to know specifically what that way of doing things is.

[Andymsa]

1 hour ago, jamespetts said:

 

I did look into this in some detail when first choosing the software to use, and chose TrainController over iTrain specifically because I concluded that iTrain could not do these things.

 

Do you think that there is a way of doing these things in iTrain? If so, I should be very interested indeed to know specifically what that way of doing things is.

 

Hi james,

 

as you know I use traincontroller, but I'm also looking at Itrain and getting to grips with it. WImorrison has been a great help and continues to be so as well as James at dcc automation. I am keeping a very open mind with ITrain and to compare the two programs is not really fair. TC has been around far longer and has had time to develop as opposed to Itrain which is still growing. So initial thoughts, TC seems more intuitive to use but of course I been using it awhile, there are definitely features in TC which at this time are not in Itrain but that said there are some things I like about ITrain. One area where Itrain needs to be improved is the automation creation, in TC this is simply point and click in ITrain you have to remember names of items, not an issue on smallish layouts but could be an issue on larger layouts. ITrain programming language is java based but TC is more antiquated and could be problematic as windows develops losing support for various features in it which could effect TC operation. But that said TC is my primary control system still. My biggest concern for the future  of TC is will anyone take this product on when herr friewald stops working as he is no spring chicken like most of us. As I said I'm keeping an open mind and will continue to learn ITrain more, many might say why do this. Simply put its a backup if TC were to stop working for whatever reason I would be somewhat prepared, even if my USB stick had to be changed at least my layout would still be operational.

 

andy

[Nigelcliffe]

On ‎04‎/‎10‎/‎2019 at 18:17, ahellary said:

so atm train controller is the way forward i must admit i have over 255 sensors on my railway

 

If you require Transponding, then yes.   But, you're also tied to Digitrax :   Digitrax locomotive decoders and Digitrax transponding detectors.  

 

It is possible to run RailCom on Digitrax hardware, though only with the "short" cutout, which limits what can be read.   Or, swap out the Digitrax command station for something else which talks LocoNet, and thus most of the LocoNet hardware investment isn't wasted.  Alternatives which support RailCom and LocoNet "out of the box" include Uhlenbrock (some issues with "ground" on BDL168's, so research before spending), Digikeijs and Roco's Z21.  With additional hardware, ESU's ECoS also works. 

 

Or, design automation which doesn't require loco identification, only occupancy detection.   That can work for vastly complicated layouts.  

 

 

 

- Nigel

 

[theflyingspanner]

if you want to do automatic uncoupling I would go for train controller I have achieved this easily

take a look at my youtube videos on youtube at overdene station 

i  used digitrax stuff first off but have since changed to digikeijs dr5000 

i find it works much better at stopping correctly and is better for speed profiling

if i can be of any more help just ask

thanks

Alan

[melmerby]

31 minutes ago, theflyingspanner said:

if you want to do automatic uncoupling I would go for train controller I have achieved this easily

take a look at my youtube videos on youtube at overdene station 

i  used digitrax stuff first off but have since changed to digikeijs dr5000 

i find it works much better at stopping correctly and is better for speed profiling

if i can be of any more help just ask

thanks

Alan

Not sure why that should be as I have had Lenz, Digikeijs DR5000 and Roco Z21 and not found any difference whatsoever when profiling and stopping.

The main component that is responsible for that is the quality of the loco decoder itself, not the system.

However IMHO the DR5000 is inferior to both others as a DCC system. The output waveform is poorer and can cause problems with some kit.

[theflyingspanner]

I'm comparing with digitrax not Lenz or z21

[melmerby]

1 hour ago, theflyingspanner said:

I'm comparing with digitrax not Lenz or z21

Never heard anyone complain about Digitrax controllers, decoders yes, but the controllers seem to be pretty good.

DR5000 however, numerous niggling little problems with the operation. Great on paper but not so good in practice.

[jamespetts]

59 minutes ago, melmerby said:

Never heard anyone complain about Digitrax controllers, decoders yes, but the controllers seem to be pretty good.

DR5000 however, numerous niggling little problems with the operation. Great on paper but not so good in practice.

 

I use mine now only for programming.

[WIMorrison]

32 minutes ago, jamespetts said:

 

I use mine now only for programming.

 

I don't even use it for that - I sold it

[mickt014]

On 02/10/2019 at 07:35, WIMorrison said:

@mickt014 the program you quote doesn’t actually provide automation in the way I have demonstrated. It provides the already free JMRI DecoderPro element to manage the loco CV and the capability to create an interactive mimic panel enabling onscreen control of the layout. It does not support the other aspects of automation such as train detection and dynamic routing.

 

i would therefore suggest that you stick to looking at the products I mentioned if you want automation.

 

a tip which has worked well for many people is that if you intent to have the layout driven fully automatically then you design it in the computer package first and test it thoroughly before committing to the build. This allows you to iron out layout errors, shows where it is inefficient and will help in the build as you will have identified where all the blocks need to be.

 

The choice of package may also be driven by budget, plus your desire (or ability) to handcraft the chosen program to suit your purposes.

 

 Hi Iain, having finally decided to go down the Itrain route I have now found out from James at dcctrainautomation that it is not compatible with NCE and never will be. I am now wondering if I should sell the NCE and go with another compatible system....decision decisions. !!

 

Edited November 11, 2019 by mickt014

[jamespetts]

48 minutes ago, mickt014 said:

 

 Hi Iain, having finally decided to go down the Itrain route I have now found out from James at dcctrainautomation that it is not compatible with NCE and never will be. I am now wondering if I should sell the NCE and go with another compatible system....decision decisions. !!

 

 

NCE is sub-optimal in a number of respects, so replacing it would not be entirely insane.

[WIMorrison]

I don’t think I knew you are an NCE man and would agree that now is a good time to move away from it and get a system that will support the future.

 

My preferences would be firstly for a Z21 as I have tried others and find this simply bullet proof and totally reliable supporting automation fully. The next choice might be the DR5000 which has a very attractive price but I found unreliable though I am sure others will disagree.l with my view.

 

clearly there are others, but these have all the capabilities required.

[theflyingspanner]

nothing wrong with the DR5000 and all its accessories the rev loop module can be a challenge but it works ok

[Nigelcliffe]

12 hours ago, mickt014 said:

 

 Hi Iain, having finally decided to go down the Itrain route I have now found out from James at dcctrainautomation that it is not compatible with NCE and never will be. I am now wondering if I should sell the NCE and go with another compatible system....decision decisions. !!

 

 

If you're going with computer control, then I think the decision list is in this order:

1 - select software to do the job.  You've selected iTrain.

2 - select best hardware for train detection to suit software and layout

3 - select command station compatible with the above, and allowing expansion options. 

 

So, yes, time to sell the NCE kit and get something compatible with your chosen automation software.   

If unsure, I'd go with Z21: the saving over a DR5000 isn't great when the entire cost of automation hardware is considered.  

 

 

- Nigel