Railmagic

[martin_wynne]

35 minutes ago, Railmagic said:

 

My lack of native English might be an issue here, but do you mean stud-contacts as in Märklin M-tracks? Then it works. The base of M-tracks are not magnetic.

 

Yes, studs between the rails for power. My post was not intended to be taken seriously, sorry. UK readers would have twigged that.

 

The more sensible question would be -- will it work for a garden railway in Gauge 1 over concrete viaducts and trackbed?

 

Martin.

[RFS]

1 hour ago, Railmagic said:

 

Thanks RFS for sharing details about your setup. With more engines than blocks the price will favor computer control over Railmagic, but it also indicates that your layout is crowded. The tracker costs around 2-4% of the price of an engine.

 

We're not like the real railway where only enough engines are purchased to run the service. Model railroaders have collections and usually far more than they need. In my case, only about half are in use at any one time, with the rest in the loco shed. It allows me to change things round to provide an interesting variety. In your example on the web-site, I don't believe anyone with a layout as large as 256 blocks would only have 60 engines!

[Andymsa]

25 minutes ago, RFS said:

 

We're not like the real railway where only enough engines are purchased to run the service. Model railroaders have collections and usually far more than they need. In my case, only about half are in use at any one time, with the rest in the loco shed. It allows me to change things round to provide an interesting variety. In your example on the web-site, I don't believe anyone with a layout as large as 256 blocks would only have 60 engines!

I have 820 detected sections and around 400 locos, emus, dmus 

[Andymsa]

2 hours ago, Railmagic said:

 

Thanks RFS for sharing details about your setup. With more engines than blocks the price will favor computer control over Railmagic, but it also indicates that your layout is crowded. The tracker costs around 2-4% of the price of an engine.

 

Railmagic will eventually be able to do more than computer control system can do, so be careful when comparing one-to-one. But to sum-up all features is wrong. They overlap. It's of course my job to make that clear for customers. For example, if you buy the Routing Automation feature, you will not need many of the other ones. Most users would spend maximum £100 on features.

 

For someone just starting to collect model trains, Railmagic should be a better alternative. For someone with a working computer control, there will always be issues to point at. It is fully understandable. Humans will always defend what they know and resist the unknown. Didn't you for example forget to tell that you have to make the wheels of your wagons conductive? Some people have difficulties climbing underneath the layout whereas the trackers can be installed by friends/shops. Because the system approaches are so difference I don't think the battle between pros./cons. brings any clearness.

I be interested to know how railmagic will be able to do more than current computer control?

[Railmagic]

19 minutes ago, RFS said:

 

Traincontroller has only needed one detector per block since version 5 from 2006. That became possible when decoders started to have accurate Back EMF. With Traincontroller you profile the speed of every engine, so TC is able to calculate how far the train travels based on the current speed step. There are brake and stop markers in every block, but these are simply offsets from the start of the block. So if a train has to stop in a block TC knows from the profile how to slow down the train and arrive accurately at the stop marker. Also, as it knows the train length it can also calculate when the train has cleared the previous block. (I do use resistor wheel sets on the last vehicle of every train, but this is only to protect against malfunctions, for example a coupling failure that causes the train to split in two.)

 

Here is an example of one of my engines - vertical axis is speed (miles per hour) and horizontal axis is DCC speed step.

 

 

 

Thanks a lot RFS. Then it works as I assumed (I have been researching). The point here is that the majority of people reading this topic didn't know it. Thank you again for bringing everyone aligned.

 

Then I want to conclude:

 

1) Both Railmagic and computer control demand decoders with back-EMF, though the demand for decoders is reasonable.

2) Both Railmagic and computer control use the length of the train to clear previous blocks.

3) The accuracy of computer control comes from back-EMF, calibration data and known fixed locations. So does Railmagic just that is got more fixed locations. Though it is reasonable to assume that Railmagic is at least as precise as computer control, as long as the principle of using magnets works.

 

[martin_wynne]

Nowadays the prototype uses axle counters instead of track circuits. Is there a model system using axle counters?

 

Martin.

[KingEdwardII]

3 hours ago, Andymsa said:

I’m not that keen on things that require router access

My experience of connecting my layout via the home router is that it is very good.

 

I have no problems with latency or with congestion on the network. Modern routers are generally more than capable of handling the traffic in a typical home, even where streaming video is being used. If the home router is old and is unable to cope with the traffic, then it's time for an upgrade, IMHO - and nothing to do with the model railway.

 

The advantage of using a home router is that equipment like smartphones and Raspberry Pi used to control the model railway also need access to the internet at the same time.

 

Yours,  Mike.

[Andymsa]

2 hours ago, RFS said:

 

Traincontroller has only needed one detector per block since version 5 from 2006. That became possible when decoders started to have accurate Back EMF. With Traincontroller you profile the speed of every engine, so TC is able to calculate how far the train travels based on the current speed step. There are brake and stop markers in every block, but these are simply offsets from the start of the block. So if a train has to stop in a block TC knows from the profile how to slow down the train and arrive accurately at the stop marker. Also, as it knows the train length it can also calculate when the train has cleared the previous block. (I do use resistor wheel sets on the last vehicle of every train, but this is only to protect against malfunctions, for example a coupling failure that causes the train to split in two.)

 

Here is an example of one of my engines - vertical axis is speed (miles per hour) and horizontal axis is DCC speed step.

 

 

I notice that the maximum speed step is not near the maximum speed set in your example?

 

Although technically correct that at a minimum only one detector is needed, I believe the more you have the more accurate stopping is achieved, as over longer distances greater errors can occur. 

[Railmagic]

19 minutes ago, Andymsa said:

I be interested to know how railmagic will be able to do more than current computer control?

 

Computer control relays on the deceleration profile in the decoder, therefore the braking is the same for a train independently on the number of wagons attached. Railmagic can brake with any profile and make it dependable on situations as load, downhill, snow on the track etc.

 

How well computer control can slow down a train at stations before starting to brake is a little unknown to me. I believe that the profiling of the engine that RFS told about somehow demand that an engine has a constant speed when entering a block. I have a feeling that computer control is a bit robotic in movement. Railmagic can change the speed without restrictions on the position in the block. For example, the virtual driver can make sure that the first turnout at the station is reached at 40 MPH if going into track #1 and 60 MPH if going into track #2.

 

Prototypical railways are moving away from block control into moving blocks. This makes trains possible to run with a constant distance between them and signals are not needed. Railmagic can do this because it has a continuously known position of the train similar to GPS for prototypical trains. Hard to see how a system based on blocks can do that. This alone is a reason to support Railmagic (can be done on our website from $10) because in 10-20 years computer control cannot simulate real behavior. A change is needed!

 

We have also been thinking about an ATC-system, where a person can drive one loco manually (popular to do in clubs at running sessions). However, Railmagic will emergency brake the loco if a signal is passed at danger (or assumed to be). With no limitation on how often the driver changes the speed of the loco, I don't believe computer control will be able to know how far the loco is from the signal. Railmagic does by the millimeter.

[Railmagic]

15 minutes ago, Andymsa said:

Although technically correct that at a minimum only one detector is needed, I believe the more you have the more accurate stopping is achieved, as over longer distances greater errors can occur. 

 

I agree, TrainController is designed to use 3 detectors per block, and that is probably because it is best to do so. But I am not the right person to be be claiming this. I have just been looking in the manual and not tried.

[Andymsa]

10 minutes ago, Railmagic said:

 

Computer control relays on the deceleration profile in the decoder, therefore the braking is the same for a train independently on the number of wagons attached. Railmagic can brake with any profile and make it dependable on situations as load, downhill, snow on the track etc.

 

This is incorrect to correctly set up an acceleration or braking profile then the computer software should do this and any settings in the decoder for this should be off or disabled. This is because inaccuracies will occur because the software will not know how far the train has travelled. There are many adjustments that additionally can be enabled in software like weight type of train and gradients.

 

15 minutes ago, Railmagic said:

 

How well computer control can slow down a train at stations before starting to brake is a little unknown to me. I believe that the profiling of the engine that RFS told about somehow demand that an engine has a constant speed when entering a block. I have a feeling that computer control is a bit robotic in movement. Railmagic can change the speed without restrictions on the position in the block. For example, the virtual driver can make sure that the first turnout at the station is reached at 40 MPH if going into track #1 and 60 MPH if going into track #2.

 

 

no again this is not the case a train can already be braking before it enters the next block. The software can adjust speeds for the next block or section and can be set for the block or a specific turnout.

 

19 minutes ago, Railmagic said:

 

 

Prototypical railways are moving away from block control into moving blocks. This makes trains possible to run with a constant distance between them and signals are not needed. Railmagic can do this because it has a continuously known position of the train similar to GPS for prototypical trains. Hard to see how a system based on blocks can do that. This alone is a reason to support Railmagic (can be done on our website from $10) because in 10-20 years computer control cannot simulate real behavior. A change is needed!

 

We have also been thinking about an ATC-system, where a person can drive one loco manually (popular to do in clubs at running sessions). However, Railmagic will emergency brake the loco if a signal is passed at danger (or assumed to be). With no limitation on how often the driver changes the speed of the loco, I don't believe computer control will be able to know how far the loco is from the signal. Railmagic does by the millimeter.

as to millimetre stopping at signals I can do this in software already. As to moving blocks that is a system of working, actual physical blocks still exist.

[Andymsa]

7 minutes ago, Railmagic said:

 

I agree, TrainController is designed to use 3 detectors per block, and that is probably because it is best to do so. But I am not the right person to be be claiming this. I have just been looking in the manual and not tried.

no it’s not designed to use three detectors per block. You can have as many as you want. As RFS states you can use one but for more accurate stopping it’s best to use more.

[RFS]

19 minutes ago, Railmagic said:

How well computer control can slow down a train at stations before starting to brake is a little unknown to me. I believe that the profiling of the engine that RFS told about somehow demand that an engine has a constant speed when entering a block. I have a feeling that computer control is a bit robotic in movement. Railmagic can change the speed without restrictions on the position in the block. For example, the virtual driver can make sure that the first turnout at the station is reached at 40 MPH if going into track #1 and 60 MPH if going into track #2.

 

When a train enters a block, TC knows what speed step it is on and therefore how fast it is travelling. Let's say you have set your brake marker at 100cm and your stop marker at 200cm, both measurements being relative to the start of the block. TC will allow the train to continue travelling for another 100cm at its current speed. Then it will decelerate the train over the next 100cm at a rate that allows it to come gradually to a stop. It is very accurate to within 5 cm.

 

In TC you can specify a speed restriction for a block, in which case TC will slow down the train realistically within the previous block so that, when it enters the speed-restricted block, it will do so at the correct speed. 

[Railmagic]

12 minutes ago, RFS said:

 

When a train enters a block, TC knows what speed step it is on and therefore how fast it is travelling. Let's say you have set your brake marker at 100cm and your stop marker at 200cm, both measurements being relative to the start of the block. TC will allow the train to continue travelling for another 100cm at its current speed. Then it will decelerate the train over the next 100cm at a rate that allows it to come gradually to a stop. It is very accurate to within 5 cm.

 

In TC you can specify a speed restriction for a block, in which case TC will slow down the train realistically within the previous block so that, when it enters the speed-restricted block, it will do so at the correct speed. 

 

But it has to enter a block with a constant speed, right? This means you have to decide where the trains are going to slow down before building the layout. Railmagic can slow down anywhere. Further, you specify where the speed limit begins. The engine drivers start to brake at different locations to reach the desired speed at the same location.

[Andymsa]

2 minutes ago, Railmagic said:

 

But it has to enter a block with a constant speed, right? This means you have to decide where the trains are going to slow down before building the layout. Railmagic can slow down anywhere. Further, you specify where the speed limit begins. The engine drivers start to brake at different locations to reach the desired speed at the same location.

no incorrect, I’m sorry but by your own admission you really need to use both ITrain and Traincontroller in a real world situation to gain a better understanding of these programs.

 

what is truly missing is a programme that takes the best from both programs.

[Railmagic]

27 minutes ago, Andymsa said:

This is incorrect to correctly set up an acceleration or braking profile then the computer software should do this and any settings in the decoder for this should be off or disabled. This is because inaccuracies will occur because the software will not know how far the train has travelled. There are many adjustments that additionally can be enabled in software like weight type of train and gradients.

 

It is unclear whether you describe what computer control "is" doing or "should" be doing. What you describe is how Railmagic does it, so again the systems are very alike.

[Railmagic]

3 minutes ago, Andymsa said:

no incorrect, I’m sorry but by your own admission you really need to use both ITrain and Traincontroller in a real world situation to gain a better understanding of these programs.

 

what is truly missing is a programme that takes the best from both programs.

 

You indicates that both programs have limitations and room for improvements. Can you specify? To me it is still a kind of "in this block do this, in the next block do this" causing what I call robotic movement. 

[Andymsa]

26 minutes ago, Railmagic said:

 

It is unclear whether you describe what computer control "is" doing or "should" be doing. What you describe is how Railmagic does it, so again the systems are very alike.

It is doing it.

[Andymsa]

20 minutes ago, Railmagic said:

 

You indicates that both programs have limitations and room for improvements. Can you specify? To me it is still a kind of "in this block do this, in the next block do this" causing what I call robotic movement. 

yes both programs have good and bad points. Unfortunately this is a topic in itself and quite vast. Many users will have various views on this and I would recommend doing research on the forums on this.

 

as I said you truly need to look at both these programs in real life and your see it’s not robotic at all

[Railmagic]

55 minutes ago, RFS said:

 

In TC you can specify a speed restriction for a block, in which case TC will slow down the train realistically within the previous block so that, when it enters the speed-restricted block, it will do so at the correct speed. 

 

There is apparent inconsistency between what users of computer control say. Some claims one detector per block is enough, others that more is better. Some claims speed can be changed while crossing between blocks, others that speed changes occur inside blocks. No wonder we who dream of automation are confused.

[Andymsa]

8 minutes ago, Railmagic said:

 

There is apparent inconsistency between what users of computer control say. Some claims one detector per block is enough, others that more is better. Some claims speed can be changed while crossing between blocks, others that speed changes occur inside blocks. No wonder we who dream of automation are confused.

there is no confusion at all, one detector or multiple detectors both are ok. We all just different approaches to achieve the same results. Both statements for speed changes are correct between blocks this is the beauty and versatility of these programmes. No one size fits all and there are different ways to achieve the net end result for different users. 

[Railmagic]

It is not just a question of whether computer control is able to do something, but whether an averaged skilled person within reasonable time and effort can do it.

[Andymsa]

17 minutes ago, Railmagic said:

It is not just a question of whether computer control is able to do something, but whether an averaged skilled person within reasonable time and effort can do it.

I would say yes they could do it

[Railmagic]

10 minutes ago, Andymsa said:

there is no confusion at all, one detector or multiple detectors both are ok. 

 

And this is how it goes:

You go for one detector per block and spend $300 on detectors and $250 on iTrain.

 

One year later:

You find out of that it is not good enough and you need two detectors per block.

You double the number of detectors (how to do this easily?), another $300.

You are not happy with iTrain and change to TrainController, yet another $639.

 

So in theory computer control costs $550 but in reality you spend $1489.

[Andymsa]

16 minutes ago, Railmagic said:

 

And this is how it goes:

You go for one detector per block and spend $300 on detectors and $250 on iTrain.

 

One year later:

You find out of that it is not good enough and you need two detectors per block.

You double the number of detectors (how to do this easily?), another $300.

You are not happy with iTrain and change to TrainController, yet another $639.

 

So in theory computer control costs $550 but in reality you spend $1489.

And the opposite is true you install two detectors then find a year later you save $150. The point is proper planning and testing.

changing software now there’s a debate, but before people commit to either one you can try out both for free so a correct choice can be made.

 

its great your trying to introduce a new system but unfortunately it appears as it stands problematic at this time. I looked at your video on calibration of a loco. In I train or traincontroller there is no need to pick up a loco or inter fear once calibration is taking place I just go and have a cup of tea and let it get on with it.