CS2 Memory Route Conditioning Feature

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

Notification

Error

CS2 Memory Route Conditioning Feature - thoughts on the practicality of this new feature

Options

View

Previous Topic Next Topic

clapcott		#1 Posted : 24 April 2013 11:20:38(UTC) Retweet
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand		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
		Peter

6 users liked this useful post by clapcott		Bigdaddynz, Nielsenr, jeehring, Christoffer, GSRR, Janne75
User Profile View All Posts by User View Thanks


	Wish to join the discussion?! Login to your marklin-users.net community \| Forum account or Register a new forum account. Or Connect via Facebook

jeehring		#2 Posted : 24 April 2013 19:15:12(UTC) Retweet
Joined: 25/09/2003(UTC) Posts: 2,786 Location: ,		If I understand correctly (not so sure) we have the choice between 3 "conditions" 1/ no conditionning + two" ERW conditions" A/ sensor occupied or B/ sensor unoccupied....I mean "B" (sensor unocuppied) is another condition different from "1/" (no conditionning). It looks somewhat interesting, . For instance, before entering a 2 tracks shadow station on which one track is occupied, calling 2 routes together on the same sensor connected to 2 s88 inputs, if we specify "unoccuped sensor" for both, then the memory should automaticallly choose the free track... What about a 3 tracks shadow station as 3 routes are called together when only one track is occupied already : will the memory be abble to choose between the two remaining free tracks ? Are the contacts or s88 inputs prioritized ? (like with the old memory).Between all the 16 inputs of an S88 module, does the CS2 consider a priority order ? Or : is the memory abble to choose any of the two remaining free tracks randomly ? (we suppose that ERW condition "unoccupied" was specified)


User Profile View All Posts by User View Thanks

clapcott		#3 Posted : 25 April 2013 01:06:23(UTC) Retweet
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand		Originally Posted by: jeehring What about a 3 tracks shadow station as 3 routes are called together when only one track is occupied already Quote: - will the memory be able to choose between the two remaining free tracks ? Yes - sort of , one of the routes will be set but it is a fixed choice - see observations below Quote: - Are the contacts or s88 inputs prioritized ? (like with the old memory). Not detectable in this context Quote: - Between all the 16 inputs of an S88 module, does the CS2 consider a priority order ? 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. Quote: - Or : is the memory able to choose any of the two remaining free tracks randomly ? 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.
		Peter

5 users liked this useful post by clapcott		Bigdaddynz, GSRR, jeehring, MikeR, Elsleuth1
User Profile View All Posts by User View Thanks

clapcott		#4 Posted : 25 April 2013 01:22:48(UTC) Retweet
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand		A note re a comment Tom Cathrall made on the subject in the Digital Newsletter Vol24No5 (Sep-Oct 2012). At the time he mentioned this function was in beta testing. In the last paragraph he refers to the "Ausloser" field as being the "Condition". And refers to "Bedingung" with a descriptor as "the field for identifying "which port must also be set in order for the primary trigger to work" My reference to "Bedingung" as translated to "Condition" , comes from Google-Translation. This makes more sense to me but I mention this to explain any forthcomming confusion of terminology.
		Peter


User Profile View All Posts by User View Thanks

clapcott		#5 Posted : 02 June 2013 04:25:51(UTC) Retweet
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand		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.....
		Peter


User Profile View All Posts by User View Thanks

Johnvr		#6 Posted : 12 September 2017 16:35:40(UTC) Retweet
Joined: 03/10/2010(UTC) Posts: 1,293 Location: Cape Town, South Africa		Hi all, This is a continuation of an older thread in the Marklin User Forum ... I am using the Marklin CS2 , which has L88 (60883) and S88 (60881) connected to it, and using the 24994 Circuit Tracks to trigger routes. Everything is working as expected. The trains trigger the circuit tracks, and the memory routes kick in and set off the next sequence of instructions. I am quite interested to start experimenting with Conditional Triggering of Routes. And to be more precise, I am thinking of two types of conditional triggering : 1) physical, and 2) logical. 1) Physical Triggering would only occur if an Occupation Detection condition was fulfilled, for example. ie, a train is waiting at a station. This would be included in a feedback to the S88 and fed back to the CS2, whereupon the conditional trigger would examine the condition and take action. 2) Logical Triggering would only occur if an internal switch in the CS2 is set to be 'green', otherwise no triggering if the switch is 'red'. for example, if an Accessory like a signal or a turnout is Green or Red, whereupon the conditional trigger would examine the condition and take action. I am keen to find out from other users whether they have used Conditional Triggering of Memory Routes, and what your experience has been like. Regards, John


User Profile View All Posts by User View Thanks

clapcott		#7 Posted : 12 September 2017 22:24:05(UTC) Retweet
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand		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])
		Peter

1 user liked this useful post by clapcott		MikeR
User Profile View All Posts by User View Thanks

clapcott		#8 Posted : 17 September 2017 04:41:17(UTC) Retweet
Joined: 12/12/2005(UTC) Posts: 2,448 Location: Wellington, New_Zealand		While this thread was started when a CS2 function became available, it would be remiss to not reference the current and telegraphed CS3 perspective on the issue. Current (1.3.0(0)): The CS3 has introduced the concept of a type of virtual Sensors that do not relate to a physical S88 port. The CS3 calls these "Controlling Contacts" These may be used by the operator ONLY to set on or off and to have them affect the conditional logic of Events. One deficiency, compared to the CS2, is that you can only test for one conditioning sensor when commencing an event from a triggering sensor. It is possible to use the Continue/Delay logic within the event but that looks untidy as it leaves the "red" (fail) status, when it is not really a failure. Really could do with a more distinct icon/button for this. Telegraphed (in ChangeLog) as "Alpha testing and not included with 1.3.0(0)" : Extensions Events In the test are extensions to events. These are preliminary and will not be included in the release. 1 - Setting the status of S88 contacts. 2 - Accessories and locomotive control as conditions for waiting or canceling. If this matures (item 1) , then we will not need to find an external workaround (relay into a S88 port) to manage the conditions. However, again we are in a waiting game with no real firm statement from Marklin that the feature will actually be available and, if so, a timeline to work to. Marketting would love us to not have this function (for free) as it means less m84(60842) sales Item 2, sounds intriguing, however I wonder if it is overkill. If the ability to set the Conditional S88 contacts is done correctly do you really need to refer directly to the accessory or locomotive state? It might be worthwhile if the button/icon to change a signal invoked an event of its own and this could be conditional. Edited by user 17 September 2017 10:12:53(UTC) \| Reason: Not specified
		Peter


User Profile View All Posts by User View Thanks

siroljuk		#9 Posted : 17 September 2017 09:09:12(UTC) Retweet
Joined: 29/10/2010(UTC) Posts: 377		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

2 users liked this useful post by siroljuk		grnwtrs, river6109
User Profile View All Posts by User View Thanks

Users browsing this topic
Guest

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.