开云体育

Hi
For transits, you would use the defined transits as templates, duplicate the
transit & start train on the duplicate.
Steve G.

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:

Yes, but I for one like to have something in my hand to read. A real printed manual at my leisure instead of staring at a computer monitor. I can also concentrate on learning about the program whenever I want to without having to go back and fourth between the program and the online manual. That is just me. Granted, if there are manuals that are incomplete or out of date like those of today, then a manual to that extent is not going to do much training. Thus my solution to set a release date for the software to come out every year, and put a printable manual out for use in that year. Makes sense to me. Unfortunately I am not knowledgeable enough on the software to help with the writing of such a large undertaking. And I do realize it is a big undertaking. But many of us (like me) out here are just squeaking by on how to use the software and as some say even the software instructions for today would be inadequate to instruct anyone today just because things are changing so fast. But it would be nice to have something to look at in my lap while learning the software. Anyone else out there agree?

--
Bob Jacobsen
rgj1927@...

开云体育

OK, so I was being daft! I hadn't set up the turnouts in the DCC++ configuration so the feedback was coming back from the command station. I will set it up properly and then report back....

A partial implementation script has been uploaded to /g/jmriusers/files/ProblemsBeingWorkedOn/Back%20and%20Forth%20Script%20with%20Reporter%20Action/BackAndForthMod.py for your inspection and modification.

The BackAndForth.py script has been modified to allow multiple trains to run between specific sensors and with forward and reverse speeds as parameters.

The identified sensors are queried for Reporter information, but neither RailCom or Transponder sensors are available for me to do any further investigation or testing. All "testing" done thus far has been with simulators for Digitrax, NCE, and XpressNet with the Sensor Table to pretend that the trains have arrived.

Not specifically requested, but a separate modification also provides a brute force method that stops all of the trains that are being controlled by this script when the "Quit" Button is clicked on the PanelPro window.

Hope this effort provides someone else with clues as to what might be provided (or corrected) next.

Cliff in Baja SoCal

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:

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).

--
Bob Jacobsen
rgj1927@...

“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, thanks for the quick response.
However I am not quite sure I know how to establish a reference to the window.
Below is a brief skeleton of my script. Is "f" the window reference?

class ThrottleA(jmri.jmrit.automat.AbstractAutomaton) :
.... followed by a bunch of listener classes, e.g.
class F0Listener(javax.swing.event.ChangeListener) :
def stateChanged(self,event) :
... etc
def init(self):
....
return
def relThrottle(self,event):
self.throttle.release()
print("Release")
***>>>> here's where I would like to close the window
return
.... followed by a bunch of other defs, then...
def setup(self):
.... establish buttons, panels and the JFrame, e.g.
f = javax.swing.JFrame("CAB 41",preferredSize = (250,250))
.... layout the panels, e.g.
f.contentPane.add(self.panel1)
f.pack()
f.show()
self.start()
return
a = ThrottleA()
a.setName("ThrottleA Code")
a.setup()

Appreciate your help
Fred Miller

--
Bob Jacobsen
rgj1927@...

Thanks Dave, some progress, but still not there! I set the turnouts to BSTURNOUT and I also tried BSOUTPUT. The feedback changed from unknown to inconsistent when clicked. I got the animation on the panel but it still only clicks the one way... Is it a DCC++ problem I wonder?

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

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).

Bob, thanks for the quick response.
However I am not quite sure I know how to establish a reference to the window.
Below is a brief skeleton of my script.? Is "f" the window reference?

class ThrottleA(jmri.jmrit.automat.AbstractAutomaton) :
.... followed by a bunch of listener classes, e.g.
? class F0Listener(javax.swing.event.ChangeListener) :
?? ?def stateChanged(self,event) :
???... etc
?? ?def init(self):
??....
????return
?? def relThrottle(self,event):
???? self.throttle.release()
??? ?print("Release")
? ??***>>>> here's where I would like to close the window
??? return
.... followed by a bunch of other defs, then...
?? def setup(self):
??.... establish buttons, panels and the JFrame, e.g.
?? f = javax.swing.JFrame("CAB 41",preferredSize = (250,250))
??.... layout the panels, e.g.
?? f.contentPane.add(self.panel1)
?? f.pack()
?? f.show()
?? self.start()
?? return
a = ThrottleA()
a.setName("ThrottleA Code")
a.setup()

Appreciate your help
Fred Miller

James,

Some of what you want would be a script or user interface that in turn is
driving Dispatcher. So the start and termination of the trains would be in
the upper level and it treats all of Dispatcher as the lower level.

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

Thank you for the help. I'm going buy another cable later. I now have both my computers up and running JMRI with Power Cab and Power Pro. Now to get them setup on One Drive for the roster info. It's great when things go the right way. When I retired they gave this HP Stream and I said that would be great to use on the layout?with JMRI and now I'm a happy railroader.
Bob

Thank you for your response - that is helpful. I do not think that a procedural system is really suitable for full timetable based automation of a large layout, as I need to be able to amend the timetable without having to reprogram (and debug) a script - for anything non-trivial, it is important that data be separated from code.

Is there no means of achieving timetabling in JMRI with a higher level of abstraction?

To close a window, you keep a reference to that window (i.e. called myFrame) and then do either:

myFrame.setVisible(False)
myFrame.dispose()

_or__

myFrame.dispatchEvent(java.awt.AWTEvent.WindowEvent(myFrame, java.awt.AWTEvent.WindowEvent.WINDOW_CLOSING))

(I haven’t checked that these are exactly Jython syntax; they’re copied from Java and adjusted) The first one is simpler, but doesn’t __quite_ do exactly what the close button does. The second is exactly the same as clicking the button.

Bob

On Aug 14, 2018, at 12:53 PM, Fred Miller via Groups.Io <tractionfan@...> wrote:

I have a python script which runs a nice throttle. It builds a window with necessary buttons, etc. However I am trying to figure a way of closing the window (terminating the script) from within the script but in the same way as clicking on the red title bar close button. I have tried "exit()" but that closes down PanelPro altogether. I have tried "f.dispose()" as in one of the example scripts but since I have my script in a Class, I am apparently not getting the f.dispose() at the right level. within the code. I wanted to execute it from a defined function called from a button click.

--
Bob Jacobsen
rgj1927@...

开云体育

In my panel's xml file, <LayoutEditor, what is the difference between?

height="676" width="1893" windowheight="364" windowwidth="951" panelheight="676" panelwidth="1893"

I'm trying to reduce the size of the panel by eliminating the extra space. (Maybe I don't really need to, but...) Also sometimes, especially now after I've mucked with these setting, the panel opens without all the layout pieces shown. I have to zoom out and then back in to get everything to display.

On Tue, Aug 14, 2018 at 05:11 AM, Greg Komar wrote:

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

Greg,

We don't go back and modify a releases. These changes will be applied in 4.13.3.
If you wish to use the modified files you can download from the link provide and install the changes yourself following the instructions provided in the zip file.

--
Peter Ulvestad

JMRI Users Group Moderator - ( )
Tam Valley Group Moderator - ( )
Sprog-DCC Group Moderator - ( )
Edmonton Model Railroad Association -

James,

YAAT is procedural oriented but flexible. As such, it is as you described. Set turnout, move at this speed, wait for something to change, etc.

YAAT evolved while helping a guy in England automate trains without block detection. He uses IR detectors at the stations.

The first part of the script has the documentation.

The zip file has a demo panel and text files that I use for testing. The most complex one has two trains coming from branches to the main station and back again. It uses a sensor group to control which train has access to the shared mainline.

I am working on version 1.7 which adds memory variables. This would the provide access to IMCURRENTTIME. That would still be procedural but would allow actions based on time.


Dave Sand

Dear Paul,

Thank you for your reply. It is kind of you that you are going to look into the matter further.

Can you get me a log of how the railcom detection messages are showing up from the Roco 10808 sections?

Unfortunately I don't know how to get such a log.? There is a program called "Z21 Maintenance Tool" that can be used to make the Roco10808 emulate R-Bus and/or LocoNet and/or Lissy/Marco detection.

Yours,
????????????? Gabor

??? I agree with you that decoders are becoming more sophisticated, but applying more (up to the safe limit)?voltage has been recommended by just about everyone who uses digital devices. I learned this as an auto tech, we couldn't get the express up feature on Mercedes without starting the car or using a battery charger. Car batteries are 12.5 volts but run at 14.5+. I have worked at many dealers where a battery charger had to be installed to do most reprogramming. Just my 2 cents.?????? Jim