|
Locked
Full timetable automation - AutoDispatcher 2 - abstraction - documentation - scripting
I am in the process of evaluating whether JMRI is suitable for what I want to do. In simple terms, I am planning on building some UK based main line railway layouts focussing on passenger operations. is a track diagram for the one that I am planning to build first, in UK N gauge 1:148. I am after full automation, preferably with optional manual intervention in the area of signalling ("dispatching" in US terms). I have started with a small test layout, and have been having some difficulties in getting JMRI to work consistently, as discussed in more detail here. Some of those difficulties I have managed to resolve with assistance, but some remain.
I have seen that some people have managed some feats of (semi-)automation with JMRI, with the video in the preceding link showing a layout with a fully realistic IECC panel and simulated off-scene train movements. However, the more that I look into this in detail, the more that I find that there is a lack of clear documentation about how to achieve all but the most basic of automation and what automation functions are actually built into JMRI and what has to be done by way of scripting (and, if the latter, quite how general and abstract that these scripts can practically be). My own investigations so far have got as far as transits and Auto Active Trains running on transits. I note that transits cannot easily be used in an abstract way in scripting because only one Auto Active Train may be assigned to a transit at a time. So, for example, if I wish to have two trains on the down main, each stopping at the station and then returning to the fiddle yard, I need a separate transit for each. Furthermore, there does not seem to be any built-in support for timetables. I had wondered whether OperationsPro would allow for this. IT does appear to have a timetable function. However, its suggests that this tool is not suitable for passenger operations. To quote from the manual, "The JMRI Operations program allows you to create computer generated train Manifests for your railroad. A train details the work that a crew will perform during an operations session. The Manifest provides a list of car pick up and set outs and shows where the cars are located and where they should be eventually positioned on the railroad. The program allows you to enter a roster of and , define (stations) on the railroad, and for to travel. The car roster includes information about the car, including road, number, type of car, color, length, weight, load, date built, and owner. Trains are assigned routes that define locations or stations where cars can be picked up or set out. Features include the ability to control what car types, roads, and car loads a location or industry can service, the available track space for a location, and the maximum length the train can be between any two locations in the train's route" The whole of the documentation for OperationsPro seems to focus on the concept of industries and what "cars" (wagons) need to be dropped off or collected from such industries and the creation and subsequent automation of manifests that describe precisely this process. The timetable feature appears from what I can tell to link directly into the concept of manifests, which have no equivalent in UK passenger operation. Have I misunderstood OperationsPro - is it suitable for a high-level, abstracted implementation of timetable based UK style passenger operations on a substantial main-line layout? If so, is there any documentation on how it might be used in this way? There is then the "" script in the of the JMRI website. This is described thus, "This script provides full layout automation, using connectivity info provided by Layout Editor panels" However, there is no documentation on how to use this or what its capabilities are. Looking at the code, I note that there is substantial code for parsing timetables, but there is no documentation on the format of these timetables. I could in theory eventually work out what it does by reading the code and testing it in practice, but this seems a rather absurd length to which to have to go to learn how some software works, especially if I cannot be sure before investing that sort of amount of time that it will do what I want in the first place. Aside from OperationsPro with its apparent limitations, and the enigmatic AutoDispatcher 2, has anyone managed to use JMRI for layout automation in a way that does not involve writing layout-specific and possibly even timetable-specific logic in a Jython script? I do not want to have to rely on software in which code and data are not separated in order to automate my layout Do the tools built into JMRI itself allow for sufficient abstraction for this to work without having to write all the abstraction (and basic things such as text file parsing logic for interpreting timetables) into a Jython script? A scripting language seems inapposite for writing what would amount to a very substantial piece of abstracted program logic. What would be ideal is a very high level of abstraction, although whether this is possible with any current software I am doubtful. Ideally, there would be diagrams, which would describe the service pattern of a train in a vaguely similar way to transits, but with a higher level of abstraction (e.g., start from somewhere (i.e., not a specific road, but any road) in the up fiddle yard, progress through the down relief line, stop at platform 5 (or, if that platform is not available, platform 3) until the timetabled departure time for the working in question from that station, then continue on the down line to?any free road in the down fiddle yard). There would then be workings, which would define an individual instance of a train working that diagram. A timetable would specify timing points for each working on each diagram (in the above example, there would be timing points at the start of the working and for departure from the station platform), and would also give the workings each a unique name (which could be an alpahnumeric code such as 2A32 such as used in the UK TOPS system), which would then be displayed on the panel next to the train as it moves through the sections in the layout. (I have seen videos of this sort of train describer working, but I have never found any documentation on how to achieve this - the closest that I have got is using reporters for RailCom feedback devices, but these are very crude). The next layer of abstraction would be formations - a specific set of locomotives, carriages and/or wagons making up an individual train. At the first timing point of a working, a particular formation in the fiddle yard would be selected using an algorithm (which might be semi-random, e.g., pick any train in the up fiddle yard marked as suitable for this diagram that is not in the process of being re-marshalled). Has anyone ever managed to achieve anything like this level of abstraction? I have seen lots of layout automation examples, but because they rarely come with detailed documentation on how they were achieved, it is hard to know whether they were anything more than a wholly procedural system (code explicitly providing, e.g., increase throttle on train no. 421 until sensor 15 is high, then decrease throttle after 2 seconds; when sensor 14 is low, throw points 19 and 20 then increase throttle on train no. 317...", etc.) specific to that layout and timetable. I imagine that some of this abstraction could workably be implemented by scripts, but only if the base logic in JMRI were sufficient prevent the script from having to be in effect a fully fledged automation package with JMRI acting only as the interlocutor between the scripting language and the layout hardware: having to implement text parsing logic, a user interface for inputting timetables, etc. into a script (and a script is not really suited to that task in any event, I imagine) seems rather excessive. I should be very grateful for feedback on this issue, as I am keen to make progress with evaluating various types of layout control software so that I am able to focus on learning only one and also so that I can consider my hardware needs in light of the software choice, as some hardware (specifically, MERG CBUS equipment) works only with JMRI. |
|
Locked
Re: New file uploaded to [email protected] - tcs-wow.zip
开云体育Michael, ? Better to apply this (TCS_WOW_Diesel03.xml & TCS_WOW_Diesel04.xml & paneWowReadMe.xml) to production release JMRI_v4.12+Rb6a9bb1 or the latest beta, JMRI_v4.13.2+R8a2b21d? ? Thank you very much!! ? Greg Komar gkomar@... "The nicest thing about the future is that it always starts immediately." From: [email protected] [mailto:[email protected]]
On Behalf Of [email protected] Notification
Sent: Monday, August 13, 2018 8:41 AM To: [email protected] Subject: [jmriusers] New file uploaded to [email protected] ? Hello, This email message is a notification to let you know that a file has been uploaded to the Files area of the [email protected] group. File: tcs-wow.zip Uploaded By: Michael Mosher Description: You can
access this file at the URL: Cheers, |
|
Locked
Re: Inconsistent behaviour with the dispatcher
I have been running further tests relating to this topic. First, I installed proper resistance wheelsets on one of the carriages that I am using, since the carbon paint that I had been using had too high a resistivity to work. I have found that, with the Digikeijs DR5088RC, I need two 10k resistors on adjacent axles for this to work reliably (and even then, the resistance seems to have been reduced by coating some of the top in silver paint to ~5-7k per wheelset rather than the base 10k; shorting the track with a 10k resistor in line will not trigger the occupancy detection).
I next re-ran the tests that I had run earlier on the modified, simplified version of my testing layout, represented as a single loop with the modified panel kindly provided earlier in this thread. I made sure to select "all cars have resistance wheelsets" and I measured the length of the trains and converted these to scale meters to enter into the auto active train dialogue. There was a slight improvement, in that, with the resistance wheelsets, the train would not stop with the carriages still in the previous section. However, there is still inconsistency between running with two active trains and one active train that is not explained by the necessities of slowing for signals. With two active trains, as before, the trains would stop much farther into the final section in the transit than with just one active train. Moreover, with just one active train, the train would accelerate to a high speed and very suddenly decelerate to a much lower speed on entering the final section in the transit. Having done that, it would then stop fairly smoothly with all carriages fully in the final section, but in a completely different place (less far into the final section in the transit) to the place in which it would stop when there was a second active train on the layout. Does anyone have any idea why this sudden deceleration behaviour is occurring? Further, is there any way of making the trains stop at a consistent? (or specific) point at the ends of their transits (consistent, that is, with the behaviour of trains at the end of their transits also under a restrictive signal aspect as when there are two trains on the layout)? I am using Zimo decoders with BEMF, so it should be possible to assume accurately that commanded speed has a consistent relationship with actual speed. Inertia/momentum is set to zero on the decoder, although I usually set the ramp speed to "medium slow" in the Auto Active Train settings. |
James E. Petts
Greg Komar