Page 1 of 1

Possible bug at rocnet.c

Posted: 05.06.2015, 18:57
by mserrano
Hi there,

I hope Rob reads this message.

Unless I am misunderstanding something – apologies on that case - I have found a bug on the rocnet library, at rocnet.c. It seems the protocol code is not correctly parsed:
The following piece of code will never return RN_MOBILE_PROT_DCC14 but RN_MOBILE_PROT_DCC28 – after the first “if”, the second “if” will overwrite the “prot” definition for spcnt<28.

Code: Select all

static byte __getProtocol(iONode loc) {
	  byte prot = 0;
	  if( StrOp.equals( wLoc.getprot(loc), wLoc.prot_N ) || StrOp.equals( wLoc.getprot(loc), wLoc.prot_L ) || StrOp.equals( wLoc.getprot(loc), wLoc.prot_P ) ) {
	    if( wLoc.getspcnt(loc) < 28 )
	      prot = RN_MOBILE_PROT_DCC14;
	    if( wLoc.getspcnt(loc) > 28 )
	      prot = RN_MOBILE_PROT_DCC128;
	      prot = RN_MOBILE_PROT_DCC28;
	  else if( StrOp.equals( wLoc.getprot(loc), wLoc.prot_M ) ) {
	    prot = RN_MOBILE_PROT_MM;
	  return prot;
I suppose no one was using this functionality, solution should be quite simple by adding an "else".
I realise about this issue because, following Rob suggestion, I am trying to make my rpic solution compliant with a protocol already supported by rocrail, like rocnet.

In this context I would also appreciate if the MM protocol code is provided as explained in the wiki – potentially correcting also the repeated code of 3 for MM1 and DCC14. I really need to differentiate at least between MM1 and MM2.
A potential solution would be to actually start MM definition in code number 4 for MM1 and use as simple rule as this:

Code: Select all

  else if( StrOp.equals( wLoc.getprot(loc), wLoc.prot_M ) ) {
    prot = RN_MOBILE_PROT_MM+wLoc.getprotver(loc)-1;
I know this is probably a low priority request, since it seems the bug has been there from the beginning… but it will really help me to complete the migration of my rpic solution to rocnet.

Thanks in advance – as usual – for the support,


Re: Possible bug at rocnet.c

Posted: 05.06.2015, 19:52
by rjversluis
Hi Manolo,

sorry, but your code change does not make sense to me.
RN_MOBILE_PROT_MM is an internal used number unrelated to the loco its protocol version.

Re: Possible bug at rocnet.c

Posted: 05.06.2015, 20:05
by mserrano
Hi Rob,

I thought RN_MOBILE_PROT_MM was defined as 4 at rocnet-const.h (#define RN_MOBILE_PROT_MM 4)
Thus 4+the protver -1 will be equal to:

MM1 protver=1 as usually defined in ddx for instance
MM2 protver=2 as usually defined in ddx for instance

and so on...

This will leave the code definition for rocnet similar to what it is in the wiki (correcting the MM1=DCC14 I mentioned before).

Other option would be to configure the protver with the code to be sent by rocnet.. but I have assume this is not desired since it is not the way it is provided for DCC... and moreover it seems natural to define the interface with a protocol type and a version for the protocol.

Hope the code make sense know.
Best regards,


PS: Maybe it is my mistake... I considered RN_MOBILE_PROT_MM "related" to the protocol version number.. according to the wiki RN_MOBILE_PROT_MM=4=MM2