开云体育

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.