¿ªÔÆÌåÓý

  1. Jmriusers
  2. Topics

Locked DECODERPRO VERY LONG IDENTIFICATION TIME

 

Hello @ all,

In recent days the time to identify a locomotive with Decoder Pro has become extremely long. About 6 minutes.?Before that was going much faster.
?
I came back to an earlier version of JMRI, no change.
?
Here is the description of my system:
Digital Central: DCC++
JMRI: 4.14+Rd060e0b
Java: 1.8.0_211
PC with W10 family 1809 version: 17763.503
Proc: Intel Intel Core I3 5005U 2.00GHZ
RAM: 4Go / 3.87Go free
 

What decoder were you trying to read?
Does th loco have a keep alive in it?
These at best interfere and at worst, prevent reading of or writing to decoders.

One can desolder one keep alive lead, use a normally closed magnetic reed switch
in series with the keep alive or rig up a pin and socket arrangement.
The deluxe method would be the reed switch, just a magnet to open the reed
switch and you don't need to disassemble the loco in any way, only downside with
this would be finding room for the red switch.

John

---------- Original Message ----------
From: fcot2002@...
Date: May 28, 2019 at 8:33 AM


Hello @ all,

In recent days the time to identify a locomotive with Decoder Pro has become
extremely long. About 6 minutes.?Before that was going much faster.

I came back to an earlier version of JMRI, no change.

Here is the description of my system:
Digital Central: DCC++
JMRI: 4.14+Rd060e0b
Java: 1.8.0_211
PC with W10 family 1809 version: 17763.503
Proc: Intel Intel Core I3 5005U 2.00GHZ
RAM: 4Go / 3.87Go free
 

Six minutes sounds very long.

What¡¯s the status line showing while that¡¯s happening? Is it retrying a read multiple times?

What programming mode are you using?

Bob

On May 28, 2019, at 6:33 AM, fcot2002@... wrote:

Hello @ all,

In recent days the time to identify a locomotive with Decoder Pro has become extremely long. About 6 minutes. Before that was going much faster.

I came back to an earlier version of JMRI, no change.

Here is the description of my system:
Digital Central: DCC++
JMRI: 4.14+Rd060e0b
Java: 1.8.0_211
PC with W10 family 1809 version: 17763.503
Proc: Intel Intel Core I3 5005U 2.00GHZ
RAM: 4Go / 3.87Go free
--
Bob Jacobsen
rgj1927@...
 

Fcot,

I'd suggest that you open the connection monitor (DCC++->Traffic Monitor) to
trace the traffic between JMRI and the command station. That will show if it
is doing a bunch of retries or what it going on. Also other errors might be
showing up in the system console. So open that (Help->System Console) too.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
 

Hello All,

@ John
I said that I had no problem with my locomotives before the last days.
The decoders are for example:?Laisdcc86010?or?LokPilot v3.0 dcc

@Ken Bob
Error message: Decoderpro status: stopping due to error: time exceeded for communication with the dcc control panel (306)

Direct Byte or Direct bit it's the same

I will test again with Connection monitor, I come back.

thank's
 

monitor connection console result

16:34:55.006:? Prog Read Cmd:?
CV: 29
Callback Num: 0
Callback Sub: 82
16:34:56.240:? Program Reply:?
Callback Num: 0
Callback Sub: 82
CV: 29
Value: 39
16:34:56.256:? Prog Read Cmd:?
CV: 17
Callback Num: 0
Callback Sub: 82
16:36:26.250:? Prog Read Cmd:?
CV: 17
Callback Num: 0
Callback Sub: 82
16:36:27.469:? Program Reply:?
Callback Num: 0
Callback Sub: 82
CV: 17
Value: 192
16:36:27.500:? Prog Read Cmd:?
CV: 18
Callback Num: 0
Callback Sub: 82
16:37:57.486:? Prog Read Cmd:?
CV: 18
Callback Num: 0
Callback Sub: 82
16:37:58.720:? Program Reply:?
Callback Num: 0
Callback Sub: 82
CV: 18
Value: 218
16:37:58.736:? Prog Read Cmd:?
CV: 7
Callback Num: 0
Callback Sub: 82
16:39:28.736:? Prog Read Cmd:?
CV: 7
Callback Num: 0
Callback Sub: 82
16:39:29.986:? Program Reply:?
Callback Num: 0
Callback Sub: 82
CV: 7
Value: 43
16:39:30.001:? Prog Read Cmd:?
CV: 8
Callback Num: 0
Callback Sub: 82
16:40:59.998:? Prog Read Cmd:?
CV: 8
Callback Num: 0
Callback Sub: 82
16:41:01.248:? Program Reply:?
Callback Num: 0
Callback Sub: 82
CV: 8
Value: 151
?
 

Is there a DCC++ support list somewhere?

We¡¯re seeing more and more reports of odd (i.e. not good) behavior of DCC++ command stations. This is an example: It looks like the DCC++ command station is crashing on you.

Unfortunately, there¡¯s only a little DCC++ expertise here; only a small number of JMRI users have DCC++ command stations, and many of them are beginners at all of this.

If there was a DCC++ list, that might be a better place to get things like this sorted out.

Bob

--
Bob Jacobsen
jacobsen@... +1-510-708-5988 AIM, Skype JacobsenRG
 

There are some forums / groups DCC ++, but not found that kind of problem.
?
As I have another arduino I will test to see if it does not come from the card itself.
 

Bob:

Seems there is on Facebook groups... Quick read of first several posts isn't "expert..."

I've built a test rig for our club based on Steve Todd's RPi-JMRI plus the DCC++ command station... No issues there. I'll check the rev levels of the installed software to perhaps set a base configuration where we thinks this works.

Where I usually see long delays with JMRI starting is where there is a USB port not found or connection issue.

We have a bunch of factors... OS, Java, JMRI and serial connection.

Stay tuned from me I'll get back on this Thursday... club machine access is tomorrow...

Jim Albanowski
 

Wow! That command trace says the delay is all something in the command
station. If you pair the commands, you would see that JMRI is asking for the
next CV within 100mS or less from receiving the prior answer. It isn't doing
retries from JMRI. Something in the command station is being really slow.

Any chance of dirty track or wheels?

The CV says that's a Heller decoder. And it read the long address, so that's
the mode it is using. I've got no idea except something odd in the command
station would cause it to take so long to reply to each command from JMRI.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
 

Yes I also think that the problem comes from the station.
?
The rail and wheels are clean ;-)
 

Could it be something like a debug mode left on in the command station and
its sending messages out another port? Waiting for an answer there and
timing out? That would be my guess, presuming there image in the command
station is ok.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
 

There was no change to the station and DCC ++ code.
?
The station had been working properly since last November, CV reading and identification was fast.
 

Hello @ all!
?
First of all thank you for the interest spent on my problem :-)
?
JMRI is OK!
?
It seems that the problem comes from the shield ethernet, I removed it, passed in serial connection, and in less than 10sec to identify my locomotives.
?
I may not be an "expert" (...) but I know how to search.
?
Have a good day @ all
 

I promised to get back...

Test/programming track DCC++/JMRI build for our club...

Raspberry Pi 3B+, Arduino Mega (Inland (MicroCenter) clone), Arduino Motor Shield and using onboard USB serial communications. JMRI is stock 4.15.4. Java 1.8.0_201.

DCC++ is current production build. Arduino IDE 1.8.5. Download? to Arduino via Mac not the Pi. Raspbian 2018-11-13. Update/Upgrade last done several weeks ago. xscreensaver added to keep screen from timing out.

No delays reading all CV's into new roster entry from a couple of decoders (MTH.)

I don't see a specific debug mode in config.h where we might have competing I/O's on the serial connection.

Sorry, no help here?

Jim Albanowski
 

Hello boy's
?
Bad news ! Yesterday I mounted a brand new DCC ++ Ethernet for a friend, and the problem of slowness is reproduced.
?
We switched to a USB serial and everything is ok.
?
Thank you Jim Albanowski for your comment, but I see that you are in USB serial and no problem, like us here.
?
The problem only comes in Ethernet mode ...
?
Someone would have any idea ?
?
Thank you for reading us (and for helping us too :-) )
 

Fcot,

Are you using some serial to ethernet adapter? If that is the case I suspect
your setup for things like how it knows when to send packets is not correct.
I've seen a lot of those devices that default for expecting some sort of
text or other form with a known delimiter to trigger sending the buffer as
one packet. But this traffic isn't like that. It needs to do something like
raw and a very short timeout, so it will complete the packet to JMRI (or the
other way, to the DCC+++ device).

OTOH, if somebody knows the protocol for DCC+++ and it is formed with a
known 'end' character, then making sure the interface knows that character
might make the difference.

That's my guess, but that's only if the interface is a serial to ethernet
buffer. If the DCC+++ command station is native ethernet, then I would doubt
this is related to your problem.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
 

Hello Ken,
?
No it is not a serial ethernet, but an arduino ethernet shield that comes plugger on the Mega Arduino.
?
It uses the classic ethernet protocol.
?
Thank you :-)
 

While I might be tempted to try to duplicate your Ethernet problem... I'm not sure I can...

Looking at the coding to configure the connection I see three specific Ethernet shields listed and would wonder if the one that's close to wired boards I have would actually work. I know my Ethernet shield works with demo programs and a Uno or Mega but that's with it's board specific library.

So I'm going to hold off testing but will make one suggestion. There's mention of hard coding the IP of the DCC++ command station. Have you tried both getting the IP from the PC and hard coded?

Jim Albanowski
 

Good evening Jim,
?
So I just re-check everything, I switched to fixed IP on the Mega and the PC, then in DHCP on the Mega and the PC ...
?
Same result 5 to 6 minutes to identify a locomotive.
?
Next test: replace the switch
?
Thanks everyone

1 - 20 of 21