开云体育

From the NCE Power Pro manual:
AIU BROADCAST ENABLE

The system can be set to have any connected AIU (Auxiliary Input Unit) automatically outputs its status via the RS232 port on the system box whenever an AIU input changes. This is disabled by default. Press ENTER to skip setting this parameter.

As Ken has said, the design of JMRI is such that it cannot cope with unsolicited broadcast messages from the NCE command station while it is waiting for a response to another command it has sent to the NCE command station.

So when you add AIU sensors, JMRI sends regular 0x8A yy (Return status of AIU yy) commands for all known AIUs. This process is known as polling and is subject to your computer and JMRI being free enough to send a command and accept a response.
--
Dave in Australia

RJ,



If you research the prototype, you will find they used a number of different
ways over the years. And then if you add multiple tracks, trains that
approach but back up, trains that stop, etc. it gets even more fun.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

Nick,



Two things to keep in mind:

1. Most sensors do have some internal delay, at least track sensors do.
Optic sensors are quicker usually. Which do you have??

2. The delays tend to be consistent and average out over time.



As said by others, this sort of issue, stopping the train at a station, is
harder than it looks. When I wrote RobotThrottle, I had the train slowing
down for the approach to the station and then generally creep along the
platform. I found that the stopping point was usually plus/minus 5 inches of
the ideal spot.



Many other issues seemed to come into play biggest of which was the change
in a given train over time, meaning as it warmed up, the response time would
change. Some trains would stop quick while others would stop slower. During
a 6 hour show, I'd have to tweak the response (or keep the trains short)
about twice.



Anyway the NCE command station has to run with AIU broadcast off.
Unfortunately the way it was coded JMRI couldn't identify the difference
between some normal responses it was looking for from the AUI broadcasts and
other things would get messed up.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

Ken B,



Somewhere along the 4.7.* development cycle, we started pretesting the panel
file and trapping errors like duplicates where they don't belong. In your
case a signal LH82 is mentioned more than once in a panel and it raised the
complaint.



If you could post the file to the user group space under 'Problems being
worked on' we can take a look at the file and see if the complaint is valid
and help fix it.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

Thank You Ken Cameron. Finding out that it is more complicated than operating a bull dozer! will continue to muddle along. RJ


---In jmriusers@..., <kcameron@...> wrote :

RJM,



It sounds like you are asking about the typical road crossing a set of
tracks. As pointed out, there are many ways and combinations of track so a
one-size-fits-all doesn't exist. Another issue is there are a range of
solutions that will emulate a range of prototypical behavior but at varying
costs and complexity. And then comes of the issue of which way to detect the
presence of the train. If you already have track detection for line side
signaling, then leveraging that is best. Others us photo sensors to know
when a train is approaching or departing.



So lots of options that depend on what you already have or are willing to
add to the layout.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

Hi,


What are AIU broadcasts and what problems/symptoms should I expect in JMRI?.


I only ask because I'm using NCE Power Pro 5, NCE AIU, sensors and JMRI script to measure speed of train going round my DCC test track in order to test speed response of RFID reader.


Regards


Nick

Ken,

What version of PanelPro are you running?

The easiest way to diagnose this problem is for you to upload the XML file to the ProblemsBeingWorkedOn folder.

Dave Sand

I did a prnt scrn of the error message and pasted it in this message but
it seems it didn't stick so here it is.

Parse error

while parsing file
/W:/Users/Ken/Dropbox/JMRI/1%20NEWEST%20UPDATED%20PANEL.xml

Exception: org.jdom2.input.JDOMParseExceptoin: Error on line 1651:
cvc-identity-constraint.4.1: Duplicate unique value [LH82]

declared for identity constraint "signalHeadUserName" of element
"layout-config".

See http//jmri.org/help/en/package/jmri/configurexml/ErrorHandler.shtml
for more information.

My panel file suddenly won't load. This error message appears. Any help is appreciated.

Thanks, Ken

AIU broadcasts must be disabled for JMRI to work with NCE systems. JMRI does not listen for these. See point 5 at <>

JMRI works by polling your AIUs at intervals for status and polling can be subject to variable delays.
--
Dave in Australia

Hi,

I'm trying to understand how OpenLCB node configuration works.
To this end, I'm creating a working model, which I did have working up to having JMRI presenting the configuration panel.
I adapted the model to try to process configuration changes. When I try to test the program it JMRI appears to wait for approximately three seconds between the first and second requests for CDI data, which causes a time out and fail.


Here are the log and Traffic monitor entries:


Messages.log
2017-06-30 12:31:10,724 util.Log4JUtil INFO - * JMRI log ** [main]
2017-06-30 12:31:10,884 util.Log4JUtil INFO - This log is appended to file: /home/user/.jmri/log/messages.log [main]
2017-06-30 12:31:10,887 util.Log4JUtil INFO - This log is stored in file: /home/user/.jmri/log/session.log [main]
2017-06-30 12:31:10,914 apps.Apps INFO - PanelPro version 4.6-R81496dc starts under Java 1.8.0_77 on Linux amd64 v4.4.0-83-generic at Fri Jun 30 12:31:10 CEST 2017 [main]
2017-06-30 12:31:14,007 apps.Apps INFO - Starting with profile CDI.3f40ba91 [main]
2017-06-30 12:31:14,132 node.NodeIdentity INFO - Using jmri-00163E00006E-3f40ba91 as the JMRI Node identity [main]
2017-06-30 12:31:14,672 net.NetworkDriverAdapter INFO - Connection complete with cangw.solwiz.local/192.168.0.112 [main]
2017-06-30 12:31:15,795 util.FileUtilSupport INFO - File path program: is /home/user/JMRI.4.6/ [main]
2017-06-30 12:31:15,795 util.FileUtilSupport INFO - File path preference: is /home/user/.jmri/CDI/ [main]
2017-06-30 12:31:15,796 util.FileUtilSupport INFO - File path profile: is /home/user/.jmri/CDI/ [main]
2017-06-30 12:31:15,797 util.FileUtilSupport INFO - File path settings: is /home/user/.jmri/ [main]
2017-06-30 12:31:15,797 util.FileUtilSupport INFO - File path home: is /home/user/ [main]
2017-06-30 12:31:15,798 util.FileUtilSupport INFO - File path scripts: is /home/user/JMRI.4.6/jython/ [main]
2017-06-30 12:31:54,469 jdom.CdiMemConfigReader WARN - Error reading CDI: 100 [Timer-5]
2017-06-30 12:31:54,504 ConfigRepresentation WARN - Failed to parse CDI output: org.jdom2.input.JDOMParseException: Error on line 2: XML document structures must start and end within the same entity. [Timer-5]
2017-06-30 12:31:54,554 MemoryConfigurationService WARN - Could not find a matching memo for MemCfg response datagram from 05.01.01.01.31.FF payload 20 53 00 00 00 40 53 63 68 65 6D 61 2D 69 6E 73 74 61 6E 63 65 22 20 78 73 69 3A 6E 6F 4E 61 6D 65 73 70 61 63 65 53 63 68 65 6D 61 4C 6F 63 61 74 69 6F 6E 3D 22 68 74 74 70 3A 2F 2F 6F 70 65 6E 6C 63 62 2E 6F [AWT-EventQueue-0]

OpenLCB Traffic Monitor
12:31:42.389: [[19828c6e] 01 23 ] S: 02.01.12.FE.03.DF - 05.01.01.01.31.FF ProtocolSupportInquiry with no payload
12:31:42.390: [[19490c6e] ] S: 02.01.12.FE.03.DF Verify Node ID Number: all nodes
12:31:42.390: [[19170c6e] 02 01 12 FE 03 DF ] S: 02.01.12.FE.03.DF Verified Node ID Number
12:31:42.505: [[19668123] 0C 6E D0 18 00 00 00 00] R: 05.01.01.01.31.FF - 02.01.12.FE.03.DF ProtocolSupportReply with payload D0 18 00 00 00 00
12:31:42.525: [[19de8c6e] 01 23 ] S: 02.01.12.FE.03.DF - 05.01.01.01.31.FF SimpleNodeIdentInfoRequest with no payload
12:31:42.526: [[19170123] 05 01 01 01 31 FF ] R: 05.01.01.01.31.FF Verified Node ID Number
12:31:42.537: [[19a08123] 1C 6E 04 ] R: Unknown message [19a08123] 1C 6E 04
12:31:42.558: [[19a08123] 3C 6E 4F 20 53 63 68 72] R: Unknown message [19a08123] 3C 6E 4F 20 53 63 68 72
12:31:42.611: [[19a08123] 3C 6E 65 69 62 6B 65 00] R: Unknown message [19a08123] 3C 6E 65 69 62 6B 65 00
12:31:42.663: [[19a08123] 3C 6E 54 65 73 74 20 4E] R: Unknown message [19a08123] 3C 6E 54 65 73 74 20 4E
12:31:42.715: [[19a08123] 3C 6E 6F 64 65 00 ] R: Unknown message [19a08123] 3C 6E 6F 64 65 00
12:31:42.767: [[19a08123] 3C 6E 30 2E 31 00 ] R: Unknown message [19a08123] 3C 6E 30 2E 31 00
12:31:42.819: [[19a08123] 3C 6E 30 2E 31 00 ] R: Unknown message [19a08123] 3C 6E 30 2E 31 00
12:31:42.829: [[19a08123] 3C 6E 02 ] R: Unknown message [19a08123] 3C 6E 02
12:31:42.874: [[19a08123] 3C 6E 00 ] R: Unknown message [19a08123] 3C 6E 00
12:31:42.928: [[19a08123] 2C 6E 00 ] R: 05.01.01.01.31.FF - 02.01.12.FE.03.DF Simple Node Ident Info with content '4,O Schreibke,Test Node,0.1,0.1,2,,,'
12:31:51.454: [[1a123c6e] 20 43 00 00 00 00 40 ] S: 02.01.12.FE.03.DF - 05.01.01.01.31.FF Datagram: (7) 20.43.0.0.0.0.40
12:31:51.510: [[19a28c6e] 01 23 80 00 00 00 00 00] R: 02.01.12.FE.03.DF - 05.01.01.01.31.FF DatagramReceivedOK with payload 80
12:31:51.513: [[1bc6e123] 20 53 00 00 00 00 ] R: (Start of Datagram)
12:31:51.520: [[1cc6e123] 3C 3F 78 6D 6C 20 76 65] R: (Middle of Datagram)
12:31:51.522: [[1cc6e123] 72 73 69 6F 6E 3D 22 31] R: (Middle of Datagram)
12:31:51.525: [[1cc6e123] 2E 30 22 3F 3E 0A 3C 63] R: (Middle of Datagram)
12:31:51.535: [[1cc6e123] 64 69 20 78 6D 6C 6E 73] R: (Middle of Datagram)
12:31:51.545: [[1cc6e123] 3A 78 73 69 3D 22 68 74] R: (Middle of Datagram)
12:31:51.557: [[1cc6e123] 74 70 3A 2F 2F 77 77 77] R: (Middle of Datagram)
12:31:51.560: [[1cc6e123] 2E 77 33 2E 6F 72 67 2F] R: (Middle of Datagram)
12:31:51.588: [[1dc6e123] 32 30 30 31 2F 58 4D 4C] R: 05.01.01.01.31.FF - 02.01.12.FE.03.DF Datagram: (70) 20.53.0.0.0.0.3C.3F.78.6D.6C.20.76.65.72.73.69.6F.6E.3D.22.31.2E.30.22.3F.3E.A.3C.63.64.69.20.78.6D.6C.6E.73.3A.78.73.69.3D.22.68.74.74.70.3A.2F.2F.77.77.77.2E.77.33.2E.6F.72.67.2F.32.30.30.31.2F.58.4D.4C
12:31:51.589: [[19a28c6e] 01 23 ] S: 02.01.12.FE.03.DF - 05.01.01.01.31.FF DatagramReceivedOK with no payload
12:31:54.450: [[1a123c6e] 20 43 00 00 00 40 40 ] S: 02.01.12.FE.03.DF - 05.01.01.01.31.FF Datagram: (7) 20.43.0.0.0.40.40
12:31:54.464: [[19a28c6e] 01 23 80 00 00 00 00 00] R: 02.01.12.FE.03.DF - 05.01.01.01.31.FF DatagramReceivedOK with payload 80
12:31:54.510: [[1bc6e123] 20 53 00 00 00 40 ] R: (Start of Datagram)
12:31:54.510: [[1cc6e123] 53 63 68 65 6D 61 2D 69] R:12:31:51.589 (Middle of Datagram)
12:31:54.513: [[1cc6e123] 6E 73 74 61 6E 63 65 22] R: (Middle of Datagram)
12:31:54.527: [[1cc6e123] 20 78 73 69 3A 6E 6F 4E] R: (Middle of Datagram)
12:31:54.534: [[1cc6e123] 61 6D 65 73 70 61 63 65] R: (Middle of Datagram)
12:31:54.537: [[1cc6e123] 53 63 68 65 6D 61 4C 6F] R: (Middle of Datagram)
12:31:54.544: [[1cc6e123] 63 61 74 69 6F 6E 3D 22] R: (Middle of Datagram)
12:31:54.548: [[1cc6e123] 68 74 74 70 3A 2F 2F 6F] R: (Middle of Datagram)
12:31:54.558: [[1dc6e123] 70 65 6E 6C 63 62 2E 6F] R: 05.01.01.01.31.FF - 02.01.12.FE.03.DF Datagram: (70) 20.53.0.0.0.40.53.63.68.65.6D.61.2D.69.6E.73.74.61.6E.63.65.22.20.78.73.69.3A.6E.6F.4E.61.6D.65.73.70.61.63.65.53.63.68.65.6D.61.4C.6F.63.61.74.69.6F.6E.3D.22.68.74.74.70.3A.2F.2F.6F.70.65.6E.6C.63.62.2E.6F
12:31:54.567: [[19a28c6e] 01 23 ] S: 02.01.12.FE.03.DF - 05.01.01.01.31.FF DatagramReceivedOK with no payload



My environment:
JMRI 4.6 running on an Ubuntu 16.04.2 LTS virtual machine. Java 1.8.0_77.
JMRI connects through the GridConnect Network interface to a sketch running on a NodeMCU ESP8266.


I won't post the ESP8266 code here, unless someone needs it, as it's rather long.



Does anyone have any ideas why the pause between 12:31:51.589 and 12:31:54.450 is happening?
Subsidiary question: is there any publicly available documentation on how the CDI exchange and configuration works? I don't mean the Standards and Technical notes; they are horrible to work with and don't give the details on how JMRI expects things to happen.



Thanks and regards
Otto

Hi,


I too have noticed that I can stop a train more accurately with a throttle than with a sensor using a JMRI script and an NCE Power Pro 5 and an NCE AIU.


The status of the AIU is not sent via the NCE serial interface to the computer at a very high repetition rate so there is a variable delay there.


Also even locos without flywheels don't stop immediately.


When stopping a loco with a throttle I guess the human brain compensates using the visual cue of how fast the train in approaching the point you want to stop at.


If using just one position sensor and trains at medium or high speeds it may not be possible to stop the train accurately. The speed of a model train vs DCC speed step probably depends on a number of factors:


The relationship between motor speed (tested disconnected from loco) vs DCC speed step.
The amount of momentum the DCC decoder is applying.
The cleanliness profile of the track.
The state of the wheels and pickups and their efficiency vs speed profile.
The DCC peak voltage.
The Back EMF profile of the DCC decoder(the percentage of back emf feedback used at low speeds and how it tails off towards higher speeds and cuts off).
The friction profile of the train as it approaches the position to stop at.
The ratio of static friction of the train to dynamic.
The mass vs diameter characteristics of the flywheel(s) (if fitted).


People in the past have used at least two position sensors to stop a train near a pre-determined position. The loco decoder must be set and capable of very low levels of momentum.
The first sensor is a long way from the stop point - a JMRI script will start reducing the speed step from this point for so many milliseconds depending on the speed of the train and the locos speed step vs speed profile. The script reduces the train speed to a constant value - a slow speed that the loco is happy with just in time for the arrival at the second sensor. Then the script reduces the speed step to zero fairly rapidly to give as accurate stopping point beyond the sensor as possible.


The sensors also have to be fairly accurate - they need to have narrow sensing width and very low delay time - an IR sensor looking straight up for the loco chassis may be a good geometric setup.


Regards


Nick

Waz, since I did the original post I have ripped out the BLI decoder and
replaced it with a Soundtraxx Econami 200, part number 881102. I don't like
the BLI decoders as they are prone to fail, the magnetic reed switch, and I
don't like puffing smoke as it's just toy like. Also I found that it chuffs
erratically which is very annoying, again the magnetic reed switch. The
Soundtraxx decoder has a better chuff and whistle and will fit in the loco
boiler with a speaker, once all the junk has been removed, and it's a simple
matter to wire up. Now the sound comes from the right place in loco and with
the addition of a 1Kohm surface mount resistor, Soundtraxx decoders use 12V
lighting so a resistor is a necessary for LED lighting. I also wired a
function for the fire box light with gives the necessary flicker. This is
also translated to oil lamps which now have a nice flicker as well though
they are a little bright so I may have to fit a larger resistor.

Sorry I no longer have the settings in my roster but make sure you have the
latest test version of Decoder Pro as this will have the latest decoder
definitions.



Regards

Charles Emerson

Queensland

Australia

From: jmriusers@... [mailto:jmriusers@...]
Sent: Friday, 30 June 2017 5:42 PM
To: jmriusers@...
Subject: RE: [jmriusers] JMRI Dapol Black Label A4





Hi Charles,

Firstly which decoder type did you use? as when I try and add the loco to my
Roster it returns error unknown decoder. And secondly have you had any luck
with changing the Lighting CV settings as I would like to try and get the
oil lamps to flicker.


Many Thanks


Waz

Thank you for this. I will try to find time later today to try this out.

We have a public awareness event tomorrow and I was hoping to have the small railway shunting yard we have as part of that but the sensors problem was blocking me somewhat.


I will no doubt be asking more questions, but I'll put them in other posts with more appropriate title. Thanks again.

Hi Charles,

Firstly which decoder type did you use? as when I try and add the loco to my Roster it returns error unknown decoder. And secondly have you had any luck with changing the Lighting CV settings as I would like to try and get the oil lamps to flicker.


Many Thanks


Waz

Hi,
I too am new to jmri scripting. I think you are spot on to start with something simple. I did the same. With regard to your question, I have two comments that hopefully may be helpful if I have understood correctly.
Firstly, I found that if I instructed a train to stop based on the state of a block occupancy sensor instead of some internal condition in the script, there was a notable difference in the time to react. I presume that is the same kind of issue you are referring to ?
With regard to a script solution, it is possible to add a delay in a script using the sleep function ( you need to load the relevant module at the start of the code in order to access it). However, the sleep function pauses the entire script, and in my case the script controls many trains so it is not good to pause the entire script because other things may be happening to other trains thst need the script?s attention at that time.
So I wrote some code that pauses only a specific operation rather than the entire script.
I am a novice so this may not be an optimum solution but I am happy to show you what I did if I have understood what you need to do correctly and it would help.

RJM,



It sounds like you are asking about the typical road crossing a set of
tracks. As pointed out, there are many ways and combinations of track so a
one-size-fits-all doesn't exist. Another issue is there are a range of
solutions that will emulate a range of prototypical behavior but at varying
costs and complexity. And then comes of the issue of which way to detect the
presence of the train. If you already have track detection for line side
signaling, then leveraging that is best. Others us photo sensors to know
when a train is approaching or departing.



So lots of options that depend on what you already have or are willing to
add to the layout.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

Sounds like the Consist settings for 5629 are not "Locomotive Address Only" for Lights and Bell. What brand and model of decoder? Read the actual values in CVs 21 & 22 and if not already so, set them both to zero.
--
Dave in Australia

RJM,

It seems that you are asking about automation of "crossing signals" for a location where a street crosses one or more tracks. Is that correct?

So far as I am aware, JMRI does not have any specific support for this. There are something like a bazillion ways to implement such a thing, so JMRI cannot easily implement a "one-size-fits-all" solution.

(Since you seem to be working on a LocoNet-based solution, I will contact you "off-list" about possible solutions.)

Regards,
Billybob

In the Layout Editor they’re called “Level Crossing”s…

--
Enjoy,
George Warner
eMail/iChat: <geowar1@...>