|
Locked
Re: Full timetable automation - AutoDispatcher 2 - abstraction - documentation - scripting
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. |
|
Locked
Re: New file uploaded to [email protected] - tcs-wow.zip
¿ªÔÆÌåÓýEither should work for Diesel 3 or 4But 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 On 8/14/2018 7:11 AM, Greg Komar wrote:
|
|
Locked
Re: Decoder Pro Manual ?
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:-- Bob Jacobsen rgj1927@... |
|
Locked
Re: New file uploaded to [email protected] - tcs-wow.zip
¿ªÔÆÌåÓýThe question was WHICH of the two JMRI versions would be the preferred version to apply the update to¡. ? Greg Komar gkomar@... "The nicest thing about the future is that it always starts immediately." From: [email protected] [mailto:[email protected]]
On Behalf Of Peter Ulvestad
Sent: Tuesday, August 14, 2018 1:50 PM To: [email protected] Subject: Re: [jmriusers] New file uploaded to [email protected] - tcs-wow.zip ? On Tue,
Aug 14, 2018 at 05:11 AM, Greg Komar wrote: |
|
Locked
Re: Full timetable automation - AutoDispatcher 2 - abstraction - documentation - scripting
Most of the JMRI community doesn¡¯t really think or talk in terms of ¡°abstractions¡±.
JMRI itself is entirely organized around (internal) events and listeners. Things like Logix, signal logic, etc, listen for changes in object state and react. At the lowest level, those listened-to objects are small things like individual sensors, turnouts, lights, icons on panels, etc. From those are built higher-level objects like signal heads and masts, signal logic, CTC elements, etc. In certain cases, JMRI will also use threads to handle sequencing, in the usual sense of ¡°do X; wait for Y; do Z¡±, etc, sequencing. JMRI itself uses this pattern for i.e. control of operations across communication links, sequencing startup, etc. There can be many threads running in parallel, each operating their own sequence. A lot of scripting is done this way, because many model railroaders find it easier to think that way, and it¡¯s an easy way to build a little sequence of tests and operations. But please note that there¡¯s no practical limit on how many of those can be running in parallel, either for small things (sequencing the operation of a few sensors and turnouts) or something large and complicated. I know a local layout that¡¯s running over 80 threads in parallel (two per CTC control point because of how their CTC panel was coded) just fine during operating sessions, and it¡¯s doing just fine. Dispatcher, Warrants, etc are all suitable for specific purposes, but if they¡¯re not suitable for you it¡¯s not so hard to craft a custom solution. (It¡¯s usually _much_ easier to create a custom solution than a general one what will work for lots of different purposes and layouts). All those tools started as efforts that somebody thought were suited to their specific application When scripting, the best way to think about it is that you¡¯re writing Python (really Jython to ease Java access, but that matters little; JavaScript is also available if you prefer that) on top of a JMRI library that gives access to layout objects. There are no fundamental limits to what that can do that way. If you want to create your own class library that has abstractions you like, go ahead: You have the full power of the Python language available for OO, functional, relational or even dynamic programming. Use listeners, threads and other constructs as you¡¯d like; they all work. For example, all the way back in 2006, there was a JMRI-driven layout (built by John Plocher with help from Dave Falkenburg and others) at the Java One conference that ran multiple interleaved trains: two in one direction around an oval with two sidings, with another one working its way in the other direction. That was done with (IIRC) one thread per train, plus JMRI-standard signal logic that was automatically setting and clearing up signals. One thread per train was a good way to get this specific demo up and running really quickly. Bob On Aug 14, 2018, at 3:16 PM, jamespetts via Groups.Io <jamespetts@...> wrote:-- Bob Jacobsen rgj1927@... |
|
Locked
Re: How to terminate python script
¡°f¡± is the thing you need to keep. It¡¯s the JFrame object that you create in your setup(..) method. ¡°f¡± is a local variable now, you have to save it somehow. You can either put it in a global variable, or you can put it in the object you create by referring to it as ¡°self.f¡± everywhere, and the using a.f to refer to it.
Bob On Aug 14, 2018, at 3:13 PM, Fred Miller via Groups.Io <tractionfan@...> wrote:-- Bob Jacobsen rgj1927@... |
|
Locked
Re: Full timetable automation - AutoDispatcher 2 - abstraction - documentation - scripting
James,
Dispatcher already has the logic for working out how to allocate sections to trains. To it, a train follows a route of a series of sections. So when you tell it to start a train, it will work along allocating and releasing sections. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org |
|
Locked
Re: Full timetable automation - AutoDispatcher 2 - abstraction - documentation - scripting
Ken,
thank you for your reply. In very general terms, that is what I had already understdood to be the case. However, what I am not clear on is quite what abstraction capabilities are built in and what have to be scripted. Take transits, for instance. There is no way of permitting more than one train to be travelling the same transit at once, so I imagine that the way of acheiving something similar to this would be a higher level class (scripted) concatenating lots of very short transits. In this case, the whole abstraction for this, all the variables, the UI and the logic would have to be scripted, I presume, and then several layers more abstraction on top would also have to be scripted to deal with actual timetabled working - is this correct? I am finding it very difficult to get detailed information on what abstractions that JMRI is capable of internally and what needs to be done by way of scripting - and I think that I am correct in concluding that scripting is not really suitable for large-scale abstraction logic, although if somebody has achieved this successfully, please do let me know, as this would be most interesting to observe. It looks like "AutoDispatcher 2" is perhaps the closest that anyone has come to this, but I cannot find any documentation on its capabilities, so it is very difficult to understand what this is really able to do (and this is already a very substantial piece of software in itself). |
James E. Petts
Michael Mosher
Bob Jacobsen
Greg Komar
Ken Cameron