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.

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

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.

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

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.

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.

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.

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.