The recent updates to the CS2 added a feature to the Memory Route capability whereby a pre"condition" can be configured so that a route will not be triggered EVERY time a sensor is activated. Its activation is conditional on the state of a 3rd state.

For those not familiar with the Memory/Route function, there are 2 benefits offered
a) The ability to chain a number of turnout and signal operations together so that a single button can set a whole route
b) In addition to manually activating the route, it can be triggered by a s88 sensor (i.e a train passing a contact track)

Note: Last year the CS2s code was updated so that the selected s88 sensor could be attached any auxillary CS2 - not just the master
Comment: It is expected that the Links88 (announced at Nurnberg and expected late 2013) will be available in a similar manner.

One minor bugbear with routes triggered by a sensor in an automated running configuration is that they work EVERY TIME.
Areas where this may not be desirable are
- on branch lines with trains running in either direction
- including a locomotive sound in the route which is triggered by the wrong loco
- a ladder yard when one yard is vacant (disrupting the sequence)
- to program more than one sequence of operation
......

Of course if you are getting too complex a PC is the way to go, however somewhere in between there is value to be had by being able to "condition" a sensor so that the route only triggers if a separate condition exists.

So.. the screens for the solution provided is shown below whereby an "advanced" configuration panel is available by pressing "Erw" (short for "Erweiterte Einstellungen" meaning "Advanced Settings"). The right hand side relates to the "conditioning" which , at this version, is limited to testing the state of another sensor.

Leaving the sensor ID as "0" zero, means no conditioning an the route will trigger every time. If a Sensor ID is entered the condition to cause the route to trigger can be further qualified by the "Ein" CheckBox - meaning that the trigger will occur if the sensor is occupied (CheckBox ticked) or if it is unoccupied (CheckBox unticked).
Summary = Therefore 3 options
- no-conditioning
- - S88 Contact set to "0"
- Conditioning on active "2nd" contact
- - S88 Contact set to a value other than "0"
- - Ein Checkbox ticked
- Conditioning on inactive "2nd" contact
- - S88 Contact set to a value other than "0"
- - Ein Checkbox not ticked


At this point I have to concede that there are "close to zero" solutions I can conceive where this would actually be practical. I would far rather be able to set a condition based on the state of an accessory address ( a dummy signal if you will). In this way you could add the changes in conditioning signal as part of the automation.

I would like to hear what ideas other people have for this.



Comments:
- If a route, that contains a "signal to green" GO is prevented from activating how do you subsequently set the sequence off again

One possibility is to have a switch as the sensor, and to have 2 routes set up with the same conditioning sensor (the switch) but one with the "Ein" CheckBox ticked and one with the CheckBox unticked.

Edited by user 24 April 2013 23:41:23(UTC)  | Reason: Not specified

Yes - sort of , one of the routes will be set but it is a fixed choice - see observations below

Not detectable in this context

The sensor inputs are not - all sensors are processed.
However if you are referring to the "Routes that are configured triggered by the same sensor" and are asking if, when one route meets the condition and is activated, will it stop the other routes from activating? This would be nice , however observation at this code level does not bear this out.

Again - nice concept (readily achievable with a PC) but not seen in the current implementation.


An example of your 3 track shadow station is shown below. In this case 3 routes would be setup on the same sensor number 1
- Route A1
- - Sensor 1 Trigger : Condition if Sensor 2 is UNOCCUPIED then set turnout 21 to Straight
- Route A2
- - Sensor 1 Trigger : Condition if Sensor 3 is UNOCCUPIED then set turnout 21 to Curve and turnout 22 to Curve
- Route A3
- - Sensor 1 Trigger : Condition if Sensor 4 is UNOCCUPIED then set turnout 21 to Curve and turnout 22 to Straight

Given that "blue" indicates an occupied sensor in the figure, then Triggering Sensor 1 will result in ONLY Route A3 being activated - thus directing the train to Track 3 (bottom)

Note: The position of the turnouts as shown are not meaningfull - i.e. consider them a random state before Sensor 1 is triggered



In this next image with 2 unoccupied tracks (Track 1 and 3) then BOTH routes A1 and A3 will be activated (albeit in a serial manner) so the turnout sequence will be a chatter of turnout 21 as it turns straight (as instructed by A1) and then Curve (as instructed by A3) followed by turnout 22 to Straight (also as per A3)


If there was a "priority" of routes , logic states that A1 would run before A2 based on the order they are portrayed on the MEMORY panels. HOWEVER (I stress this is observation) a) Both Routes do activate, but b) the actual order of activation appears "curious" - I did think it might be the order in which the routes were created but have found exceptions.

While at no time during my testing did I end up with a route that incorrectly set the turnouts to an occupied track I am left with the impression that this scenario of configuring for 2 (or more) vacant tracks is not really desirable - using this method.

One scenario that has come to mind for this conditional trigger, could make use of an otherwise hard to use feature of a routes capability, namely to trigger a locomotive function (i.e. sound when entering a tunnel or at a crossing).

The problem with adding a function to a route is that the function is specific to a given loco. Therefore if there was some way to only trigger a route for that particular locomotive then this could actually be meaningful

Therefore if you like "parading your trains" and your layout has a storage facility where a "specific train" uses a "known" location, then using the condition that the "location sensor is not active" i.e. not at home, implies that when the sensor (by the tunnel) is triggered it must be that specific train(loco) and the appropriate sound(route) could be triggered.

Just one thought while we wait for something more usable.....

We use relays (originally from a k83/k84) which directly wire to ports on an S88 to set the states we wish to use for conditions

The relay "states" are used conditionally to
- augment CS2 shuttles (because we use reed switches or circuit tracks, and not contact tracts that Marklin expect)
- directional indication - e.g. branchlines and barrier arms
- counters - 1 sensor gives you up to 2, 2 sensors gives a count up to 4 etc.
- which "act" of the show is in play (similar to counter)

The relays are x8x controlled and are altered as part of the memory/route/event sequence.


As a contemporary comment.
The m84.2(60842) may appear to be a bit of an overkill however it can act as 8 relays compared to its predecessors 4.

Because the cost per port has effectively halved (from the 60841) and it is self contained this is worth investigating.
The m83.2(60832) may also be used with external relays and can possibly be assembled with less cost, however this means more components, real estate and skill (electronics soldering).

m84.2 = 75€/50€ / 8 = 9.4€/6.3€ per port
m83.2 = 50€/33€ / 8 + (reed relay and resister) 2€ = 8€/6€ per port
(prices indicative from [MarklinShop]/[WebDealer])

Hello Peter and others too

I believe I have seen this virtual feature when I first was testing S88 features just I have got the new CS3 plus.
I wrote also about my findings then to this Forum. After the first official upgrade, the feature was lost and I even wrote it in some mail.

I have found writings about this feature from earlier versions of CS3 German manual and in their German language book of CS3 there is a hint about coming features, I think this is it now.

Lippe informed me last week that they have sent me a new English version of the CS3 book. I think that i receive it next week.
We can see if there is something about this virtual feature.

I will write about it after I have red the whole new book.

I haven't seen that promised new upgrade of CS3 yet I hope it will come soon.

After last big upgrade my CS3 had strange behavior considering electricity on my layout. Strange sound irregular from somewhere digital turnouts and flickering light from old lighted wagons at the same time and same frequency. And at the same time some active locos didn't functioned as they should. Jamming and speed was not smooth etc. etc. I was using booster also

Then came a small new update and after I have loaded it strange behavior was gone. At the moment all functions works fine no problem at all.

That's all folks Have Fun

Jukka