TrainController good or not so good

[model-trains]

I have used both iTrain and Traincontroller, although not used traincontroler within the last 3 years. I found both work differently, but iTrain (once you figure out the order in which to do things) has worked really well for me. Route setting on Traincontroller was nicer, with the ability to change it to different colours, and the keyboard shortcuts being more obvious, but once I found my way around iTrain and settled for the gold track routes I was ok. I use this at a model railway club, with a keyboard to set routes. I am in no way an expert at it, but the forum was super helpful. 

I plan on moving to the new digikeijs controller  at the club soon so will see what happens then!

 

Thanks for your comments tophski, 

 

Hearing people reports, the good bits and the not so good is a great help.

 

I am on day 2 of my trial with iTrain, so I am starting to add accessories first and just starting to play with signals. So far I have to agree TrainController was fast and easy to set up, as far as I have got that is, the blocks are very clear and it is nice to see loco's going from block to block. I smile already at your comment regarding iTrain, 'once you figure out the order to do things'. It so far doesn't seem as straight forward, but my mind is open and I will see as I had a few more signals and get routes programmed. I have just this last hour added my first turn out and signal, and got them working from the blue dot indicator.

 

With iTrain I am also watching a YouTube video which is very helpful...

 

 

For TrainController I was working through a set of videos starting with this one by Rudy...

 

 

 

Thanks again for your comments, now back to iTrain .

Edited December 19, 2018 by model-trains

[Edwin_m]

Does anyone know if Train-Tech signals work with TrainController? 

I'm not familiar with these but TC can be set up to use very complex logic to turn a particular accessory output on or off.  So if they can connect to an accessory decoder there should be no problem operating them.  The one possible exception I can think of is flashing aspects, which can't sensibly be "flashed" by TC turning the output on and off.  They would need some kind of external flasher circuit unless the decoder provided that function. 

Edited December 20, 2018 by Edwin_m

[RFS]

I've been a Traincontroller user for over 10 years now, and have worked my way up from 5.8 to the current release 9. I have no experience of iTrain so cannot offer a comparison, so perhaps I can list a few points for you to ponder.

 

Blocks and train lengths. TC Gold has comprehensive support for managing both long trains in short blocks, and short trains in long blocks.  It uses "dead reckoning" to calculate where a train is in a block, so knowing the train length (which you have defined) it knows when it's clear of the preceding block. This allows early release of that block (for short trains) and delayed release (for long trains).  It requires that you profile all your locos once so TC knows how fast the loco travels on any given speed step, but is extremely accurate. Of course this does rely on having decoders that have accurate BEMF.  I have now standardized on Lenz (mainly) and some Zimo decoders, all of which are excellent in this respect.  Also I use occupancy detectors and with TC and I only need one per block. This allows me to set multiple brake and stop markers (eg for short and long trains, scheduled vs. unscheduled stops etc.).

 

Turnouts. I can only speak for TC, but it always fires the points in a route regardless of their current state. There are reasons it needs to do this but it can be a bit of an issue with solenoid point motors. It can become quite noisy at times which detracts quite a lot. I have now set up my layout exclusively with Tortoise slow-motion motors.  As the change only requires reversing polarity, nothing happens when the motor is set the right way.  And even when they switch there's much less noise plus you can switch as many simultaneously as you like. And point motor reliability is crucial.

 

Signals. Mine are all 2 and 3 aspect colour light signals, some of which also have feathers. For the 3 aspect ones with feathers, there's the complication of setting yellow or green according to the next signal on the route that has been set. I do this with a feature in TC called flagmen. Feathers on the other hand are easy: feathers are powered along with green aspect (or yellow green output for 3-aspect) but routed via the second switch on the Tortoise powering the turnout for the diverging route. In this way the feather comes on automatically only if the signal is green and the diverging route is set. 

 

Simple two-aspect signals are easily accommodated using triggers that you define on the green aspect. In my case the triggers are that the block in front of the signal is occupied, and TC’s internal block signal is set to green for the correct direction of travel. This means the signal is automatic, and reverts to red as soon as the block occupation goes off.

 

My signals are operated by latching DPDT relays controlled by Lenz LS150s. I made my own circuit boards for these but today I would probably have used Gaugemaster GM500 ones.

 

General. No matter what automation software you use, it’s imperative that your hardware is reliable. Hence well-laid track, electrofrog points, very reliable point motors (hence my use of Tortoise), decoders with accurate BEMF, locos that keep their feet etc. Automation will quickly expose any shortcomings!

 

You can run TC in simulation mode and there’s no time limit in this.

 

Hope this helps.

Edited December 20, 2018 by RFS

[Edwin_m]

Signal aspects and route indicators can be driven by TC flagmen based on routes set.  I found it was almost a parallel system to the signals that TC uses internally to control automated train movement.  I think I put a check in the data so the signal won't clear on the screen or the trackside* unless the equivalent TC signal is also clear, but I've not got far enough into the automation side to test if this works. 

 

*which in my case I have not got, though I know how to do them when I get some! 

[model-trains]

I'm not familiar with these but TC can be set up to use very complex logic to turn a particular accessory output on or off.  So if they can connect to an accessory decoder there should be no problem operating them.  The one possible exception I can think of is flashing aspects, which can't sensibly be "flashed" by TC turning the output on and off.  They would need some kind of external flasher circuit unless the decoder provided that function. 

 

Many thanks for your comments Edwin_m, I think with the Train-Tech signals as I already have 20+ I will contact them and ask them if their signals work with TrainController. I have 2,3 and 4 aspect signals, I will want more with the larger layout but wouldn't be using flashing signals. 

 

Thanks again for your comments hey are very helpful. 

[model-trains]

I've been a Traincontroller user for over 10 years now, and have worked my way up from 5.8 to the current release 9. I have no experience of iTrain so cannot offer a comparison, so perhaps I can list a few points for you to ponder.

 

Blocks and train lengths. TC Gold has comprehensive support for managing both long trains in short blocks, and short trains in long blocks.  It uses "dead reckoning" to calculate where a train is in a block, so knowing the train length (which you have defined) it knows when it's clear of the preceding block. This allows early release of that block (for short trains) and delayed release (for long trains).  It requires that you profile all your locos once so TC knows how fast the loco travels on any given speed step, but is extremely accurate. Of course this does rely on having decoders that have accurate BEMF.  I have now standardized on Lenz (mainly) and some Zimo decoders, all of which are excellent in this respect.  Also I use occupancy detectors and with TC and I only need one per block. This allows me to set multiple brake and stop markers (eg for short and long trains, scheduled vs. unscheduled stops etc.).

 

Turnouts. I can only speak for TC, but it always fires the points in a route regardless of their current state. There are reasons it needs to do this but it can be a bit of an issue with solenoid point motors. It can become quite noisy at times which detracts quite a lot. I have now set up my layout exclusively with Tortoise slow-motion motors.  As the change only requires reversing polarity, nothing happens when the motor is set the right way.  And even when they switch there's much less noise plus you can switch as many simultaneously as you like. And point motor reliability is crucial.

 

Signals. Mine are all 2 and 3 aspect colour light signals, some of which also have feathers. For the 3 aspect ones with feathers, there's the complication of setting yellow or green according to the next signal on the route that has been set. I do this with a feature in TC called flagmen. Feathers on the other hand are easy: feathers are powered along with green aspect (or yellow green output for 3-aspect) but routed via the second switch on the Tortoise powering the turnout for the diverging route. In this way the feather comes on automatically only if the signal is green and the diverging route is set. 

 

Simple two-aspect signals are easily accommodated using triggers that you define on the green aspect. In my case the triggers are that the block in front of the signal is occupied, and TC’s internal block signal is set to green for the correct direction of travel. This means the signal is automatic, and reverts to red as soon as the block occupation goes off.

 

My signals are operated by latching DPDT relays controlled by Lenz LS150s. I made my own circuit boards for these but today I would probably have used Gaugemaster GM500 ones.

 

General. No matter what automation software you use, it’s imperative that your hardware is reliable. Hence well-laid track, electrofrog points, very reliable point motors (hence my use of Tortoise), decoders with accurate BEMF, locos that keep their feet etc. Automation will quickly expose any shortcomings!

 

You can run TC in simulation mode and there’s no time limit in this.

 

Hope this helps.

 

 

Thank you for taking time to provide an excellent reply, it is mist helpful.

 

I use Cobalt slow action point motors so they will not be an issue. I never likes the click, click, click of solenoid, the Cobalt are positive, as you say, an essential part of trouble free model railway. 

 

Your reply is a great help RFS, thank you, but I am currently looking for the feet on my loco, I knew I should have read more of the manual   

[model-trains]

Testing TrainController Gold and iTrain, latest trial editions, I am finding at this stage, both appear very good software packages, although they both do things in different ways.

 

TrainController appears to allow me to see loco's proceeding along a route, protected with block protection.  One signal aspect showing on the end of the block, there is no signal at the left side of the track.

 

iTrain allows me to set routes and clearly see the route set as well as all accessories in the route that are protected. Signalling appears to include European signals but a small number of UK signals are in the library. These can be added to the track on the left as the engine driver would see them. So far I have only added 2 and 3 aspect signals, I can get 2 aspects to work but not the Y on the 3 aspect. I need to look into this more as the majority of my signals are Train-Tech 3 and 4 aspect signals, once I suss this out I can look at back down the line signalling. iTrain is limited as only a small number of accessories can be added in the trial version, I have taken a more complicated section of the layout to use to test the software.

 

I need to find out more with both packages, before I can make a decision, already both look good, but both have advantages and dis-advantages, the only thing clear at present is the price difference, could this be the defining point.

 

Please do continue adding any advantages and disadvantages you find with either or both of these software packages. 

 

Thank you in advance for your comments, good and bad, things you like and items you may find frustrating, I am expecting the deeper I get into the trial versions items will crop up that are awkward, frustrating or not possible. 

[model-trains]

Hi Suzie

 

Thanks for the suggestions. I have been browsing and searching the net to see what they are and what I could find out. I am not sure they will work with the Hornby Elite, I found a couple of forum comments on the xpressnet regarding this that didn't confirm this.

 

I think my options are, staying with Hornby and see what their Loco Detection brings up in 2019, whilst I build the new layout, or ditch it completely for either TrainController or iTrain. That said would the DR5000 be better? I am going to create another thread to ask about the DR5000 and welcome members comments about this controller, as this thread is for considering the advantages and disadvantages of both TrainController and iTrain software. 

[RFS]

When considering which DCC system to use with automation software, it's worth bearing in mind that much of your interaction with the layout will be via this software and not the DCC handset.  I use a Lenz LZV100 system with LH100 controller. Some folks might regard this as a bit dated, but it provides a solid, reliable DCC system and TC runs very well with it. At a recent session with the grandchildren, I ran the layout in automation mode for a couple of hours and the LH100 never left its holster.

 

Lenz have now introduced a replacement handset, the LH101. Looks to be more comprehensive and Lenz have said the reason for having a dedicated handset was because they felt that operation of a DCC system using a smart phone (or similar device) was not ideal. The LZV100 is due to be replaced by the LZV200 which I understand is being released in February 2019. 

 

I have also tried to keep the hardware as simple as possible, so for detection I've used LDT RS8 occupancy detectors, with one detector per block. Turnouts are not monitored, nor are short sections of track between them as TC manages this well. 

[jamespetts]

I have spent some time looking into model railway automation software for two layouts that I am planning to build in my shed. My own intention was and remains full automation, and, for that purpose, I found that the TrainController software was preferable to the two alternatives that I seriously considered, being JMRI and iTrain. I have posted a video of a test layout showing automation at work: see here.

 

For full automation, the trouble with JMRI and, to a lesser extent, iTrain, is the lack of suitable abstraction features. For example, TrainController has a feature allowing schedules (i.e. specific scheduled movements) to have a percentage chance of starting late or not running at all; it is possible for a schedule to be set to be started from any one of a number of blocks, selected at random and/or based on specific criteria, such that one can have a number of suitable trains in a fiddle yard to start a specific schedule(d movement), and TrainController will, out of all the fiddle yard roads where a train suitable to start the schedule might be found, choose one with a suitable train in it (e.g. not a freight train for a passenger service, etc.), and run the schedule with that. TrainController also allows for some really quite precise stopping based on inferring how far that a train has travelled beyond a sensor (such as a boundary between two occupancy detector sections), using data about the relationship between the commanded and actual speed of the specific locomotive in question measured in a profiling session. The latter feature in particular is very important for full automation, as automation is impossible without being able to stop trains in the right places (especially if coupling/uncoupling is to be automated, as on both of my layouts). JMRI has a profiling system, but has less precise control of stopping (TrainController allows selecting a specific point in the block for beginning to slow down and another for actually coming to a halt).

 

JMRI has the advantage of being open source and able to be scripted, so in some ways there is a great deal of flexibility: but because JMRI lacks good abstraction features, for full automation, one would have to write what would amount to a substantial independent piece of software in the scripting language to implement all the necessary abstraction layers - unless one were content with a fully procedural automation (which is what JMRI users usually do) of the "move train no. X from block N to block P at Z time" variety, which, because it fails to separate code and timetable data, loses all flexibility, is extremely hard to change (as changing one thing may require scores of other things to be changed as all subsequent movements depend on assumptions made about the state of the layout resulting from each previous movement) and is very fragile.

 

However, for anything short of full automation (i.e., using the software just to control points/signals or using it for signalling plus some minor ancillary automation of, e.g., a branch line shuttle), JMRI is probably preferable: it is open source, has UK signalling built-in and is designed to be set up using NX routing. I should note, however, that I have not looked into this use case in detail as my own use case is full automation.

 

As to the TrainController licence and the somewhat bizarre dispute about a "demo licence", the actual licence agreement is quite specific about what is and is not permitted with an ordinary licence:

 

 

 

Use of our Software for commercial Purposes
All terms of use as full version contained in the previous section apply also to the use of our software for commercial purposes. Furthermore the following terms apply: if our software is used for commercial purposes for more than 30 not necessarily successional days per year, then a license for commercial purposes is required. Licenses for commercial purposes can only be obtained by contacting Freiwald Software directly via the published contact address. Freiwald Software reserves the right to fix specific prices for commercial use on an individual basis, which are different from the generally published prices.

 

Provided that the use to which the software is put be not commercial, or if it is used for commercial purposes for 30 or fewer days in every year, no additional licence will be required. It is not at all clear how the people at Friedwald Software thought that demonstrating the system at model railway exhibitions could amount to a commercial use: it is not at all clear what the commercial transaction was imagined to have been.

 

The way in which the licence agreement is drawn suggests that it was not written by legal professionals, however. For example, the following bizarre passage appears under "Illegal Use of Our Software":

 

 

 

The use of the software is especially illegal if a license code has been applied, that has not been registered by Freiwald Software to the name of the purchaser.

 

No competent lawyer would use the phrase "especially illegal" in a legal document. It may well be that the people at Freiwald Software have a very limited understanding of the law. That, however, does not and cannot affect people's actual rights under the licence agreement.

[RFS]

I have 2 and 3-aspect signals on my layout and have set them up to work automatically. For example, you define a 3-aspect signal and place it either in-line on the track or adjacent to it. The definition looks like this:

 

 

It has two addresses, usually consecutive, and you specify in the "output configuration" which combination of settings is correct for each aspect. Once defined, you can operate the signal manually just be clicking on the object on the switchboard. You can also set specific aspects by actions on, for example, the setting of routes or by push-button definitions.

 

To have the signal operate automatically you use triggers - there's a tab for this on the properties. There are no triggers on the red aspect: for a 2-aspect signal the trigger for the green would typically be that the route is allocated, and the block in front of the signal is occupied. (TC automatically defines a route for every path between two blocks, and the occupied block in this case would be the first of the two blocks in the route). Once the train leaves the first block, the signal will revert to red. For a 3-aspect signal you would have these triggers for both yellow and green, with the yellow having an additional trigger that the next signal is red, and the green that the next signal is not red. I have also defined the internal block signal as a dummy (defined as "without connection") and use this as an additional trigger, as some of my station roads are bi-directional and I don't want an incoming train to operate the outgoing signal. 

 

Hope this helps

Edited December 22, 2018 by RFS

[model-trains]

I have spent some time looking into model railway automation software for two layouts that I am planning to build in my shed. My own intention was and remains full automation, and, for that purpose, I found that the TrainController software was preferable to the two alternatives that I seriously considered, being JMRI and iTrain. I have posted a video of a test layout showing automation at work: see here.

 

For full automation, the trouble with JMRI and, to a lesser extent, iTrain, is the lack of suitable abstraction features. For example, TrainController has a feature allowing schedules (i.e. specific scheduled movements) to have a percentage chance of starting late or not running at all; it is possible for a schedule to be set to be started from any one of a number of blocks, selected at random and/or based on specific criteria, such that one can have a number of suitable trains in a fiddle yard to start a specific schedule(d movement), and TrainController will, out of all the fiddle yard roads where a train suitable to start the schedule might be found, choose one with a suitable train in it (e.g. not a freight train for a passenger service, etc.), and run the schedule with that. TrainController also allows for some really quite precise stopping based on inferring how far that a train has travelled beyond a sensor (such as a boundary between two occupancy detector sections), using data about the relationship between the commanded and actual speed of the specific locomotive in question measured in a profiling session. The latter feature in particular is very important for full automation, as automation is impossible without being able to stop trains in the right places (especially if coupling/uncoupling is to be automated, as on both of my layouts). JMRI has a profiling system, but has less precise control of stopping (TrainController allows selecting a specific point in the block for beginning to slow down and another for actually coming to a halt).

 

JMRI has the advantage of being open source and able to be scripted, so in some ways there is a great deal of flexibility: but because JMRI lacks good abstraction features, for full automation, one would have to write what would amount to a substantial independent piece of software in the scripting language to implement all the necessary abstraction layers - unless one were content with a fully procedural automation (which is what JMRI users usually do) of the "move train no. X from block N to block P at Z time" variety, which, because it fails to separate code and timetable data, loses all flexibility, is extremely hard to change (as changing one thing may require scores of other things to be changed as all subsequent movements depend on assumptions made about the state of the layout resulting from each previous movement) and is very fragile.

 

However, for anything short of full automation (i.e., using the software just to control points/signals or using it for signalling plus some minor ancillary automation of, e.g., a branch line shuttle), JMRI is probably preferable: it is open source, has UK signalling built-in and is designed to be set up using NX routing. I should note, however, that I have not looked into this use case in detail as my own use case is full automation.

 

 

Many thanks for a very detailed and comprehensive reply, I feel this thread is becoming very helpful and informative, some really great and knowledgeable guys, many thanks to you all.

 

It is interesting James you have included JMRI here also, and included advantages and disadvantages for it, it makes it a valid consideration I think. That said and I feel there is a lot more to consider before I can finally decide which is right for me, it does appear that TrainController and iTrain are the main considerations for automation of model railway, therefore let us continue to learn from each other, and go deeper into the comparison between the two. 

 

I have opened your video link James and will watch it later, thanks you. 

 

Although frustrating having dismantled by layout 2 prior to moving home, and being twelve months with no trains! It is important, I think, to find out as much as possible before starting a layout, especially one with costly items needed to run it, so often we do not have time, or take time, to plan or consider the options prior to commencing a layout.

 

Happy Christmas all. 

[WIMorrison]

I was in the same position 18 months ago and did a side by side comparison of the TC9 and iTrain and came to the conclusion that I could do everything that I wanted with either package with some differences - a large one being that to do what I wanted (which isn't that complicated) I found I needed to buy TC9 Gold to get the control I wanted whereas the standard iTrain at less than half the price offered everything I needed - that was a major factor for me. I suggest that you take a close look at what is provided at the different levels as both programme trial options are for the bells and whistles versions.

 

I also use railcom and iTrain worked at that time with railcom and is now working even better as it supports multiple locos in the same block whereas at that time TC9 was very flaky with railcom, though I believe it works now.

 

The final decision was made also on the interface, I find that TC9 is a rather clunky interface which is expected given the underlying MIcrosoft platform whereas iTrain has a very clean interface which runs on any platform that will run Java. I was also concerned about support and with a UK agent who is very supportive iTrain one on this also - personal thing perhaps but I found the author of TC9 very difficult to converse with on some issues that I had whereas the author of iTrain is very helpful.

 

I have looked back at TC9 again and having looked back I am even more confident that I made the right choice, especially as we are expecting another major upgrade to iTrain 5 next year.

[model-trains]

I was in the same position 18 months ago and did a side by side comparison of the TC9 and iTrain and came to the conclusion that I could do everything that I wanted with either package with some differences - a large one being that to do what I wanted (which isn't that complicated) I found I needed to buy TC9 Gold to get the control I wanted whereas the standard iTrain at less than half the price offered everything I needed - that was a major factor for me. I suggest that you take a close look at what is provided at the different levels as both programme trial options are for the bells and whistles versions.

 

I also use railcom and iTrain worked at that time with railcom and is now working even better as it supports multiple locos in the same block whereas at that time TC9 was very flaky with railcom, though I believe it works now.

 

The final decision was made also on the interface, I find that TC9 is a rather clunky interface which is expected given the underlying MIcrosoft platform whereas iTrain has a very clean interface which runs on any platform that will run Java. I was also concerned about support and with a UK agent who is very supportive iTrain one on this also - personal thing perhaps but I found the author of TC9 very difficult to converse with on some issues that I had whereas the author of iTrain is very helpful.

 

I have looked back at TC9 again and having looked back I am even more confident that I made the right choice, especially as we are expecting another major upgrade to iTrain 5 next year.

 

Thanks for your reply Iain, a lot of key points mentioned I think.

 

At present I have TC 9 Gold Trial and iTrain top of the range Trial, the first I have done 10 days trial, iTrain only 2-3 days. Differences are clear from the start, not mentioning the price yet, support is an important consideration, but there are also forums, and RMWeb is great for these subjects. Good knowledgeable guys (and gals) willing to share information in the interest of all. Thank you all. 

 

I am sure price will come into it at the end but until then I keep an open mind and would like the very constructive discussions on here to continue, hopefully they will help others both now and maybe in the future.

 

Current comparison on the prices:

TC 9 Gold with DR5000 control station would be £700 approx. with the additional 15% added for next 12 months.

iTrain would be £350 approx. for the Plus version and the DR5000 control station. A significant price difference.

 

But until I find out more about the above packages, advantages and disadvantages, including what sensor systems work with each, I will keep an open mind.  Not hard as there isn't much between the ears anyway 

[Haymarket47]

Hi, is it possible in I Train to trigger an action in a loco eg if it enters a section with a tunnel can it automatically blow the loco’s horn? I think this is possible in TC9 with the use of flagmen?

 

Also, in TC 9 you can set a breaking section when a loco enters a block, does I Train do this?

 

I too am weighing up the option between the 2 systems.

 

Thanks

Alan

[WIMorrison]

YEp, both of them can be done using actions.

 

I have sounds that I trigger when a train receives a conmand to move e.g. platform announcements, I could have it when it arrives or when it is passing through a block. Entering a tunnel would just be the same thing - it is a block of track

 

As for braking, you can set the braking to start as a train enters the block, at a specific point in the block are ignore it - you can also stop the train anywhere in the block or centre it on a platform.

 

You could also set the maximum speed for a specific block, or a train or a loco

 

All the functions are there

[Haymarket47]

YEp, both of them can be done using actions.

I have sounds that I trigger when a train receives a conmand to move e.g. platform announcements, I could have it when it arrives or when it is passing through a block. Entering a tunnel would just be the same thing - it is a block of track

As for braking, you can set the braking to start as a train enters the block, at a specific point in the block are ignore it - you can also stop the train anywhere in the block or centre it on a platform.

You could also set the maximum speed for a specific block, or a train or a loco

All the functions are there

That’s great, thanks for the quick response. I think it’s going to be I train for me - seems to offer much better value for the money. Would you recommend the Standard or Plus version?

 

Thanks

[WIMorrison]

Depends on what need - ALL command and control functionality is provided within the Standard package but it will only support one interface - which isn’t an issue if you only have one controller - if you want the multiple screen capability, or decoder programming (which isn’t very clever anyway) then you need to buy the other versions or (assuming you have one interface) start with the Standard and buy an upgrade to another version later (the upgrade is simply the costs between versions).

 

Also, get the trial for a 2 months which has everything and decide what you need and make the decision at the end of the trial

 

Feel free to ask any more questions or PM me

[Haymarket47]

Depends on what need - ALL command and control functionality is provided within the Standard package but it will only support one interface - which isn’t an issue if you only have one controller - if you want the multiple screen capability, or decoder programming (which isn’t very clever anyway) then you need to buy the other versions or (assuming you have one interface) start with the Standard and buy an upgrade to another version later (the upgrade is simply the costs between versions).

Also, get the trial for a 2 months which has everything and decide what you need and make the decision at the end of the trial

Feel free to ask any more questions or PM me

That’s sound advice, I’ll do the homework and make a decision after evaluating it. Thanks for offering to help

[model-trains]

That’s great, thanks for the quick response. I think it’s going to be I train for me - seems to offer much better value for the money. Would you recommend the Standard or Plus version?

 

Thanks

 

Use the comparison list you will see in the link below...

 

https://dcctrainautomation.co.uk/itrain/4728-itrain-4-plus

 

• Do you want the decoder programming?
• Do you want multiple digital interfaces at same time?

 

If you don't want the two items mentions Standard will do, it you want either of the above you will need the Plus package.

 

I too am learning and trying both packages before purchasing. 

 

WIMorrison is very helpful. 

Edited December 26, 2018 by model-trains

[tender]

Im at a stage where i need either to upgrade my TC version or look at another system. In view of the recent TC pricing structure I'm inclined to call it a day and move on before investing any more in a product that's rapidly becoming poor value for money.

 

I've had a quick look at iTrain but couldn't find out if it supports NCE equipment. I have both a PowerCab system and a PowerPro system.

Any advice appreciated.

 

Ray.

[WIMorrison]

Unfortunately, you have found the one system that it doesn't support - yet

 

It is allegedly something about licencing in the EU but the hope is to have it resolved in the next major release which is expected in 2019, though incremental upgrades for new systems happen quite often

[tender]

Unfortunately, you have found the one system that it doesn't support - yet

 

It is allegedly something about licencing in the EU but the hope is to have it resolved in the next major release which is expected in 2019, though incremental upgrades for new systems happen quite often

 

Thanks Iain, looks like i'll be stuck with TC for a bit longer but won't bother upgrading. Hopefully NCE support for iTrain won't be too far away.

I could change system but that would also mean replacing (and rewiring) 48 block detection channels. As the layout is currently working with NCE equipment and TC it's not something i'd like to undertake at this stage.

[Haymarket47]

Hi, I downloaded and had a quick browse of the itrain manual and off I went to download a trial version of Itrain and got nowhere fast. Apparently Java seems to be needed and by all accounts it seems to be a product on the way out. My browsers Firefox and Edge do not support it, something to do with, inter Alia, security issues such as malware attacks. I could use Explorer but I am concerned that this will eventually be obsolete and I’ve been there before with no support and it’s not a good place to be. I wonder if the itrain developers are working to overcome this? Can anybody shed light on this?

 

Thanks

Alan

[WIMorrison]

Java - on the way out? Better tell the millions of developers using it, not to mention that the web runs on it. Oracle has changed the licencing model for developers and that means that some of their development kits need updating to meet the current security demands, but that  doesn't mean Java is 'on the way out'.