Your tip to place direction sensors on the layout worked a treat and after some forensic debugging have now solved the signalling issues.? Thanks very much for your help.

Peter

John,

An alternative to only allowing non "E" or "L"? on the barge is to use the the destination tool to "Only allow cars with a final destination" for the barge C/I tracks.? This method would eliminate the need for custom loads.? Your industry schedules would only demand a certain car type, custom loads would be optional.



Dan

Hi John,

You want your cars to move with purpose rather than just random movement.? In your configuration, the program will grab the first 10 cars from your storage track with the lowest moves, drop them off to the barge, and hope there's places for them to go to.? What you need is for your industries to demand certain cars.? ?That can be done using schedules.



To generate the loads and destinations for your industries, you would make your storage "staging" tracks.? It can be one large one with all of your cars, or if you use boxes, one staging track per box. Place all of your "storage" boxes in one location, we'll call it "Storage" for now.? The route for the train that services the "Storage" and barge looks like this"

Storage -> barge -> Storage

Set up the train to allow cars to return back to storage if they can't find room on the barge.? So for example, say you have 50 cars in storage, the program will try and find 10 cars to place on the barge that have destinations on the layout, and return the other 40 back to storage.? If the barge has 10 cars on it, the program will try and pull all 10 back into storage, effectively swapping the cars on the barge for you.? You should configure the barge C/I tracks to only accept cars with custom loads, this will prevent cars from being placed randomly onto the barge. The best way to do this is to exclude the "E" and "L" default loads for your barge tracks.

Let us know if you get it to work!

Dan

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