Benefits of computer control?

[Robin2]

I have figured out that I can control my locomotives with my own software by connecting my pc to my Hornby Elite controller  and I suspect that I should be able to write a control program that is much more flexible than using a "proper" controller.

 

I suspect I am not the only one who is interested in computer programming as well as trains.

 

For example,

 

• It should be easier to set up acceleration and braking patterns on the PC.

• It would be possible to have separate brake and throttle controls. Shutting the throttle would only slow the train a little - you would need to use the brake to stop it. And using the brake without shutting the throttle would not be effective either.

• It would be easy to make the acceleration and braking vary with the number of carriages or the number of locomotives.

• I'm not sure how sound and lights work as I am probably not going to use them in N gauge. From bits I've read it seems that some of the decoder chips are programmed with the same numbers as the locomotive. A computer could easily and "invisibly"  send instructions to several chips at what would seem to be the same time, or even in a preferred order. For example the engine sound of a diesel electric could rise to max before the train moved.

 

 

I was really annoyed to discover that the knobs on the Hornby Elite spin round and round rather than going from 0 to 10. It means you have no way to know where you have set the train speed. That meant that I had sort of "parked" my modelling for several months.

 

Then I saw the article in Model Rail November about the Sprog controller and it occurred to me to see if I could use the Elite as a computer interface to avoid buying a Sprog. The Elite seems to work fine.

 

I would be interested to hear comments from more experienced DCC users or from anyone interested in doing his/her own programming.

 

 

[martinbv]

Unless you enjoy writing computer programs more than running trains why not first see what others have done - there is a lot out there both commercial and free.

 

You might want to start looking at JMRI

 

http://jmri.sourceforge.net/

 

OR here

 

http://www.qtutrains.com/index.php

[Robin2]

You are right Martin, I do like programming as much as I like trains.

 

I have the JMRI software, but it seems to me to be designed to work with the normal usage of decoders rather than to substitute for them.

 

I just want a small piece of software that operates as a throttle.

[Steven B]

I have the JMRI software, but it seems to me to be designed to work with the normal usage of decoders rather than to substitute for them.

I just want a small piece of software that operates as a throttle.

 

JMRI has a unit that does just that. DCC addresses can be entered manually or selected from a drop-down menu if you also use it for programming CVs. Other than that it's a set of buttons for turning functions on/off and a slider for controlling the speed.

 

It works with a Sprog2, no idea about a Hornby Elite.

 

Happy modelling.

 

Steven B.

[Robin2]

Perhaps my original post was not as clear as I thought.

 

I would like to make contact with people who are interested in computer programming as well as railway modelling and who would like to try (or are already) writing their own programs rather than using JMRI etc. (Not that there is anything wrong with JMRI but just because DIY programming is fun).

 

 

What I have in mind is that the performance of the locomotive would be modelled in the PC software rather than in the CVs of the decoder chip. The decoder chip could be set to give instant response (no momentum etc) and the PC program would delay the speeding up or slowing down. For example the PC would "know" that if I select full power it should actually be applied in steps over a period of (say) 5 seconds and the PC would send a series of step-by-step speed increases to the locomotive.

 

Changing the amount of "momentum" could then be done without reprogramming the decoder chip. In effect all the decoder chip would be routing the instructions to the correct locomotive.

 

Also I think it might be useful to get up to speed instantly - for example so that a train emerging from a hidden fiddle yard would appear in the viewable area at full speed but would behave with realistic acceleration and braking while in view.

 

If there was a box for entering the number of carriages on a train the acceleration could be reduced for the "heavier" load. And it would be a simple matter of setting the number of carriages to 0 when the locomotive was detached from the train so that it could behave like a light locomotive.

 

I have the feeling that this approach to computer control could be much more flexible than what you get by programming the CVs of the locomotive decoder chips.

 

 

[sncf141r]

Hi Robin2;

 

I, too, find the conventional DCC controls "interesting". I do have quite a bit of full sized preservation railway background; am licensed by the province of Ontario here in Canada to do full sized steam operation of locomotives and steam tractors, etc.

 

I understand where you are coming from; eg, flange squeal comes from running, not from pressing a button! Same with "coupler clank". Same with "momentum", etc. Don't know how one would simulate the feel of the real size in model, though!

 

 

Keep going, you never know exactly where you'll end up;

 

JohnS.

[Edwin_m]

Certainly this is possible because the (expensive) Railroad and Co software works in this way.

 

An alternative might be to use programming on the main so that your computer can change the acceleration rate CV on a particular loco when its load changes, or it enters/leaves the fiddle yard etc. This might reduce workload on the computer and traffic on the interface.

 

I believe JMRI and RocRail are open source communities so anyone can add to or modify their software and make it available to other users. Might adding some new functionality to one of these be a better way forward than starting from scratch on your own?

[Matt Harris]

Perhaps my original post was not as clear as I thought.

 

I would like to make contact with people who are interested in computer programming as well as railway modelling and who would like to try (or are already) writing their own programs rather than using JMRI etc. (Not that there is anything wrong with JMRI but just because DIY programming is fun).

 

I must say that I am also interested in computer programming as well as railway modelling.

 

However, rather than write stuff purely for myself, I decided to contribute to JMRI.

 

 

What I have in mind is that the performance of the locomotive would be modelled in the PC software rather than in the CVs of the decoder chip. The decoder chip could be set to give instant response (no momentum etc) and the PC program would delay the speeding up or slowing down. For example the PC would "know" that if I select full power it should actually be applied in steps over a period of (say) 5 seconds and the PC would send a series of step-by-step speed increases to the locomotive.

 

Changing the amount of "momentum" could then be done without reprogramming the decoder chip. In effect all the decoder chip would be routing the instructions to the correct locomotive.

 

Also I think it might be useful to get up to speed instantly - for example so that a train emerging from a hidden fiddle yard would appear in the viewable area at full speed but would behave with realistic acceleration and braking while in view.

 

If there was a box for entering the number of carriages on a train the acceleration could be reduced for the "heavier" load. And it would be a simple matter of setting the number of carriages to 0 when the locomotive was detached from the train so that it could behave like a light locomotive.

 

I have the feeling that this approach to computer control could be much more flexible than what you get by programming the CVs of the locomotive decoder chips.

 

 

This sounds like something that could be achieved in JMRI via Jython scripting using the existing throttle classes, or going straight to Java code.

 

Elements of the existing scripts, such as RobotThrottle and AutoDispatcher could help provide initial pointers for, at least, some of the lower level interactions with the jmri throttle classes.

 

Best regards,

 

Matt H

[Ian J.]

The single biggest problem I can see trying to directly control the locomotive from a computer in all respects and not have the DCC decoder do any of the work itself is that you'll likely very quickly overload the DCC track bus. It simply doesn't have the bandwidth or speed to take all those commands being sent out.

 

I am also interested in PC based control, but actually want to offload even more control to the decoder rather than the opposite that you are looking to do. But I can only look at doing such offloading when they start putting a good size memory into decoders, and provide much more in the way of speed and distance information directly with in the decoder. In effect, I want to use the decoder as it's own A.I. driver, working to a set of instructions pre-downloaded into it.

 

The PC program I have in mind to provide that information is a variant on the TOPS system, which I've got a semi-working prototype for, but only in the basic database sense at the moment. It requires a hell of a lot more work to get it even somewhere near to a TOPS style system, and I've got so much other stuff to do that it's going to be one of those 'I'll get round to it one day' projects.

[Robin2]

I greatly admire anyone who can make sense of the hundreds (thousands?) of files that make up the jmri software but life is too short for me to try.

 

I like programming in Ruby - Java looks too much like C

 

 

Also, I have no plans to produce something that will rival the breadth of JMRI

 

 

 

 

On the question of overloading the system, Xpressnet claims to be able to service 1000 requests per second. I can't imagine getting anywhere near that with 2 or 3 locomotives.

 

 

[Etched Pixels]

JMRI is a bit of a beast - I'm slowly plotting away at adding a proper DCC network stack to the Linux kernel so it would be exposed as a socket family. It moves very slowly however as I have other more interesting projects.

 

DC computer control is also quite doable. Cwm Bach was DC computer controlled. The train control was via a motormind B (designed for robot work - a great source of computer control bits), combined with a set of light sensors under the track, relays etc wired to a serial<->IO control breakout box., everything just talked to some serial ports.

 

You can do something like DCC entirely in application software with the Sprog USB controller if so minded

[beast66606]

"Java looks like C" - you've never experienced the "Joy of C" (was that a book ) then - strangely I've just been looking at some C comms software I wrote in the 1990s, trying to remember what I was thinking of

 

One day I might get some motivation for home grown control of the trains but at the moment RailRoad and Co does what we (WFRM) want (signal box emulation) and the MILF needs more development for MILF2011, however I will be interested in reading about any progress.