Hi,
I have a couple of panels with the, apparently older, SSL type signaling logic set up. Works OK for just running trains around manually. In looking at the instructions for signal masts and signal mast logic there was a statement to not use SSL and Signal mast constructs in the same panel. So if I want to use Dispatcher for example do I need to delete the SSL content?
Thanks,

Allen

Steve,

thank you for your reply. To answer your question, the current version of the trackplan for one of the two layouts that I am planning to build (and the one that I am currently planning to build first) is . For reference, tracks in various shades of green are fiddle/staging yards; tracks in white are main line and tracks in red are yards/sidings in the scenic area, mainly carriage sidings.

The complexity that requires abstraction is not so much the pathfinding as the relationship between a timetable (existing as a dataset apart from any specific code anywhere) and actually selecting specific trains to run particular transits, etc. at specific times.

How did you set up AutoDispatcher - do you have any documentation for this? It would be very useful to know more about its capabilities.

Having spent some time just now considering the Traincontroller documentation, it does appear to have support for precisely what I want to achieve in terms of abstraction and automation (pick one train from a set of trains starting in one of a set of starting blocks, travel to an end block, and be able to select that set of things to occur at specific times and/or repeat at specific intervals by way of user interface entries), but at the cost of an awful user interface, being not open source and having to use Windows, as well as a non-trivial financial cost.

I am interested that somebody has written something in Jython to achieve something apparently similar to what I am after, although it would be a great shame if this were never to be made public, as it would be of great use. The reasons for not making something like this public are usually either: (1) it has lots of code that is only relevant to the specific user/coder and is not very portable; (2) the coder does not consider it of good enough quality to make public; or (3) the coder wishes to be able to sell it commercially one day.

In any event, I should be interested to learn more about this script.

Forgot to mention, Jason Janzen added a layer on top of Dispatcher using jython that might be very similar to what you're wanting to do. I don't think he ever made that effort public, but perhaps he could give you some advice.
--SteveT

James,
I have used AutoDispatcher to schedule and run 40+ trains at a "museum" a couple of years ago. I now use Dispatcher to run 5 trains on my small home layout. Both required considerable investment in time to understand fully, and both required extremely solid physical setup (trains, track, turnout control, detection, etc.).
AD is probably closer to what you desire, as you tell it when and where you want to go and the code finds the best path based on current occupancy, etc.
I've not used TC, but I've seen it in effective use. My take is that it limits the flexibility of the "panel" so that the routing logic becomes easier. Not a bad compromise if true. Of course, considerable time investment is required with that tool as well.

Regarding "abstracting" out the scheduling and running, I'd be very interested to see your track plan. In practice, there just aren't that many ways to get "there" from "here" on most model layouts. So things like transits become much less of an issue than they seem at first. With both of my tools, most of the "trick" is collision-avoidance, not routing and scheduling.

--SteveT

Thank you all for your replies - that is most helpful. I take it that nobody knows how AutoDispatcher 2 works or what its capabilities are? I have found a discussion about it on the JMRI Developers mailing list , but that refers to some documentation that I cannot find and dates from 2008, whereas the latest revision of that script is in 2011.

In relation to the abstract question of abstractions (!), the issue is, I think, that writing fully procedural logic for a non-trivial case is labour intensive and not very robust. It is not labour intensive compared to creating a system of higher level logic from scratch, of course, but it is very labour intensive compared to using already implemented and designed higher level logic in a specific case. To use a metaphor, it is a bit like the difference between maintaining a 'blog using WordPress compared to maintaining a 'blog using hand-crafted HTML in Notepad - it takes much, much more effort to write WordPress than it takes to write a few pages in Notepad, but, once WordPress is already written, it is vastly easier for somebody to create and maintain a 'blog using WordPress than using Notepad. Moreover, trying to use Notepad to maintain a 'blog that is regularly updated with lots of cross-linked pages which links need updating every time that a new post is added quickly becomes unmanageable, even though using Notepad to create a static website is perfectly feasible. Because what I am after is the layout equivalent of a dynamic 'blog rather than the layout equivalent of a static website, I am after the layout control software equivalent of WordPress (the self-hosted version that one can tinker with, to extend the metaphor rather furhter) rather than the layout control software equivalent of Notepad (or even Dreamweaver - does that thing still exist?). Of course, in theory, one could create WordPress in Notepad (or DreamWeaver) - but the amount of work involved in doing so would not feasible be just for the purpose of creating a single 'blog.

I hope that that metaphor makes sense and explains what I am after. Is the only way to get a WordPress like experience (without the trying to write WordPress in Notepad experience) to use software such as Traincontroller? That would be a shame if it were so, especially since my attempts this evening to see whether Traincontroller would run under Linux using Wine were unsuccessful (bizarrely, it was the user interface and not the layout hardware connexion that was the point of failure: I could get it to connect to my control station and throw turnouts and monitor sensors, but the throttle window would freeze the whole interface).

One other concern that I have is undocumented and inconsistent behaviour with the dispatcher, which I have posted about here, with only a partial solution to the problems that I have found so far. It is a concern because building timetabling logic on top of that is likely to exacerbate that inconsistency, and if, fairly early in my explorations with JMRI, I come accross quite a number of behaviours which are not readily explicable even after reading the documentation either at all or without a chance meeting with someone with experience of the software, I can foresee a very large number of similar problems obstructing reliable automated working in the future if I were to try to script this.

I am particularly interested in what people who have actually implemented timetable based automation on their layouts have achieved and how they have achieved it, so I am very interested to hear from David Parks. I have looked at the Cumberland West website with much interest; that is really a rather impressive layout.

As an aside, the difference in conventions between the way in which US layouts are operated compared to the way in which British layouts are operated intrigues me, and I do find the US style of operation (and the design of a layout built for the purposes of that sort of operation) of interest. One of the notable features of the US convention from a British perspective is the far greater emphasis on the operational aspect, whereas the British convention tends (albeit not universally by any means) often to treat operations as just a way of showing trains running on the layout without much thought about why a particular train is running in a particular place at a particular time.

That aside is not entirely off topic, since the US convention for model railroad operations is more likely to involve the kinds of automation that interest me than the more characteristically British approach, albeit much of the detail will be different, and there is likely to be far more of a focus on freight, whereas I am more interested in passenger operations.

I am thus very interested to learn more about how David has implemented the automation on the impressive Cumberland West layout, and, in particular, the extent to which this is procedural and the extent to which this uses higher level/abstracted logic so that changes to the schedule or even layout itself can be achieved by changing only data, not code. David - do you use a script similar to AutoDispatcher for the automation of Cumberland West? To what extent is the automation achieved by portable logic separated from data and to what extent is it achieved by logic that is specific to the layout and the timetable that you run?

Thank you all again very much for your replies - it is most helpful.

I am sorry that this small step does not seem to help get some progress toward your goal. Many JMRI users run scripts without understanding the internal workings, only the results.

It is not clear to me that I understand the context of your intended application or your question.

Let me ask a trivial question that is, nevertheless, not clear to me: How many sensors does your first example need for moving two locomotives?

As written, the two examples at the end of the script each control a single hypothetical locomotive and have a sensor at each end of some undefined physically selected route. Each "object" of the class named "BnFModTest" provides an expanded capability to duplicate of the ability to control a locomotive, as was done in the BackAndForth.py script. It also allows one to provide customized forward and reverse speed settings for each train.

Part of what I inferred from your original post was that you have at least two trains running back and forth on two separate locations on your layout, each with two physically separated sensors. Total of four sensors for two trains, or six sensors for three trains. Did I misunderstand that part of the post?

Also, I thought that I understood that you wanted the ability to take advantage of your RailCom sensors and decoders to allow other trains to cross into or just through one of those routes without causing a false trigger to the back and forth train running in the same region. I did not question how you were going to manage the intrusion of a manually controlled train into the automatically controlled route, and just assumed that you have a large enough space between the two ends of the route to allow a sufficient time interval to avoid unpleasant results. Perhaps I got that wrong too?

Our club is strongly considering the use of the Digitrax Transponders on a new expansion that is still in the planning stage, and I have made several stabs at understanding the Reporter capabilities in JMRI. Clearly, without any hands-on experience, I have a long way to go. JMRI seems to treat the incompatible Transponder and RailCom in manner that allows common software.

We have used a variation of the BackAndForth script for a small portion of the existing layout from time to time and again for a scenic animation device that only rotates back and forth.

Any further information or questions will be appreciated,

Cliff

Thanks, but I am looking to understand how the C/I track type could really be used to allow the cars from storage to "pause" at the barge location and be picked up by another train to deliver...

开云体育

Dear Cliff,

Thank you for the examples and the work you invested into them. Unfortunately, I am not familiar with the language and I must confess I cannot follow what is going on in them.

Let me ask a trivial question that is, nevertheless, not clear to me: How many sensors does your first example need for moving two locomotives?

Yours,
????????????? Gabor

We have been using automated running for over 15 years.? We used Winlock until they folded.? Then we moved to MRI Control Panel Warrants. ? We run multiple trains using Warrants overlapping in time every op session.? Mostly we use Warrants for stage train fetching.? Logix can launch warrants, but the primary capability missing is the ability to be driven from a flexible schedule.? A key is absolutely bullet proof layout control.? That we now have since converting the layout to LCC for everything except throttles.? Out goal is a mix of Automated trains and operator trains mixed in the same territory. We have 6 tower positions using controlling 12 interlocking sections using JMRI touch-panel CTC.? These towers can be controlled by an operator or automatically following Routes. ? We are very interested in automated training running developments.

David Parks
Los Altos, CA
dpcw.borail.net

That fixed it! Turnout mode BSTURNOUT

开云体育

Either should work for Diesel 3 or 4
But 4.13.2 has an update for all WOW decoders and first version to have the
paneWowReadMe.xml file, so if 4.13.2 then you don't really need to copy that file, it was included in zip for those with 4.12

Installing the files from the zip to 4.12 will give latest version of Wow diesel 3 & 4 but 1 & 2 and all the steam versions will be slightly out of date but the change was just adding a note indicating to turn off a couple JMRI settings.

Michael Mosher
Webmaster, ECSFM            
Member SFRH&MS              
DCC Master PVSMR            

开云体育

Hi
For transits, you would use the defined transits as templates, duplicate the
transit & start train on the duplicate.
Steve G.

Over the years, people have started to write manuals (i.e. something with a linear organization) a couple times:



They’ve even gone to some trouble to make nicely—printable versions:



But none of those efforts have really continued. The people involved would be the ones to say definitively why, but it seems to me that it was an unfortunate balance of motivation and desire: The people who wanted to work on the manuals were trying to make a contribution, spent a lot of time creating them, but most of the comments they got back were requests for them to do even more work (!) When the first PDF manual came out, the first few JMRIusers posts were mostly requests: better cross-references, a different font, even a request that it "come out earlier next time”!

I think it would be great if a few people decided to create a printable, linear manual. They could start with one of the older ones, or start anew from the help pages, or whatever other strategy they want. One way to do it quickly would be to pretty-print a few of the key web pages to make a PDF, then create a table of contents and/or index.

Bob

On Aug 13, 2018, at 6:24 PM, george.pendergraft <gmpender@...> wrote:

Yes, but I for one like to have something in my hand to read. A real printed manual at my leisure instead of staring at a computer monitor. I can also concentrate on learning about the program whenever I want to without having to go back and fourth between the program and the online manual. That is just me. Granted, if there are manuals that are incomplete or out of date like those of today, then a manual to that extent is not going to do much training. Thus my solution to set a release date for the software to come out every year, and put a printable manual out for use in that year. Makes sense to me. Unfortunately I am not knowledgeable enough on the software to help with the writing of such a large undertaking. And I do realize it is a big undertaking. But many of us (like me) out here are just squeaking by on how to use the software and as some say even the software instructions for today would be inadequate to instruct anyone today just because things are changing so fast. But it would be nice to have something to look at in my lap while learning the software. Anyone else out there agree?

--
Bob Jacobsen
rgj1927@...

开云体育

OK, so I was being daft! I hadn't set up the turnouts in the DCC++ configuration so the feedback was coming back from the command station. I will set it up properly and then report back....

A partial implementation script has been uploaded to /g/jmriusers/files/ProblemsBeingWorkedOn/Back%20and%20Forth%20Script%20with%20Reporter%20Action/BackAndForthMod.py for your inspection and modification.

The BackAndForth.py script has been modified to allow multiple trains to run between specific sensors and with forward and reverse speeds as parameters.

The identified sensors are queried for Reporter information, but neither RailCom or Transponder sensors are available for me to do any further investigation or testing. All "testing" done thus far has been with simulators for Digitrax, NCE, and XpressNet with the Sensor Table to pretend that the trains have arrived.

Not specifically requested, but a separate modification also provides a brute force method that stops all of the trains that are being controlled by this script when the "Quit" Button is clicked on the PanelPro window.

Hope this effort provides someone else with clues as to what might be provided (or corrected) next.

Cliff in Baja SoCal