开云体育

Ok I'll give it a try it will take some time to make the changes I need to work through several trains to be able to set it up and see what happens
Thanks
Matt Greenwood

On Sat, Jul 20, 2019 at 04:42 AM, <fcot2002@...> wrote:

I saw somewhere, but I couldn't find, the possibility of displaying the train name/number on the screen.

?

I tried with the markers but it doesn't follow the train on the screen.

I saw your question but did not know exactly what you're trying to do.? My guess was you wanted to have the train markers on a Layout Editor panel show up automatically and move when the train was detected (after being moved), and that is way above my pay grade.

However, if you merely want an opportunity to show markers on a Layout Editor panel and move them by clicking on a conductor's Move button (if the Trains are built and coordinates added to the Train Route so the marker can be placed in the correct location on the Panel for the station it is at), that is a different animal.? For example, I have built Panels to allow me to indicate what section of track is occupied (red) and by what train(s) (using memory variables), but it has to be manually kept current.? I have also built panels that move a marker on a Layout Editor panel (to the next location on the Route) by clicking on the Conductor's "Move" button in Ops.

So, whichever way you were thinking, please clarify and someone can respond with more authority.

Phil in gorgeous Young Harris, Georgia, USA

Yes, your manifest and switch lists will be updated.

Dan

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

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

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

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 <gbglacier@...> 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
rgj1927@...

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 <gbglacier@...> 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
rgj1927@...

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

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

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.



Dan

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

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
rgj1927@...

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 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 /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

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:

and here:


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

? ? 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

Hello,

a little "up".?

no one has any idea to help me?

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

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

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