On Dec 18, 2018, at 10:42 AM, Iain <iain@...> wrote:

Dave,

I have spent some time with your program and have come to understand it.

It's about 20 years since I last wrote programs and the facilities of the languages have changed dramatically. I would never have worked out how to get input via rolling selection lists.

I have made a couple of changes in order to get raw times and times in Excel format (that is where the time is a fraction of 1 or 1*(time in mins/1440). I am now looking at getting trains sorted by start times (ultimately by a specified station departure time) in order to produce "printed" timetable data.

It's all very interesting, and I am glad I have a decent editor which keeps me clear on required indentations!

Thanks for getting me started.

On Dec 18, 2018, at 8:49 AM, Don Weigt <dweigt47@...> wrote:

On my physical control panels, I've always placed LED indicators for train photodetectors along the centerline of the track. This divided the line representing the track into many small segments, with the LEDs between. I had 24 photodetectors spaced along each of two blocks (27 feet/8m) in a hidden staging area. With DCC and these detectors, I previously staged two or three trains on each long block. I'm reconstructing my railroad in our new home. It will use the same hidden staging area.

I'm just learning how to use Layout Editor. This conversation makes it seem I won't be able to represent my track and photodetectors the same way with LE, that I will need to have the sensor indicators alongside the track symbol, not in it. If interrupted by sensor indicators, each of those blocks would be shown as 24 short line segments separated by indicators. I think that graphic representation would require each short segment to be connected to a pair of end points. If so, could multiple segments of that sort be assigned to the same block? Or, is there a workaround? Could I name them 1a, 1b, 1c, and so on, and have them share power control and a single current based occupancy detector?

Don Weigt

On Dec 17, 2018, at 12:36 PM, Dave Sand <ds@...> wrote:

Iain,

The 24/0 wrap is caused by not having a defined wait time that spans the 24 to 0 time period. As indicated in the help document, this is required to prevent strange issues like you see.

For your data output you need to think of a 5x50 grid. You need to account for every cell in the grid. If a train does not have a stop at a station, that grid cell needs to be “empty”. Since there are arrive and depart times, maybe the grid is 5x100. The other thing to keep in mind is that some trains run from station 1 to station 5 AND other trains run from station 5 to station 1.

The easiest solution is to export the data using a CSV (comma separated values) file. This is actually on my TODO list.

In the meantime, I will create a python version. The rows will be station and train arrive and depart times are the columns.


Dave Sand

On Dec 17, 2018, at 11:42 AM, Iain <iain@...> wrote:

Dave,

I have spent many hours entering my data into Timetable for the Ullapool - Lochinver segment. That is 5 stations and some 50 or so trains. I have put the data file into the problems list if you want to look at it. The graph output is interesting in that the 24hr to 0hr wrap-round goes right across the page.

I have taken your code fragment and produced this:

import java
import jmri

# Get the Timetable data manager
tdm = jmri.jmrit.timetable.TimeTableDataManager.getDataManager();


for stop in tdm.getStops(0, station.getStationId(), False):
train = tdm.getTrain(stop.getTrainId())
print train, stop.getArriveTime()

Which lists for one station (Lochinver) the UNSORTED arrival (and departure by coincidence) time of all trains at that station.

What I need is to produce an output (table/matrix) something like:
station 1 station 2 station 3 station 4 station 5
train 1 arr dep arr dep
train 2
train 3
etc

Which when inverted would produce a timetable for the line. I don't need the station names of course.

There is a snag since there are more trains between stations 1 and 2 than the other stations. I am not sure how that gets dealt with?

If I wanted to graph it I would need to output station-no train time pairs for the y/x axes:

train1 station-no arr-time station-no dep time station-no arr-time station-no dep time etc......
train2
train3
etc.

On 18 Dec 2018, at 7:16 AM, Ken Cameron <kcameron@...> wrote:

The other speed have been proved to overrun the command station. Jim even
proved this a couple of years ago and so we dropped the other speeds as they
will lead to dropped command bytes if the command station gets busy. By
design, the command station should always be able to service the uart within
the time of one 9600 byte.