DCC4PC Railcom Reader RCLink Bug Surfaced ?

All issues about RailCom
rupertb

DCC4PC Railcom Reader RCLink Bug Surfaced ?

Post by rupertb » 19.02.2012, 16:58

I'm in the process of added the DCC4PC Railcom Reader Board to my setup and in chatting with them there seems to a be bug in the RCLink Code that their emulation relies on
I dont want to spend time doing my own build and want to make sure the proposed fix can be used by all flavours of Railcom stuff

See transcript as follows

On 18/02/12 18:03, Rupert D.E. Brown wrote:
> Nicholas
> Which command station driver do I need to set up in Rocrail and what
> are the comms settings I'm assuming it's the RCLink one but I keep
> getting a not detected error -R
>

Hi Rupert,

You've most likely set it up correctly. I've just tried to do the same
on this end and run into similar difficulties. It seems that the RocRail
RCLink support has a bug in its handling of input numbers larger than
128. As our emulation supports a full 239 inputs this is a problem.

I have tracked down the bug to a buffer overflow in the RCLink
implementation. Specifically there is an array with a value for each
input which is 128 values long. There is also no check that the input
number isn't larger than 128. This causes the RCLink code to overwrite
other memory in a semi-random fashion when presented with an input
number larger than 128.

There are two possible fixes: first, I can produce a Tams emulation
firmware image which removes the inputs from 129 upwards. This should
solve the problem, but will require maintaining two different sets of
Tams emulation firmware. The second alternative is to fix RocRail. This
would give you the full range of 239 possible inputs, but would require
you to recompile the source yourself. As such, if recompiling isn't an
issue I would recommend the latter, otherwise, producing a RocRail
specific firmware version isn't any trouble.

In case you want to have a go at fixing the code yourself, you need to
change the file "rocdigs/rocdigs.xml" and change "readerTick[128]" to
"readerTick[256]" on line 721. It should be in a section which starts
"<object name="RcLink"..." in case the line numbers are a bit different
in your version. After making the change, just save and recompile.

I hope this makes things a bit clearer.

Kind regards,

Nicholas Simmonds

rjversluis
Site Admin
Posts: 42383
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 19.02.2012, 19:09

Try if 3293 is OK.

rupertb

DCC4PC Railcom Reader RCLink Bug Surfaced ?

Post by rupertb » 20.02.2012, 21:41

Have installed it and the server log suggests things are ok but am not seeing any Railcom updates from the DCC4PC end - will check back with them next to verify the config is ok
Has anyone else out there successfully used DCC4PC as a Railcom feedback system with RocRail and Lenz as the main control system or am I blazing a new trail....
-R

rupertb

DCC4PC Railcom Reader RCLink Bug Surfaced ?

Post by rupertb » 26.02.2012, 20:17

Had a proper look at this today
3 Observations

1) There are a lot of messages as the rclink driver cycles through 239 addresses polling state - can they be supressed so only occupied blocks/sensors show in the log

2) I have close RocView and restart it for a change to appear on the trackplan (I only have one test section) i.e. transition sensor state from red to green or vice versa

3) I get an address value if 16383 back from the decoder which doesnt match anything useful - the loco decoder address is in the 30's how is this partition into address + speed vals - its a Lenz Gold Maxi onboard

Photo attached
You do not have the required permissions to view the files attached to this post.

rjversluis
Site Admin
Posts: 42383
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 26.02.2012, 20:39

Hi,

in 3320 the zero reports are ignored.

For all other issues: DCC4PC seems to be not compatible with RCLINK.

rupertb

DCC4PC Railcom Reader RCLink Bug Surfaced ?

Post by rupertb » 26.02.2012, 22:08

Thanks Rob
I will try this tomorrow night hopefully along with some new TAMS Emulation firmware DCC4PC have sent me
-R

rupertb

Post subject: DCC4PC Railcom Reader RCLink Bug Surfaced ?

Post by rupertb » 27.02.2012, 21:32

Rob
Making the log files quieter helped a lot - 2 trace files attached
First time round the updates were coming through for the detector fine and when I took the loco off the track they stopped - however the track plan display didnt change colour.
When I put the loco back in the section the trace messages came through again but still no screen update
See the 2 trace file
I then restarted the Rocrail server and started getting random addresses reporting they are alive again - as if the array corruption the DCC4PC guys found last week had reappeared
See 3 trace file
-R
You do not have the required permissions to view the files attached to this post.

rjversluis
Site Admin
Posts: 42383
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 27.02.2012, 22:01

Hi,

how to use bidi sensors can be read it in the Wiki.

The Firmware should be compatible with RCLink otherwise this library is not suitable.

rupertb

DCC4PC Railcom Reader RCLink Bug Surfaced ?

Post by rupertb » 29.02.2012, 08:28

Rob
I understand that when blocks are connected to sensors there is a notion of direction (enter2in) etc - clearly this isnt going to work properly until DCC4PC sort out their Tams/RCLink emulation issues

Last night I took the block off the plan and just left the sensor in - when I put the loco in the section the sensor goes from Green to Red as expected but when I remove it the sensor stays Red even though there are no occupancy messages coming via RCLink any more - i.e. currently basic occupancy is working with the DCC4PC/RCLink combination even if the data about the loco is wrong
When I manually reset the sensor it clears ok until I put the loco back in the section.

Is there some other directionality hidden somewhere that isnt in the sensor setup dialogs and am I cheating by manually placing the loco in the section and removing it rather than driving it in and out.

-R

rjversluis
Site Admin
Posts: 42383
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 29.02.2012, 08:44

The current implementation of rclink reports the sensor off if it receives an event from the RC-Link with loco address is set to zero.

Older RC-Link firmware did not send this zero event and it was managed in the Rocrail rclink library to automatically send an off sensor event after 2.5 seconds.

opendcc
Posts: 137
Joined: 08.01.2009, 22:03

Post by opendcc » 22.03.2012, 20:42

Hello,
For all other issues: DCC4PC seems to be not compatible with RCLINK.
I talked to the DCC4PC-guys and hinted them to BiDiB. They are willing to change thier host emulation towards BiDiB.

best regards

Wolfgang (www.opendcc.de)

rjversluis
Site Admin
Posts: 42383
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 22.03.2012, 21:05

Hi Wolfgang,

very good move! :-)

rupertb

Post by rupertb » 23.03.2012, 08:15

FYI I've been working with the DCC4PCGuys on this for a couple of weeks now and we have got the detectors working and the address decode issues sorted - they have some fixes to rclink to put back in the tree
Now the weather is getting better I can go out into the garden and start to wire it all up
-R

DCC4PC

DCC4PC Railcom Reader RCLink Bug Surfaced ?

Post by DCC4PC » 27.03.2012, 02:49

Hello,

I have been working on reproducing and fixing the bugs in RocRail's RCLink handling which are causing issues with our hardware. To this end I have produced a patch (attached) against revision 3454 which makes the following changes:

1. Remove the broken "no message on unoccupied" code which was recently added.
2. Remove the old "ticker" code which is no longer used.
3. Store the last address and orientation received from each input and only send an event to the RocRail core if the address or orientation has changed.
4. Suppress debug messages when there is no change of address.
5. Add support for treating addresses above 10239 as occupied with no address.

This code has been tested by Rupert, and appears to solve the issues he was having.

Using an address larger than that supported by DCC is a DCC4PC specific extension to the RCLink protocol, to work around the absence of a means to signal occupancy without an address. That said, treating an address which is both non-zero and not a valid DCC address as occupied seems a sensible interpretation which should not cause problems with other hardware.

Kind regards,

Nicholas Simmonds
DCC4PC
You do not have the required permissions to view the files attached to this post.

rjversluis
Site Admin
Posts: 42383
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Post by rjversluis » 27.03.2012, 06:12

Hi Nicholas,

is this patch also tested with the original Tams RC-Link?

Post Reply

Return to “RailCom”