SRCP 0.8 Questions

Moderator: Moderators

SRCP 0.8 Questions

Postby svesch » 27.10.2009, 09:25

Hi all,

after testing a littlebit arround with rocrail and SRCP I have got a few questions and maybe bug reports regarding the documentation and the implementation.

1) 0.7x <-> 0.8.X
The wiki distinguishs the SRCP versions 0.7.X and 0.8.X. How the decision is done programmatically (no radio button on the settings dialog)?

The hints for 0.8.X are simply wrong and misunderstandable. There are no longer COMMAND, INFO and SENSOR ports, only one port, but two different connection types (COMMAND and INFO). I would recommend to reflect this on the wiki and settings pages.

2) POWER bug?
I have tested with DDW 0.78 (protocol 0.8.X). For switching the power busses, the client must first INITialize and do a GET else the servers responds with a ERROR forbidden message on SET.

3) Synchronizity
The first thing I have done, is to connect my SRCP client and rocrail to the same SRCP server. The client tracks all the changes at the SRCP server (direction and speed changes) which are initiated by rocview. But rocview does not react on the changes of my client. The INFO messages are received by the rocrail server but not forwarded into the rocrail system?

Best regards, Sven.
svesch
 

Postby rjversluis » 27.10.2009, 10:04

Hi Sven,

using the srcpd I get following traces:

rocrail:
Code: Select all
20091027.100118.494 r9999I main     OSRCP    0563 ----------------------------------------
20091027.100118.494 r9999I main     OSRCP    0564 srcp 1.4.0
20091027.100118.494 r9999I main     OSRCP    0565 ----------------------------------------
20091027.100118.495 r9999I main     OSRCP    0454 Connecting to SRCP server localhost:4303
20091027.100118.496 r9999I main     OSRCP    0464 Handshaking
20091027.100118.496 r9999I main     OSRCP    0485 Response from server: srcpd V2.0.12; SRCP 0.8.3; SRCPOTHER 0.8.4-wip
20091027.100118.496 r9999I main     OSRCP08  0555 ----------------------------------------
20091027.100118.496 r9999I main     OSRCP08  0556 srcp08 1.4.0
20091027.100118.496 r9999I main     OSRCP08  0557 ----------------------------------------
20091027.100118.496 r9999c main     OSRCP08  0430 sent: SET PROTOCOL SRCP 0.8.2

20091027.100118.496 r9999c main     OSRCP08  0430 sent: SET CONNECTIONMODE SRCP COMMAND

20091027.100118.496 r9999c main     OSRCP08  0430 sent: GO

20091027.100118.497 r9999c main     OSRCP08  0430 sent: INIT 1 POWER

20091027.100118.497 r9999I main     OSRCP08  0488 Handshake completed.
20091027.100118.497 r9999I main     OSRCP    0496 Server response for protocol 0.8 ok.
20091027.100118.497 r9999I main     OSRCP    0506 Handshake completed.
20091027.100118.497 r9999I main     OControl 0850 initDigInts OK
20091027.100118.497 r9999c ddlfb088 OSRCP    0178 Connecting FB port localhost:4303...
20091027.100118.497 r9999I clocktic OControl 0943 ClockTicker started.
20091027.100118.497 r9999I checker  OControl 1000 Checker started.
20091027.100118.498 r9999I main     OControl 0161 Init shortcut sensor...
20091027.100118.498 r9999I cconmngr OClntCon 0317 Manager started.
20091027.100118.498 r9999I main     OClntCon 0478 ClientConnection started on port 62842.
20091027.100118.498 r9999I main     OModel   0496 updateFB
20091027.100118.498 r9999I main     OApp     0736 MemOp.getAllocCount() = 344
20091027.100118.498 r9999c ddlfb088 OSRCP    0185 FB Connected
20091027.100118.498 r9999c ddlfb088 OSRCP    0188 srcpd V2.0.12; SRCP 0.8.3; SRCPOTHER 0.8.4-wip

20091027.100118.498 r9999c ddlfb088 OSRCP    0197 SET PROTOCOL SRCP 0.8.2

20091027.100118.499 r9999c ddlfb088 OSRCP    0210 SET CONNECTIONMODE SRCP INFO

20091027.100118.499 r9999c ddlfb088 OSRCP    0223 GO

20091027.100118.537 r9999I ddlfb088 OSRCP    0262 fbAddrStr = [1256633978.202 100 INFO 0 DESCRIPTION SESSION SERVER TIME GM]
20091027.100118.548 r9999I ddlfb088 OSRCP    0262 fbAddrStr = [1256633978.199 101 INFO 0 TIME 0 0]
20091027.100118.558 r9999I ddlfb088 OSRCP    0262 fbAddrStr = [1256633978.202 100 INFO 1 DESCRIPTION GA GL SM POWER LOCK DESCRIPTION]
20091027.100118.568 r9999I ddlfb088 OSRCP    0262 fbAddrStr = [1256633978.202 100 INFO 1 POWER OFF AUTO POWER OFF]
p
20091027.100143.432 r9999I main     OApp     0886 POWER ON
20091027.100143.432 r9999I main     OModel   1483 sys: go
20091027.100143.432 r9999I main     OModel   1488 informing 0 listeners of a system event...
20091027.100143.432 r9999c main     OSRCP08  0430 sent: SET 1 POWER ON

20091027.100143.433 r9999I main     OApp     0736 MemOp.getAllocCount() = 347
20091027.100143.433 r9999I ddlfb088 OSRCP    0262 fbAddrStr = [1256634103.433 100 INFO 1 POWER ON ]


As you can see the protocol version is automatically chosen depending of the server welcome message.

srcpd:
Code: Select all
Oct 27 09:59:38 verslr20348 srcpd[18239]: srcpd V2.0.12; SRCP 0.8.3; SRCPOTHER 0.8.4-wip
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 0] init_bus 0
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 1] DDL init with debug level 4
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 1] DDL init done
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 0] Time thread created.
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 0] Starting 1 bus interface threads.
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 0] Starting interface thread number 1 (type = 1).
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 0] Thread on bus 1 is woken up
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 1] DDL bus started (device = /dev/ttyS0).
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 0] Netservice thread for port 4303 created.
Oct 27 09:59:38 verslr20348 srcpd[18239]: All threads started
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 0] changed to group srcpd
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 0] changed to user srcpd
Oct 27 09:59:38 verslr20348 srcpd[18239]: [bus 1] refresh cycle stopped.
Oct 27 10:01:18 verslr20348 srcpd[18239]: [bus 0] New connection received.
Oct 27 10:01:18 verslr20348 srcpd[18239]: [bus 0] Connection from 127.0.0.1/37717
Oct 27 10:01:18 verslr20348 srcpd[18239]: [session 1] Session started (mode = 1).
Oct 27 10:01:18 verslr20348 srcpd[18239]: [session 1] Command mode starting.
Oct 27 10:01:18 verslr20348 srcpd[18239]: [bus 0] New connection received.
Oct 27 10:01:18 verslr20348 srcpd[18239]: [bus 0] Connection from 127.0.0.1/37718
Oct 27 10:01:18 verslr20348 srcpd[18239]: [session 2] Session started (mode = 2).
Oct 27 10:01:18 verslr20348 srcpd[18239]: [session 2] New INFO client requested.
Oct 27 10:01:18 verslr20348 srcpd[18239]: [session 2] Send all data for bus number 0 to new client.
Oct 27 10:01:18 verslr20348 srcpd[18239]: [session 2] Send all data for bus number 1 to new client.
Oct 27 10:01:18 verslr20348 srcpd[18239]: [session 2] All messages send to new INFO client.
Oct 27 10:01:43 verslr20348 srcpd[18239]: [bus 0] Thread on bus 1 is woken up
Oct 27 10:01:43 verslr20348 srcpd[18239]: [bus 1] refresh cycle restarted.


No error at POWER ON from the srcpd.


Looks quit OK to me.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby svesch » 27.10.2009, 10:31

Hi Rob,

srcpd is far less messy with the SRCP protocol than DDW.

There is written in the protocol:
After INIT any write access to the affected device by SET or INIT for all active sessions is invalid until reading access is processed by the commands GET or VERIFY(depending on the device group) or TERM. This includes the session executing the INIT.


As you can see the protocol version is automatically chosen depending of the server welcome message.


This fact is worth written into the wiki.

Sven
svesch
 

Postby rjversluis » 27.10.2009, 11:03

Hi Sven,

in the 0.8.2, german only, is following stated:

Nach einem INIT ist für alle aktiven Sessions jeglicher Schreibzugriff mittels SET, RESET oder INIT auf das betreffende Gerät unzulässig, bis ein Lesezugriff durch die Befehle GET, WAIT oder VERIFY (je nach Gerätegruppe) oder ein TERM ausgeführt wurde. Einzige Ausnahme hiervon ist die Session, die den INIT veranlaßt hat.


The last sentence describes an exception on this rule: The session which originated the init.
So Rocrail is implemented on 0.8.2 as is seen in the trace:

Code: Select all
20091027.100118.496 r9999I main     OSRCP    0485 Response from server: srcpd V2.0.12; SRCP 0.8.3; SRCPOTHER 0.8.4-wip
20091027.100118.496 r9999I main     OSRCP08  0555 ----------------------------------------
20091027.100118.496 r9999I main     OSRCP08  0556 srcp08 1.4.0
20091027.100118.496 r9999I main     OSRCP08  0557 ----------------------------------------
20091027.100118.496 r9999c main     OSRCP08  0430 sent: SET PROTOCOL SRCP 0.8.2

The server is informed that Rocrail uses 0.8.2.
So my conclusion is that DDW does not care about the SET PROTOCOL.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Re: SRCP 0.8 Questions

Postby rjversluis » 27.10.2009, 11:41

Hi Sven,

svesch wrote:3) Synchronizity
The first thing I have done, is to connect my SRCP client and rocrail to the same SRCP server. The client tracks all the changes at the SRCP server (direction and speed changes) which are initiated by rocview. But rocview does not react on the changes of my client. The INFO messages are received by the rocrail server but not forwarded into the rocrail system?


You can put a feature request for this sync topic at launchpad.net/rocrail

https://bugs.launchpad.net/rocrail/+filebug

Importance -> Whishlist
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby svesch » 27.10.2009, 13:26

Hi Rob,

three more statements for this:

1) Reported the feature request on launchpad, but I was not able to change the importance?!

2) Very obscure, that srcpd only supports 0.8.3 like posted in its welcome message and do not reject the rocrail SRCP clients wish to get a 0.8.2...

3) The problem with DDW is rather an initialization problem than a version problem. There is already another client connected to DDW which also initialized the POWER devices. Here is my TCP trace between rocrail SRCP client and DDW:

Code: Select all
Willkommen am Eisenbahnserver DDW V 0.7.8; SRCP 0.8.2; SRCPother 0.7.3;  Server information: Bus 0: Server-Service (Session, Time, Power) Bus 1: Generic Loco Maerklin/Motorola & Power Bus 2: Generic Loco NMRA/DCC (short address)& Power Bus 3: Generic Loco NMRA/DCC (long address)& Power Bus 4: Generic Loco protocol by server & Power Bus 5: Generic Accessoire Maerklin/Motorola & Power Bus 6: Generic Accessoire NMRA/DCC & Power Bus 7: Generic Accessoire protocol by server & Power Bus 8: Feed back S88 & Power Bus 9: Feed back M6051 & Power Bus 10: Feed back I8255 & Power Bus 11: Service Mode & Power Bus 12: Feed back HSI88 & Power
SET PROTOCOL SRCP 0.8.2
1256645673.445 201 OK PROTOCOL SRCP
SET CONNECTIONMODE SRCP COMMAND
1256645673.455 202 OK CONNECTIONMODE
GO
1256645673.465 200 OK GO 896
INIT 1 POWER
1256645673.485 424 ERROR device reinitialized
SET 1 POWER ON
1256645690.119 415 ERROR forbidden


To prevent this situation and to get synchronous with the SRCP system, a SRCP client should try GET before INIT (not only for POWER devices).

Sven.
svesch
 

Postby rjversluis » 27.10.2009, 14:15

Hi Sven,

svesch wrote:To prevent this situation and to get synchronous with the SRCP system, a SRCP client should try GET before INIT (not only for POWER devices).


Can you report this too at LP?

Is there a list of differences between 0.8.2 and 0.8.3?
A textual compare is not possible because 0.8.2 is in German and 0.8.3 in English.
The Subversion repository only contains 0.8.3 and 0.8.4.
To do a manual compare between both versions is out of the question for me.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby rjversluis » 27.10.2009, 17:18

Hi Sven,

which version do you use?
DDW 0.78 seems to be broken:

Code: Select all
SET PROTOCOL SRCP 0.8.2
1256659927.863 201 OK PROTOCOL SRCP
SET CONNECTIONMODE SRCP COMMAND
1256659940.641 202 OK CONNECTIONMODE
GET 1 POWER
1256659998.885 202 OK CONNECTIONMODE


It always replies with OK CONNECTIONMODE. Even on the second session which have been connected with info mode...

DDW is not compatible with SRCPD:
- srcpd is not case sensitive
- srcpd always respond as expected
- srcpd does not complain when more sessions issue an INIT 1 POWER without a GET 1 POWER command issued before.

Sorry, but I can not do anything here when DDW is broken.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby svesch » 27.10.2009, 18:07

Hi Rob,

I use DDW version 0.78.

In your DDW log posting the GO is missing.

DDW is not compatible with SRCPD:

Yes its the annoying reality if you develop a client for SRCP that the servers react that different.

DDW is not compatible with SRCPD:
- srcpd is not case sensitive


Thats a srcpd problem. The SRCP standard clearly says, that all words are case sensitive and the commands must always written in uppercase letters.

- srcpd always respond as expected


Whats the expectation? :)


Regarding to your question whats the difference between 0.8.2 and 0.8.3 I have started a discussion on the srcpd-devel list.

Sven.
svesch
 

Postby rjversluis » 28.10.2009, 07:39

oh boy...

srcpd:
Code: Select all
go
1256712041.453 200 OK GO 1
get 1 power
1256712017.707 100 INFO 1 POWER ON AUTO POWER ON
init 1 power
1256712053.837 200 OK
get 1 power
1256712017.707 100 INFO 1 POWER ON AUTO POWER ON
term 1 power
1256712067.285 200 OK
get 1 power
1256712067.285 100 INFO 1 POWER OFF Device Termination
init 1 power
1256712084.989 200 OK


ddw:
Code: Select all
GO
1256710216.047 200 OK GO 40
GET 1 POWER
1256710221.685 416 ERROR no data
INIT 1 POWER
1256710237.303 200 OK
GET 1 POWER
1256710241.533 100 INFO 1 POWER OFF
TERM 1 POWER
1256711170.301 200 OK
GET 1 POWER
1256711177.621 416 ERROR no data
INIT 1 POWER
1256711205.672 200 OK


They are totally different with responses....
I do not like this at all; and I will **not** add a server option for srcp. (srcpd/DDW/...)
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby svesch » 28.10.2009, 08:50

Hey Rob,

you are right. I try to get a clear statement for 0.8.4 regarding to this. Thats a true protocol definition problem, I think.

Sven.
svesch
 

New from SRCP

Postby svesch » 03.11.2009, 14:29

Hi,

after some discussion on drmb newsgroup and srcpd mailinglist I have some infos regarding to this problem.

The differences between 0.8.2 (very outdated) and 0.8.3:


- handshake phase has a new error code 410
- time stamp may be derived from TIME device or a simple counter, not
all systems have a system time
- GA may use Seletrix
- FB may be set via protocol
- changed sgml to docbook xml, translated into (some kind of) English


The differences between 0.8.3 and 0.8.4:
- no more wildcards (no one ever implemented them)
- Generic Messages device group



To the differences between srcpd and ddw. It makes no sense to distinguish between that both servers on client side. That also would be against the idea of SRCP. Here are some hints:
    - srcpd is not case sensitive. However, the SRCP protocol specifies this, and the rocrail client should implement all commands case sensitive.
    - If a device is already initialized, then you get an appropriate INFO message on the INFO channel right after connect. Also you should get an error message when you try to renitialize the device (error code 424). srcpd does not return this error message, that seems to be a bug.
    - Either you check for 424 after INIT or (as a workarround) you could use GET before you INITialize a device.
    - You have to call GET after INIT to get knowledge over the state of a device. Be prepared to get a 416 error message.


Sven
svesch
 

Postby rjversluis » 03.11.2009, 15:01

Hi Sven,

can you put this in a bug report to keep this in mind?
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Postby svesch » 02.12.2009, 16:19

Hi Rob,

today I have tested the new srcp capabilities. Thank you very much for the quick fixes you have made. I now have installed the 1.30 Rev. 982 from 6th November.

The synchronization between other SRCP Clients (i.e. eWicht) works well. But the power device seems to have still problems:

Before using the POWER device the client has to initialize it: INIT X POWER. Rocrail tries to SET the POWER without initializing it. Also use GET to prevent reinitializing the device.

Best regards,

Sven.
svesch
 

Postby rjversluis » 02.12.2009, 17:34

Hi Sven,

the POWER issue is also implemented.

After
SET PROTOCOL SRCP 0.8
a
GET 1 POWER
is send, and if the return value is not equal 100 a
INIT 1 POWER
is send to the SRCP server.
Best Regards, Rob.
:!: PS: Do not forget to attach the usual files.
:!: PS: Nicht vergessen die übliche Dateien an zu hängen.
[ macOS - Linux] - [ N: CBus - CAN-GCA ] - [ 0: RocNetNode - GCA-Pi ]
rjversluis
Site Admin
 

Next

Return to srcp