(Solved) p50x: Endless zero speed loop

Moderator: Moderators

(Solved) p50x: Endless zero speed loop

Postby andre0604 » 05.02.2013, 10:15

Hi Rob,

my question was regarding the endless zero speed loop if this is the wanted behaviour as Patrick did asked too.
Hi Rob,

just for my knowledge, is there a specific reason for this looping or was/is it bad behavior of the RocRail driver?

Kind regards,

Patrick


I am still searching for the communication problem with my TAMS MC. It looks like that it is related to my TAMS but maybe can sending less commands give some improvement.

Best regards
Andre
Last edited by andre0604 on 06.02.2013, 10:09, edited 1 time in total.
andre0604
 

Postby rjversluis » 05.02.2013, 10:35

Hi Andre,
andre0604 wrote:my question was regarding the endless zero speed loop if this is the wanted behaviour as Patrick did asked too.

No, this is not wanted.

andre0604 wrote:just for my knowledge, is there a specific reason for this looping or was/is it bad behavior of the RocRail driver?

Trace file created with the latest Rocrail revision?
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 andre0604 » 05.02.2013, 11:18

Hi Rob,

Hi Patrick,

sorry but this did not help.
I need some line which give me a clue for this looping in setting zero speed.

Please make a trace with:
BYTE off
INFO on
AUTOMATIC on
MONITOR on
DEBUG on

Delete all existing trace files before restart.
Zip all new traces files and post it here.


this is the wanted Trace from Patrick as posted above in this thread. If this is not as you wanted I will do a new trace.

Best regards
Andre
You do not have the required permissions to view the files attached to this post.
andre0604
 

Postby rjversluis » 05.02.2013, 11:27

Hi Andre,

please provide a new trace with the latest Rocrail revision.
Debug and Byte both OFF.
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 LDG » 05.02.2013, 12:52

Hi Andre,

your logs are 3 months old and not created with a TamsMC. Reported firmware 1.0.15, minimal for TamsMC was 1.4.0, current is 1.4.6m.
I guess your log was created with the Elektor DCC Command Station (by Patrick). These problems should be solved with a FW-update provided by Patrick.

Regards,
Lothar
LDG
Site Admin
 

Postby andre0604 » 05.02.2013, 13:07

Hi Lothar,

you are right. This is a trace from patrick regarding the endless zero speed loops. As Rob said this is not the wanted behaviour of Rocrail. Patrick changed the firmware so that his CS can accept these loops. Because I have sometimes communication problems with my TAMS I like to see if there is some improvement without these loops. I will make new traces by using my TAMS.

Best regards
Andre
andre0604
 

Postby rjversluis » 05.02.2013, 13:41

Hi Andre,

there are no loops programmed to send V=0 commands.
Please provide a trace if you detected any...
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 Patrick Smout » 05.02.2013, 20:16

LDG wrote:
These problems should be solved with a FW-update provided by Patrick.



Hi Lothar,

the root cause that caused my station to crash was the fact that the station did not send urgent DCC frames if track power was switched off. The station uses a circular refresh buffer to continously send DCC velocity/function commands to the LOCs while track power is on. DCC urgent frames are send for accessory decoder commands and if a loc speed/function has changed. When track power was off, the urgent frames were internally queued. A queue full caused the station to spinlock internally until queue space was available. Because power was off and no urgent frames were send, this station was deadlocked.

This behavior was present for years but popped up only recently because RocRail did send V=0 speed commands while track power was off.
I used an external RS232 sniffer to hunt down the problem. It revealed clearly that RocRail repeatedly sends V=0 commands (in that particular version)

Basically it was not releated to RocRail but RocRail did provide the necessary conditions.

The problem was easily solved by not queuing DCC urgent frames when track power is off.

Regards,

Patrick
Patrick Smout
 

Postby andre0604 » 06.02.2013, 10:09

Hi Patrick,

thanks for clarification. So it looks like that there could be no improvement for my TAMS MC. Maybe I should buy a Elektor CS :D

Best regards
Andre
andre0604
 

Solution for the 'Error on mutex trywait' error message ?

Postby pradines » 11.10.2013, 16:18

Hello Patrick,

I am a french user of the Elektor DCC CS.
I try to use it with Rocrail revision 6099 using a USB to Serial Ftdi cable.

I too have the 'Error on mutex trywait' message ! Is it the endless zero speed loop problem ?

What is the solution ? I bought the kit of the CS at elektor, and hoped to get the latest software version out of the box ...

Help would be appreciated :)

Bernard.
pradines
 

Re: Solution for the 'Error on mutex trywait' error message

Postby Patrick Smout » 11.10.2013, 19:58

Hello Bernard,

I believe they don't have the most recent version.
Just send me a private email and I will send you the most recent version.

Best regards,

Patrick
Patrick Smout
 


Return to P50 and P50x