Newbie Question - DCC/Computer Control

[Alan Kettlewell]

10 hours ago, Andymsa said:

 

Hi alan,

 

you used the kibri kit Kiel for the station, that's exactly what I'm thinking of doing so is good to see an example of it in use.

 

andy

 

Hi Andy,

 

It's a great kit and goes together really well.  I couldn't fit it all in one straight line as my road bridge isn't quite long enough so I positioned it with the Post Office turned through 90 degrees at the far end.  It comes with a sample lighting system from Vollmer but you only get 4 lights ie 4 rooms can be lit, so it could be much enhanced if you buy a few more lights.

 

Cheers … Alan

[Wordsmith]

On 19/08/2019 at 06:49, WIMorrison said:

@Wordsmith

1.  Do you want to have Railcom for automatic loco identification on your automation program?  Often dismissed by people not familiar with the benefits of Railcom on an automated layout I would consider this as a must for any new layout.

So, I was working through this list of questions, and I focused on the above one. 

 

https://www.locgeek.com/2012/10/railcom-railcom-plus-what-are-these/

 

So, it looks as if Railcom/RailcomPlus provides feedback for an DCC controller/computer controlled layout, but what is the actual benefit for a computer controlled layout? A little bit of further research suggests that Railcom ties in with breaking up the track into sections and using a feedback module to determine whether a section is occupied or vacant. Railcom then enables block control and more, plus scripting of locomotive movements. Have I got that right?

 

I presume Railcom ties me in with a sub set of manufacturers - not all DCC equipment manufacturers support Railcom. So , if I want to use Railcom, I have to use a compatible controller?

 

Finally, is there a decent book available on computer control for model railways? I had a look on Amazon, but there wasn't a stand out choice. I found books on many aspects of railway modelling, but not computer control.

 

Cheers,

 

Wordsmith

 

 

 

 

 

 

 

 

 

 

[melmerby]

On 19/08/2019 at 06:49, WIMorrison said:

1. Do you want to have Railcom for automatic loco identification on your automation program?  Often dismissed by people not familiar with the benefits of Railcom on an automated layout I would consider this as a must for any new layout

 

Hi Iain

You didn't say why you consider it a must for automation.

 

[WIMorrison]

Keith,

 

Railcom (or Railcom Plus) is not a MUST for automation using computer software however it does bring significant advantages.

 

With Railcom you have a positive identification of where each Loco is by DCC Number which has the significant advantage of the software knowing which train is where through positive feedback of location within a feedback rather than by the optimistic assumption used when Railcom is not present. If you move anything manually - either with the software disconnected using a DCC Controller, or even simply by picking it up and placing it elsewhere then Railcom will identify that loco (and the attached train) when you reconnect the layout to the computer placing it in the correct position on the layout mimic - without Railcom this must be done manually for any loco or train that has been moved manually. It is also very beneficial if you take locos on and off the layout because when you place it on the layout the software will instantly show that you have placed x or y on the layout.

 

The next advantage is the ability to read and write CVs using POM, I know that you can write CV using POM without Railcom but being able to read them is very useful, especially when tuning motor parameters to get the smoothest running motor.

 

Personally I would not be without it now - you can see here the one loco that doesn't have Railcom yet, compared to the positive identification of the others on my Alpine Narrow Gauge layout.

 

 

 

[melmerby]

4 hours ago, WIMorrison said:

Keith,

 

Railcom (or Railcom Plus) is not a MUST for automation using computer software however it does bring significant advantages.

 

With Railcom you have a positive identification of where each Loco is by DCC Number which has the significant advantage of the software knowing which train is where through positive feedback of location within a feedback rather than by the optimistic assumption used when Railcom is not present. If you move anything manually - either with the software disconnected using a DCC Controller, or even simply by picking it up and placing it elsewhere then Railcom will identify that loco (and the attached train) when you reconnect the layout to the computer placing it in the correct position on the layout mimic - without Railcom this must be done manually for any loco or train that has been moved manually. It is also very beneficial if you take locos on and off the layout because when you place it on the layout the software will instantly show that you have placed x or y on the layout.

 

The next advantage is the ability to read and write CVs using POM, I know that you can write CV using POM without Railcom but being able to read them is very useful, especially when tuning motor parameters to get the smoothest running motor.

 

Personally I would not be without it now - you can see here the one loco that doesn't have Railcom yet, compared to the positive identification of the others on my Alpine Narrow Gauge layout.

 

Hi Iain

I agree about the advantages but as yet I haven't found a overwhelming need (personally) to go for it.

I don't find the odd occasion when I need to re-allocate much of a problem.

As to programming, I use JMRI to keep my roster details and loco programming CVs so never consider POM

I just lift the loco from one track to the other change the CV then put it back, TC doesn't remove it from the diagram when you are programming.

When using the Z21 I always have the computer up and running, manual moves are always done whilst TC is up and running and it tracks the moves.

 

I'm not familiar with how iTrain identifies things but I assume the unfitted one is the "Long Timber", not showing an adjacent number.

[WIMorrison]

Keith

 

I guess that for most people Railcom is a bit like a microwave - if you don't have one and have never used one then you will never miss it, once you have one then you wonder how you managed without it

 

Iain

[Junctionmad]

On 20/08/2019 at 17:09, MikeH_83 said:

Out of interest, Does anyone run computer control combined with multiple touchscreen monitors?  I have been thinking about it as a setup recently so that I can also use the monitors as a switchboard etc when I want to take control.  Just wanted to see if anyone has tried it and if there are any suggestions for equipment etc. 

 

Cheers

As someone who has developed a prototype Railcom detector , I would say that the “ promise “ of Railcom is not always delivered 

 

firstly Railcom in itself does not know where the loco is , this still requires TOTI , ( train on track indication ) , ie you have to break up your track into electrical “ detection “ sections etc , with all the attendant wiring. 

 

Secondly all Railcom does in this context is add confirmation of the loco dcc address to the occupancy information. Both TC and iTrain maintain a “ memory map “ of trains on the layout and don’t actually need the confirmation . Manual loco moves are done in conjunction with the software and hence are tracked also. 

 

To my knowledge neither TC or iTrain will handle the “hand of god “ loco  relocation issue without telling the software manually whether Railcom is present or not 

 

reading Cvs on the main is a “ nice to have “ but it’s not a great justification for Railcom per se. 

 

The auto “ registration “ feature of Railcom plus is a proprietary extension to Railcom and is only available to its licensees ( Esu ) it’s somewhat of a gimmick as new dcc locos are not just “ dropped “ onto a typical dcc layout as these days you have to set up buttons for sound , lights etc etc. 

 

Track occupancy detection is of great benefit to automation software as it can be used to confirm the “ memory map “ or to allow the software to correct that “ map “ , Railcom actually doesn’t bring a whole lot extra to the party in my experience 

 

there are other issues like the issue of propelling , where the Railcom dcc address is effectively late in being acquired etc. 

 

Railcom “ could “ be expanded to provide lots of useful info but the state of the so-called NMRA spec ( “ under review since 2012 !!!) has stymied development and consistent features and lenzs approach hasn’t helped either . The USA controller industry has effectively abandoned Railcom and the European approach is piecemeal 

 

my advice is to be aware of  Railcom but I wouldn’t overly focus on it or consider it at all necessary for good automation  

 

Dave 

Edited August 29, 2019 by Junctionmad

[WIMorrison]

34 minutes ago, Junctionmad said:

 

...

To my knowledge neither TC or iTrain will handle the “hand of god “ loco  relocation issue without telling the software manually whether Railcom is present or not 

...

 

 

iTrain definitely understands the 'hand of God' relocation issue automatically when Railcom is present and IIRC from my TC9 testing it will also handle the manual relocation automatically. In the case of iTrain when you plonk the loco down the mimic panel will immediately show that train in the feedback.

 

In iTrain if you have a Railcom+ command station then all details are automatically imported into iTrain, I suspect that TC9 also offers this capability.

 

The need to break the track up into feedbacks which then form blocks is fundamental to any software automation system as the software is simply moving the train from one feedback to the next feedback in the route which may (or may not) require turnouts to be changed, signal to be operated, or a series of others actions to be performed. With Railcom the software has positive conformation that loco #x has arrived in the feedback or block, without Railcom the software can only assume that what it was expecting to arrive has arrived.

 

 

Edited August 29, 2019 by WIMorrison

[Phil S]

On the Continent - as that area to the east of the UK was once known - 2-rail has to compete against '3rail' (ie centre stud) contact from Marklin and they have Mfx(R( which does all that Railcom /+ does - including automatically allocating identifying a newly added loco and allocating its buttons ... the advantage of a single company rather than competitive committee approach.  Therefore there is an established threshold of features to compete against in the 2-rail v '3-rail' market. Most Marklin, and all competitors 3-rail versions of locos come ready equipped with a decoder  (not necessarily Mfx compatible ...and  called M4 when not in Marklin product) .... as the decoder provides the electronic interface to the ac/3-rail.  (ESU makes  multi-standard locos: 2/3 rail with the user fitting the central shoe if desired - instead of having to stock 2 rail and 3 rail versions.) .

 

For my loft layout - where I have no isolated sections for the purpose of Block/tracking, I have Hector IR detectors (as a separate system to the track dcc) and this is supplemented by RFid tags being read on the exits from any area where train formation is expected to change - ie the storage area and terminal stations.

However, for our (trans)portable H0 layout I intend using Railcom on 1 or 2 boards - feeding via the Digikeijs modules - but otherwise retain the optical detection for tracking movement... its predecessor layout was used as my test bed for the Hectors intended for the loft layout ... and I miss the tracking display on the current H0 layout !   ... as Ian suggests ... you miss a feature once you have (successfully) used it 8-)

[Crosland]

On 27/08/2019 at 22:36, Wordsmith said:

So, I was working through this list of questions, and I focused on the above one. 

 

https://www.locgeek.com/2012/10/railcom-railcom-plus-what-are-these/

 

The first diagram is wrong.

 

The programming track allows full read/write of CVs.

 

[RAF96]

Also not all controllers need an ack such as a motor pulse for programming. Hornby Elite can program dummy cars without a motor or having to double up with a motor car.

Edited August 29, 2019 by RAF96
Typo

[jamespetts]

TrainController 9 does allow for RailCom detection  of locomotives placed on the track without further manual intervention. For locomotives removed from the track, it seems to retain a sort of shadow occupancy, and will assume that any non-RailCom equipped locomotive placed in the section from which a locomotive was removed is occupied by the previous locomotive.

[Wordsmith]

On 19/08/2019 at 06:49, WIMorrison said:

@Wordsmith

 

Considerations are

1. What control protocol do you wish to use?  LocoNet has the best range of products available, but RS Bus, RBus, Xpressnet, CBus, Canbus, S88 are all options and there are very few systems that support multiple protocols

 

Thanks all for previous replies. I can see the logic of using Railcom to set up a feedback loop. I'd idly set my sights of coming up with a computer controlled layout, and without some sort of feedback, debugging an hour's program of train movements to find the error in the code might be a PITA. Incidentally, I've just watched some of the videos, which gave me an idea of what you could you could do with computer control - particularly with Jame's video, which showed some shunting movements. A distant ambition is to shunt a small (mid 1930's) goods yard automatically, which I suspect might be pushing the limits of the technology.

 

On first reading, I got the impression that DCC used a single protocol, but I found this on Wiki. 

 

https://en.wikipedia.org/wiki/Digital_Command_Control

Quote

There are two main European alternatives: Selectrix, an open Normen Europäischer Modellbahnen (NEM) standard, and the Märklin Digital proprietary system. The US Rail-Lynx system provides power with a fixed voltage to the rails while commands are sent digitally using infrared light. Other systems include the Digital Command System and Trainmaster Command Control.

 

Several major manufacturers (including Märklin, Roco, Hornby and Bachmann), have entered the DCC market alongside makers which specialize in it (including Lenz, Digitrax, ESU, ZIMO, Kühn, Tams, North Coast Engineering (NCE), and CVP Products' EasyDCC, Sound Traxx, Lok Sound, Train Control Systems and ZTC). Most Selectrix central units are multi protocol units supporting DCC fully or partially (e.g. Rautenhaus, Stärz and MTTM).

 

So how compatible ate the different system with one another?

 

And is it a case of picking a DCC manufacturer and sticking with it, and can there be a degree of mix and match?

 

Finally, how tied is the choice of accessories (such as decoders) to the choice of DCC controller? Will decoder's from manufacturers A, B and C, work with DCC manufacturer X, or will manufacturer X's stuff only work reliably with Decoder A?

 

Thanks in advance for the replies - this thread is proving educational.

 

Wordsmith

[Sol]

I use decoders from many different manufacturers with my NCE command station OK - that is the concept that Lenz started years ago.

And a modeller her in South Australia using Lenz & railroad & Co software, crteae an automatic shunting layout, even to the extend of remote uncoupling of Kadee couplings

 

[melmerby]

2 hours ago, Wordsmith said:

 

Thanks all for previous replies. I can see the logic of using Railcom to set up a feedback loop. I'd idly set my sights of coming up with a computer controlled layout, and without some sort of feedback, debugging an hour's program of train movements to find the error in the code might be a PITA. Incidentally, I've just watched some of the videos, which gave me an idea of what you could you could do with computer control - particularly with Jame's video, which showed some shunting movements. A distant ambition is to shunt a small (mid 1930's) goods yard automatically, which I suspect might be pushing the limits of the technology.

 

On first reading, I got the impression that DCC used a single protocol, but I found this on Wiki. 

 

https://en.wikipedia.org/wiki/Digital_Command_Control

 

So how compatible ate the different system with one another?

 

And is it a case of picking a DCC manufacturer and sticking with it, and can there be a degree of mix and match?

 

Finally, how tied is the choice of accessories (such as decoders) to the choice of DCC controller? Will decoder's from manufacturers A, B and C, work with DCC manufacturer X, or will manufacturer X's stuff only work reliably with Decoder A?

 

Thanks in advance for the replies - this thread is proving educational.

 

Wordsmith

A regards the shunting, you could certainly do that as the program will add or remove "cars" from a train, which with calibrated speed and known length of vehicles the exact positions give or take a small error would be calculated.

 

I have a couple of routines where fully automatically a train pulls into the terminus, loco uncouples, a second loco arrives from the shed and couples to the other end of the train, which the departs. The first loco now moves onto shed, is turned and ready to couple to the next train into the station

Another has a loco uncouple, run around its train and couples on the other end ready for departure.

However complex moves can involve a lot of programming and tweaking to get them to work correctly.

 

All decoders that are operated by the DCC signal should work with any command station if they both meet the NMRA specification. (I believe all now do)

Those are such as loco decoders, point decoders, signal decoders etc.

(Note that the orignal Hornby R8215 loco decoder would work with only a few command stations as it didn't fully conform to the spec, neither originally did the Hornby Select controller.)

 

Feedback devices for such things as occupation detection or turnout position monitoring are connected to a feedback bus which can be of many different specifications.

(You don't even need to use the same controller or even same type/make of controller to monitor feedback, currently I have a Z21 driving the trains and a Lenz 100 system monitoring feedback.)

Lenz have the "RS" feedback bus, Digitrax have the "Loconet" bus, there is also the "CAN" bus and various others.

They are generally not compatible to one another, however third party manufacturers have devices that will convert from certain feedback busses to others.

 

N.B. A Loconet bus is more versatile than just feedback and offers control of accessories and for adding extra throttles.

 

Edited September 1, 2019 by melmerby

[WIMorrison]

DCC is actually a trademark owned by NMRA and as you have found it is one of several ‘standards’ - more accurately methods - for achieving Digital Command Control. That said what is generally referred to as DCC is probably the most common method of control globally and within the UK.

 

 

[NIK]

Hi,

 

I thought I'd add a few words about computer controlled shunting.

 

I think most of the technology to do realistic (as good as the best exhibition) shunting is too expensive at present.

 

Some DCC decoders include features to allow a DCC controlled uncoupler to be operated by a function button and the loco to perform a shuffle to uncouple from the next vehicle. 

 

The bit that I think is expensive is a general purpose high resolution detection system so that locos and rolling stock can be positioned accurately.

This could be done with a ranging 3D camera (such as Intel make) plus a recent Intel CPU computer. Approximate cost £1000 per 4' by 3' baseboard (OO models).

Integration with existing commercial model railway automation software might be difficult.

 

Alternative computer vision might be more affordable. The new Raspberry Pi 4B single board computer (base model £34 for 'motherboard') may be powerful enough to recognise individual model railway vehicles.

 

I see the technical challenge is the difficult cases such as a wagon carrying track panels which to a camera mounted over the baseboard might look like the track is unoccupied - might be able to use the movement of the wagon to separate its image from the background or use shadows for the same purpose.

 

 

Regards

 

Nick

 

 

 

 

[melmerby]

1 hour ago, NIK said:

Hi,

 

I thought I'd add a few words about computer controlled shunting.

The bit that I think is expensive is a general purpose high resolution detection system so that locos and rolling stock can be positioned accurately.
 

Regards

 

Nick

 

How accurate do you want?

 

[NIK]

30 minutes ago, melmerby said:

How accurate do you want?

 

Hi,

 

If using remote uncouplers such as Spratt and Winkle then an accuracy of a few millimetres to uncouple a vehicle over a magnet. To couple together vehicles with any coupling system an accuracy of a millimetre might be needed (OO) (to avoid the stationary vehicles moving excessively during the coupling operation).

 

Regards

 

Nick

[jamespetts]

For uncoupling, the degree of accuracy required depends on the length of the uncoupler (often a magnet). For coupling, the accuracy required depends on the level of tolerance for the rolling stock being pushed backwards.

 

It is not necessary to use depth sensing cameras or DCC powered uncouplers to shunt using computer automation: see the video that I posted above showing such shunting working without either of these technologies. The DCC powered uncouplers may well make uncoupling easier (either when automated or human controlled) than using track based uncouplers and is an interesting technology generally, although its commercial availability is currently limited. As to depth sensing technology, has anyone tried this for model railway operations?

[Wordsmith]

I always anticipated that shunting would be be pushing it, especially for N gauge. Some parts appear more difficult than others. For example:

1. Loco come in off main line with wagons for shunting, goes into head shunt, then reverses in sorting siding. It can then detach itself from the wagons by moving extremely slowly forward again over an activated magnetic de-coupler.
2. Ditto the shunting engine splitting (say) 12 wagons into groups of four: same method - forward slowly over magnetic de-coupler and leave unwanted wagons behind.
3. The problem would seem to occur with sorting single wagons - positioning accuracy needed would seem to be +/- 2 mm.

I'm coming back in to this as a hobby after 50 odd years, so I can only make wild guesses as to what is possible, but I'm hoping it will be possible to start with basics - drop off 12 wagons/pick up 12 wagons - and gradually push the boundaries.

 

(I like problem solving - we'll see if I've bitten off more than I can chew).

 

Wordsmith

 

 

[melmerby]

9 minutes ago, Wordsmith said:

I always anticipated that shunting would be be pushing it, especially for N gauge. Some parts appear more difficult than others. For example:

1. Loco come in off main line with wagons for shunting, goes into head shunt, then reverses in sorting siding. It can then detach itself from the wagons by moving extremely slowly forward again over an activated magnetic de-coupler.
2. Ditto the shunting engine splitting (say) 12 wagons into groups of four: same method - forward slowly over magnetic de-coupler and leave unwanted wagons behind.
3. The problem would seem to occur with sorting single wagons - positioning accuracy needed would seem to be +/- 2 mm.

I'm coming back in to this as a hobby after 50 odd years, so I can only make wild guesses as to what is possible, but I'm hoping it will be possible to start with basics - drop off 12 wagons/pick up 12 wagons - and gradually push the boundaries.

 

(I like problem solving - we'll see if I've bitten off more than I can chew).

 

Wordsmith

 

 

If using 00 and Kadees the tolerance is much more than a couple of mm as the magnets are effective for about 50mm and the couplers can open over most of that distance.

With Kadees you need to do the well known "shuffle" as the couplings will only completely part* once you move away again for a short distance, then you can push the wagon to it's desired positioin.

 

* just a few mm and still over the magnet and then they will be in "delayed" position, so you can push, they will not re-couple.

Edited September 2, 2019 by melmerby

[NIK]

6 hours ago, jamespetts said:

For uncoupling, the degree of accuracy required depends on the length of the uncoupler (often a magnet). For coupling, the accuracy required depends on the level of tolerance for the rolling stock being pushed backwards.

 

It is not necessary to use depth sensing cameras or DCC powered uncouplers to shunt using computer automation: see the video that I posted above showing such shunting working without either of these technologies. The DCC powered uncouplers may well make uncoupling easier (either when automated or human controlled) than using track based uncouplers and is an interesting technology generally, although its commercial availability is currently limited. As to depth sensing technology, has anyone tried this for model railway operations?

Hi,

 

I can't find a video on any of your posts in this topic.

 

I haven't tried depth sensing a whole baseboard due to the high cost and I haven't got an application for that level of automation. I've bought some miniature infrared ranging laser modules (approx. £4 each) for sensing where the end of a train is with respect to the buffers but that is a very specific application.

 

For hidden fiddle yards I've been trying computer vision using the obscured pattern technique. I've tried putting black printed strips with white squares on them and placed between the rails. I tried a Raspberry Pi 3B/Pi Cam using OpenCV software to recognise the white squares and reject as many other patterns as possible. When a white square disappears its assumed there is a train over it. The latency of the system was well over 100ms at times and I've yet to find out why - it seemed to be in the sending of the X,Y (only 10s of Kilobyes per second) info over Wifi.

 

I've now bought a Pixy2 camera with some built in object recognition which is said to be able to recognise and report the X,Y coordinates of up to 200 identical coloured shapes at 60 frames per second. It also works by using hue rather than RGB so may be more tolerant of lighting conditions.

 

Regards

 

Nick

 

 

 

 

[jamespetts]

2 minutes ago, NIK said:

Hi,

 

I can't find a video on any of your posts in this topic.

 

I haven't tried depth sensing a whole baseboard due to the high cost and I haven't got an application for that level of automation. I've bought some miniature infrared ranging laser modules (approx. £4 each) for sensing where the end of a train is with respect to the buffers but that is a very specific application.

 

For hidden fiddle yards I've been trying computer vision using the obscured pattern technique. I've tried putting black printed strips with white squares on them and placed between the rails. I tried a Raspberry Pi 3B/Pi Cam using OpenCV software to recognise the white squares and reject as many other patterns as possible. When a white square disappears its assumed there is a train over it. The latency of the system was well over 100ms at times and I've yet to find out why - it seemed to be in the sending of the X,Y (only 10s of Kilobyes per second) info over Wifi.

 

I've now bought a Pixy2 camera with some built in object recognition which is said to be able to recognise and report the X,Y coordinates of up to 200 identical coloured shapes at 60 frames per second. It also works by using hue rather than RGB so may be more tolerant of lighting conditions.

 

Regards

 

Nick

 

 

 

 

My apologies: I must have omitted to link to it. It is here.

 

If you have a video of your depth sensing system, that would be very interesting to see.

[NIK]

Hi James,

 

I don't have a video of using the IR laser ranging modules - I tend to rush my projects. I'm planning to try them out on a club layout in some sidings that can't be seen by the public (or the goods yard operator if they sit at the front of the layout) so I may be able to make a video then. I hope to interface them to MERG CBUS as the layout is going to have CBUS added for feedback.

 

The actual Infrared laser ranging chips are small enough to fit in a OO buffer beam but they are surface mount and the electrical pads are on the back of the chip so are difficult to connect to- hence the use of small modules (from China).

 

Regards

 

Nick