Date   
Re: Servos, Ardunios, and JMRI #arduino

Geoffb
 

Hi Bob,
Thanks for all those comments and pointers.
Since way more people are using these than I had imagined, I will try to incorporate these and test them with multiple
USB channels when I can pull everything together.

Much appreciated.
Have fun!  :-)
Best regards,
Geoff Bunza
scalemodelanimation.com

Re: loco assignments #operationspro

cascaderwy
 

Hey Dan,
Thanks, I assume that I do this edit after I build the train.Will the add show on the manifest (the pickup and the dropoff at the properly location)?
Thanks
Matt Greenwood

Re: DP feature request

thomasmclae
 

I started JMRI long before the consisting tool, and never got the habit of using it.
Which is why i never saw the option.
And training all 60 club members how to use a new tool is not trivial either. (This is a computer, bush this button to start...)

We removed the programming track from the layout system when we discovered programming mode locked out all the throttles (Easy DCC). so the other guy running bashed into the stopped train due to no control.
We have two separate programming tracks/tables/computers, with different systems. (Easy DCC, Digitraxx, SPROG, and Pi-Sprog)

Add hock consists are set with wi-throttle or Engine Driver, or on the EasyDCC panel. Engine Driver is getting most of the consisting features mentioned.

Just the club scaleability issues.

But automatic consist as throttle address would still be nice on the programming tracks.

Thomas
DeSoto, TX

Re: Servos, Ardunios, and JMRI #arduino

Bob Jacobsen
 

I think those changes will do it.

Another approach would be to pass the output stream into the listener objects, so that two separate copies of the class wouldn’t be needed.

Bob

On Jul 24, 2019, at 1:21 PM, Geoffb <@Geoffb> wrote:

If :
# get I/O connections for later
inputStream = port.getInputStream()
outputStream = port.getOutputStream()
...
outputStream.write(event.source.userName)
outputStream.write(",0")
...
outputStream.write(event.source.userName)
outputStream.write(",1")

were changed to
# get I/O connections for later
inputStreamPT = port.getInputStream()
outputStreamPT = port.getOutputStream()
...
outputStreamPT.write(event.source.userName)
outputStreamPT.write(",0")
...
outputStreamPT.write(event.source.userName)
outputStreamPT.write(",1")

and
# get I/O connections for later
inputStreamST = port.getInputStream()
outputStreamST = port.getOutputStream()
...
outputStreamST.write(event.source.userName)
outputStreamST.write(",0")
...
outputStreamST.write(event.source.userName)
outputStreamST.write(",1")

would these changes be enough to solve the problem?
--
Bob Jacobsen
@BobJacobsen

Re: Servos, Ardunios, and JMRI #arduino

Bob Jacobsen
 

If you have a panel file loaded (before the script is run) that has created internal Turnouts with the appropriate user names, then all is well.

However, it’s good to have scripts like this (which can be distributed to others) be more general. When the script calls provideTurnout(..) that will create the turnout if it doesn’t already exist, using the argument as a system name. (It could call getTurnout(..), which will find an existing turnout with that user name or system name, and return None / null if it doesn’t exist already).

So to make the script general, I think it would be best to either use getTurnout and document then should already exist, or use valid system names.

(Some people might want to give _other_ user names, so valid system names might be best, but either is pretty good)

Bob

On Jul 24, 2019, at 1:21 PM, Geoffb <@Geoffb> wrote:

also Bob, your comment:
This script creates internal Turnout objects with names at start with AT and ST. Although it woks for you now, there’s no guarantee that always will. Better would be names like ITAT or ITST, which are the standard form and won’t (possibly) break in the future.
Uses ATxx and STxx as the User names for the internal Turnout objects or they could refer to hardware objects. I would think that User names as an independent alias for internal or hardware references would be "protected" as a system design feature of JMRI in the future, as it seems to be "advertised" as such (as consistent in future releases)?
No? Did I misunderstand?
--
Bob Jacobsen
@BobJacobsen

Re: Servos, Ardunios, and JMRI #arduino

Geoffb
 

Bob, et al.,

If :
# get I/O connections for later
inputStream = port.getInputStream()
outputStream = port.getOutputStream()
...
        outputStream.write(event.source.userName)
        outputStream.write(",0")
...
        outputStream.write(event.source.userName)
        outputStream.write(",1")

were changed to
# get I/O connections for later
inputStreamPT = port.getInputStream()
outputStreamPT = port.getOutputStream()
...
        outputStreamPT.write(event.source.userName)
        outputStreamPT.write(",0")
...
        outputStreamPT.write(event.source.userName)
        outputStreamPT.write(",1")

and
# get I/O connections for later
inputStreamST = port.getInputStream()
outputStreamST = port.getOutputStream()
...
        outputStreamST.write(event.source.userName)
        outputStreamST.write(",0")
...
        outputStreamST.write(event.source.userName)
        outputStreamST.write(",1")

would these changes be enough to solve the problem?

also Bob, your comment:
This script creates internal Turnout objects with names at start with AT and ST. Although it woks for you now, there’s no guarantee that always will. Better would be names like ITAT or ITST, which are the standard form and won’t (possibly) break in the future.
Uses ATxx and STxx as the User names for the internal Turnout objects or they could refer to hardware objects. I would think that User names as an independent alias for internal or hardware references would be "protected" as a system design  feature of JMRI in the future, as it seems to be "advertised" as such (as consistent in future releases)?
No?  Did I misunderstand?

Have fun!  :-)
Best regards,
Geoff Bunza
scalemodelanimation.com

Re: Servos, Ardunios, and JMRI #arduino

Sam Simons
 

Cliff & Bob,

Thank you for your responses. Apologies for the hidden code; some other forums have a "code" tag and I was trying to see if it would work as such in an effort to keep things neat... failed miserably.

I am heading out the door in about thirty minutes for a work trip and, if I'm lucky, I should be back Sunday so this response will be a bit brief.

Over the next couple of days I'll have some time to study the Python scopes and namespaces link. To be candid, I may well just rename the variables initially by appending P and S but - and I am afraid my knowledge of scripting as a whole is quite limited - moving the variables over to the Datatransfer class to make the whole thing more robust makes sense. I don't plan on having more than the two Arduinos at the moment but I do have a third Arduino (a Mega - don't think that'll make a difference though) available, and a single servo should Cliff wish to experiment a bit more. There are others in the local area who have been considering an Arduino solution and this may be able to help them out as they work on their layouts.

Last, regarding turnout names, my turnout table has ten rows. User names ST1-5 are assigned system names IT1-5 and PT1-5 are IT6-10. Is this not correct?

Sam

Re: loco assignments #operationspro

Dan Boudreau
 

Matt,

You can always manually assign a car or loco to a train.  You can add the car or loco anywhere along a built train's route, and you can drop off the car or loco at any location and track after the pick-up location. Use the car or loco "Set" button to add them to a train.  I believe you can stay dry.

http://jmri.org/help/en/package/jmri/jmrit/operations/Operations.shtml#LocomotivesSet

Dan

Re: Servos, Ardunios, and JMRI #arduino

Cliff Anderson
 

Correction to my previous post:

# The following will set up 5 listeners for Turnouts PT1 though PT6 (by username) for x in range(1,6) :
    Datatransfer(x,x+100)

Your changes within the Datatransfer class definition, while using the same name for what are two different classes got overlooked in my previous analysis.

Thus, my comments about duplicate Turnout change of state reports are wrong.

Cliff

Re: Servos, Ardunios, and JMRI #arduino

Bob Jacobsen
 

The problem is that both scripts are using the same global variable for `outputStream`. A single script sets that, then installs some code that listens for changes so that it can later forward those changes to the hardware via outputStream. But when you run two scripts, the second one changes the value of that variable, so now both the first set of listening code _and_ the second set are sending to the second port.

The quickest reliable fix is to make sure that all the variable named in the global (not intended) part of the first script are different from those in the second script. Append a P to one and a S to the other, or something like that.

A better solution would be to move those variables into the Datatransfer class, and then pass the port in as another argument. That would make it much easier for people to use two copies of the script. But that’s a bit more programming.

Note another thing: This script creates internal Turnout objects with names at start with AT and ST. Although it woks for you now, there’s no guarantee that always will. Better would be names like ITAT or ITST, which are the standard form and won’t (possibly) break in the future.

Bob


On Jul 23, 2019, at 4:59 PM, Sam Simons <samusi01@...> wrote:

Bob,

Here you go - the 'P' script first, then the 'S' script.

Also, this is happening on current production 4.16.

Sam
# Transfer "TurnOut" Data from to an Arduino via Serial Transmission
# Author: Geoff Bunza 2018 based in part on a script by
# Bob Jacobsen as part of the JMRI distribution
# Version 1.1
# Connects JMRI Turnout "Watcher" to an Arduino Output Channel
# Note that JMRI must be set up to have a valid
# turnout table; if you're not using some other DCC connection,
# configure JMRI to use LocoNet Simulator
import jarray
import jmri
import java
import purejavacomm
# find the port info and open the port
global extportinP
portname = "COM5"
portID = purejavacomm.CommPortIdentifier.getPortIdentifier(portname)
try:
port = portID.open("JMRI", 50)
except purejavacomm.PortInUseException:
port = extportinP
extportinP = port
# set options on port
baudrate = 19200
port.setSerialPortParams(baudrate,
purejavacomm.SerialPort.DATABITS_8,
purejavacomm.SerialPort.STOPBITS_1,
purejavacomm.SerialPort.PARITY_NONE)
# get I/O connections for later
inputStream = port.getInputStream()
outputStream = port.getOutputStream()
# define a turnout listener that will
class Datatransfer(java.beans.PropertyChangeListener):
# initialization
# registers to receive events
def __init__(self, id, value) :
self.name = "PT"+str(id)
self.closed = value # write this value to close
self.thrown = value # write this value to throw
turnout = turnouts.provideTurnout(self.name)
turnout.addPropertyChangeListener(self)
turnout.setCommandedState(CLOSED)
return

# on a property change event, first see if
# right type, and then write appropriate
# value to port based on new state
def propertyChange(self, event):
#print "change",event.propertyName
#print "from", event.oldValue, "to", event.newValue
#print "source systemName", event.source.systemName
if (event.propertyName == "CommandedState") :
if (event.newValue == CLOSED and event.oldValue != CLOSED) :
print "set CLOSED for", event.source.userName
outputStream.write(event.source.userName)
outputStream.write(",0")
if (event.newValue == THROWN and event.oldValue != THROWN) :
print "set THROWN for", event.source.userName
outputStream.write(event.source.userName)
outputStream.write(",1")
return
# The following will set up 5 listeners for Turnouts PT1 though PT6 (by username)
for x in range(1,6) :
Datatransfer(x,x+100)

# Transfer "TurnOut" Data from to an Arduino via Serial Transmission
# Author: Geoff Bunza 2018 based in part on a script by
# Bob Jacobsen as part of the JMRI distribution
# Version 1.1
# Connects JMRI Turnout "Watcher" to an Arduino Output Channel
# Note that JMRI must be set up to have a valid
# turnout table; if you're not using some other DCC connection,
# configure JMRI to use LocoNet Simulator
import jarray
import jmri
import java
import purejavacomm
# find the port info and open the port
global extportinS
portname = "COM4"
portID = purejavacomm.CommPortIdentifier.getPortIdentifier(portname)
try:
port = portID.open("JMRI", 50)
except purejavacomm.PortInUseException:
port = extportinS
extportinS = port
# set options on port
baudrate = 19200
port.setSerialPortParams(baudrate,
purejavacomm.SerialPort.DATABITS_8,
purejavacomm.SerialPort.STOPBITS_1,
purejavacomm.SerialPort.PARITY_NONE)
# get I/O connections for later
inputStream = port.getInputStream()
outputStream = port.getOutputStream()
# define a turnout listener that will
class Datatransfer(java.beans.PropertyChangeListener):
# initialization
# registers to receive events
def __init__(self, id, value) :
self.name = "ST"+str(id)
self.closed = value # write this value to close
self.thrown = value # write this value to throw
turnout = turnouts.provideTurnout(self.name)
turnout.addPropertyChangeListener(self)
turnout.setCommandedState(CLOSED)
return

# on a property change event, first see if
# right type, and then write appropriate
# value to port based on new state
def propertyChange(self, event):
#print "change",event.propertyName
#print "from", event.oldValue, "to", event.newValue
#print "source systemName", event.source.systemName
if (event.propertyName == "CommandedState") :
if (event.newValue == CLOSED and event.oldValue != CLOSED) :
print "set CLOSED for", event.source.userName
outputStream.write(event.source.userName)
outputStream.write(",0")
if (event.newValue == THROWN and event.oldValue != THROWN) :
print "set THROWN for", event.source.userName
outputStream.write(event.source.userName)
outputStream.write(",1")
return
# The following will set up 5 listeners for Turnouts ST1 though ST6 (by username)
for x in range(1,6) :
Datatransfer(x,x+100)

--
Bob Jacobsen
@BobJacobsen

Re: Servos, Ardunios, and JMRI #arduino

Cliff Anderson
 

Sam,

From your original post:

Item 3. It doesn't matter which script is loaded first; the second script will stop the first script's turnouts.

This symptom is consistent with the use of the same name for what should be considered two variables.

In the text you supplied in your most recent post, it is apparent that the variables named below are overwritten by the most recently executed script file:

  • portname
  • portID
  • port
  • baudrate
  • inputStream
  • outputStream
  • class Datatransfer

and perhaps others. Only the constant for baudrate is benign in this case.

With the possible exception of the class name, all of the other variable names are shared by all of the instances of the most recent definition of the Datatransfer class that are created in the lines:

# The following will set up 5 listeners for Turnouts PT1 though PT6 (by username)
for x in range(1,6) :
    Datatransfer(x,x+100)

which appear at the bottom of both script texts. In effect, these instances will each use the most recently set values for each of the above identified variable names.

If these are correct copies of your scripts, It is my understanding that these lines set up duplicate copies of Turnouts PT1 through PT6.

If my understanding of these lines is correct, either script would only connect with what JMRI labels as turnouts with systemName choices PT1 though PT6. Did you in fact receive state change information concerning either set of your yard turnouts but using the same JMRI systemNames?

The original structure of the class definition in TurnoutDataTransfer.py does not lend itself to easy modification to multiple input-output connections to separate Arduino devices.

My preference would be to define a more robust class with a separate groupings of instances for each Arduino. But without the hardware resources to test with at least three Arduino devices it is not prudent for me to make such an attempt. In no case would I recommend executing two script files that define copies of the same class, but that is moot here.

In your case, the quick and dirty method to simply modify all of the variable names, other than the baudrate, as you have already done for a few variables might prove to be sufficient. It would not be surprising if you chose this path.

It would be prudent to review the tutorial at https://docs.python.org/3/tutorial/classes.html and in particular the section 9.2 "Python Scopes and Namespaces."

If indeed your plan is to consider adding numerous other controls with more variations of the script, this process could easily get both tedious and difficult to maintain.

If you wish to respond off list and are willing to put up with perhaps many iterative attempts, I could provide some help.

By the way, if you had made a subfolder in https://groups.io/g/jmriusers/files/ProblemsBeingWorkedOn with a unique identifier referencing either this problem or your name, and supplied that link in your post, I believe you would have gotten more responses from a wider source of knowledge. Only by accident did I discover your pasted text marked as "Show quoted text" which usually means previous postings in the same thread.

Cliff in Baja SoCal

Re: DP feature request

Paul Bender
 

On 07/24/2019 10:30 AM, thomasmclae wrote:
I run in several layouts.
I set up my consists to run on all these layouts without change.
SO, programming track for all consist setups.

I set up specific function settings on each Lok in each consist,
beyond what the consisting tool uses.
Consisting tools are usually layout specific, and do not carry over to
other layouts.
Just to be clear, the consisting tool I am discussing is the JMRI
consisting tool:
described here:
http://jmri.org/help/en/manual/DecoderPro3/dp3_Main_ConsistControl.shtml
and here:
http://jmri.org/help/en/package/jmri/jmrit/consisttool/ConsistToolFrame.shtml

The consist tool is and isn't layout specific.

The consist tool is layout specific in that it uses features of the
command station to setup consists.

On systems that support the concept, the consist tool support may
include command station assisted consists, which don't transfer between
systems.

When the consist tool configures an Advanced Consist, it programs that
consist into CV19 of the decoder.  Where  the system supports it, this
programming operation may use system specific methods to setup the
consist.  When the system doesn't support special commands, the consist
is created either using operations mode programming of CV19 OR by using
the NMRA Consist Creation Command.

Functionally, there is no difference in the decoder between an advanced
consist created using the consist tool and one created via the
programming track.

I set my own consists up on my home layout using the consisting tool and
move them to others and just use the consist address.

If you never run anywhere else, consisting tools can be an easy
option, but for me, those hide the consist details and options I like
to set.
Part of my proposed set of changes is to force the consisting tool to
update CV19 as it is stored in the roster file, which makes it so that
detail is more visible.

The consisting tool doesn't have the ability to modify other CVs related
to a consist because those CVs remain set even when the consist is removed.

And the ask is for an option to use the consist address in the
throttle. Let me decide if I want to use CV19 or not.
There already is the option to use the throttle with a consist address. 
You currently can only get to it through the consisting tool however.

And there is always the option of typing in either of the addresses
involved and not using the roster selection.

( I have enough Loks that rebuilding consists on the fly in not
needed. Just like the prototype!)
The prototype does build consists on the fly.  I once watched CSX swap a
locomotive from one train to another, in Thurmond,WV.  One of the
locomotives on the receiving train had died, and it didn't have enough
power to make the grade with it off line.

It is also not uncommon for the prototype to split a consist once a
train enters a yard and build a new one to handle the next train.

Paul

Re: marker / follow number of train on screen

Roger Merritt
 

    I know that the block contents tries to keep track of trains as they go around the layout.  I use Dispatcher and that puts the loco number in the block contents at the start.  Then as it moves around the transit the loco number moves to the block contents as it progresses.  I'm not sure it the panel markers are suppose to move around the panel.

Roger

Re: marker / follow number of train on screen

FCOT2002
 

Hello,

a little "up". 

no one has any idea to help me?

Re: loco assignments #operationspro

cascaderwy
 

Sorry, my question was for Dan Boudreau or one of the programmers that has history with RailOp 
I don't have my railroad tied to the computer and I don't want it to be. My understanding is to have more than one loco on a train I have to go into the train screen and consist them together. All of my trains require one loco but sometimes I need to move a switcher to a new location or move a loco from a remote location to the shops for inspection. I need to be able to add or remove locos without consisting them in the computer and be able to open the loco screen and know where every loco is. Is this doable or do I go jump in the lake and downgrade back to carcards or RailOp
Thanks
Matt Greenwood

Re: JMRI and NCE

Ken Cameron
 

Ken,

The key in either version is this:

2019-07-24 09:15:08,453 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 0 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:08,562 nce.NceConnectionStatus WARN -
Incorrect or no response from NCE command station [nce.NceTrafficController
Transmit thread]

This says the USB is not responding. We get the port open in both cases, but
no answer. So the next question is what are the jumper settings on the USB
device? All on, all off, or which? If all are on, then you need to click the
'additional info' in the connection and try 19,200 baud rate. We should be
seeing an answer that tells which version of interface you have. It should
be something like version 7.3.* or 6.3.*. If we see that message, then we
are talking to the USB device ok. If we are still having issues, then we'd
start looking at the cables and a few other settings on the command station.

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

Re: DP feature request

thomasmclae
 

I run in several layouts.
I set up my consists to run on all these layouts without change.
SO, programming track for all consist setups.

I set up specific function settings on each Lok in each consist, beyond what the consisting tool uses.
Consisting tools are usually layout specific, and do not carry over to other layouts.

If you never run anywhere else, consisting tools can be an easy option, but for me, those hide the consist details and options I like to set.
I like to use ALL the features of my decoders.

And the ask is for an option to use the consist address in the throttle. Let me decide if I want to use CV19 or not.

( I have enough Loks that rebuilding consists on the fly in not needed. Just like the prototype!)


Thomas
DeSoto, TX

Re: JMRI and NCE

Kenneth Skopp
 

Hello Ken,

Here are the JMRI 1.12 LOG and JMRI 4.16 Log.
I am a computer novice computer novice.

JMRI 1.12 Log
2019-07-24 09:14:55,777 util.Log4JUtil INFO - ******
JMRI log ******* [main]
2019-07-24 09:14:55,893 util.Log4JUtil INFO - This
log is appended to file: C:\Users\Ken\JMRI\log\messages.log [main]
2019-07-24 09:14:55,893 util.Log4JUtil INFO - This
log is stored in file: C:\Users\Ken\JMRI\log\session.log [main]
2019-07-24 09:14:55,931 apps.AppsBase INFO -
DecoderPro version 4.12+Rb6a9bb1 starts under Java 1.8.0_221 on Windows 10
x86 v10.0 at Wed Jul 24 09:14:55 EDT 2019 [main]
2019-07-24 09:14:56,580 gui3.Apps3 INFO -
Starting with profile My_JMRI_Railroad.3f3718c5 [main]
2019-07-24 09:14:57,181 node.NodeIdentity INFO - Using
jmri-kyUuSdgurhNiaayakslegv-3f3718c5 as the JMRI Node identity
[AWT-EventQueue-0]
2019-07-24 09:14:57,620 xml.AbstractSerialConnectionConfigXml INFO -
Starting to connect for "NCE" [main]
2019-07-24 09:14:58,322 usbdriver.UsbDriverAdapter INFO - NCE
USB COM4 port opened at 9600 baud [main]
2019-07-24 09:14:59,642 util.FileUtilSupport INFO - File
path program: is C:\Program Files (x86)\JMRI\ [main]
2019-07-24 09:14:59,642 util.FileUtilSupport INFO - File
path preference: is C:\Users\Ken\JMRI\My_JMRI_Railroad\ [main]
2019-07-24 09:14:59,642 util.FileUtilSupport INFO - File
path profile: is C:\Users\Ken\JMRI\My_JMRI_Railroad\ [main]
2019-07-24 09:14:59,642 util.FileUtilSupport INFO - File
path settings: is C:\Users\Ken\JMRI\ [main]
2019-07-24 09:14:59,642 util.FileUtilSupport INFO - File
path home: is C:\Users\Ken\ [main]
2019-07-24 09:14:59,642 util.FileUtilSupport INFO - File
path scripts: is C:\Users\Ken\JMRI\My_JMRI_Railroad\ [main]
2019-07-24 09:15:08,453 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 0 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:08,562 nce.NceConnectionStatus WARN -
Incorrect or no response from NCE command station [nce.NceTrafficController
Transmit thread]
2019-07-24 09:15:18,563 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 1 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:18,672 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:28,683 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 2 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:28,793 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:38,794 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 3 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:38,903 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:48,912 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 4 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:49,022 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:59,033 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 5 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:15:59,144 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]

NCE 4.16. Log
2019-07-24 09:49:05,630 util.Log4JUtil INFO - ******
JMRI log ******* [main]
2019-07-24 09:49:05,630 util.Log4JUtil INFO - This
log is appended to file: C:\Users\Ken\JMRI\log\messages.log [main]
2019-07-24 09:49:05,630 util.Log4JUtil INFO - This
log is stored in file: C:\Users\Ken\JMRI\log\session.log [main]
2019-07-24 09:49:05,646 apps.AppsBase INFO -
DecoderPro version 4.16+R6f9aced starts under Java 1.8.0_221 on Windows 10
x86 v10.0 at Wed Jul 24 09:49:05 EDT 2019 [main]
2019-07-24 09:49:05,833 gui3.Apps3 INFO -
Starting with profile My_JMRI_Railroad.3f3718c5 [main]
2019-07-24 09:49:06,271 node.NodeIdentity INFO - Using
ec72de34-6564-4ed1-ac23-2fd88a2f64bc as the JMRI storage identity for
profile id 3f3718c5 [AWT-EventQueue-0]
2019-07-24 09:49:07,208 profile.ProfileUtils INFO -
Copying from old node
"C:\Users\Ken\JMRI\My_JMRI_Railroad\profile\jmri-6002922C4195-3f3718c5" to
new node
"C:\Users\Ken\JMRI\My_JMRI_Railroad\profile\ec72de34-6564-4ed1-ac23-2fd88a2f
64bc" [AWT-EventQueue-0]
2019-07-24 09:49:07,458 xml.AbstractSerialConnectionConfigXml INFO -
Starting to connect for "NCE" [main]
2019-07-24 09:49:07,458 jmrix.AbstractSerialPortController WARN - old
profile format port speed value converted [main]
2019-07-24 09:49:07,603 usbdriver.UsbDriverAdapter INFO - NCE
USB COM4 port opened at 9600 baud [main]
2019-07-24 09:49:07,728 util.FileUtilSupport INFO - File
path program: is C:\Program Files (x86)\JMRI\ [main]
2019-07-24 09:49:07,728 util.FileUtilSupport INFO - File
path preference: is C:\Users\Ken\JMRI\My_JMRI_Railroad\ [main]
2019-07-24 09:49:07,728 util.FileUtilSupport INFO - File
path profile: is C:\Users\Ken\JMRI\My_JMRI_Railroad\ [main]
2019-07-24 09:49:07,728 util.FileUtilSupport INFO - File
path settings: is C:\Users\Ken\JMRI\ [main]
2019-07-24 09:49:07,728 util.FileUtilSupport INFO - File
path home: is C:\Users\Ken\ [main]
2019-07-24 09:49:07,728 util.FileUtilSupport INFO - File
path scripts: is C:\Users\Ken\JMRI\My_JMRI_Railroad\ [main]
2019-07-24 09:49:17,713 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 0 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:49:17,822 nce.NceConnectionStatus WARN -
Incorrect or no response from NCE command station [nce.NceTrafficController
Transmit thread]
2019-07-24 09:49:18,666 roster.LocoFile WARN - Did
not find locofile variable "Forward Motor Trim" in decoder definition, not
loading [AWT-EventQueue-0]
2019-07-24 09:49:18,666 roster.LocoFile WARN - Did
not find locofile variable "Reverse Motor Trim" in decoder definition, not
loading [AWT-EventQueue-0]
2019-07-24 09:49:27,823 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 1 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:49:27,933 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
m
2019-07-24 09:49:37,933 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 2 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:49:47,947 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AE C2 64 00 C9 06 consecutive timeouts = 3 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:49:57,957 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AE C2 64 00 C9 06 consecutive timeouts = 4 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:07,958 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AE C2 64 00 C9 06 consecutive timeouts = 5 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:17,960 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AE C2 64 00 C9 06 consecutive timeouts = 6 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:18,069 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:28,076 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 7 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:28,188 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:38,194 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 8 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:38,303 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:48,310 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 9 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:48,419 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:58,430 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 10 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:50:58,540 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:08,545 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 11 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:08,654 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:18,655 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 12 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:18,765 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:28,775 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 13 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:28,884 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:38,894 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 14 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:38,994 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:49,003 jmrix.AbstractMRTrafficController WARN -
Timeout on reply to message: AA consecutive timeouts = 15 in
nce.NceTrafficController [nce.NceTrafficController Transmit thread]
2019-07-24 09:51:49,112 nce.NceConnectionStatus WARN - No
response from NCE command station [nce.NceTrafficController Transmit thread]

-----Original Message-----
From: jmriusers@groups.io <jmriusers@groups.io> On Behalf Of Ken Cameron
Sent: Tuesday, July 23, 2019 11:21 PM
To: jmriusers@groups.io
Subject: Re: [jmriusers] JMRI and NCE

Ken S,

I think this is a direction to try.

1. First thing is cut/paste the console log from starting up with your
working 4.12 system. This gives us a baseline of your setup.
2. Make sure you open/save any panel files you are using.
3. Make a minor change in the preferences, something you can change back,
like add a startup action.
4. Those steps make sure the files are written at the 4.12 version level.
5. Update to 4.16.
6. Startup with 4.16 and cut/paste the console log. This will show what is
or isn't not happening.

Make no other changes. From this we can see the where you start and finish.
Then we can give meaningful comments.

Sometimes there are changes that make updates along the way. If someone is
jumping too many versions, the old version might not be able to be correctly
read by the new version. Making regular updates, the issue doesn't come up.
For a while a new version will still read the old version files, but it is
using old code we have replaced with new methods. Eventually we clean up
things and remove that old code. That is when somebody who didn't do
updates, and then did a load/save to save all new way entries will have an
issue. It happens very seldom, but making a few more steps here should
figure out if this is a part of your problem or if something else is
happening.

You might also use the Help->Upload Debug Info, it will send a package or
details like your profile and log files, with some system details too. That
may also give us more clues when it isn't working.

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

Re: Alternate Sections in Transits using Dispatcher

Steve_G
 

Hi Torben.
You cant actually call it a bug as it was done by design. If both the primary
and alternate are both occupied then it wants the operator to choose which will
be the next section, that is which one is it going to use next, regardless of
which one comes vacant first, this due to the way the dispatcher currently
works. The same problem occurs if manually allocating.
Steve G.

---------- Original Message ----------
From: Torben Cox <@Torben_C>
Date: July 22, 2019 at 6:39 AM


Hi - I hope someone will be kind enough to help please.

In my Transits I set up alternate Sections where available (ie for single line
coming into dual platforms for instance), and it works perfectly if one or
other of the Sections is occupied. -

However, if both Sections ahead are occupied then a window comes up asking the
user to choose a Section for the train to use. - In fact multiple windows open
for each section the train passes through on the way to the red light in front
of the 2 blocked sections. - This means that running is sadly no longer
automatic.

I don't know if anyone is actively working on Dispatcher, but it would be
wonderful if in the above scenario the train stopped and waited for one of the
two Sections ahead to become clear.

So, firstly, in case I've missed something / am being stupid (!), please could
someone confirm that I'm not doing something wrong

& Secondly, if I'm right I wonder if some kind soul could see if this could be
fixed please.

Many thanks
Torben


Pi 4 heat and cases

jimalbanowski
 

Group:

I was posting about the new Raspberry Pi 4 and heat issues... I've added a gallery and photo of a DIY 3D printed case and a commercial product.

The case came from Thingiverse though I can't link to it now, not sure just how I found it... The commercial case (Micro Connectors from MicroCenter) predates the 4 but being open on all sides the change in the Pi 4 connector arrangement won't matter. Tried to score a Pi 4 4GB too... all gone...

The printed case has a salvaged slice of CPU heatsink poking out... milled a chunk out of an old PC CPU heatsink held on with thermal compound, friction fit and glue to case top.

Jim Albanowski