Not sure if this should be here or in HO but this is as good as any.

I want to run a Shuttle train , using the shuttle train feature of the CS and Ecos. BUT with a difference. I want to run two (2) trains (in opposite directions) with a passing Loop somewhere between the stations.

IS this possible, and how.

Thanks,
nev

May 2011:
towards the end are the best parts.

NN

Edited by user 22 May 2011 03:26:16(UTC)  | Reason: Not specified

Nev hi,

What you plan should be possible with a simple trick: let the ECoS set the two locos you will use in this scenario as double header locos. As a result; their speed would be exactly the same.

From there on you wouldn't have any problems running them from opposite directions.

Cem.

That's right Ray, it have to be in the middle.

Cem.

Ray, that is the real question can the shuttle sequence handle intermediate stops and two trains. Even if the passing loop was in the exact centre there would be the chance of a horrible collision.
Nev

Cem, thanks that is along the lines that I was thinking. BUT HOW to set it up. Is it a shuttle, or a route.

nev

Instant communication here.

Ray, It will be a dedicated line for the shuttles. I think we just need block clear notices,

But will the shuttle set up handle 2 trains or do we go some other plan.
I am sure that LH could answer but I live in hope
N

The issue with the shuttle trains is that they have two S88-sensed triggers, one at each end. However, the best idea would be to see if you have some programming capability and make it so that you have to wait a certain amount of time after BOTH trains have re-entered the end sections to make sure all are "back home." Also, you may want to take some precautions at the two ends of the fork to make sure a train cannot exit onto the shared track if the other train is still there. Timing is fine until it isn't, and it eventually isn't!!--MM

It has to be a route, IMHO, but you can't control the loco speed.

The Duke Left town. I was feeling poorly.

Thanks, Dave I will send Clapcott a PM.
NN

This is the kind of challenge that I think emphasizes the difference between the model railroading hobby and the current range of "canned, finite solution" toys.

With a pallet of components, that are in themselves wide and diverse, people can employ each in a number of quantities, depth and configurations to realise any vision they, and not someone else with corporate narrow mindedness, has imagined.

Marklin added the shuttle function as another tool into the digital portfolio with the CSv2 but prior to that numerous people had found ways to achieve similar results, be it with electronics ( relays, pulse circuits and delay circuits) or with a PC (using the interface and 602x digital with s88s).
The feature is a basic teaser and comes with limitations that are , in my view , annoying
- inability to adjust speed (to tune)
- inability to change function (sound horn)
- fixed delays at both ends (and middle for CS2)
- requires exclusive use of the section of track (sensors cannot be triggered by another train)

But when one shuttle route is not enough (and it never is) a decision has to be made as to the degree of investment needed..
- "just enough to get the thing working"
or
- "a scalable infrastructure that can grow and mature" (or be suspended).

One consideration with any "electronic" solution is the fact that it was generally hardwired and inflexible outside the original design objectives, while a PC program could introduce logic (decision), randomness, and variation once the base infrastructure is in place.

To address Nev's scenario a "hardwired" solution is certainly possible using k84s (relays) in combination with the shuttle function and other sensor triggered routing. I will post one "possible" solution shortly.

However it doesn't take too much comparison to see that a simple "Shuttle only" program-ette could overcome a number of hurdles
- cost of hardware - k84s are not cheap
- fixed solution
- - may want to run only one train, or none ( Trains passing straight through the section)
- - (CS1 does not allow disabling of routes - they activate every time the associated s88 triggers)
- variation
- - different times at each end
- - randomness
- enhancement wishes
- - include functions (whistle, lights)
- - accessory coordination - platform lights on

And for those wary of the PC, please consider that it is NOT an all or nothing choice. One or more program(s) can be selectively run OR not. allowing bits of the layout to be set for automatic running while other bits are under manual control.

More to come ...

Peter,
You are indeed thinking outside the square. I look forward to the solution and I have months to await the result.

thanks immensely,

Nev

PS: at my age Cost is not a consideration. No pockets in shrouds. [}:)][}:)]

Not sure or this is out of bounds, but have you thought of Uhlenbrock Lissy?

The offer a set called "pendelzugsteuerung art. 68010" which is designed for this http://www.uhlenbrock.de/germany/index.htm , which contains all the stuff you will need to operate a pendel train.

I use the system my self for different purposes (steering of my entire lay-out) and I must say it works quite good.

Peter is referring to LocoBuffer


http://www.locobuffer.com/


And there is also LocoBuffer-USB


http://rr-cirkits.com/

A) Sensor enable/disable

The CS shuttle function works with 2 sensors (at each end of a route for each train). These sensors are unaware of which train triggers them.

As mentioned above. If only one train at a time is in operation and its direction is consistent with the 2nd train when it starts to work then a single route can be used by both trains. The following presumes that this is not always the case and therefore a shuttle route PER TRAIN is needed.

Therefore in order to run 2 (or more) trains on the same piece of track (over the same trigger section) some way is needed to enable only the appropriate connection to the S88 sensor input that is applicable to the train in the vicinity

The diagram shows how a k84 (relay contact) can be used to enable or disable a train that triggers contact track "A" from activating Sensor input 12


So if we were to have a second sensor which we want to enable for the second train we may have this...


And taking into account the other end of the route - this ....


This is great if we want n'th degree of control of each sensor , however , aside from using up k84 ports unnecessarily this is usually not the case.
It should be possible to use the same track contact and route it to EITHER of 2 sensors as we are unlikely to want to ever enable them both at the same time.
Thus ...

Note: Using a Contact track (e.g. C-Track 24995) this way (rather than Circuit Track) removes the need to worry about placing the 2 trains on the line facing the same way

... Moving on and including the other end of the line ...


Now - given that we plan to have a link between the left and right ends of the route and the two trains location at any one instance in time, we should be able to tie these two relays together.
The k84 only offers Single pole contacts so let us introduce the universal relay 7244 driven by a k83


This offers 4PDT but we only need 2 for this project.

Shown here in the "Green" position,
- Contact "A" is allowed through to Sensor 15 and contact "B" is allowed through to Sensor 13.
If switched "Red"
- Contact "A" is allowed through to Sensor 16 and contact "B" is allowed through to Sensor 14.

Thinking ahead it may be seen that
- Train "X" will be configured to operate with a shuttle route containing Sensor 15 and 14 and
- Train "Y" will be configured to operate with a shuttle route containing Sensor 16 and 13
The configuration shown (Green aspect) will be the setup with Train "X" heading west and Train "Y" heading east


On a personal note I usually deviate from the 7244 into a bit of electronics with a 12V DC latching relay. This is both smaller and removes the mechanical aspect of the 7244 (It is also cheaper - even with the diodes and resistor)


Ref:
http://www.jaycar.co.nz/...atching&form=KEYWORD
http://www.jaycar.co.nz/...cts_uploaded/SY-4060.pdf

B) Interlocking

Most of the sequencing in a layout is a series of fundamental causes and effects.
e.g. A train goes past a signal it sets the signal to Red.

Occasionally there is a need for two (2) events to occur before any action happens. To complicate the issue there is no guarantee that the events will occur in a particular order.

The following addresses this issue of Nevs challenge by having each of the two sensors (address D/11 & C/12) on either side of the loop run a route in the CS that closes (turn ON) a k84 relay/switch (addresses 4 and 3 respectively ).
Only when both switches are closed/ON does the "T" signal get through to the s88 and trigger the input for sensor 8.



The route associated with sensor 8 would include commands to turn signals 11 & 12 to Green.
Thus the first train to arrive, regardless of it being X or Y would be met by a Red signal and only when the second train arrived (and the line clear) would it be allowed to proceed

Note: The location of Sensor C and D must be such that the train is totally within the loop (clear of the point) before they are triggered.

Note: I am assuming that the dead sections (indicated in blue) are wired into the signal and will stop a train when the signal is Red

The Second Train would not stop as the signal just ahead of it would be set Green just before it was reached.



Of course k84 switches 3 and 4 must be OFF to start with. One (cheats) option is to have the Sensor 8 route also turn these switches off after it has set the signals and dead section to Green. However it is important that the rear of the train is not prone to "bouncing" the "C" and/or "D" contacts which will cause the re-triggering of the route.

It is better to do this "rearming" of the switches when the trains are well out of the loop.
It might be considered that another interlock of sensors A and B might achieve this ...... but



... consider the possibility that one train is faster and/or travels a shorter distance to get to the end sensor,reverse and get back to the loop before the other train has reached its end / reverse point.

To cover this the route associated with triggers A AND B should both switch k84 contacts 3 & 4 off..... but ....

... what if the train does not move out of the loop (Speed somehow set to zero or on a dirty piece of track)

I appreciate that this may be OVERTHINKING the issue , and that some basic setup checks for correct speed settings and a clean track will mitigate the risk , but Murphy will strike when least expected


Here I suggest programing the 2nd interlock circuit so that Sensors A AND B are both needed before signals 9 and 10 can do green.
For cosmetic reasons there need not be an actual signal mast - just the controlled dead section.

Also , since 9 and 10 will both be either live or dead, it may be worth considering a DPDT relay - see above - and only needing 1 k83 port.

Pulling these thoughts together the 2 interlocking circuits would be set up to "allow trains through" only when BOTH conditions are met AND would ALSO Rearm each other !

Sensor C AND D are needed ..
.. to set Signals/Dead Section 11 and 12 to Green
.. and would also set k84 addresses 1 and 2 OFF
.. and would also set Dead Section 9 and 10 Red
Sensor A AND B are needed ..
.. to set Dead Section 9 and 10 to Green
.. and would also set k84 addresses 3 and 4 OFF
.. to set Signals/Dead Section 11 and 12 to Red

Note: Reality Scenario ...
If Train X is reversing east and its rear carriage triggers Sensor D while the loco (pickup) is still in the section controlled by signal 9. The Route sequence, which includes setting signal 9 to red, will cause the train to stop undesirably.

This must be addressed by either
- Altering the length of the train and/or distance between the contact track and the controlled section.
- Or by using a non-contact track solution (e.g. a magnet and reed switch) to better position the train past the controlled section when the sensor is triggered

Consideration of the final solution must account for the same train consist returning (west) as train Y through the bottom part of the loop. And how Sensor D and controlled Section 10 inter-relate


C) The Toggle

To recap on the Brief.
- Configure a shuttle operation on the same line using 2 trains
- Use CS1/EcoS Shuttle Feature (and supporting features Routes, k8x decoders)

Considerations
- the 2 trains "may" be moving at the same time and in either the same or different directions
- The shuttle function of the CS1 cannot disable a sensor.

Therefore 2 sensors are needed (at each end) - one for each train - configured in such a way that only the one for the "expected" train is armed/enabled.
As a Train triggers a sensor the CS1 Shuttle route controller will stop it, reverse it and send it on its way.
Some time after the train has left the sensor area but before the second train arrives, the sensor (for train-A) must be disabled and the other one (for Train-B) must be enabled.

This changing of sensor configuration needs to be repeated alternateively as the trains swap ends of the line
This is what I call "toggling" and the proposal is for something akin to a JK FlipFlop.

It is important that he change from Mode-A (Train-A expected East,Train-B expected West) to Mode-B (Train-A expected West, Train-B expected East) occur when both sensors are clear (to avoid an erroneous trigger).

I propose this is done when we know both trains are in the loop

Two further issues
- the Toggle should only change Once (we must stop a bouncing train from causing multiple switches)
- Prior to the state change the new state must be armed as the alternate of the existing one.

The following worm diagram attempts to show the sequence of events.
The changes themselves are all produced by a s88 sensor switching a route that includes k84 relays



When the two trains are in the loop the "interlock" detection (described in the above section) will clock the state of the PreLatch through to the Mode Latch
In the diagram below ..
- The ModeLatch is K84-7
- The PreLatch is K84-8

Also note
- While the section on interlocking offered the scenario for generating an interlocked trigger when BOTH "A" and "B" events occur, this can be mitigated and I have removed the clutter
- insertion of "disable" relay/switch into the feeds from sensors "C" and "D" to prevent multiple triggers. These will be K84-1 and K84-2
- interuption of sensor feeds from "A" and "D" as we will move towards the configuration in the firsts section of this rant [b"]A) Sensor enable/disable"[/b]. As shown we will allocate S88-13,14,15,16 for the 4 triggers. And for the relays we will stick with K84-5,6 (keeping in mind a DPDT relay driven by a single K83 output could apply)



So as the 2 trains arrive at the loop Sensors C/S88-12 and D/S88-11 will trigger. The programing behind this trigger would be
S88-12 = K84-3/G (and if used) K83-10/R for protection
S88-11 = K84-4/G (and if used) K83-9/R
However we also want to stop retriggering of the sensors so we add
S88-12 = K84-3/G, K83-10/R, K84-2/R
S88-11 = K84-4/G, K83-9/R, K84-1/R

Previously we saw that K84-3/G and K84-4/G would send a trigger pulse through to S88-8 and this is what (as Programed in the CS1) would set the signals K83-11/G and k83-12/G - and off the Trains would go.
S88-11 = K84-11/G, K84-12/R

For good measure we will reset the "train arrived" latches now, ready for the next interlock K84-3,4 so S88-11 should now be
S88-11 = K84-11/G, K84-12/R, K84-3/R, K84-4/R

This same signal that triggered S88-8 would also proceed through K84-7 to either S88-1 or S88-2 with the aim of setting the layout up for Mode-A or Mode-B operation.
S88-1 would set K84-5 to Red (Train-A expected East), K84-6 to Green (Train-B expected West)
S88-2 would set K84-5 to Green (Train-B expected East), K84-6 to Red (Train-A expected West)

To this is added the commands to prepare the PreLatch, K84-8, for the next toggle thus ..
S88-1 = K84-5/R, K84-6/G , K84-8/Red
S88-2 = K84-5/G, K84-6/R , K84-8/Green

Thus the only step left is to somehow cause a trigger to change the K84-7 ModeLatch based on the state of the K84-8 PreLatch.
This could be done anytime both trains are not in the loop, therefore we could use Either Sensor "A" or Sensor "B".

Below shows Sensor "A" (which would also be routed through K84-5 to cause the Trains Shuttle to change direction) being routed via K84-8 to either S88-3 or S88-4.
The route programing for this would be
S88-3 = K84-7/G
S88-4 = K84-7/R



D) Sync ?

All this logic is great but it makes at least some assumptions. Even assuming there is no issue with "dirty track", certain scenarios do exit if the distances east and west of the loop are significantly different and the speeds of the 2 trains also different that things will get out of sync.

However by far the biggest assumption is that the trains are setup to run in the direction that the "Layout Mode" is expecting. As to the particular state of all the signals and relays must be primed. This latter can be done by setting a dummy "Setup" route in the CS1 what does it for you (rather than remembering).

Personally I find it handing in these situations to add an indicator LED (e.g. on the ModeLatch) for a visual check that the relays have been set correctly.

E) One Solution ?

At this stage I refrain from posting a complete solution , primarily because of the cob-web it would look like. But also because I am of the conclusion that a PC based solution would be simpler, more versatile (tweekable) and far less expensive. This does not detract from the validity of the challenge

Hopefully the above "building blocks" will allow for the selection of components needed , should this sort of hardware solution still be desired.

[b]Open for Peer review

Peter,
Thanks for your efforts.
I will talk to my "experts to decode this for me and get something working some time in the near future. Like as soon as we can.

Nev

Thanks a million Peter, for you great effort doing this comprehensive lookup table, drawings and explanation.

BTW, did you strike out the B) Interlocking section by your edit command or is it to come later? (No rush).

I was trying to take a shot of our club's 1 Gauge layout, when Clapcott walked between the camera and the subject......

Edited by moderator 11 January 2011 18:27:10(UTC)  | Reason: Not specified

Hi Peter i started reading then i started laughing that must be the best answer i seen for a while I will draw it to dions attention he will love it and then his brain will click in, he's been working on a mountain railway for a chap the last few weeks so he might find you your answer interesing,and then he might sit down and write a programme to do it, I seen him do it so often, he loves these sort of problems its his idea of mental sport
great to see the photos from the exhibition Dion and Diana had a great time
regards bryan

wot can i say. magnificent. my head is spinning. i will read, digest, get in my electronic code breakers and think.
thanks for the software program.

nn

Peter,
I've gone through your explanation with different scenarios, does it include in case a carriage is left behind ?
If I missed it, my code breaker is not working very well on Sunday.

regards.,
John

regards.,
John

Correct - 15471 , for TCP

I would not be surprised if standard firewalls get in the way, but generally you get alerted to the attempt and have the option to accept or decline. If this prompting is off then you will get a 30 second time out (similar to entering the wrong address). Some manual exclusions to the firewall may be needed.

More to the point however I note that the CS1 will not "wake up" if the network cable is plugged in after a restart. Either ..
- restart the CS1 with the cable already connected to a live network
- use the Settings tab to change the address and then change it back. This appears to kick things into life.

Basic tests to see if PC is actually talking to CS1 at all.
- ping
c:\>ping 192.168.0.81
Pinging 192.168.0.81 with 32 bytes of data:
Reply from 192.168.0.81: bytes=32 time=1ms TTL=64

- telnet ( you should at least get the login prompt )
c:\telnet 192.168.0.81
CentralStation login:

- from browser



If these basic tests work then it is almost certainly a firewall issue against either port 15471/TCP or the application itself.

Edited by moderator 11 January 2011 17:15:01(UTC)  | Reason: Not specified

Peter:

- No firewall enabled on PC
- CS was powered up after the network hub was turned on
- Can ping the IP address of the CS from the PC
- Can connect to the CS with LocCommander and control the layout via the PC.

I do also have the Rocrail server running as a service on the PC, which may have possibly grabbed the TCP port, although LocCommander wasn't affected by that. I'll try again later on with the Rocrail service stopped.

- XP SP3
- 172.31.21.250 (CS) 172.31.21.203 (PC) both 24 bit mask.
- Can ping and telnet to CS, can access CS web management page.
- Shuttle program does not connect to CS.
- LocCommander and Rocrail do connect to CS
- CS1 is at v2.0.4

That connects now!

But getting some unhandled exceptions if I try to dial up speed control on a loco.

It reads the loco list OK.

I tried a program restart, still got the unhandled exceptions.