|
Locked
Re: NCE POWER PRO
The tool for scanning the cab bus is on the NCE menu, Show Cabs.
So most people with a Power-Pro system use addresses like 50 and higher for the AIU address. Each board or throttle must have a different number. When entering a sensor in JMRI, you can use the shorthand of 50:1 for the first pin of AIU addressed at 50. Just keep in mind that the AIU had 14 pins, but the starting number works out to every 16 sensor numbers. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org |
|
Locked
Re: NCE POWER PRO
AIU is set default not enable.
I solve the problem but further testing will go on. The Belkin Serial to USB that I have been using for serval years does not like Window's 10. I switch out the cable for the serial to usb cable that came with my ESU programmer and things are working fine now. Was able to monitor the cabs, backup, add marcos. set clock etc. So I guess I have to buy the Keyspan Serial to usb now. Thanks for all the help. Bob |
|
Locked
Re: Full timetable automation - AutoDispatcher 2 - abstraction - documentation - scripting
Hello James,
I am struggling with similar issues and have been pouring through many, many lines of code to learn how JMRI can truly automate train movements. So far, I also keep running into limitations and examples that are designed for a specific layout and timetable. Have you tried the Train Controller software from Railroad & Company? This program is free to try and offers a level of sophistication I have not seen elsewhere. I have used this software for over ten years to automate two large layouts in a model railroad museum here in the US. Download the "Gold" version (V9), and the 400+ page manual. You may find this will meet your needs. Richard |
|
Locked
Re: NCE POWER PRO
EPROM version is set for 2006 and later
AIU is set to 0 Baud rate is set to 9600 in Power Pro and JMRI Com Port is on 6 I use a Belkin Serial to USB Model F5U409. I have had it ever since I started using JMRI and never had a problems. I haven't used it that much with the Power Pro system as I have a Power Cab system setup on my bench for programing and setup of engines. Just started to try to use with the layout to monitor cabs, backup and make changes to marco's which I have done in the past. Bob |
|
Locked
Re: XML code question: panel size
panelheight and panelwidth are the size of the underlying panel itself.
When it opens, windowheight and windowwidth are how big a window to display. (If that¡¯s enough smaller, scrollbars are used) But note that your local preferences override these: If you¡¯ve resized the panel in the past, the window preferences will open it at the same place and size as it was, even if you change these. Plain height and width are still there for compatibility, but were deprecated a long time ago. Doesn¡¯t matter if you remove them; they¡¯re not read if the ¡°panelX¡± and ¡°windowX¡± forms are present. Bob On Aug 14, 2018, at 7:25 AM, Nick Brownsberger <nbrownsbe@...> wrote:-- Bob Jacobsen rgj1927@... |
|
Locked
Re: Decoder Pro Manual ?
George,
From my view, the bigger use for a document would be as an overview or guide to JMRI. It would try to document the concepts and thoughts behind JMRI and how to figure out which parts you want to use and how to find them. This would get to the point of knowing which screens you need to work with. Then the help on those screens would provide the details of what you need to know. The advantage of this split would be these documents would not age as quickly since the contents they cover don't change that fast and they don't have the lower level details that tend to change quickly in comparison. I'm not a document type, so I get my info from the details. I can see how this would help those know where to start. The help screens are only good if you find the right ones. Now the counterpoint to the manual idea would be more of the short, focused, YouTube videos on specific steps or topics. This seems to be more the way of the modern mind. Granted much of the audience has the prior version of minds. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org |
|
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, |
Ken Cameron
Bob
rsauerbrun
Bob Jacobsen
James E. Petts
Greg Komar