Jump to content
 

Getting back into DCC, automation and routing


Lacathedrale
 Share

Recommended Posts

Hello all,

 

As per the post in the wonderful Chapeltown thread I've seen that DCC is mature enough now that computer control is fairly par for course if you're that way inclined, and there are dozens of software options for automating some and all parts of your layout.

 

I understand how route setting works with software, but on the aforementioned thread northolland there are two features which really stand out to me:

 

The system appears to know where each locomotive is at any one time, and uses this as the basis for protection/interlocking and to facilitate automated movements. What kind of magical occupancy detector is this? Surely it's not just logic based on the last known location, because Mr. Holland is manually switching trains as well as using automated timetables. Fundamentally I understand how accessory decoders are controlled, but even those expensive detectors I have seen that can return specific train occupancies seem to only do so via LCD screen as opposed to comms back to the controller itself?

 

Mr Holland also has push buttons which immediately active a given route program in his software - and I gather that's the same kind of question - is that DCC traffic going around the bus, or some additional layer of connectivity?

 

Many thanks,

Link to post
Share on other sites

Try the NCE Powercab, I tried it on a friend's layout and once you learn the basics (which can be picked up quickly) you will be driving away absolutely free! Although he did say that they are pricey, so if you are on a tight budget (like me) either you will have to save up or look for something good but still cheaper.

Link to post
Share on other sites

  • RMweb Premium

Thank you sir - these seem to be route setting within the unit itself however, rather than influencing Traincontroller/JMRI/etc. ?

 

Route setting is as you say part of NCE as it is on Gaugemaster

 

My understanding is on the NCE systems they use a macro which are able to communicate to a external device that can be programmed to not only set a route but also drive the train setting signals, sound, speed of locomotive and journey duration.

 

I have seen it demonstrated and I am researching it further.

 

Eltel

Link to post
Share on other sites

Hi DoubleDeckInterurban I've used those hardware controllers in the past and they seemed expensive for what they did, which is why I'm interested in JMRI/Traincontroller and a SPROG-USB connector, but I still just can't grasp the kinds of feedback that track detection requires to automate it to the level that's been done.

 

On the other hand, maybe one-engine-in-steam with DC and an isolating block might just keep things simple at this rate, the more I dig the more I see very transient technology stacks and software that already looks 20 years old...

Link to post
Share on other sites

  • RMweb Gold

I use Traincontroller Gold version 9. With this software, the only detection required is an occupancy detector. In my case, with Lenz LZV100 command station, that's the LDT RS8 which manages 8 blocks. Each block is fed from a port on the RS8 and is isolated from adjacent blocks via an IRJ, with the feed from the RS8 being to one rail only. The other rail is connected directly to the bus. 

 

Like other automation software, TC works via simple train tracking. In other words it knows the starting position (ie which trains are in which blocks and which direction they're pointing). When you run a train via an automated schedule, or manually through the software, TC is able to track the trains round the layout because it knows which way the points are set (and sets them itself for automated schedules) so when an occupancy detector goes on it knows which train it is.

 

With automated schedules, one of the hard tasks is bringing a train smoothly to a stand in a block either for a scheduled stop (station etc) or unscheduled stop (red signal). TC profiles all your locos by a process that runs the loco back and forth over a measured block at various speeds so that it then knows the speed profile of the loco. With this information it's able to being a train to a stand at an exact point by simple dead reckoning. You will have defined the stop points as well as the brake markers (ie tells TC when to start slowing down). 

Link to post
Share on other sites

RFS that's quite interesting - so essentially you broker the RS8 blocks between the bus and the rail sections. I didn't realise that 'train tracking' was the defacto standard (what would happen if I picked up a train and put it somewhere else and then started a timetable??)

Link to post
Share on other sites

  • RMweb Gold

RFS that's quite interesting - so essentially you broker the RS8 blocks between the bus and the rail sections. I didn't realise that 'train tracking' was the defacto standard (what would happen if I picked up a train and put it somewhere else and then started a timetable??)

 

Each block is electrically isolated from others (and turnouts between blocks which are not normally part of blocks). So when a train enters a block, the occupancy detector comes on and the RS8 signals this change to the DCC system and to TC, and TC does the rest by its tracking logic. Same when an detector goes off.

 

A schedule is a series of routes. Each route is a pair of blocks so a train scheduled to run from, say block A though B, C and end in D will allocate routes A-B, B-C and C-D. When the train leaves A the detector will go off (usually when the engine leaves). However block A will not be released (nor turnouts in between) until the software has calculated that the train is fully in B. With Traincontroller this is done by dead reckoning, but other software (eg Rocrail) will need a second sensor to tell it the train has fully entered the block.

 

If you pick up a train from one block and place it in another then the software won't understand. The original block will remain allocated to the train, and the new block will be marked occupied by an unknown train. You have to tell the software you've done this. With TC you can simply drag the train's icon from the old block to the new.

Edited by RFS
Link to post
Share on other sites

Hello all,

 

As per the post in the wonderful Chapeltown thread I've seen that DCC is mature enough now that computer control is fairly par for course if you're that way inclined, and there are dozens of software options for automating some and all parts of your layout.

 

I understand how route setting works with software, but on the aforementioned thread northolland there are two features which really stand out to me:

 

The system appears to know where each locomotive is at any one time, and uses this as the basis for protection/interlocking and to facilitate automated movements. What kind of magical occupancy detector is this? Surely it's not just logic based on the last known location, because Mr. Holland is manually switching trains as well as using automated timetables. Fundamentally I understand how accessory decoders are controlled, but even those expensive detectors I have seen that can return specific train occupancies seem to only do so via LCD screen as opposed to comms back to the controller itself?

 

Mr Holland also has push buttons which immediately active a given route program in his software - and I gather that's the same kind of question - is that DCC traffic going around the bus, or some additional layer of connectivity?

 

Many thanks,

 

Hi,

 

I don't know the layout or system you are referring to but I do have some general information about train tracking (mainly DCC).

 

If there is a position detector at every point a train can stop at then it is possible with some types of computer assistance software for the software to track where the trains are based on where they came from. 

 

In addition to position detectors (such as Infra Red detectors) the computer needs to know how the points are set. Some DCC systems (I've used this on a NCE Power Pro 5) can report back to a computer the DCC commands sent to the points.

 

The computer assisted system also needs to have allocated an identification for each loco. This can be done by entering the DCC address of a loco into the computer when each loco is placed on the track or by  some remote identification system such as Railcom.

 

If all of the above features are working then trains can be manually switched and mixed with automated timetables/schedules.

 

I've got Train Controller Silver and JMRI but I've yet to try mixing manual switching and automated schedules although I think the McKinley layout does this using Train Controller Silver or Gold. Train Controller (not sure about the Bronze option) claims to be able to mix manual switching and automated schedules.

 

​Yes, its done by logic based on last known location and the state of the points being quickly fed back to the computer.

 

​I've used JMRI to display the state of points on a layout (using a NCE Power Pro 5 and a suitable USB to RS232 adapter). Even if the points are set by an NCE macro selected on a throttle handset JMRI can be set to display the current positions of the points (Thrown or Closed in US parlance).

 

Things can be made less complicated by adding extra Remote Identifiers at key places on the track layout. However commercial remote identification readers seem to be a bit scarce in the UK at the moment. For example I think there are only two Railcom readers with computer interfaces available in the UK at present.

 

If you are into DIY electronics the MERG club have Radio Frequency Identification (RFID) kits and are working with the JMRI group on more choice of computer interfaces for their RFID kits. The present kits work with a particular family of RFID tags the smallest of which is presently 12mm long by 2mm diameter. RFID can be used for Remote Identification but the MERG tags at present can't report the present DCC address of a loco and the readers are position readers rather than detecting the ID of locos in a block - that's what Railcom does. So at present a newly introduced loco has to be pass over an MERG RFID reader before the computer assistance can know its ID - and that ID doesn't tell the computer what the DCC address is directly (although there is technique that will make things easier).

 

​So I think Remote Identification is not as easy as it should be at present. There is a GPS like radio locator and ID system for model trains (from Games On Track) but the transmitters seem large and expensive to me.

 

​However if a layout has its locos left on the track after each operating session then Remote Identification might be dispensed with at least initially.

 

​Bear in mind Railcom remote identification requires Railcom compatible DCC equipment - the Command Station/Booster(s) in particular have to be of a certain design to allow Railcom to work. Each loco decoder needs to be have Railcom as well for full train tracking. Also the track wiring and isolation gaps will need modifying which partially cancels out an advantage of DCC. I'm not sure if Train Controller works out of the box with MERG RFID - I suspect not. 

 

Regards 

 

Nick

Link to post
Share on other sites

......Each loco decoder needs to be have Railcom as well for full train tracking......

 

 

If I may add, NIK.

Apart from locos with RailCom equipped decoders on-board, any loco fitted with a non-RailCom decoder can have a suitable RailCom sender installed to make the loco compatible with RailCom.

 

 

 

 

.

Edited by Ron Ron Ron
Link to post
Share on other sites

 the RS8 signals this change to the DCC system and to TC, and TC does the rest by its tracking logic. 

 

So I am really very sorry for asking this - so you have the LDT RS8 wired up appropriately into a Lenz base station (into the accessory ports). This is internal Lenz proprietary information, but which TC can read and be notified of through the Lenz USB adapter? 

 

If that's the case, then I think I'm clear here - I didn't realise that the feedback/sensors/etc. would be essentially running in a parallel set of wiring back to the station, which would be dependent on whichever DCC vendor you pick. I gather that means that I could use a SPROG with something like TrainController, JMRI or RocRail, but without any feedback functionality I wouldn't get train detection, etc. ?

Link to post
Share on other sites

  • RMweb Gold

There's more than one protocol.  Lenz, for example, use the RS feedback bus and therefore you need feedback modules that support that.  That's why I use the LDT RS8. There are other protocols such as S88 and LocoNet.

 

Have look at the documentation here - https://www.ldt-infocenter.com/dokuwiki/doku.php?id=en:dl_rs_8 - in particular the sample connections document.  It will give you an idea of how the RS8 is wired.  Occupancy detectors from other manufacturers for different protocols will follow similar lines. (It's an old Lenz diagram showing an LV101 and LZ100 which have since been superseded by the combined LZV100).

 

The RS8 feeds back to the Lenz command station and its events are broadcast on the RS bus so that listeners can see the events, listeners being things like LH100 handsets as well as PC connections such as the Lenz LI-USB which connects to your PC. This is how Traincontroller sees the events from the detectors. 

Edited by RFS
  • Like 1
Link to post
Share on other sites

Hi Lacathedrale,

 

I'm not sure there are dozens of software programs offering computer assistance in the form of train tracking and autonomous running of trains to schedules and responding to signals.

 

There are quite a few now that offer a mix of point control, routing, simplistic signal control, schedules for starting trains and crude time based automation.

 

I know of only three that do train tracking and autonomous running of trains including obeying signals: Train Controller, Rocrail and JMRI.

 

Those three all require an extra method of getting information back from sensors to do train tracking and autonomous running of trains. 

 

At present not all new DCC has a method built into the DCC bus of getting sensor information back to a PC or intelligent DCC system although Railcom might have the potential to do this in the future for some Railcom compatible DCC command stations.

 

So at the present day one needs a (separate) feedback bus of some kind and although they exist there is not a single standard unlike DCC.

 

If one is using a PC and its got spare USB ports then there are a number of feedback bus to USB adapters available.

 

Using such an arrangement one is not limited to using the same feedback bus as the DCC command station has although it can be useful in some circumstances to use a compatible bus.

 

So for now one has to add a bus in addition to DCC in order to do train tracking (unless you use Model railway 'GPS' like I mentioned in an earlier post).

 

In order to do most computer assistance the DCC command station needs a computer interface that allows the PC to control and access all required 'functions' - some of which are not accessible without a computer.

 

Not all DCC command stations have computer interfaces and some of those that do have only limited communication with a PC. Some have computer interfaces only for updating the functionality of the command station and not for computer assistance.

 

Probably no computer assistance software for model railways covers all DCC command stations although coverage of commercially made command stations is pretty good across Train Controller, Rocrail and JMRI.

 

I think at present Rocrail and JMRI can be evaluated for free whereas an evaluation copy of Train Controller (Bronze edition) was 99 euros last time I looked. I've had problems with the documentation of both Rocrail and JMRI although I think JMRI has more info on the web.

 

Train Controller has German signal types, JMRI has mainly US signal types and I don't know about Rocrail.

I found Train controller easier to use than JMRI although JMRI includes the option of scripting and runs on a variety of computer operating systems unlike Train Controller which is Windows only.

 

Scripting is useful if one needs to do things the standard software cant do by default. If the scripting language is powerful enough and there is also access to all the data and 'functions' inside the computer assistance software then one can expand the computer assistance until the program reaches the point where its too slow to respond to data inputs & sensors.

 

 

Regards

 

Nick

 

Link to post
Share on other sites

 

Train Controller has German signal types, JMRI has mainly US signal types and I don't know about Rocrail.

I found Train controller easier to use than JMRI although JMRI includes the option of scripting and runs on a variety of computer operating systems unlike Train Controller which is Windows only.

 

 

JMRI has signalling from all over the world, including UK signalling.   ( I know the person who put a lot of the UK signalling into JMRI, quite a few years ago.)

 

Earlier there was mention of a MRC Prodigy, sorry that's one of the "not really computer compatible" systems.  There is very limited support for it in JMRI, but nobody else touches it.  That's mostly due to the maker's reluctance to work with software providers.   If going for computer assisted layout control, chuck it out and get something which plays well with software. 

 

 

- Nigel

Link to post
Share on other sites

  • RMweb Gold

I think at present Rocrail and JMRI can be evaluated for free whereas an evaluation copy of Train Controller (Bronze edition) was 99 euros last time I looked. 

 

You can download any version of Traincontroller (Bronze, Silver or Gold) and run it in evaluation mode. The product has an excellent simulation feature, and you can run this indefinitely on a PC where there is no connection to the layout.  If you want to test for real, you can do so connected to the layout, but you are limited to 15-minute sessions. And you can only do this for a limited number of days. 

 

JMRI and Rocrail are free anyway so there's no need to worry about evaluation limits. 

Link to post
Share on other sites

  • RMweb Premium

Whilst mentioning the DCC systems you can now buy some which are multi-protocol. i.e. you can hook up modules using different manufacturer's bus signals (at the same time.)

I have a Lenz system which uses Xpressnet but I also have a Digikeijs DR5000 which can accept inputs from several different protocols including Xpressnet, S88 & Loconet.

It's €159,95 with power supply but does not come with a handset, you normally use a computer.

Others are available in ascending price!

 

Keith

Link to post
Share on other sites

Hi DoubleDeckInterurban I've used those hardware controllers in the past and they seemed expensive for what they did, which is why I'm interested in JMRI/Traincontroller and a SPROG-USB connector, but I still just can't grasp the kinds of feedback that track detection requires to automate it to the level that's been done.

 

On the other hand, maybe one-engine-in-steam with DC and an isolating block might just keep things simple at this rate, the more I dig the more I see very transient technology stacks and software that already looks 20 years old...

I may go for an app called Withrottle, which I can use on a Moblie Device. It costs around $14.99, and if you are uncertain there is a 'Lite' version that can be used as a trial.

Link to post
Share on other sites

Wow, there's alot of great info here. It seems the Digikeijs DR5000 might be the ticket! Wow! So if I'm reading it correctly, I can connect it up to both a programming track and the layout, and I can use whatever feedback modules I want as long as I wired them into the correct bus connectors on the control station.  I gather that the price is as such because it doesn't have a controller system and will require either computer control or virtual throttles as discussed above? It just seems like it's in a different class to the stuff of last generation.

Link to post
Share on other sites

Rocrail has UK signals too - I put them in there!

 

The way of getting feedback without running a new bus is to use Railcom - you just cannot get much hardware for it unfortunately to do feedback. Otherwise most feedback buses are quire simple and you can get interfaces for most of them without requiring a connection on your command station. RS is probably the simplest of all with just a pair of wires, with most of the others using 6-wire telephone cables or 8-wire Ethernet cables which keeps things simple.

Link to post
Share on other sites

  • RMweb Premium

I'll try Rocrail out too. So just to be clear, I could use the Digikeijs DR5000 alone to both a) control my trains and b) recieve feedback information from whatever subsystem, both via the USB connection to my PC? 

When it has been installed on the PC the DR5000 appears as three USB devices, one Lenz, one Loconet & one DR5000 monitor.

The Railway control software e.g. TrainController can connect to it as if it was a Lenz device or a Loconet device or both.

It has in & out interfaces for several different protocols which can be mixed & matched. All the feedback appears in the same feedback area.

As an example my DR5000 is connected to a load of RS-8 (Lenz Expressnet) block occupancy modules but TrainController is set up to treat them as if they are Loconet modules!

 

As it comes the DR5000 has it's own PC program with which you can control a loco and it's functions, operate points & see occupancy feedback.

The program also has a window which monitors some other items such as track current & internal temperature.

 

It does not have any layout control software of it's own of which several have already been mentioned in previous posts, hence no track diagrams of it's own.

It also has no handset.

 

Keith

Link to post
Share on other sites

The OP touches on a complex issue , DCC automation , paradoxically dcc automation is arguably a good bit more complex then DC as the primary issue is how to communicate loco address so the software can recognise the particular engine.

 

This is the issue you run into when you move dcc locos by hand or using manual overrides.

 

There is only one real solution and that's railcom , but it's very incomplete , particularly the method of getting the data back to the controller

 

In my case I have my own railcom decoder , that interfaces to the MERG CBUS system ( it's still an alpha prototype ) the idea being to implement " local " automation like controlled slow downs , stop on red etc, rather then an all encompassing computer controlled layout. The overall idea being to allow one operator to manage several trains at once

 

 

Implementing a full automatic uk signalled layout with " drive to signals " based on the prototype , is actually very complex. ( try implementing rule 39 (a) for example )

Edited by Junctionmad
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...