Welcome to the forum   
Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Share
Options
View
Go to last post in this topic Go to first unread post in this topic
Offline MikeR  
#1 Posted : 07 September 2014 21:56:44(UTC)
MikeR

United States   
Joined: 26/08/2012(UTC)
Posts: 263
Location: Denver
Originally Posted by: Nigel Packer Go to Quoted Post


... I defy anyone to run a complex model railway layout like mine, where we had more than 40 trains running, without the occasional mishap! So I will still work on improving the reliability still further, but I am very pleased with the way it all worked on its first major public display. I think there's probably no other layout like mine in the UK (at least not in private hands) where we have sophisticated computer control of all the trains, with all sounds and functions automatically managed, lots of functioning models like a wind farm, dance hall, car showroom, TV tower, water mill, saw mill, and so on, a computer-controlled car system on the roads with lighting functions and automatic route generation, complete room and layout lighting effects, also computer controlled, with subtle daytime and night-time including the room window blinds opening and closing automatically, and weather and other environmental sound effects creating quite an amazing ambience. There are so many trains, with the sequence of operations and train routes being randomly generated, that the same combination of trains never occurs twice, and there is always something to watch.



The above quote from the recent UK model train club meeting thread made very interesting reading as Nigel has achieved a relatively flawless operation of a complex computer controlled layout. To run 40 trains with little or no problems over 2 days is really a fantastic achievement! BigGrin BigGrin Well done Nigel! I have been involved in computer control for some time with various levels of success and understand some of the complexities and problems that are encountered. Nigel must have been building and debugging the layout and associated control systems for some years. The success and complexity (including room lighting effects!) of this layout makes me interested in discovering which software is being used as well as some technical specification of the system. Nigel if you see this post please can you assist?

I am also interested in ideas on what makes a successful computer controlled layout operate smoothly.

To start the ball rolling I would suggest that it is essential to have access to an electronics and computer whizz if you do not have these skills yourself. Because of the complexity it is often necessary to involve an expert in these fields to assist with problems that are encountered.

Next, flawless operation of all computer controlled accessories, in particular the points/turnouts, is absolutely essential. At present I am involved in setting up a show layout consisting of our members' modules. While the trains operate well on the track around the layout, the problem of erratic points/turnouts makes the automation of this layout problematic. This erratic behaviour is the result of scenery building affecting the operation of the points/turnouts as well as different decoders being used with more or less success.

The third issue is the ability to stop trains within a relatively tightly controlled margin. Trains that under- or overshoot the defined stopping point can cause derailments to other trains at junctions.

I don't believe that the make of software plays a role as I think that the basic facilities in the software packages are probably very similar. Maybe a poll on the software being used can be conducted if other members disagree with this statement

Any other thoughts, ideas, comments etc. will be appreciated.

Mike
Digital - C track with CS2 and Railroad&Co TrainController; feedback using LocoIO via a Locobuffer
Analog - M track with solid centre rail (after C track layout is complete)
Collect all Eras - especially Crocodiles
Member of ETE
Previously a member of the Marklin Modellers' Group Johannesburg
Offline kiwiAlan  
#2 Posted : 07 September 2014 23:05:36(UTC)
kiwiAlan

United Kingdom   
Joined: 23/07/2014(UTC)
Posts: 8,067
Location: ENGLAND, Didcot
I can confirm that Nigels layout is IMPRESSIVE! He uses Railroad & Co as the control software for everything, controlling something like 4 or 5 different drive systems (Nigel will correct me if I'm wrong) including the CS2 and the car system.

The one problem I saw that exists with the Marklin points is that there is no method of feeding back the position of the points to the control software, so if a command to change points gets lost in a noise spike or flood of messages the software has no means of knowing that the point hasn't changed. There were several cases where this seemed to happen and a train was sent on its way by the software on the assumption that a point had changed only to end up with an operator having to hit the emergency stop on the CS2 to stop a collision.

The other problem that occurs is that the software does not know what train is in a block - it just knows there is a train present in a block. So if a train is stopped in a block, the software changes a point behind the train, and sets another train on its way, the it expects that train to appear in the empty block that it believes the point is now directed to. But if the message to change the point has somehow got lost then the software cannot detect the train has entered the already occupied block without having what I would describe as a 'micro block' immediately after the point that allows the software to detect that the train has gone the wrong way. But this also means the available length of storage tracks is reduced by essentially a coach length ON EVERY BLOCK to allow this detection to take place. This clearly not practicable, especially on an existing layout, so some other means is required to ensure that points are set correctly before a train proceeds.
thanks 1 user liked this useful post by kiwiAlan
Offline Drongo  
#3 Posted : 08 September 2014 01:35:18(UTC)
Drongo

Australia   
Joined: 03/06/2008(UTC)
Posts: 1,221
Location: Sydney, NSW
From Nigel's report, I assume that he has mastered the problem with point motors. Please Nigel - tell us how you did it. I'm using TrainController and really love it, but the points failing regularly is the major problem. It's so frustrating and annoying. Cursing Cursing Cursing
Take it easy . . . . or any other way you can get it !!!!
thanks 1 user liked this useful post by Drongo
Offline cookee_nz  
#4 Posted : 08 September 2014 07:56:36(UTC)
cookee_nz

New Zealand   
Joined: 31/12/2010(UTC)
Posts: 3,946
Location: Paremata, Wellington
Originally Posted by: youngagain Go to Quoted Post
From Nigel's report, I assume that he has mastered the problem with point motors. Please Nigel - tell us how you did it. I'm using TrainController and really love it, but the points failing regularly is the major problem. It's so frustrating and annoying. Cursing Cursing Cursing


I got involved with Computer control quite some time ago in the game (mid-90's) using a program produced by a couple of fine Ockers (Ross & Peter).

I automated a quite small layout figuring that it's actually harder to get a small layout running well than a larger one, mainly on the basis that with less time for things to happen you needed to keep your routines tight and anticipate pretty much anything and everything that could go wrong.

I never implemented it but the problem of confirming that a train had indeed followed the correct aspect of a turnout was a key potential problem.

For me, it seemed the safest thing would be track detection immediately past the turnout. You could use an LED sensor simply looking for any train activity on each of the outgoing tracks. If the train is meant to go straight but the turnout does not switch properly, then you would get a double error - ie "a train is not where it it should be", and "a train is where it should not be". With either condition being true, power to that section or the entire layout would be stopped to avoid any collision, and the sensor which flagged the error would also be hi-lighted to quickly locate the problem.

If you wanted to avoid the overhead of the software doing the monitoring, you could even consider adding entirely separate components to do this.

I'm thinking here of a circuit which receives the same signal or pulse that the turnout receives. So let's say the turnout gets a pulse on the green lead for going straight (ps - you should never assume the turnout is already straight, even if it 'should' be, I would always resend the command regardless), the green pulse not only sets the turnout but also sets the safety-sensor to monitor the Green and Red (branch) outward track. If the train arrives on the Green sensor as expected it is reset and everything continues as normal. But if the Red sensor detects the train then an error condition results and you implement whatever action you wish in that event.

What this scenario does NOT address is if the signal to change the turnout is never generated in the first place, and that would usually be software failing to send it, but of course could also be a weak signal, bad connection etc.

Another slightly more crude way to achieve this would be all tracks leading from turnouts are isolated and wired to a universal relay or similar which also receives the same signal as the turnout motor and this livens the correct track, and isolates the incorrect one. This gets messy when two-way running on a single track is involved but it's something I'd play around with if for no other reason than to prove or disprove.

Either way, both of these suggestions involve more wiring, and further error-handling and I'm sure there are more elegant ways to manage the problem but this is some of my thinking anyway. Might give some food for thought? It would not be needed for every turnout, just those where a wrong direction could lead to a catastrophic (expensive) collision.

Either way you need a way to confirm that what you have intended to happen, has actually happened - 'is the turnout blade where it is meant to be at this point in time?".

Regards

Steve
Cookee
Wellington
NZ image
thanks 1 user liked this useful post by cookee_nz
Offline French_Fabrice  
#5 Posted : 08 September 2014 13:23:51(UTC)
French_Fabrice

France   
Joined: 16/05/2011(UTC)
Posts: 1,474
Location: Lyon, France
Originally Posted by: kiwiAlan Go to Quoted Post
...
The other problem that occurs is that the software does not know what train is in a block - it just knows there is a train present in a block....

Hi,

I think you're wrong. A software knows exactly and at every moment which loco is in which block. If not, you won't be able to drive the trains correctly.

Apart that, as previously stated, the main problem is lack of feeback on turnout positions with Marklin tracks. On my side, I don't know how to solve this problem.

Cheers
Fabrice
thanks 2 users liked this useful post by French_Fabrice
Offline kiwiAlan  
#6 Posted : 08 September 2014 14:42:43(UTC)
kiwiAlan

United Kingdom   
Joined: 23/07/2014(UTC)
Posts: 8,067
Location: ENGLAND, Didcot
Originally Posted by: French_Fabrice Go to Quoted Post
Originally Posted by: kiwiAlan Go to Quoted Post
...
The other problem that occurs is that the software does not know what train is in a block - it just knows there is a train present in a block....

Hi,

I think you're wrong. A software knows exactly and at every moment which loco is in which block. If not, you won't be able to drive the trains correctly.

Apart that, as previously stated, the main problem is lack of feeback on turnout positions with Marklin tracks. On my side, I don't know how to solve this problem.

Cheers
Fabrice


Well, yes the software knows which train is in a block - if the points have worked correctly.

But when the points don't work and the train goes where it shouldn't, then the software doesn't know that train is lost because it doesn't know what point failed.

Feedback on turnout positions at least allows the software to resend the command to set the turnout the way it wants if it isn't set after a suitable timeout period, and if that doesn't work then it doesn't start the train move and can report an error to the operator.
thanks 1 user liked this useful post by kiwiAlan
Offline Danlake  
#7 Posted : 08 September 2014 15:04:17(UTC)
Danlake

New Zealand   
Joined: 03/08/2011(UTC)
Posts: 1,571
Traincontroller has build in function to be able to monitor turnouts and take some actions (e.g. diverting train to an alternative route or simple action - stop the trains).

However full function of course require a feedback from the turnout. I beleive this is possible with servo motors with DCC decoders (not sure if there is any decoder that supports MM/MfX)?

See below extract from manual (only copied some parts):

14.11Turnout Position Control (page 270 of silver/gold manual):

Turnout position control can be used to protect turnouts, that are currently locked in routes, against outside interferences or operation failures. Turnout position control is based on different categories of turnout status:

a) The digital system stores and reports back the most recent turnout command (logical turnout state). This information can be for example used to detect, if a turnout is operated by an external handheld.

b) The turnout decoder can report back the electrical status of the turnout drive. This feature usually requires a turnout decoder, which is able to report back the current status to the digital system, and certain circuitry associated with the turnout drive, which reports the turnout status back to the decoder. This information can be used to detect, if the turnout drive failed to execute a turnout command issued by the digital system.

c) The electrical status of the turnout is reported back to the digital system or the com-puter, respectively, by feedback input contacts, which are associated with a separate feedback encoder. This information can be used, too, to detect, if the turnout drive failed to execute a turnout command issued by the digital system.

Error Processing

Turnout position control does not make any sense, if there is no reaction to failing turnouts.

One of the following mandatory reactions must be individually selected for each turnout. The selected reaction is performed, when the turnout is locked by a route for a train in a schedule:

a) Search alternate path: if this option is selected, then TrainController™ tries to continue the affected schedule with an alternate path.

b) Lock block exit: if this option is selected, then TrainController™ locks the exit of the block, where the affected train is currently located. This will cause the train to stop in this block and enables the human operator to clear the turnout problem.

c) Stop schedule: if this option is selected, then TrainController™ terminates the af-fected schedule. This is another, more drastic measure to prevent the train from passing the failing turnout and to enable the human operator to resolve the problem first.

Brgds - Lasse
Digital 11m2 layout / C (M&K) tracks / Era IV / CS3 60226 / Train Controller Gold 9 with 4D sound. Mainly Danish and German Locomotives.
thanks 1 user liked this useful post by Danlake
Offline H0  
#8 Posted : 08 September 2014 15:39:36(UTC)
H0


Joined: 16/02/2004(UTC)
Posts: 15,249
Location: DE-NW
Originally Posted by: kiwiAlan Go to Quoted Post
But when the points don't work and the train goes where it shouldn't, then the software doesn't know that train is lost because it doesn't know what point failed.
Some software will detect that a block is now occupied unexpectedly and will stop all train operations. Blocks behind the turnouts can substitute feedback from the turnouts.
Not the best solution because a turnout can be wrong for a long time - error is detected as soon as a train goes the wrong way.

Regards
Tom
---
"In all of the gauges, we particularly emphasize a high level of quality, the best possible fidelity to the prototype, and absolute precision. You will see that in all of our products." (from Märklin New Items Brochure 2015, page 1) ROFLBTCUTS
UserPostedImage
Offline MikeR  
#9 Posted : 08 September 2014 21:07:53(UTC)
MikeR

United States   
Joined: 26/08/2012(UTC)
Posts: 263
Location: Denver
Hi Steve

Thanks for your in depth analysis and your thoughts on this issue. You have obviously had this problem and have spent some time thinking about the issue.

Originally Posted by: cookee_nz Go to Quoted Post


I automated a quite small layout figuring that it's actually harder to get a small layout running well than a larger one, mainly on the basis that with less time for things to happen you needed to keep your routines tight and anticipate pretty much anything and everything that could go wrong.


I agree that a smaller layout is more difficult than a larger layout. The contacts and points are much closer and require a faster PC to handle the volume of events on the layout when a number of trains are being run.

Originally Posted by: cookee_nz Go to Quoted Post


For me, it seemed the safest thing would be track detection immediately past the turnout. You could use an LED sensor simply looking for any train activity on each of the outgoing tracks. If the train is meant to go straight but the turnout does not switch properly, then you would get a double error - ie "a train is not where it it should be", and "a train is where it should not be". With either condition being true, power to that section or the entire layout would be stopped to avoid any collision, and the sensor which flagged the error would also be hi-lighted to quickly locate the problem.


Your idea of using track detection immediately past the point is interesting as on my layout I do have short sensors on both tracks adjacent to the points. I normally use these contacts as Stop markers to stop trains as they approach the point from the other direction. It would be relatively simple to stop trains prior to these sensors so that they are not activated by a waiting train. Then with some logic (flagmen in TC) it is possible to use these sensors to indicate whether the point has thrown and the train has taken the correct route. The attractiveness of this solution is that it will not require the installation of any further sensors as the solution is implemented in software. Slightly shorter trains will have to be run when using this solution as the full length of the block will not be available.

I have a few troublesome points where I would initially develop the logic, and then roll the logic out where needed to other points.

Originally Posted by: cookee_nz Go to Quoted Post


If you wanted to avoid the overhead of the software doing the monitoring, you could even consider adding entirely separate components to do this.

I'm thinking here of a circuit which receives the same signal or pulse that the turnout receives. So let's say the turnout gets a pulse on the green lead for going straight (ps - you should never assume the turnout is already straight, even if it 'should' be, I would always resend the command regardless), the green pulse not only sets the turnout but also sets the safety-sensor to monitor the Green and Red (branch) outward track. If the train arrives on the Green sensor as expected it is reset and everything continues as normal. But if the Red sensor detects the train then an error condition results and you implement whatever action you wish in that event.



A good idea and something worth considering. This would alleviate the need for logic in the PC as the signal would only be sent if the incorrect sensor is activated. As you mention the only downside would be if the signal to the point is not generated irrespective of point position.

Regards
Mike
Digital - C track with CS2 and Railroad&Co TrainController; feedback using LocoIO via a Locobuffer
Analog - M track with solid centre rail (after C track layout is complete)
Collect all Eras - especially Crocodiles
Member of ETE
Previously a member of the Marklin Modellers' Group Johannesburg
Offline MikeR  
#10 Posted : 08 September 2014 21:20:33(UTC)
MikeR

United States   
Joined: 26/08/2012(UTC)
Posts: 263
Location: Denver
Originally Posted by: Danlake Go to Quoted Post
Traincontroller has build in function to be able to monitor turnouts and take some actions (e.g. diverting train to an alternative route or simple action - stop the trains).

However full function of course require a feedback from the turnout. I beleive this is possible with servo motors with DCC decoders (not sure if there is any decoder that supports MM/MfX)?



Hi Lasse

I must admit I have not looked at the TC manual to see what functionality exists for turnouts being incorrectly thrown - a lot more than I realised.

I have shorted out all micro-switches on my C track points motors. Your response makes me wonder whether it is possible, with a different method of shorting out the micro-switches, to use them to indicate the turnout position to TC. I need to open a turnout motor again and see whether this is possible.
Mike
Digital - C track with CS2 and Railroad&Co TrainController; feedback using LocoIO via a Locobuffer
Analog - M track with solid centre rail (after C track layout is complete)
Collect all Eras - especially Crocodiles
Member of ETE
Previously a member of the Marklin Modellers' Group Johannesburg
thanks 1 user liked this useful post by MikeR
Offline MikeR  
#11 Posted : 08 September 2014 21:23:52(UTC)
MikeR

United States   
Joined: 26/08/2012(UTC)
Posts: 263
Location: Denver
Originally Posted by: H0 Go to Quoted Post
Originally Posted by: kiwiAlan Go to Quoted Post
But when the points don't work and the train goes where it shouldn't, then the software doesn't know that train is lost because it doesn't know what point failed.
Some software will detect that a block is now occupied unexpectedly and will stop all train operations. Blocks behind the turnouts can substitute feedback from the turnouts.
Not the best solution because a turnout can be wrong for a long time - error is detected as soon as a train goes the wrong way.



Ideally the point error should be identified as soon as the route has been set but before the train accesses the route.
Mike
Digital - C track with CS2 and Railroad&Co TrainController; feedback using LocoIO via a Locobuffer
Analog - M track with solid centre rail (after C track layout is complete)
Collect all Eras - especially Crocodiles
Member of ETE
Previously a member of the Marklin Modellers' Group Johannesburg
Offline kiwiAlan  
#12 Posted : 09 September 2014 10:50:11(UTC)
kiwiAlan

United Kingdom   
Joined: 23/07/2014(UTC)
Posts: 8,067
Location: ENGLAND, Didcot
Originally Posted by: MikeR Go to Quoted Post
Originally Posted by: H0 Go to Quoted Post
Originally Posted by: kiwiAlan Go to Quoted Post
But when the points don't work and the train goes where it shouldn't, then the software doesn't know that train is lost because it doesn't know what point failed.
Some software will detect that a block is now occupied unexpectedly and will stop all train operations. Blocks behind the turnouts can substitute feedback from the turnouts.
Not the best solution because a turnout can be wrong for a long time - error is detected as soon as a train goes the wrong way.



Ideally the point error should be identified as soon as the route has been set but before the train accesses the route.


I agree, so the software needs to send the point operation command, wait a timeout time, check the point is as expected, then run the train if satisfactory, or retry the point operation or post an error if point did not operate.
thanks 1 user liked this useful post by kiwiAlan
Offline Chook  
#13 Posted : 09 September 2014 11:47:52(UTC)
Chook

Australia   
Joined: 15/08/2012(UTC)
Posts: 234
Location: Perth, Western Australia.
KiwiAlan
I agree, so the software needs to send the point operation command, wait a timeout time, check the point is as expected, then run the train if satisfactory, or retry the point operation or post an error if point did not operate.



The problem we now have is the method to identify that the mechanical changeover of the frog has actually occurred.
The mechanisms are tiny and so are the forces required to actuate them. There is no reliable "spare" force available to actuate a micro switch as a feed back to the controller. This has been attempted by Marklin and according to the feedback from forum members is fraught with problems.

What we need to be thinking about is some aftermarket device which will sense the movement of the frog. This will confirm that the point has actually moved and not been hindered by say a piece of ballast or the electrical failure of the coil.

Thoughts?

Regards.....Chook.
thanks 1 user liked this useful post by Chook
Offline Renato  
#14 Posted : 09 September 2014 12:15:17(UTC)
Renato

Italy   
Joined: 19/03/2004(UTC)
Posts: 976
Location: Gorizia, Italy
Hi Chook,

Reading this and similar posts made me thinking about the Hall effect sensors which are used in many electronics devices: there is no mechanical contact and therefore force needed to operate it.

Another possibility could be the use of the tiny optical sensors used e.g. to detect the opening/closing of panels in laser printers etc.

Only thoughts indeed, as some efforts have to be done to install these tiny devices inside the turnouts mechanisms and connect the movable part to the mechanism itself.

Last but not least a suitable electronic circuit has to be designed for the digital system interfacing.

Cheers

Renato
thanks 1 user liked this useful post by Renato
Offline kiwiAlan  
#15 Posted : 09 September 2014 13:28:44(UTC)
kiwiAlan

United Kingdom   
Joined: 23/07/2014(UTC)
Posts: 8,067
Location: ENGLAND, Didcot
Originally Posted by: Chook Go to Quoted Post
KiwiAlan
I agree, so the software needs to send the point operation command, wait a timeout time, check the point is as expected, then run the train if satisfactory, or retry the point operation or post an error if point did not operate.



The problem we now have is the method to identify that the mechanical changeover of the frog has actually occurred.
The mechanisms are tiny and so are the forces required to actuate them. There is no reliable "spare" force available to actuate a micro switch as a feed back to the controller. This has been attempted by Marklin and according to the feedback from forum members is fraught with problems.

What we need to be thinking about is some aftermarket device which will sense the movement of the frog. This will confirm that the point has actually moved and not been hindered by say a piece of ballast or the electrical failure of the coil.

Thoughts?

Regards.....Chook.


So you remove the Märklin switch motors and fit something like Fulgurex slow motion motors? These come with microswitches that can be used to drive an s88 to give feed back.

thanks 1 user liked this useful post by kiwiAlan
Offline kiwiAlan  
#16 Posted : 09 September 2014 13:36:11(UTC)
kiwiAlan

United Kingdom   
Joined: 23/07/2014(UTC)
Posts: 8,067
Location: ENGLAND, Didcot
Originally Posted by: Renato Go to Quoted Post
Hi Chook,

Reading this and similar posts made me thinking about the Hall effect sensors which are used in many electronics devices: there is no mechanical contact and therefore force needed to operate it.

Another possibility could be the use of the tiny optical sensors used e.g. to detect the opening/closing of panels in laser printers etc.

Only thoughts indeed, as some efforts have to be done to install these tiny devices inside the turnouts mechanisms and connect the movable part to the mechanism itself.

Last but not least a suitable electronic circuit has to be designed for the digital system interfacing.

Cheers

Renato


I was intrigued by a demonstration given by one of our club members who is a member of the MERG group. He was showing a natty little device using an R/C servo to move s gate such as might be used into a private siding from railway right of way. The gate itself was removable, and the gatepost that rotated it has a 2mm diameter rare earth magnet on the bottom end to make the 'drive' connection with a metal pad mounted on the servo. meant that the gate could be knocked by a train accidently without damaging anything., and if the servo was made to swing far enough then the gate could hit a fence post and would auto-align with the servo again.

MERG also do a nice plastic mount for an R/C servo as a point motor. two microswitches can be mounted each side so that frog switching on 2 rail layouts, and point position can be reported. I am looking to use some of these on a club layout after I come back from holiday.
thanks 1 user liked this useful post by kiwiAlan
Offline Drongo  
#17 Posted : 09 September 2014 15:05:45(UTC)
Drongo

Australia   
Joined: 03/06/2008(UTC)
Posts: 1,221
Location: Sydney, NSW
I have absolutely no idea what you fellas are talking about on the technical side of things - I'm just a plain Drongo. However, it sounds like you guys are almost developing the perfect turnout motor. Please keep going with your ideas and perhaps someone at Marklin might see this post and decide to manufacture them.

It's so frustrating when you can't rely on the motors switching the turnouts and you stand ready at the central station to hit the stop button - automation is not meant to be like this.
Take it easy . . . . or any other way you can get it !!!!
thanks 2 users liked this useful post by Drongo
Offline Tdl  
#18 Posted : 09 September 2014 16:53:06(UTC)
Tdl

Netherlands   
Joined: 30/03/2006(UTC)
Posts: 71
Location: Amsterdam
All,

indeed setting a point – either by hand or by a computer program - is a risky operation.

Apart from setting the right point at the right moment – no train on it – we would like to be sure that the point has been completely set, i.e that the blades are in the ordered position.

In HO scale most point machines have no provision to feed back the true position of the blades. Some types of point machines (e.g. Tortoise) have a switch that changes as the point motor moves. On märklin K point machines one can use the switches that are provided to deactivate the coils to monitor the movement of the machine. However this will not tell us if the blades are completely set.

Until know I have lived with the fact that now and then on my computer controlled layout a point has not been (completely) set.
When the point is in the wrong position then the train will go the wrong way on that point. My program notices this. Currently the program then alerts the dispatcher. In an earlier version the program automatically stopped the train but that is not very prototypical.
When the point is not completely set then the train may derail. This is part of the game.

However, derailments should not occur too often. Hence I strive for it to make my point machines as reliable as possible and I repair or replace a malfunctioning point machine immediately.

Yet it would be nice to have a point machine or an add on mechanism for märklin K and C points that gives a feed back about the true position of the blades.
I have been thinking about making an additional linkage to the blades that generates an electrical signal when the blades are in either end position. The signal will be compatible with a feedback encoder.

I would be pleased to hear about any solutions that are proven to work.

Regards, Willem

Edited by user 10 September 2014 10:33:29(UTC)  | Reason: Corrected spelling

thanks 1 user liked this useful post by Tdl
Offline MikeR  
#19 Posted : 09 September 2014 21:20:25(UTC)
MikeR

United States   
Joined: 26/08/2012(UTC)
Posts: 263
Location: Denver
Thanks everyone for your comments.

Maybe we should check the incidence of problems with our points. I have tried to avoid points problems by shorting all of the micro-switches and ensuring that points operate smoothly while laying my track and before moving on to the next section of track. Any sign of a problem is investigated and resolved immediately. I am sure that when I complete my track laying and start serious running I will identify problem points which are most likely to be those that are least accessible. Cursing If possible I will try and arrange schedules to overcome any problems. I recently overcame a problem by upgrading my PC as the points commands were not being generated from the old hardware.

The ideal solution seems to be having a feedback mechanism on the flanges of the points that will identify how the points are set - a complex and potentially expensive solution. The question of whether this is really worth all the effort then arises. Are there alternative methods of increasing the reliability of the points, the point motors, the decoders and the system generating the points' commands? If this is possible it will reduce the need for the monitoring system provided an acceptably low level of point problems can be achieved.

Originally Posted by: Tdl Go to Quoted Post

When the point is in the wrong position then the train will go the wrong way on that point. My program notices this. Currently the program then alerts the dispatcher. In an earlier version the program automatically stopped the train but that is not very prototypical.
When the point is not completely set then the train may derail. This is part of the game.



Willem, I assume you are using sensors to detect when a train goes the wrong way on a point? If you are using TC how are you alerting the dispatcher? Is it via the facilities available to check whether a point is thrown or are you using flagmen?

Regards

Mike
Digital - C track with CS2 and Railroad&Co TrainController; feedback using LocoIO via a Locobuffer
Analog - M track with solid centre rail (after C track layout is complete)
Collect all Eras - especially Crocodiles
Member of ETE
Previously a member of the Marklin Modellers' Group Johannesburg
thanks 1 user liked this useful post by MikeR
Offline Tdl  
#20 Posted : 10 September 2014 10:59:47(UTC)
Tdl

Netherlands   
Joined: 30/03/2006(UTC)
Posts: 71
Location: Amsterdam
Mike,

when a train goes the wrong way at a point, a track will become occupied to which no route has been set.
This event causes the alert in my program.

I do use track occcupancy detection that is on each track on my layout, not an additional sensor.
However, when the track in the wrong way is already occupied then there is no change in track occupation and than my program does not alert. So it is not a full proof solution.

I am not using TC. I have written the program myself.

My program sends a command to the digital system to operate a point and then checks the reply from the digital system.
When this is positive, the program considers the point to be in the ordered position.

However a positive reply from the digital system is no guarantee that the point is in the ordered end position. When the digital system does not put the point command in the trackdata or when the point machine fails then the point will not ne in the ordered position.

Both failures occur. As an average I have one point setting failure every 2-3 hrs of operation.

As said before, I can live with this.

Regards, Willem
thanks 3 users liked this useful post by Tdl
Offline walter__  
#21 Posted : 12 September 2014 10:38:13(UTC)
walter__

Belgium   
Joined: 30/12/2013(UTC)
Posts: 19
Location: Antwerp
Hi all,

we use a similar approach.. the software and hardware are custom made, each block has its own current sensing having 4 states that are transmitted to the computer by S88 bus.
The block states are "free", "occupied", "pulse" and "short", where "pulse" is a sudden change of power in that block.
When a point did not switch, and there is no train in the "wrong" track, the program will just stop the trains when the whole train is out of the previous block.
When there is already a train waiting on the "wrong" track, the faulty incoming train generates a power PULSE in that block and the program does a panic stop.

So at all time we know where all trains are due to the current sensing, of course electronics for that are extensive.

In addition, the program also stops when after a disconnection a last wagon with lights is detected in a block that should be free.

The final goal is to make some 35 à 40 trains run in a random pattern, keeping in mind that special trains (like Goliath crane) cant take all tracks.

Regards,
Walter
Offline MikeR  
#22 Posted : 12 September 2014 15:51:42(UTC)
MikeR

United States   
Joined: 26/08/2012(UTC)
Posts: 263
Location: Denver
Originally Posted by: walter__ Go to Quoted Post
Hi all,

The block states are "free", "occupied", "pulse" and "short", where "pulse" is a sudden change of power in that block.
When a point did not switch, and there is no train in the "wrong" track, the program will just stop the trains when the whole train is out of the previous block.
When there is already a train waiting on the "wrong" track, the faulty incoming train generates a power PULSE in that block and the program does a panic stop.



Hi Walter

I like this solution - the electronics however must be a special detector circuit. I am using a simple contact track as a sensor, isolating one of the rails on my C-track. This is simple and inexpensive and I am not sure I could implement your solution without some additional work. I will discuss with my friend who is the electronics expert to see whether this is feasible.

Your action when there is an error also makes sense - only need an emergency stop when the block is already occupied.

Regards
Mike
Digital - C track with CS2 and Railroad&Co TrainController; feedback using LocoIO via a Locobuffer
Analog - M track with solid centre rail (after C track layout is complete)
Collect all Eras - especially Crocodiles
Member of ETE
Previously a member of the Marklin Modellers' Group Johannesburg
Offline walter__  
#23 Posted : 13 September 2014 12:35:44(UTC)
walter__

Belgium   
Joined: 30/12/2013(UTC)
Posts: 19
Location: Antwerp
Originally Posted by: MikeR Go to Quoted Post
Originally Posted by: walter__ Go to Quoted Post
Hi all,

The block states are "free", "occupied", "pulse" and "short", where "pulse" is a sudden change of power in that block.
When a point did not switch, and there is no train in the "wrong" track, the program will just stop the trains when the whole train is out of the previous block.
When there is already a train waiting on the "wrong" track, the faulty incoming train generates a power PULSE in that block and the program does a panic stop.



-- the electronics however must be a special detector circuit --


Hi Mike

Here you can find the block diagrams we use.. its a basic booster schematic, added just a current sensing chip converting floating current into voltage for the processor..
the processor calculates the averages and decide the states, then transmits it to the S88 bus.

Also the processor looks for shorts. When a short occurs it then disconnects the track in a 9/10 cycle to monitor the shortage. This reduces the power and need for big cooling. As soon as the shortage is lifted, all resumes normally, during shortage no other block is affected and trains stay on running.. the program knows the short and will not send a new train to that block (same for occupied blocks).

Cards were created with 4 blocks and a processor, as we plan to have some 96 blocks in use (84 for now), its 24 cards. S88 Feedback is 2 bits per block, 8 bits per card which the processor can handle nicely, 192 bits in total giving an equivalent of 12 S88 units.

Should you require more (component) specific info, just ask Confused

Greetz,
Walter
Offline NZMarklinist  
#24 Posted : 13 September 2014 18:14:23(UTC)
NZMarklinist

New Zealand   
Joined: 15/03/2011(UTC)
Posts: 1,757
Location: Auckland NZ
Maybe Nigel is away, so as I am privy to some of the technical details of Nigel's layout, maybe I can answer a couple of the questions raised above;

Nigel did employ professional help in the design and construction of the layout for Computer Control, saved him years !! Wink

It has a special Computer especially built and configured for the layout and auxiliary functions. The TrainController program was customised for Nigel, particularly where the Car System is concerned !

The layout does not use Marklin point motors, they are operated by servo's, and whilst I was told, I cannot remember the brand, other than they are not ESU servos that I intend to use for some of my points. RollEyes
Glen
Auckland NZ

" Every Marklin layout needs a V200, a Railbus and a Banana car", not to mention a few Black and red Steamers, oh and the odd Elok !

CS1 Reloaded, Touch Cab, C Track Modules, K track layout all under construction. Currently Insider
Offline MikeR  
#25 Posted : 13 September 2014 21:36:57(UTC)
MikeR

United States   
Joined: 26/08/2012(UTC)
Posts: 263
Location: Denver
Originally Posted by: walter__ Go to Quoted Post


Here you can find the block diagrams we use.. its a basic booster schematic, added just a current sensing chip converting floating current into voltage for the processor..
the processor calculates the averages and decide the states, then transmits it to the S88 bus.

Also the processor looks for shorts. When a short occurs it then disconnects the track in a 9/10 cycle to monitor the shortage. This reduces the power and need for big cooling. As soon as the shortage is lifted, all resumes normally, during shortage no other block is affected and trains stay on running.. the program knows the short and will not send a new train to that block (same for occupied blocks).

Cards were created with 4 blocks and a processor, as we plan to have some 96 blocks in use (84 for now), its 24 cards. S88 Feedback is 2 bits per block, 8 bits per card which the processor can handle nicely, 192 bits in total giving an equivalent of 12 S88 units.



Thanks Walter for the feedback and for your site address. I had a look at your system. It is a comprehensive and elegant solution. You and Erik have obviously put a lot of thought into the design and build of your system.

The layouts I have been involved with have insulator sections on one of the rails and only function as simple binary detection circuits. Either there is a train/ locomotive/ wagon present or not. To redo the layout with insulation blocks on the centre rail would be a big job. Maybe your approach is something I can consider if I get to build a new layout in the future.

Regards
Mike
Digital - C track with CS2 and Railroad&Co TrainController; feedback using LocoIO via a Locobuffer
Analog - M track with solid centre rail (after C track layout is complete)
Collect all Eras - especially Crocodiles
Member of ETE
Previously a member of the Marklin Modellers' Group Johannesburg
Offline MikeR  
#26 Posted : 13 September 2014 21:59:19(UTC)
MikeR

United States   
Joined: 26/08/2012(UTC)
Posts: 263
Location: Denver
Originally Posted by: NZMarklinist Go to Quoted Post

Nigel did employ professional help in the design and construction of the layout for Computer Control, saved him years !! Wink

It has a special Computer especially built and configured for the layout and auxiliary functions. The TrainController program was customised for Nigel, particularly where the Car System is concerned !

The layout does not use Marklin point motors, they are operated by servo's, and whilst I was told, I cannot remember the brand, other than they are not ESU servos that I intend to use for some of my points. RollEyes


Hi Glen

Thanks for the feedback on Nigel's layout. Interesting that he is using servos as point motors. One of the Modellers in our group was investigating servos but I have not asked him the outcome. I presume that Nigel found them more reliable. Our problem has not been with the point motors as far as we can tell but with the power needed to drive these motors and getting the required power to the point motor locations. The decoders must supply sufficient 'oomph' to positively drive the motors. In all cases we have recently been shorting out the micro-switches which has improved the reliability. As a Group, for our modular layout, we have also standardised on a couple of decoder types which has also improved the reliability. The current status on the modules is a continuous debug of the system. At today's prep session for the show in October a number of hurdles and goals were achieved. In fact we managed to run 5 trains simultaneously using TC's Spontaneous (random) run. The major identified problem is a 3-way point that requires a new decoder.

I previously overcame problems of points not switching on my home layout by upgrading my PC - the old PC was not able to handle the volume of traffic.

We also rely heavily on a member who is an electronics expert, and who provides a huge input, without which we would be struggling. I guess Nigel feels the same way we do about having someone with the right level of knowledge. BigGrin BigGrin

The problems are many and varied and with the help of our resident expert we have been eliminating them. Hopefully by the time of the show we should have a fairly bug free modular computer layout.

Regards
Mike
Digital - C track with CS2 and Railroad&Co TrainController; feedback using LocoIO via a Locobuffer
Analog - M track with solid centre rail (after C track layout is complete)
Collect all Eras - especially Crocodiles
Member of ETE
Previously a member of the Marklin Modellers' Group Johannesburg
Offline NZMarklinist  
#27 Posted : 14 September 2014 06:48:17(UTC)
NZMarklinist

New Zealand   
Joined: 15/03/2011(UTC)
Posts: 1,757
Location: Auckland NZ
Originally Posted by: MikeR Go to Quoted Post
Originally Posted by: NZMarklinist Go to Quoted Post

Nigel did employ professional help in the design and construction of the layout for Computer Control, saved him years !! Wink

It has a special Computer especially built and configured for the layout and auxiliary functions. The TrainController program was customised for Nigel, particularly where the Car System is concerned !

The layout does not use Marklin point motors, they are operated by servo's, and whilst I was told, I cannot remember the brand, other than they are not ESU servos that I intend to use for some of my points. RollEyes


Hi Glen

Thanks for the feedback on Nigel's layout. Interesting that he is using servos as point motors. One of the Modellers in our group was investigating servos but I have not asked him the outcome. I presume that Nigel found them more reliable. Our problem has not been with the point motors as far as we can tell but with the power needed to drive these motors and getting the required power to the point motor locations. The decoders must supply sufficient 'oomph' to positively drive the motors. In all cases we have recently been shorting out the micro-switches which has improved the reliability. As a Group, for our modular layout, we have also standardised on a couple of decoder types which has also improved the reliability. The current status on the modules is a continuous debug of the system. At today's prep session for the show in October a number of hurdles and goals were achieved. In fact we managed to run 5 trains simultaneously using TC's Spontaneous (random) run. The major identified problem is a 3-way point that requires a new decoder.

I previously overcame problems of points not switching on my home layout by upgrading my PC - the old PC was not able to handle the volume of traffic.

We also rely heavily on a member who is an electronics expert, and who provides a huge input, without which we would be struggling. I guess Nigel feels the same way we do about having someone with the right level of knowledge. BigGrin BigGrin

The problems are many and varied and with the help of our resident expert we have been eliminating them. Hopefully by the time of the show we should have a fairly bug free modular computer layout.

Regards


Hi Mike,

I think the answer to getting enough power to point motors lays in the wiring and configeration of the decoders.
For a large layout it is usual practice to have a dedicated booster for the decoders (weather it is the controller or a booster) and also use externally powered K83s eg; Viessmann. The other advantage they have is that the dip switches for setting the address, can be got at externally.
I am using or should I say intending to use, a few of the ESU servos on my layout, mounted directly below the turnout, because I have a cluster of three curved and one regular turnouts all connected together, where one track comes off an embankment and there is not room for a couple of the Marklin motors without burying them in the scenery structure. I intend to use the Viessmann K83s on my layout for the Marklin point motors, and will power them externally, altho they will be supplied directly by the Controller, most likely CS2, and all track power will be thru boosters, even though my layout is only small, 2.7 x 2.0 m
If the servos are successful, for me, I will use them throughout the BTW which is at the front and centre of my layout as not having them gives a much cleaner look, check out the pics on the thread about Nigels UK Club weekend, of his track work ThumpUp

That said the "Professional" involved with Nigel's layout is building a huge privately owned layout for public display, which is a two year + project. It is all K Track and they are using Marklin Turnout motors in the hidden areas, Schattenbahnhoff etc. Check it out here;

http://www.modellanlagen...201437_Wochenbericht.htm

Scroll down for many different scenery and technical views.

That company, BRIMA, I just remembered, had one of the 52 modules this layout is made up of, on display at the Marklin Days, last year. I will post the pics I took of it showing construction and wiring details when I get a moment later this week. Perhaps I might include some of the pics I took at the factory last year also, just to give you guys an idea of the scale of it ! Wink It is over 60m long Blink
Just FYI , Brima, construct their layouts in a large modularised form, so that they can be transported from their factory to the owners premises. Each of the modules of this layout are a large Van or small Truck load, the logistics of installing it will be interesting ! Scared

Miniatur Wunderland in Hamburg have been using the standard Marklin K Track turnout Motors on their layout since it's inception, and, whilst nine years ago they told me they were intending to replace them over time, (with tortoise because MiWuLa is all DCC) but I still saw lots of them on the layout and in some of the more recent sections as well like the Airport, on my visit there last year after the Marklin Days. One thing in their favour, they are relatively easy to replace if you have access to them. Smile
Glen
Auckland NZ

" Every Marklin layout needs a V200, a Railbus and a Banana car", not to mention a few Black and red Steamers, oh and the odd Elok !

CS1 Reloaded, Touch Cab, C Track Modules, K track layout all under construction. Currently Insider
thanks 1 user liked this useful post by NZMarklinist
Offline DaleSchultz  
#28 Posted : 23 October 2014 00:34:02(UTC)
DaleSchultz

United States   
Joined: 10/02/2006(UTC)
Posts: 3,997
I take the same approach as Willem (tdl)

1) lay and test all points well
2) set the turnout and assume it turned properly
3) I place s88 detection points after every turnout, if no train is booked to arrive there, then an incorrect turnout will put the train on the wrong track and will immediately trigger the s88 point. When that happens my software places the layout in halt mode and shows a pointer to the s88 that was triggered.
4) the number of times a turnout fails to move properly is minimal and tolerable. (I use K-track)

The k-track switch motors do have a little contact pad on the underside that one could use as a feedback loop (via a s88 port) to know that the motor itself moved. This would add the cost of at least one s88 port per turnout. (off = position A and on = position B) but I find they are relaible enough without full turnout feedback.

Self-written software.
Dale
Intellibox + own software, K-Track
My current layout: https://cabin-layout.mixmox.com
Arrival and Departure signs: https://remotesign.mixmox.com
thanks 2 users liked this useful post by DaleSchultz
Offline Gregzim  
#29 Posted : 05 November 2014 13:57:55(UTC)
Gregzim

Australia   
Joined: 09/11/2007(UTC)
Posts: 116
Location: Melbourne, Australia
Very interesting thread with lots of ideas. Studying the C turn out - a simple way to detect if the turnout actually moved mechanically could be done by attaching a tiny flag pole to the end of slider that the rails are attached to (its passes under each outside rail - with the flag pointing 90 degs to the track and with a pair of light emitting sensors positioned facing each other with the flag travel between them.

When the turnout moves the travel arm would slide the flag either away from the light path or into the light path (makes no difference) but the result is a signal to the software via a decoder that the turnout both moved and in which direction.

A similar if slightly move fiddly method that would work for K or C track is to put a small IR sensor under the track pointing up very close to where the inside curve moving frog end comes to a stop against the inside curve rail. By attaching (with epoxy) a small metal/platic tab to the "underside" of that moving inner rail - as it moves into place against the outside rail - the tab would cover the IR beam - turnout shut signal sent.

I also have a question - does anyone know how to disconnect the C track motor/decoder electronics without lifting the turnout? (I assume drill a hole somewhere to access the wires to cut them? but maybe there is another way ) If they fail I want to just replace with servos or slow motion external motors.
Users browsing this topic
Similar Topics
Computer Train Control Basics (Digital)
by michelvr 28/04/2019 15:50:22(UTC)
Computer Train Control Supports New Lok Features? (Digital)
by svgeorgiad 13/01/2006 14:01:41(UTC)
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

| Powered by YAF.NET | YAF.NET © 2003-2024, Yet Another Forum.NET
This page was generated in 1.810 seconds.