Rocrail and M*rklin Software

Märklin Central Station 2

Rocrail and M*rklin Software

Postby bertc3p0 » 30.11.2015, 12:08

Hi,

I'm using the mgbox module and can2lan(aims to be the CS2 CAN gateway with Gleisbox) to control my equipment. When I use Rocrail and M*rklin Software at the same time the throttle is being updated when I e.g. change the speed on Rocrail. If I do it the other way, change the speed on M*rklin App or MS2 the throttle on Rocrail isn't being updated. With follwoing patch both ways are working:
Code: Select all
--- a/rocdigs/impl/mgbox.c
+++ b/rocdigs/impl/mgbox.c
@@ -2419,11 +2419,11 @@ static void __reader( void* threadinst ) {
      else if( in[1] == ( CAN_ID_PING | BIT_RESPONSE ) ) {
       __evaluateMCS2Ping( data, in );
     }
-    else if( in[1] == ID_LOCO_DIRECTION | in[1] == ID_LOCO_VELOCITY ) {
+    else if((in[1] == ID_LOCO_DIRECTION + BIT_RESPONSE) | (in[1] == ID_LOCO_VELOCITY + BIT_RESPONSE)) {
       /* loc speed or direction comamnd, not from Rocrail. */
       __evaluateMCS2Loc( data, in );
     }
-    else if( in[1] == ID_LOCO_FUNCTION ) {
+    else if( in[1] == ID_LOCO_FUNCTION + BIT_RESPONSE ) {
       /* locfunction command, not from Rocrail. */
       __evaluateMCS2Function( data, in );
     }

I'm wondering if anybody else is using Rocrail and M*rklin PC Software, M*rklinApp or MS2 at the same time and see the same behaviour ?

Regards

Gerd
bertc3p0
 

Re: Rocrail and M*rklin Software

Postby eroncelli » 30.11.2015, 20:19

Maerklin PC SW and RR are conflicting sometime: it depends on which one is started first.
Seems that we got to wait for Maerklin issueing an update.
HO Maerklin, CS2+MS2, PC with Win10, Android phone, electronics by IEK, decoder by Maerklin-ESU-TAMS
".. and let your dog enjoy Rocrail"
eroncelli
 

Re: Rocrail and M*rklin Software

Postby woodyboy » 30.11.2015, 22:25

Hi Gerd,

The MGBOX lib is tested with the CS2 and MS2 and it works without a problem, updates in both directions.
Your change request results in triggering on the reply of the Gleisbox/GFP. But that reply is only generated on a request by the associate command. Why is your Rocrail version not triggered by the issued command? The Gleisbox executes only commands, not replied commands with the response bit set.

After a second thought, Rocview is update by the Rocview command itself and the Gleisbox replied command, that sounds not efficiënt to me. I'll postpone the request to trigger on the response.

Could produce a trace on byte level?

PS @Eroncelli. MGBOX assumes that your CS2 is up and running before starting Rocrail.
Regards,

Bert

Equipment: Roco WLANMaus, MS2, Gleisbox 2x(separated switch & rollingstock). Ubuntu 16. Edits booster. Arduino: S88 CANbus interface & Ethernet-CANbus gateway
woodyboy
 

Re: Rocrail and M*rklin Software

Postby bertc3p0 » 01.12.2015, 18:16

Hi Bert,
woodyboy wrote:Hi Gerd,

The MGBOX lib is tested with the CS2 and MS2 and it works without a problem, updates in both directions.
Your change request results in triggering on the reply of the Gleisbox/GFP. But that reply is only generated on a request by the associate command. Why is your Rocrail version not triggered by the issued command? The Gleisbox executes only commands, not replied commands with the response bit set.

the behaviour (only sending loco cmmands with response bit set) is expected: my can2lan only sends these. If I dump a communication between two CS2 PC-Software I only see loco commands with response bit set:
Code: Select all
% ./read_cs2_dump cs2_b_f.pcap
0001 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 31 00 00 08 43 54 1c 60 ff 00 00 10   |.1...CT.`.....|

0002 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 31 00 00 08 43 54 1c 62 ff 00 00 00   |.1...CT.b.....|

0003 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 31 00 00 08 43 54 1c 64 ff 00 00 20   |.1...CT.d... .|

0004 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 31 00 00 08 43 54 1c 66 ff 00 00 ee   |.1...CT.f.....|

0005 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 31 00 00 08 43 54 1c 68 01 00 00 40   |.1...CT.h...@.|

0006 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 01 36 00 00   |..........6...|

0007 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 33 00 00   |..........3...|

0008 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 66 00 00   |..........f...|

0009 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 99 00 00   |..............|

0010 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 cc 00 00   |..............|

0011 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 ff 00 00   |..............|

0012 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 01 32 00 00   |..........2...|

0013 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 01 36 00 00   |..........6...|

0014 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 01 2b 00 00   |..........+...|

0015 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 01 2b 00 00   |..........+...|

0016 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 01 21 00 00   |..........!...|

0017 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 01 17 00 00   |..............|

0018 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 01 0d 00 00   |..............|

0019 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 ee 00 00   |..............|

0020 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 cf 00 00   |..............|

0021 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 c4 00 00   |..............|

0022 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 a5 00 00   |..............|

0023 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 91 00 00   |..............|

0024 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 68 00 00   |..........h...|

0025 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 2a 00 00   |..........*...|

0026 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 00 00 00   |..............|

0027 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 09 03 00 06 00 00 00 14 00 00 00 00   |..............|

0028 UDP 10.151.86.126 -> 255.255.255.255 port 15730 -> 15731  packet_length 13
00 31 00 00 08 00 00 00 00 01 01 ee ee   |.1............|

0029 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 31 00 00 08 00 00 00 00 01 01 ee ee   |.1............|

0030 UDP 10.151.86.126 -> 10.151.86.220 port 15731 -> 15730  packet_length 13
00 31 00 00 08 00 00 00 00 01 01 ee ee   |.1............|

So I assumed that it is only needed to send these requests to all via UDP.

After a second thought, Rocview is update by the Rocview command itself and the Gleisbox replied command, that sounds not efficiënt to me. I'll postpone the request to trigger on the response.

Could produce a trace on byte level?
On byte level there won't be any difference: the behaviour is expected - my can2lan is doing it this way.

I will think about it ... Maybe I'm on the wrong road here ...

Anyway, many thanks for your response.
Regards

Gerd
bertc3p0
 

Re: Rocrail and M*rklin Software

Postby woodyboy » 01.12.2015, 18:56

Hi Gerd,

There is another trade-off when your requested patch is implemented. The throttle id is isolated from the CAN id in the message which is send by the throttle controlling the loco during the issued speed/function command. The throttle id is showed in the loco list in Rocview.
For this reason, your proposal sounds to me not as an improvement.

Why not implementing a transparant gateway for all CAN messages in can2lan? The equipment on both sides of the gateway could be evaluating all messages and act as designed.
Regards,

Bert

Equipment: Roco WLANMaus, MS2, Gleisbox 2x(separated switch & rollingstock). Ubuntu 16. Edits booster. Arduino: S88 CANbus interface & Ethernet-CANbus gateway
woodyboy
 

[solved] Rocrail and M*rklin Software

Postby bertc3p0 » 02.12.2015, 11:15

Hi Bert,
woodyboy wrote:Hi Gerd,

There is another trade-off when your requested patch is implemented. The throttle id is isolated from the CAN id in the message which is send by the throttle controlling the loco during the issued speed/function command. The throttle id is showed in the loco list in Rocview.
For this reason, your proposal sounds to me not as an improvement.

Why not implementing a transparant gateway for all CAN messages in can2lan? The equipment on both sides of the gateway could be evaluating all messages and act as designed.

many thx for your valuable input. I appreciate your comments.
IMHO it's not a good idea to create a one-by-one gateway in both directions and send all packets received bei UDP or TCP over CAN. E.g. the MS1(working fine in combination with M*rklin PC Software and Rocrail) gets stuck and reboots if there are to many CAN packets. If two CS2 (PC or real) exchanging data, the CAN-Bus is under heavy load if you would mirror all data.

Anyway, I've done a little change in can2lan to send packets reached over TCP to UDP. Please ignore my patch request - it's working fine with mgbox now :-)

Regards

Gerd

BTW: MS2 was working without any changes. There wasn't any error, just wrong observation.
bertc3p0
 

Re: Rocrail and M*rklin Software

Postby eroncelli » 02.12.2015, 19:07

woodyboy wrote:...

PS @Eroncelli. MGBOX assumes that your CS2 is up and running before starting Rocrail.


Of course, but the problem arises with Maerklin PC SW, not with the CS2 as, from what I understand, is the situation that Gerd refers to.
HO Maerklin, CS2+MS2, PC with Win10, Android phone, electronics by IEK, decoder by Maerklin-ESU-TAMS
".. and let your dog enjoy Rocrail"
eroncelli
 


Return to CS2

cron