This kind of operation might require thinking outside the blocks.

I’ve had small parts in the work on two different non-blocked systems for locating model-railroad rolling stock.

*) One was RPS (), which even had some JMRI support (). It used ultrasound transmitters attached to DCC decoders for location. It worked, but it required hardware on engines and cabooses, and at the time was too expensive to be popular.

*) The other, more recent one used a couple of RPi’s with high-def video cameras looking at the layout to locate trains. Stable alignment was achieved through a couple of IR LEDs (visible to the cameras, not to people) buried on the layout. It basically worked, even separating trains on adjacent tracks in yards (which can be tricky because of shadows), although getting good coverage would have required more cameras because of poor layout sight-lines. Then it went sideways as my collaborators wanted to use IR LEDs to uniquely identify engines: More engine-by-engine hardware, etc.

Neither of those projects really worked out, but either method might work with some real attention. Or there might be even better ideas!

Bob

On Aug 19, 2018, at 10:26 AM, Spuds McCat <spudsmccat@...> wrote:

The problem with multiple trolleys in sane block, us how does the computer know where to stop each one, if it's all 1 block.

Theoretically, you could have Railcom feed how many are in block, and stop with space for leading trains, but this requires all trolleys to have Railcom, and you're hoping everything stops the same way each time.

Alternative 2 is many small blocks with hidden virtual signals, so it looks the same, but many many more detectors required

Alternative 3 is use dcc car (or DC car website is broken now so can't check official name) which hacjs a decoder so each car/trolly has an IR led shining behind it, and an IR detector to the front, so it can detect what's in front if it and slow/stop without hitting.

It uses the brightness to determine now close it is and slow/ stop as appropriate

Due to having multiple trains in 1 block, i strongly suspect it'd be incompatible with Jmri automation.



On Sun, Aug 19, 2018, 08:44 Andy Reichert <andy_r@...> wrote:
Life gets even more away from US freight operations when one considers
trolley layouts, of which there a considerable and growing number in
Europe. And a few modern prototype examples in the US.

As well as being timetable driven, the case of several trolleys from the
same or different routes becoming temporarily lined up nose to tail at a
street junction traffic light, or busy passenger stop is quite common.
And that does not lend itself at all to the simple present/absent block
detection that seems to be assumed in much of the JMRI postings.

The driver centric model where the driver obeys signals and reacts to
obstructions only as observed from the cab would seem to require a lot
of autonomous processing capability in the car itself, rather than
relying entirely on sensor inputs to a central control function.

Andy

--
Bob Jacobsen
rgj1927@...

开云体育

Is there a way to use JMRI for an inventory of my Motive power, Rolling stock, and/or Structures?
Thanks,
Phil

James I suggest to have a look here
Perhaps you may find what you are looking for...
Regards

开云体育

The following is an important point.

On Aug 19, 2018, at 7:01 AM, whmvd <vandoornw@...> wrote:

Something we mustn't lose sight of, is that JMRI was conceived as a means to get to DCC control, not so much as a complete and finished product, no matter how far it has come to being just that in quite a few areas. JMRI was to be a command and control layer upon which users could build. That's certainly how I plan to use it. If, by doing so, I can eventually give something back to the community, then that would be great. Should the community be interested in what I plan to do.

Everything in JMRI is available to the hobby because (1) somebody wanted to do it, (2) did it, and (3) was willing to share it with others.

There are 280 people on the acknowledgements page () who’ve done that (and if we missed anybody, please let me know!) Together, they’ve written almost three million lines of code, decoder and signal definitions, help text, etc that together are available to people who want to use them. (In the last month, 19 authors have pushed 293 changes: ) It’s all been done incrementally, in fits and starts, with occasional blind alleys as part of multiple approaches. _That_ _approach_ _works_.

It’s great to have discussions about new features, new approaches, improved capabilities. That’s often step (0) in getting new things done, because it’s a key part of (1) somebody wanting to do it. Wide-ranging discussions often helps people get motivated about a longer-term goal.

It’s also important to (2) and (3) done. That’s where sometimes things hang up with they start off too audacious. “There’s so much here, how can I even imagine getting it done?” can make things harder. “There’s s much more to do, how can I share this now?” can prevent other people getting involved to help make faster progress.

So I encourage people with all the great ideas in this thread to make a gentle start by just turning even small starting parts into code. A bit of script here, an added method in a Java class there, and start to see how it comes together. You’ll learn a lot, most likely get a better understanding of what you’re trying to do, and possibly even find people to work with you on it.

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

(left the original post for context)

The "self.getThrottle(self.number, long)” method should only be called from within init() or handle(). It’s OK if handle() calls something that calls something that calls something that calls getThrottle(), but the start has to be in either init() or handle().

Java allows programs to work effectively in parallel using threads. When one thread is stalled waiting for something to happen, another can still run. For some (but not all) DCC systems, getThrottle() takes time because it has to negotiate with the command station. In that case, the thread that calls getThrottle will be stalled for a second or so; sometimes longer. If that’s your AbstractAutomat thread, the one with init() and handle(), no big deal: They’ll pick up where they left off eventually, and weren’t doing anything in the meantime.

However, there are other threads that are handling things like mouse clicks and cursor movements. You really don’t want to stall those. So if you start on a mouse click, and end up a getThrottle which stalls, the entire interface is going to stall. Not good, though perhaps OK if it’s fast and only occasional.

That second case, stalling the wrong thread, is what the message warns of. You’re doing getThrottle in your whenMyButtonClicked routine, which is called from a button.

A better pattern would be to just save the address and do the .start() operation, then have init() (which is called on your thread after start()) do the getThrottle.

But if it’s not broke, maybe you don’t have to fix it.

Bob

On Aug 18, 2018, at 11:26 PM, LMSFAN72 <andrew@...> wrote:

Hi

I have put together a script that shuttles a selected loco back and forth between 2 sensors a selectable number of times. The script opens a window panel to select a loco from a drop down box populated from my roster and allows the user to enter the number of back and forth (I called them loops). The window is designed to stay open so another loco can be selected when the first has finished. The window can then be closed with it's own button.

The script executes fine but I have noticed when I run the console that I get a warring message:

automat.AbrstractAutomaton WARN - getThrottle invoked from invalid context

I wonder what is causing the message, and how I might improve the code to avoid it. Outline of my code below:

import java
import javax.swing
import jarray
import jmri

class Test_Track_Shuttle(jmri.jmrit.automat.AbstractAutomaton) :

def init(self):
self.status.text = "Initiating"

# set up sensor numbers
# fwdSensor is reached when loco is running forward

# set up sensor numbers
# fwdSensor is reached when loco is running forward
self.fwdSensor = sensors.provideSensor("RH")
self.revSensor = sensors.provideSensor("LH")
# get loco address.
print ("getting throttle")
self.status.text = "Getting throttle"

return

def handle(self):

print ("Inside handle(self)")
if self.loopCnt.text == "":
Xmax = 1
else:
Xmax = int(self.loopCnt.text)
x = 1
while x <= Xmax:
loops = str(Xmax - x + 1)
print(" ".join(["Shuttle Cycles Remaining:", loops]))
# set loco to forward
print ("Set Loco Forward")
self.throttle.setIsForward(True)

# wait 1 second for layout to catch up, then set speed
self.waitMsec(1000)
print ("Set Speed")
self.throttle.setSpeedSetting(0.3)

# wait for sensor in forward direction to trigger, then stop
print ("Wait for Forward Sensor")
self.waitSensorActive(self.fwdSensor)
print ("Set Speed Stop")
self.throttle.setSpeedSetting(0)

# delay for a time (remember loco could still be moving
# due to simulated or actual inertia). Time is in milliseconds
print ("wait 20 seconds")
self.waitMsec(20000) # wait for 20 seconds

# turn on whistle, set direction to reverse, set speed
self.throttle.setF3(True) # turn on whistle
## self.waitMsec(1000) # wait for 1 seconds
## self.throttle.setF3(False) # turn off whistle
## self.waitMsec(1000) # wait for 1 second

print ("Set Loco Reverse")
self.throttle.setIsForward(False)
self.waitMsec(1000) # wait 1 second for Xpressnet to catch up
print ("Set Speed")
self.throttle.setSpeedSetting(0.3)

# wait for sensor in reverse direction to trigger
print ("Wait for Reverse Sensor")
self.waitSensorActive(self.revSensor)
print ("Set Speed Stop")
self.throttle.setSpeedSetting(0)

# delay for a time (remember loco could still be moving
# due to simulated or actual inertia). Time is in milliseconds
print ("wait 20 seconds")
self.waitMsec(20000) # wait for 20 seconds

# turn on whistle, set direction to forward, set speed
self.throttle.setF3(True) # turn on whistle
## self.waitMsec(1000) # wait for 1 seconds
## self.throttle.setF3(False) # turn off whistle
## self.waitMsec(1000) # wait for 1 second

# and continue around again
x = x+1
# release when done
## self.throttle.release()
## self.throttle = None
#re-enable button
self.startButton.enabled = True
print ("End")
return 0 # handle() is called repeatedly until it returns false.



def doClose(self, event):
print("Close")
# **** close command here ****
self.f.setVisible(False)
self.f.dispose()
self.stop()

def setup(self):
print ("Setup")
global theDCCAddress
self.f = javax.swing.JFrame("Barn Loop Automated Control",preferredSize = (600,280))
self.f.contentPane.setLayout(javax.swing.BoxLayout(self.f.contentPane,javax.swing.BoxLayout.Y_AXIS))
self.f.setDefaultCloseOperation(javaxswing.JFrame.DO_NOTHING_ON_CLOSE)
self.f.setLocationRelativeTo(None)
relButton = javax.swing.JButton("CLOSE WINDOW")
relButton.actionPerformed = self.doClose

# top explanatory panel, text only
temppanel0 = javax.swing.JPanel()
temppanel0.add(javax.swing.JLabel("<html>Select your locomotive from the roster, or type in the address in the box.<br> Then press start button.</html>"))
temppanel0.add(relButton)

# second panel has a label, then drop box and text field.
temppanel1 = javax.swing.JPanel()
temppanel1.add(javax.swing.JLabel("Locomotive "))
temppanel2 = javax.swing.JPanel()
temppanel2.add(javax.swing.JLabel("Number of Shuttles "))

# create the drop-box from the roster,
# getEntriesWithAttributeKeyValue(String key, String value)
self.roster = jmri.jmrit.roster.Roster.getDefault()
self.box = jmri.jmrit.roster.swing.GlobalRosterEntryComboBox()
self.box.itemStateChanged = self.rosterBoxChange

# create the text field
self.address = javax.swing.JTextField(5)
# create field for loop count
self.loopCnt = javax.swing.JTextField(5)

# Read the first entry from the roster drop box and write its DccAddress to the address box.
entry = self.roster.entryFromTitle(self.box.getSelectedItem())
if( entry != None ) :
theDccAddress = entrygetDccAddress()
self.address.text = theDccAddress

# create the start button to perform actions.
self.startButton = javax.swing.JButton("Start")
self.startButton.actionPerformed = self.whenMyButtonClicked

# add the drop-box, address field, and start button to the panel
temppanel1.add(self.box)
temppanel1.add(self.address)
temppanel1.add(self.startButton)
temppanel2.add(self.loopCnt)

# Create a status line
self.status = javax.swing.JLabel("Waiting for Locomotive")

# Put contents in frame and display
self.f.contentPane.add(temppanel0)
self.f.contentPane.add(temppanel1)
self.f.contentPane.add(temppanel2)
self.f.contentPane.add(self.status)


self.f.pack()
self.f.show()
## self.start()
return

def whenMyButtonClicked(self,event) :
if (self.number > 127) :
long = True
else :
long = False
self.throttle = self.getThrottle(self.number, long)
if (self.throttle == None) :
print ("Couldn't assign throttle!")
self.status.text = "no throttle"


self.start()
# we leave the button off
self.startButton.enabled = False
return

# routine to show the panel, starting the whole process
def rosterBoxChange(self, event) :
entry = self.box.getSelectedItem()
if isinstance(entry, jmri.jmrit.roster.RosterEntry):
theDccAddress = entry.getDccAddress()
# print theDccAddress
self.address.text = theDccAddress
else:
self.address.text = ""
theDccAddress = 3
try:
self.number = int(self.address.text)
except ValueError:
self.number = 3
print (self.number)

return 0



a = Test_Track_Shuttle()
a.setName("Test Track Shuttle")
a.setup()

--
Bob Jacobsen
rgj1927@...

Life gets even more away from US freight operations when one considers trolley layouts, of which there a considerable and growing number in Europe. And a few modern prototype examples in the US.

As well as being timetable driven, the case of several trolleys from the same or different routes becoming temporarily lined up nose to tail at a street junction traffic light, or busy passenger stop is quite common. And that does not lend itself at all to the simple present/absent block detection that seems to be assumed in much of the JMRI postings.

The driver centric model where the driver obeys signals and reacts to obstructions only as observed from the cab would seem to require a lot of autonomous processing capability in the car itself, rather than relying entirely on sensor inputs to a central control function.

Andy



On 8/19/2018 7:01 AM, whmvd wrote:

Thank you for the insights into how you look at time-tabling! It confirms what I thought, which is that there are many different and valid ways to look at it, and a one-solutio-fits-all approach is never going to happen. Because apart from the differences in the way people might want the automation via timetables to work, there is also the complication of layouts being wired and divided in blocks and fitted with signalling in wildly differing ways. Add to that decoder programming that can be of serious impact to automation, and the spectrum becomes nearly endlessly wide. Bringing it *all* together is not, I think, feasible - and that is what makes a generic JMRI time-table solution almost a non-starter. I'd love to be wrong, though.

My own thoughts would go along the lines of
- unity in decoder programming - certain speed steps are known to correspond to certain scale speeds (not everyone will want to do this)
- uncoupling of locos required as a loco function (mine are servo controlled)
- trains would have a real driver or an automated one, both always watching signals and responding. So the signal controls movement, as opposed to the more usual 'show green if the blocks ahead are free'.
- Here's the nub: the time-table would control *just* signals. The driver reacting to them.
- All blocks need detection.
- Signalling must be complete (virtual signals if nothing else).

The train driver would become a new Java class in JMRI, needing awareness of 'its' engine, and the signals in sight. Also knowledge of max speeds and track conditions along the way (just like a real one), and of the timetable he is supposed to adhere to. A user could take over the role of a driver for manual operation of any engine.

The time table would be a sequential list of actions a driver needs to take. Another JMRI object would read this, and set the signals. The actions in the time table would be pretty detailed; much more than leave this station at that time, next station at that time, arrive at destination. It would need to be a list of things the (automated or not) driver could do. The driver would 'know' the technicalities involved in obeying the instruction, taking into account the engine concerned. Instructions could be things like 'depart to ...', 'uncouple', 'limit speed to ...' - but not 'sound horn', which would be part of the driver's track knowledge.

So that's how I see the separation of responsabilities over Java classes/objects. It would probably work for me, and not for most others. It would, however, be reasonably layout-independent, and involve no scripting. I'm not too fond of scripting as an interface to JMRI.

Something we mustn't lose sight of, is that JMRI was conceived as a means to get to DCC control, not so much as a complete and finished product, no matter how far it has come to being just that in quite a few areas. JMRI was to be a command and control layer upon which users could build. That's certainly how I plan to use it. If, by doing so, I can eventually give something back to the community, then that would be great. Should the community be interested in what I plan to do.

At the moment, I haven't even got my layout yet. But I plan to build it in a way that will allow me to work on this time-table project. Don't know if I can finish it this century, of course...

Wouter

On 19 August 2018 at 12:19, jamespetts via Groups.Io <jamespetts@... <mailto:jamespetts@...>> wrote:

Unless I have missed something in this thread, the impression that
I am getting is that timetables are not a built-in function of
JMRI at all (with the possible exception of the schedules in
Operations, but this seems to be aimed specifically and
exclusively at U. S. style freight operations). It appears (unless
I have missed something important, in which case I should be very
grateful if someone could bring this to my attention, as obtaining
this information was one of the main purposes of me starting this
discussion) that it is necessary for anyone wishing to use JMRI
with timetables to code this entire functionality from scratch
using Jython scripts.

Somebody already appears to have done this with a script called
"AutoDispatcher 2", which is available from the JMRI script
examples download page. Unfortunately, no documentation of any
sort appears to be available for this, so the only way of using
this would be to read the code and try to infer how it works from
that.

"AutoDispatcher 2" is quite an extensive script and amounts to a
substantial piece of code in and of itself. It includes a large
amount of code for parsing timetables in a text format (no
documentation is given as to what this format is, but one could,
if one were willing to spend a considerable amount of time, infer
this from reading the code).

Unless I am missing something (and please let me know if I am), it
seems that what would be needed for timetable operation is a
script that could do at least all of the following things:

1. parse a text/XML/etc. file timetable and/or provide for a UI
for users to type in and edit their timetable inside JMRI;
2. either implement or use the apparently existing but so far as
I can find out entirely undocumented block tracking feature in
JMRI to keep a track of specifically which train is in which
block as they move around the layout;
3. provide some user interface for users to input the initial
details of the trains in each block (and optionally allow for
this to be done automatically by reporters (e.g. RailCom));
4. provide an abstraction layer (which I call "diagrams" above)
in which users can specify (and provide a UI or text/XML/etc.
format and write code to parse this) what a particular train
does when it runs a particular timetabled working (e.g., use
transits no. 3, 4, 7, 9 and 12 in that order, or
alternatively, perhaps, interface with NX logic in specific
ways to provide a particular path);
5. provide within the diagrams abstraction layer for trains to
have timetabled stopping points during their diagrammed
working so that trains operating the diagram do not resume
from specified stopping points until a specific timetabled point;
6. provide another abstraction layer (described in an earlier
post as a "working") for a specific instance of a train
running to a particular diagram at a particular time;
7. provide code for the relationship between the data structure
representing the timetable in memory and the workings (e.g.,
the timetabled starting time of working no. 23 of diagram no.
7 is 1515h in the JMRI internal clock; use a listener to check
for this clock time and then call the code for the beginning
of a diagrammed working at this time with the data specific to
working no. 23 of diagram 7);
8. provide logic for determining which specific train is to run
any specific working (this could be fairly simple but
inflexible, e.g., a system in which users input the specific
throttle ID of the locomotive in question manually to
associate with each working number, or much more
sophisticated, allowing more flexible and realistic
operations, involving complex logic with an abstraction layer
of "formations" as discussed above and complex logic to choose
which one to start use for any given working and handling the
fact that the block in which these start may not be
deterministic at the time of writing the code);
9. provide logic dealing with what happens if a train is late or
no train/formation matching the description in the timetable
is either on the layout at all or is available (i.e., is not
on another working at the time - this involves logic to keep
track of which trains are and are not available), and possibly
UI elements to alert the user about when this happens; and
10. provide logic allowing for a sensible way of dealing with
reaching the end of a timetable (e.g., allow for starting at
the beginning, stopping operations, moving to a different
timetable stored somewhere else (in which case, code for
keeping track of different timetables and finding the
appropriate next timetable would need to be written).


These are just the essentials. Much more complex logic
(interacting with many of the elements above, making each of those
elements considerably more complex) would be needed if one were to
want to have optional partial manual intervention for either
signalling/dispatching or driving (and, if for both, doubly
complex), or if one were to want to have a means of automated
shunting on the layout (in which case a whole abstraction layer
representing individual unpowered vehicles and logic for
coupling/uncoupling them and keeping track of whether they are
actually coupled/uncoupled on the layout would be necessary, as
well as a way of integrating that abstraction layer with all of
the logic above).

Unless I have missed something (in which case, I should be
extremely grateful for the details), JMRI, whilst clearly very
capable in many respects, does not have any of the above features
(or functionally equivalent features) built-in, and these would
need to be coded in a script to allow for timetabled functionality
to be set up on any given layout by just entering data rather than
writing code.

What I understand that most people who want automatic operation
with JMRI do is, rather than write general code of the above sort
and then implement it in JMRI with data in the form of a timetable
which can easily be changed, instead write a procedural script
specific to both layout and timetable. So, for example, instead of
writing a text/XML/etc. file with a diagram of movements
identified by layout data and then setting times for each workings
of that diagram in the same way, they might write a script with a
whole sequence of very specific commands as to what should happen
in JMRI and on the layout (e.g., move train no. 15 from block A to
block C at internal time 1515h; when train no. 15 has reached
block C, move train no. 19 from block D to block E, etc.), which
would require re-programming the script if any changes were to be
made to the timetable or layout and would probably require the
layout to be in a very specific starting state as regards the
position of rolling stock for it to work. (I do not know for sure
how these scripts actually work because I have not seen one, but I
am inferring how they are likely to work from discussion on this
topic and elsewhere).

These procedural scripts are easier to code individually than the
logic necessary for generalised timetabled operations as described
above, but lots of people coding lots of procedural scripts like
this takes vastly more time collectively than somebody writing the
general logic described above once and for all, and then everybody
else using what has already been written by just adding data for
their own layouts (and possibly enhancing the script and sharing
the enhanced script if any deficiencies are found). If
"AutoDispatcher 2" were better documented, it might well be
possible to use this as a starting point, but, without
documentation, it would require almost as much effort to work out
what it does and how it does it as to code this in the first
place, which effort may then turn out to be wasted if it
transpires that this script is not robust or flexible enough.

Providing for this sort of functionality in a script seems to me
to be sub-optimal: ideally, timetable capabilities would be a core
part of the program itself. Indeed, this is what OperationsPro
appears to be intending to do, but, from what I can discern, it is
very narrowly focussed on the types of operations for which it is
designed. Because of this, I have not looked in detail at is
capabilities.

For my own part, because I do not consider that, for my purposes,
a procedural approach would be workable (owing to the complexity
of the layouts and timetables that I am wanting to run, which
would make a procedural system unmaintainable and lacking in
robustness; it would work much better in a simpler case), and
because of the amount of work that would be involved in coding
(and, more importantly debugging) general purpose timetable logic
as described above, I am currently leaning towards using
Traincontroller for my own layouts. When I was first looking into
this topic, there were quite a few people who were recommending
Traincontroller over JMRI for the sort of timetabled operations
that I was interested in and stating in quite general terms that
it would take more work to achieve this in JMRI. I should have
found it very useful then to have known the specifics that I set
out above, as "more work" can mean a lot of different things. It
turns out that "more work" means writing timetabling capabilities
more or less from scratch.

I do not mean by any of this to be unkind to the dedicated people
who write and maintain JMRI in their spare time for free. I
develop open source software in my spare time myself
(Simutrans-Extended, in case anyone is interested, as it is
somewhat relevant to peoples' interests here), and I know that
lack of coding resources holds back a myriad desirable features.
Clearly, JMRI is good software and is suitable and very useful for
a whole range of things. However, unless I am missing something,
it seems at present as though having robust generalised
timetabling requires writing in a script code in amount and
complexity comparable to an entire non-trivial software
application, which is a bit much for someone who simply wants to
get a layout or two going, even someone who develops (a fork of) a
C++ open source game in his spare time.

---
This email has been checked for viruses by AVG.

Paul, ? Have put my panel in the Files area for you to look at. I guess that what you are really saying is that if the system recovers and doesn't grind to a holt its OK.? I will add the remaining logix and put it to the test!?
Many thanks,
Alan?

I would like to have the ditch lights be on going forward and be able to flash when F2 is pressed.
Currently they always flash going forward.
Function mapping has F1 both checked and F2 is unchecked.
Lights have them as Right or Left Ditch light and On forward with Function on.
Thanks, ILH

Alan,

On Aug 19, 2018, at 6:26 AM, Alan Gibbs <buggydriver17@...> wrote:
The adapter and PC are both ethernet connected to a tp-link10/100 desktop switch by short cables, the switch is connected to the router by a good quality ethernet cable about 40 mtrs long. I can't see anything wrong here.

I don’t think there is anything wrong there. It is really hard to eliminate all possible sources of interference and data corruption which is why we implement the automatic recovery process for communication errors.

I have factory reset the adapter and set up a small table with 5 logix's which control signals, which are disabled at start up. After opening the program and operating a few turnouts from the layout diagram the are no errors on the console. Enable the 5 logix and return to the console shows:-
audio.JoalAudioFactory INFO - Initialised ………
jmrix.AbstractMRTrafficController ERROR - Automatic recovery from error message.....

I then operated a turnout (twice) which is in a logix and got 9 errors !
Repeating this causes errors about 40% of the time so the errors build up rapidly on the console.

JMRI is doing what it is supposed to do here. It is recovering when the interface detects an error.

Send me a copy of the panel file and I will see if there is anything in the panel that could be contributing to the number of repeated messages you are seeing.

I suspect that operating that turnout generates a disproportionately large number of XPressNet messages when the logix is enabled.

I look forward to your response but wonder if I'd be better off using a USB adapter ?

Perhaps, but unless the recovery is impacting performance, you aren’t going to see any difference.

I have found the Ethernet interface is generally the most reliable interface to Lenz systems, especially with Windows machines.

Paul

Unless I have missed something in this thread, the impression that I am getting is that timetables are not a built-in function of JMRI at all (with the possible exception of the schedules in Operations, but this seems to be aimed specifically and exclusively at U. S. style freight operations). It appears (unless I have missed something important, in which case I should be very grateful if someone could bring this to my attention, as obtaining this information was one of the main purposes of me starting this discussion) that it is necessary for anyone wishing to use JMRI with timetables to code this entire functionality from scratch using Jython scripts.

Somebody already appears to have done this with a script called "AutoDispatcher 2", which is available from the JMRI script examples download page. Unfortunately, no documentation of any sort appears to be available for this, so the only way of using this would be to read the code and try to infer how it works from that.

"AutoDispatcher 2" is quite an extensive script and amounts to a substantial piece of code in and of itself. It includes a large amount of code for parsing timetables in a text format (no documentation is given as to what this format is, but one could, if one were willing to spend a considerable amount of time, infer this from reading the code).

Unless I am missing something (and please let me know if I am), it seems that what would be needed for timetable operation is a script that could do at least all of the following things:

1. parse a text/XML/etc. file timetable and/or provide for a UI for users to type in and edit their timetable inside JMRI;
2. either implement or use the apparently existing but so far as I can find out entirely undocumented block tracking feature in JMRI to keep a track of specifically which train is in which block as they move around the layout;
3. provide some user interface for users to input the initial details of the trains in each block (and optionally allow for this to be done automatically by reporters (e.g. RailCom));
4. provide an abstraction layer (which I call "diagrams" above) in which users can specify (and provide a UI or text/XML/etc. format and write code to parse this) what a particular train does when it runs a particular timetabled working (e.g., use transits no. 3, 4, 7, 9 and 12 in that order, or alternatively, perhaps, interface with NX logic in specific ways to provide a particular path);
5. provide within the diagrams abstraction layer for trains to have timetabled stopping points during their diagrammed working so that trains operating the diagram do not resume from specified stopping points until a specific timetabled point;
6. provide another abstraction layer (described in an earlier post as a "working") for a specific instance of a train running to a particular diagram at a particular time;
7. provide code for the relationship between the data structure representing the timetable in memory and the workings (e.g., the timetabled starting time of working no. 23 of diagram no. 7 is 1515h in the JMRI internal clock; use a listener to check for this clock time and then call the code for the beginning of a diagrammed working at this time with the data specific to working no. 23 of diagram 7);
8. provide logic for determining which specific train is to run any specific working (this could be fairly simple but inflexible, e.g., a system in which users input the specific throttle ID of the locomotive in question manually to associate with each working number, or much more sophisticated, allowing more flexible and realistic operations, involving complex logic with an abstraction layer of "formations" as discussed above and complex logic to choose which one to start use for any given working and handling the fact that the block in which these start may not be deterministic at the time of writing the code);
9. provide logic dealing with what happens if a train is late or no train/formation matching the description in the timetable is either on the layout at all or is available (i.e., is not on another working at the time - this involves logic to keep track of which trains are and are not available), and possibly UI elements to alert the user about when this happens; and
10. provide logic allowing for a sensible way of dealing with reaching the end of a timetable (e.g., allow for starting at the beginning, stopping operations, moving to a different timetable stored somewhere else (in which case, code for keeping track of different timetables and finding the appropriate next timetable would need to be written).

These are just the essentials. Much more complex logic (interacting with many of the elements above, making each of those elements considerably more complex) would be needed if one were to want to have optional partial manual intervention for either signalling/dispatching or driving (and, if for both, doubly complex), or if one were to want to have a means of automated shunting on the layout (in which case a whole abstraction layer representing individual unpowered vehicles and logic for coupling/uncoupling them and keeping track of whether they are actually coupled/uncoupled on the layout would be necessary, as well as a way of integrating that abstraction layer with all of the logic above).

Unless I have missed something (in which case, I should be extremely grateful for the details), JMRI, whilst clearly very capable in many respects, does not have any of the above features (or functionally equivalent features) built-in, and these would need to be coded in a script to allow for timetabled functionality to be set up on any given layout by just entering data rather than writing code.

What I understand that most people who want automatic operation with JMRI do is, rather than write general code of the above sort and then implement it in JMRI with data in the form of a timetable which can easily be changed, instead write a procedural script specific to both layout and timetable. So, for example, instead of writing a text/XML/etc. file with a diagram of movements identified by layout data and then setting times for each workings of that diagram in the same way, they might write a script with a whole sequence of very specific commands as to what should happen in JMRI and on the layout (e.g., move train no. 15 from block A to block C at internal time 1515h; when train no. 15 has reached block C, move train no. 19 from block D to block E, etc.), which would require re-programming the script if any changes were to be made to the timetable or layout and would probably require the layout to be in a very specific starting state as regards the position of rolling stock for it to work. (I do not know for sure how these scripts actually work because I have not seen one, but I am inferring how they are likely to work from discussion on this topic and elsewhere).

These procedural scripts are easier to code individually than the logic necessary for generalised timetabled operations as described above, but lots of people coding lots of procedural scripts like this takes vastly more time collectively than somebody writing the general logic described above once and for all, and then everybody else using what has already been written by just adding data for their own layouts (and possibly enhancing the script and sharing the enhanced script if any deficiencies are found). If "AutoDispatcher 2" were better documented, it might well be possible to use this as a starting point, but, without documentation, it would require almost as much effort to work out what it does and how it does it as to code this in the first place, which effort may then turn out to be wasted if it transpires that this script is not robust or flexible enough.

Providing for this sort of functionality in a script seems to me to be sub-optimal: ideally, timetable capabilities would be a core part of the program itself. Indeed, this is what OperationsPro appears to be intending to do, but, from what I can discern, it is very narrowly focussed on the types of operations for which it is designed. Because of this, I have not looked in detail at is capabilities.

For my own part, because I do not consider that, for my purposes, a procedural approach would be workable (owing to the complexity of the layouts and timetables that I am wanting to run, which would make a procedural system unmaintainable and lacking in robustness; it would work much better in a simpler case), and because of the amount of work that would be involved in coding (and, more importantly debugging) general purpose timetable logic as described above, I am currently leaning towards using Traincontroller for my own layouts. When I was first looking into this topic, there were quite a few people who were recommending Traincontroller over JMRI for the sort of timetabled operations that I was interested in and stating in quite general terms that it would take more work to achieve this in JMRI. I should have found it very useful then to have known the specifics that I set out above, as "more work" can mean a lot of different things. It turns out that "more work" means writing timetabling capabilities more or less from scratch.

I do not mean by any of this to be unkind to the dedicated people who write and maintain JMRI in their spare time for free. I develop open source software in my spare time myself (Simutrans-Extended, in case anyone is interested, as it is somewhat relevant to peoples' interests here), and I know that lack of coding resources holds back a myriad desirable features. Clearly, JMRI is good software and is suitable and very useful for a whole range of things. However, unless I am missing something, it seems at present as though having robust generalised timetabling requires writing in a script code in amount and complexity comparable to an entire non-trivial software application, which is a bit much for someone who simply wants to get a layout or two going, even someone who develops (a fork of) a C++ open source game in his spare time.

Hi Petr


Earlier versions of Java (up to 1.6) did not have very good facilities for rotating images, so the JMRI code is not able to rotate animated .gifs while retaining the animation (what you get is quite random unfortunately ranging from the front image to blank). The currently used Java version (1.8) does have some improved image rotating capability - but it requires someone with suitable knowledge and time to re-write the JMRI rotation code to use the features in the newer Java versions.


Some signal systems have alternative non-animated graphics which can be used instead when the images are rotated.


Suzie x

Paul,
? ? ? ? ? The adapter and PC are both ethernet connected to a tp-link10/100 desktop switch by short cables, the switch is connected to the router by a good quality ethernet cable about 40 mtrs long. ? I can't see anything wrong here.

Also I disconnected all other ethernet connections on the router but this has no effect on the errors.

I have factory reset the adapter and set up a small table with 5 logix's which control signals, which are disabled at start up.? After opening the program and operating a few turnouts from the layout diagram the are no errors on the console. ? Enable the 5 logix? and return to the console shows:-
audio.JoalAudioFactory ? ? ? ? ? ? ? ? ? ? INFO - Initialised ………
jmrix.AbstractMRTrafficController ?? ERROR - Automatic recovery from error message.....

I then operated a turnout (twice) which is in a logix and got 9 errors !
Repeating this causes errors about 40% of the time so the errors build up rapidly on the console.
I look forward to your response but wonder if I'd be better off using a USB adapter ?
Regards,
Alan

Hi

I have put together a script that shuttles a selected loco back and forth between 2 sensors a selectable number of times. The script opens a window panel to select a loco from a drop down box populated from my roster and allows the user to enter the number of back and forth (I called them loops). The window is designed to stay open so another loco can be selected when the first has finished. The window can then be closed with it's own button.

The script executes fine but I have noticed when I run the console that I get a warring message:

automat.AbrstractAutomaton ? ?WARN - getThrottle invoked from invalid context

I wonder what is causing the message, and how I might improve the code to avoid it. Outline of my code below:

My apologies for not signing the above entry. ?Hit “send” to toon.

Phil

开云体育

James,

The NX sensors are internal sensors. They are used to setup routes.

Take a look at the demo at /g/jmriusers/files/ProblemsBeingWorkedOn/dsand/NX%20Demo.xml

The icons with > or < are the NX icons. The arrows indicated which direction the icon supports.

There is some support for Logix and script access.


Dave Sand