C track point feedback

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

Notification

Error

C track point feedback

Options

View

Previous Topic Next Topic

revmox		#1 Posted : 06 April 2025 05:07:48(UTC) Retweet
Joined: 26/05/2021(UTC) Posts: 198 Location: Australia, East Maitland, NSW		I'm looking for some solid information with regard to position feedback from C track points (turnouts or switches, take your pick). I currently run my small layout with dual MS2s but use analogue point control because I really don't want to scroll through the MS2 menus to control 32 points. I have 8 x 72710 control boxes and 32 x 74492 point motors. It all works fine, it's quick and easy, provides immediate indication of point position - the only downside is running all the under-board wiring given my age and health. Fitting 74462 decoders to the points would allow the MS2 to control them. The manual says they can be configured for "DCC or fx (MM)" - does that mean they have some mfx capability (can provide feedback) or do they just run the old MM protocol on an mfx capable controller? Is there a feedback path that provides confirmation of point position from a 74462 decoder on an MS2? What is the situation with a Control Station? Does full mfx capability become available? Is feedback available directly from a 74462 decoder? Is it available when working through an m83 or other decoder? If a Command Station screen shows a point in a certain direction - is it the last commanded direction or what is actually fed back from the point itself? The more I read the Marklin documentation the more uncertain I become - maybe I need to lay off the wine a bit. I'm toying with the idea of making a switch panel and going in via the track box CAN bus to control the points - keep the easy-to-use interface and ditch the wiring. Cheers!


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

Ross		#2 Posted : 06 April 2025 05:46:41(UTC) Retweet
Joined: 25/09/2006(UTC) Posts: 945 Location: Sydney, NSW		Hi Mark, You can monitor the point motors with s88 contacts see article below. Turnout Position Control Hope it provides ideas for you. Use m83s to switch the points as it has better electronics that can be fine tuned.
		Ross
		WWW
2 users liked this useful post by Ross		revmox, Bent
User Profile View All Posts by User View Thanks

revmox		#3 Posted : 06 April 2025 08:12:56(UTC) Retweet
Joined: 26/05/2021(UTC) Posts: 198 Location: Australia, East Maitland, NSW		Originally Posted by: Ross Hi Mark, You can monitor the point motors with s88 contacts see article below. Turnout Position Control Hope it provides ideas for you. Use m83s to switch the points as it has better electronics that can be fine tuned. Thanks Ross, that's a lot to digest. IF I've read your notes correctly - 1. Without modifying the point solenoid microswitches NONE of the digital systems provide any monitoring of the physical position of the point blades (unlike the ancient analogue system). 2. If you do modify the microswitches then monitoring is possible via an s88 or equivalent. Nevertheless, it seems that some form of feedback from the decoder is possible - but it doesn't cover physical position - although that information should be present on the wires to the solenoid, just as in the analogue situation. The section from the 24802 expansion package below still reads like gibberish to me. Thanks for the help, Mark

1 user liked this useful post by revmox		Ross
User Profile View All Posts by User View Thanks

osoraku		#4 Posted : 06 April 2025 12:29:28(UTC) Retweet
Joined: 22/01/2025(UTC) Posts: 53 Location: Setubal, Palmela		Dear Mark - I have a CS2 protocol packet sniffer that I used to troubleshoot some problems with Marklin digitally controlled turnouts. Briefly, they show that the turnouts are aware of their position. How you make an S88 or M83 aware of this, I don't know - others might relate their experience. Technical details follow.. The packet sniffer prints out packets from the controller (in this case, Rocrail), the Gleisbox, and the accessory (turnout) on the rails. TCP -> CAN prefixes the packet contents (CS2 format, in hexadecimal) sent by the controller. CAN -> TCP similarly prefixes the packet contents sent by either the Gleisbox or the accessory. After each line is a decoding into English of the packet's contents. An important part of the hexadecimal codes is the second group of digits, which is the CAN hash. This is unique to every agent on the CAN bus capable of generating a command or a response. Key codes are: 4322 - Rocrail; 4f20 - Gleisbox; 0300 - Turnout (DCC accessory ID 1). TCP -> CAN 0016 4322 08 0000 3801 0101 0032 C ACC 0B (00003801): posn 1 current 1 switch time 50x10 ms CAN -> TCP 0017 4f20 06 0000 3801 0101 0000 R ACC 0B (00003801): posn 1 current 1 CAN -> TCP 0017 0300 06 0000 3801 0100 0000 R ACC 0B (00003801): posn 1 current 0 These three packets show 1) Rocrail telling the accessory to move the points; 2) The Gleisbox forwarding the command to DCC signalling on the rails; 3) the turnout acknowledging the command. The three commands move the points. TCP -> CAN 0016 4322 08 0000 3801 0001 0032 C ACC 0B (00003801): posn 0 current 1 switch time 50x10 ms CAN -> TCP 0017 4f20 06 0000 3801 0001 0000 R ACC 0B (00003801): posn 0 current 1 CAN -> TCP 0017 0300 06 0000 3801 0000 0000 R ACC 0B (00003801): posn 0 current 0 Next, these three packets show 1) Rocrail telling the accessory to move the points back to its original position; 2) The Gleisbox forwarding the command to DCC signalling on the rails; 3) the turnout acknowledging the command. (Added later) It turns out the same packet sequence is given even if a turnout is not present, so the Gleisbox is generating the acknowledgement from the turnout. There is apparently no determination of its present state. How you make an S88 or M83 pay attention to it, I have no idea. Osoraku Edited by user 27 April 2025 17:34:42(UTC) \| Reason: Updated info after tests


User Profile View All Posts by User View Thanks

revmox		#5 Posted : 06 April 2025 13:00:48(UTC) Retweet
Joined: 26/05/2021(UTC) Posts: 198 Location: Australia, East Maitland, NSW		Hi Osoraku, Thanks for all the information - quite interesting and potentially very useful. I think I understand most of it. So, it seems that the decoder can/does send back some information regarding point position - but I think the original question remains - is the decoder just reporting the last commanded position from memory (which, if everything is working correctly, should match the physical position) OR is it directly reporting the physical position of the point blades based on the levels found on the point motor wiring and coming from the solenoid limit switches? If you were to manually move the point blades would that change the data seen on the CAN bus coming back from the decoder? Do mobile stations or central stations use that data - or also just rely on the last commanded position. Maybe someone with a CS2 can answer that? The information from Ross in the previous posts explains how the S88 style decoder boxes can report the physical position of MODIFIED point motors. Cheers, and thanks again, Revmox


User Profile View All Posts by User View Thanks

blid		#6 Posted : 06 April 2025 14:21:42(UTC) Retweet
Joined: 02/01/2012(UTC) Posts: 244 Location: Stockholm, Sweden		I think you are talking about two different things here. Osoraku talks about the position command the decoder has received. Whether the turnout motor has moved the turnout to the desired position is a different matter. This can be checked by 2 s88 sensors. The turnout motors have two micro switches turning of the power at either position. By connecting the s88 to the blue wires the s88 will signal power or not. When the motor is in one position one of the s88s will be off. When it is in the other position the other will be off. While changing the position both will be on. I don’t know if these micro switches have been fixed by Marklin now. When I had my layouts they were the problem. I know because I used the s88 position control.
		OneGauge Marklin and MTH, ESU ECoS 2.1 on LGB tracks. MTH 3-rail 0-gauge, DCS on GarGraves tracks. Z: Rokuhan tracks, analog or DCC+TC Gold.

2 users liked this useful post by blid		revmox, dickinsonj
User Profile View All Posts by User View Thanks

osoraku		#7 Posted : 06 April 2025 15:19:49(UTC) Retweet
Joined: 22/01/2025(UTC) Posts: 53 Location: Setubal, Palmela		Dear Mark - Originally Posted by: revmox ... If you were to manually move the point blades would that change the data seen on the CAN bus coming back from the decoder? Do mobile stations or central stations use that data - or also just rely on the last commanded position. ... (Added later) There does not appear to be any way to query the turnout's position, so the controller only knows the last commanded position. Osoraku Edited by user 27 April 2025 17:38:03(UTC) \| Reason: Updated after hardware testing

2 users liked this useful post by osoraku		revmox, dickinsonj
User Profile View All Posts by User View Thanks

revmox		#8 Posted : 07 April 2025 00:52:55(UTC) Retweet
Joined: 26/05/2021(UTC) Posts: 198 Location: Australia, East Maitland, NSW		Thanks blid and osoraku, Just did some testing with an MS2 and a pair of points from the 24802 track expansion set. The MS2 only displays the last commanded position it sent to a point. Manually changing the point direction doesn't change what is displayed on the MS2 either immediately or after a power off restart. Setting the point to a particular direction via the MS2 then disconnecting the point wiring and changing the point direction on the MS2 will show the new direction on the MS2 even though the point isn't connected. Then reconnecting the point doesn't change the display to match the previously set direction and the point blades don't move to match what is displayed - including after a power off restart. Conclusion - the MS2 operates points in a "fully open loop" manner - there's no feedback of any kind used to confirm a direction command is received or the physical position of the point blades. Maybe a CS owner can report if that is also true for that system ... Osoraku's post does suggest that it should at least be possible to build something to read what direction the point was last commanded to be in from the point itself. Interesting that the old analogue system can easily do something that the new digital system can't. Cheers, Mark

1 user liked this useful post by revmox		marklinist5999
User Profile View All Posts by User View Thanks

dickinsonj		#9 Posted : 07 April 2025 00:57:58(UTC) Retweet
Joined: 05/12/2008(UTC) Posts: 1,801 Location: Crozet, Virginia		Central Stations work exactly the same way. They send a command and change their display to match and there is no feedback from the points.
		Regards, Jim I have almost all Märklin and mostly HO, although I do have a small number of Z gauge trains! So many trains and so little time.

2 users liked this useful post by dickinsonj		revmox, marklinist5999
User Profile View All Posts by User View Thanks

Martti Mäntylä		#10 Posted : 07 April 2025 01:32:19(UTC) Retweet
Joined: 15/11/2018(UTC) Posts: 431 Location: Uusimaa, Helsinki		CAN Digital Weichenchef switch decoders actually sense the position of a switch and report it back to the CAN Bus. So I can use the manual lever to turn the switch and see the change reflected on my Rocrail screen or MS2 display. If I remember correctly, the same goes for signals.
		- Martti M. Era III analog & digital (Rocrail, CAN Digital Bahn, Gleisbox/MS2, K83/K84), C & M tracks, some Spur 1
		Twitter
1 user liked this useful post by Martti Mäntylä		dickinsonj
User Profile View All Posts by User View Thanks

revmox		#11 Posted : 07 April 2025 05:38:00(UTC) Retweet
Joined: 26/05/2021(UTC) Posts: 198 Location: Australia, East Maitland, NSW		Originally Posted by: Martti Mäntylä CAN Digital Weichenchef switch decoders actually sense the position of a switch and report it back to the CAN Bus. So I can use the manual lever to turn the switch and see the change reflected on my Rocrail screen or MS2 display. If I remember correctly, the same goes for signals. Thanks Martti, Interesting that someone has that alternative commercially available. It probably shows that, technically, Marklin could have also made that kind of feedback available over their protocol if they had chosen to. That is not a criticism of the choice they made many years ago - things were different then and they probably did very well to achieve the level of digital control they did. In the last hour or so I've wired up an Arduino Nano and a CAN module and can now look at the signals going between my MS2s and the track box. I should be able to wire up a button panel or touch screen to control my points with CAN via the track box OR just make an 8 x 72710 control box to CAN interface - traditional buttons, minimal wiring. I started this thread just wondering whether feedback from the points was necessary/desirable/possible. I'll see where it goes ... Thanks once again, Mark

1 user liked this useful post by revmox		Martti Mäntylä
User Profile View All Posts by User View Thanks

blid		#12 Posted : 07 April 2025 12:26:07(UTC) Retweet
Joined: 02/01/2012(UTC) Posts: 244 Location: Stockholm, Sweden		I want to rephrase and clarify what I wrote in post #6 about the s88 indicators. They indicate if the micro switch is open or closed. I have assumed Marklin turnout motors. A micro switch is only open when the turnout motor is in the end position for that direction. Else it is closed and connects to the power side of the circuit. The decoder connects to the ground side when activated. The only time there is power to the motor is when the micro switch is closed and the decoder is activated for that direction. Here is the diagram by Littfinski of LDT: I did this for all my 104 turnouts back in 2008. I used the Opto version of the s88-modules and they have the reference the other way round. Ground for detection of connection to power side. The LDT decoders has a special port for this. Clear as mud. My thoughts about C-track turnout position verification in general. The only way to check the position is visually inspect it or run a train past it. The next best is to check the lantern or lever if the turnout have them mounted. This may be wrong if the moving parts (point tracks?) are stuck. May happen when landscaping but not likely once they move freely. The s88 method is just as good. It will also show a manual change of position and the position when starting the session. It is up to you or your program to update the symbol in the controller if necessary. The latest executed decoder command is only good if the turnout motor never fails and you wont see manual changes.
		OneGauge Marklin and MTH, ESU ECoS 2.1 on LGB tracks. MTH 3-rail 0-gauge, DCS on GarGraves tracks. Z: Rokuhan tracks, analog or DCC+TC Gold.

1 user liked this useful post by blid		revmox
User Profile View All Posts by User View Thanks

H0		#13 Posted : 07 April 2025 12:36:39(UTC) Retweet
Joined: 16/02/2004(UTC) Posts: 15,442 Location: DE-NW		Originally Posted by: osoraku These three packets show 1) Rocrail telling the accessory to move the points; 2) The Gleisbox forwarding the command to DCC signalling on the rails; 3) the turnout acknowledging the command. The three commands move the points. DCC decoders do not send feedback, neither do MM decoders. So the "turnout feedback" must be sent by the trackbox to indicate that the turnout command has finished. The same CAN traffic should appear if there is no turnout connected to the decoder. The same CAN traffic should appear even if there is no turnout decoder with that address.
		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

3 users liked this useful post by H0		dickinsonj, marklinist5999, revmox
User Profile View All Posts by User View Thanks

revmox		#14 Posted : 08 April 2025 00:24:21(UTC) Retweet
Joined: 26/05/2021(UTC) Posts: 198 Location: Australia, East Maitland, NSW		Here's the CAN traffic that goes out with a point command - it is the same whether the point is connected or not. This is just my understanding of what is going on, I'm no expert. 80169F61 is the ID of the MS2, 80176F27 is the ID of the track box echoing what it receives, 6 is the number of data bytes to follow. After going around in circles for an hour I remembered that MM format requires commands to be sent twice as error checking rather than using a CRC code. If you send the first line of the 4 line block twice you can control the points via a remote device. I also seem to remember that there should be a gap between MM frames so I threw in 2mS just in case. It all works, and the MS2 display indicates correctly. I don't know why the first and third lines in the block are slightly different. Note that the MS2 ID, 80179F61, is made up of a fixed part that is burnt into a particular device at the factory AND a factory reset counter - if you do a factory reset everything mfx on the layout will have to re-register. Anything you built using the old ID may then also have issues.


User Profile View All Posts by User View Thanks

osoraku		#15 Posted : 08 April 2025 10:16:33(UTC) Retweet
Joined: 22/01/2025(UTC) Posts: 53 Location: Setubal, Palmela		Dear Mark - Based on your listing, here's a decoded version of the interaction based on the CS2 protocol. (I left off the data and decoded it into English.) The first three interactions are: 80309F61 - PING command (from CAN hash 9F61) 80169F61 - ACCESSORY command (from CAN hash 9F61 to MM1/2 turnout 0) posn 0 current 1 80176F27 - ACCESSORY response (from CAN hash 6F27 to MM1/2 turnout 0) posn 0 current 1 80169F61 - ACCESSORY command (from CAN hash 9F61 to MM1/2 turnout 0) posn 0 current 0 80176F27 - ACCESSORY response (from CAN hash 6F27 to MM1/2 turnout 0) posn 0 current 0 80169F61 - ACCESSORY command (from CAN hash 9F61 to MM1/2 turnout 0) posn 1 current 1 80176F27 - ACCESSORY response (from CAN hash 6F27 to MM1/2 turnout 0) posn 1 current 1 80169F61 - ACCESSORY command (from CAN hash 9F61 to MM1/2 turnout 0) posn 1 current 0 80176F27 - ACCESSORY response (from CAN hash 6F27 to MM1/2 turnout 0) posn 1 current 0 ... The main thing this shows is that there isn't any response from the turnout itself. The CAN hash is unique to an entity on the CAN bus, and there are only two participating in the interaction log. I reckon that 9F61 is your MS2 and 6F27 is the Gleisbox. There should also be a PING response from the Gleisbox, but it isn't listed. Maybe edited out? Osoraku PS - Love your real-life turnout photos


User Profile View All Posts by User View Thanks

revmox		#16 Posted : 09 April 2025 04:35:59(UTC) Retweet
Joined: 26/05/2021(UTC) Posts: 198 Location: Australia, East Maitland, NSW		Hi again osoraku, Thanks for your replies. There's been enough clues there for me put together an Arduino Nano program to cycle some points over the CAN bus connection on the track box. Having initially gone to a little trouble to capture the MS2 ID I found that everything works fine with a default ID of 0300. Testing the points I have I found that operation with a pulse of less than 10mS was not reliable so have set the energize time to 20mS - this might have to be adjusted. MS2 still displays the last commanded state correctly. I haven't attempted to include any feedback - if it is good enough for Marklin then I guess it will do. When I get some spare time, I'll hook it up through a 72710 switch box and maybe even write something for a touch screen. Yes, ping response edited out plus some other stuff for a clearer listing. Cheers and thanks again for your help.

1 user liked this useful post by revmox		osoraku
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.