开云体育

Long story short, had to completely reload my desk top and bring Ubuntu 18.04 back to life.

I was attempting to use installation instructions as provided on the JMRI website.

Step 3. of the JMRI Linux installation instructions:

After running the Java installer, give user-level application access to your serial ports:

rich@rich-500-164:~$ chmod 666 /dev/ttyS0
chmod: changing permissions of '/dev/ttyS0': Operation not permitted

The same happened for ttyS1.?

I'm not a Ubuntu techy type, but I manage to get through it.?

As for this, it has me stumped.

Thanks,
Rich Ramik

?

This is a known issue (at least by me) between the clipping region and magnification (zoom) in the LayoutEditor.
My previous attempts kinda worked… except then the layout would draw over the scrollbars… :(
Sometime the "Zoom to fit" will fix it.
It's been "in my queue" for a while to take another look at this.

I found a similar case? in thread #160096? (May2019)? same errors. The thread is a dead end or so.

Paul Bender worked the issue and it might have been partially resolved in a JMRI test build 4.15.8.? You might try and download that test release and see if it works for you.
Paul still works on Hornby Elite and ExpressNet? as per GITHUB. His last? add was in 4.16 for the Elite programming. Something might have been broken afterwards in your 4.17.6

If not done, you might update the firmware on your Elite to 1.44

https://www.hornby.com/uk-en/hornby-dcc/elite-firmware-update.

Other thought is get on GITHUB JMRI and tell them your problem.? You might help them out.

Marc

Please provide some more information so people know how to help.?

What system are you working on, what version of JMRI, what version of Java for examples.?

There have been many updates in how the editors work and display as newer versions have come out.

Phil from gorgeous Young Harris, Georgia, USA

Thanks, I was curious as to why I could not use a throttle in a similar way to sensors and turnouts. So looked around and found the?jmri_bindings.py file and put 2 and 2 together and came up with 5. Thanks for the explanation.

Jim

The jmri_bindings.py file has been obsolete for a while, so I’m not sure what that part of your question is asking



It’s easier to handle a throttle within AbstractAutomaton because there’s specific code there to handle the necessary waits and callbacks.

Unlike a turnout operation, which is “set the command and go on with what you’re doing”, throttle operations require back-and-forth with the hardware. That can be directly coded in a script, but it’s tricky to get right.

Bob

On Jan 5, 2020, at 9:00 AM, James Anderson <james_anderson_999@...> wrote:

Hi, can I ask what there is no equivalent turnouts definition the jmri_bindings.py and if this is why I can only control the throttle from inside a class that inherits from jmri.jmrit.automat.AbstractAutomaton

thanks jim

--
Bob Jacobsen
rgj1927@...

Hi, can I ask what there is no equivalent turnouts definition the?jmri_bindings.py? and if this is why I can? only control the throttle from inside a class that inherits from jmri.jmrit.automat.AbstractAutomaton

thanks jim

Done. Thanks for the suggestion!

Bob

On Jan 4, 2020, at 10:52 PM, Graeme Brooker <gbrooker@...> wrote:

Steve T
(Back from the salt mine of my son's backyard landscaping)

Thanks Steve. That worked (deleting JMRI directory before extracting 4.18 upgrade and copying)

Can I suggest a small change to web page (jmri.org/install/Raspbian.shtml) where currently it says "You should therefore not expand the download into the same place as an existing JMRI installation. Instead, expand it into a separate location, and move in to it's final destination, completely replacing any previous version of JMRI."
I followed that procedure and that resulted in the error. Following your advice I deleted the JMRI directory and then copied the extracted files from the download directory. This fixed the problem.
Eg
" Instead, expand it into a separate location, backup any user created files in the JMRI directory and delete the JMRI directory. Then move the extracted JMRI directory and its contents in to it's final destination, completely replacing any previous version of JMRI."

--
Bob Jacobsen
rgj1927@...

JMRI now includes a solution that is intended for JMRI Test Release 4.19.2. See for some details.

If you like you can download a daily build package, available here:
jmri.tagadab.com/jenkins/job/Development/job/Packages/ (package 3571 or higher).

Klaus

/g/jmriusers/message/166411

--
Peter Ulvestad

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

OK Marc, thanks - I think I'm on a dead end with this one!

I may try simulating DCC++ if I can - my objective at this stage is evaluation, to see if I can use JMRI to get a nicer front-end than Railmaster for both running and decoder setting-up, (importing layout plans from Anyrail), without laying out more dosh (I already have an Arduino to play with). Panelpro doesn't seem to like the Elite either but I don't think I'll pursue that one.

Thanks again - Richard

I noticed that (no “Set”) since there is currently no way to directly execute the Logix that LRoutes produce (perhaps a new feature request)? ?

In my case, my first LRoute was to set the initial state of all my turnouts so it only needed a simple internal sensor to use as a trigger. ?Activate that sensor (click on its State in the Sensor Table, or bring it onto a panel) and the LRoute/Logix gets triggered “manually.” Only works where there is a single trigger for the LRoute – unless you want to get into editing the Logix conditionals (add in a single triggering sensor OR’d to the rest of the conditionals list) but that then defeats the simplicity of creating the LRoute.

I continue to be amazed by the simplicity (and complexity) that JMRI provides to us modelers. Thanks to all who help create it and maintain it.

Jerry

[and an unsolicited solicitation – click here to make a donation: ?

___________________________________
jerryg2003@...

So the supplied CV listing from the Pannier 0064 was done using Hornby's Railmaster software, USB cable and the Hornby Elite of yours.

So that would confirm the driver, the USB cable and Elite are working fine. The problem lies in JMRI itself.

I do not have a Hornby Elite but I can setup DecoderPro for the Hornby Elite and COM1? and I get the same error messages as you show in thread.

2020-01-05 02:36:17,769 hornbyelite.EliteAdapter INFO -COM1 port opened at 19200 baud with DTR: true RTS: true DSR: false CTS: false CD: false [main]
2020-01-05 02:36:22,839 jmrix.AbstractMRTrafficController WARN -Timeout on reply to message: 21 21 00 consecutive timeouts = 0 in lenz.XNetPacketizer [lenz.XNetPacketizer Transmit thread]

This 21 21 00? is DecoderPRo requesting the firmware level information from the Elite and not getting it.

It continues on with more errors :
2020-01-05 02:36:52,869 jmrix.AbstractMRTrafficController WARN -Timeout on reply to message: 21 24 05 consecutive timeouts = 1 in lenz.XNetPacketizer [lenz.XNetPacketizer Transmit thread] ?

Since I did not request a READ CV, the log ends here.? But clearly your setup is not talking to your Elite for some reason beyond my pay grade..
I would confirm that RAILMASTER and JMRI are using the same COM port setting, long shot but all I can think of.

Sorry can not help you further.

Marc

Steve T
(Back from the salt mine of my son's backyard landscaping)

Thanks Steve. That worked (deleting JMRI directory before extracting 4.18 upgrade and copying)

Can I suggest a small change to web page (jmri.org/install/Raspbian.shtml) where currently it says "You should therefore not expand the download into the same place as an existing JMRI installation. Instead, expand it into a separate location, and move in to it's final destination, completely replacing any previous version of JMRI."
I followed that procedure and that resulted in the error. Following your advice I deleted the JMRI directory and then copied the extracted files from the download directory. This fixed the problem.
Eg
" Instead, expand it into a separate location, backup any user created files in the JMRI directory and delete the JMRI directory. Then move the extracted JMRI directory and its contents in to it's final destination, completely replacing any previous version of JMRI."

Graeme Brooker
(Small donation made to JMRI)

There’s a lot of detail here that I don’t (yet) understand. Thanks for laying all that out, I’m working my way through it slowly.

JMRI’s internal model of signals works in two steps:

1) First is logic that decides what aspects to use for each individual signal mast. By individual mast, JMRI means what’s located at _one_ track at _one_ position, but includes everything associated with signals at that point: It might have multiple lights, semaphore drives, fixed targets and even appear on more than one pole. The logic looks at the track work (including routing) and next signal(s) and decides on one specific aspect from the available set.

2) Once that aspect is known, it has t be turned into an appearance. This comes in multiple forms: How are electrons to be pumped around to make the right things happen on the layout? How are pixels to be lit and en-darkened to display the right thing on a local display? How are bytes to be shuffled to make the right thing appear on a remote (web) panel?

From the limited amount that I understand, (1) will work fine. There might be a _lot_ of aspects defined to cover the possible route information (US signaling is less precise on routes, often just settling for “diverging” instead of indicating 1 on N specific paths), bu the process is pretty straightforward.

Appearance on the layout isn’t really JMRI’s problem. Typically a signal has a few of the hardware lights lit, and JMRI can easily do that. The hard part is building a sufficiently realistic piece of hardware on the layout which holds the lights in the right places, etc.

But on-screen display is JMRI’s problem and nobody elses. Right now, the way to do that is large sets of icons: Large because there are a lot of aspects (each of which needs an image) and lots of ways to arrange the head (which multiplies times the number of aspects)

For example, there are 15 different “Proceed” appearances in the BR-2003 set: That’s far from the record, which might be held by the 30 (!) ways to show Slow Clear in the B&S 2009 set, at least in part because of its equivalent of directional feathers.

So you might need one set of icons for on a pole, another for on a bridge (although sometimes that can be created with a picture, c.f. the picture at the top of ) and maybe more.

Does that sounds right?

Bob

On Jan 4, 2020, at 10:51 AM, Adam Richards <adamjmrichards@...> wrote:

Ken,
I would think that the right way to do this would be to treat each group of dolls and their associated arms for one track as a totally separate mast in Aspect Signal terms. The user would therefore have pre-designated just the arms that will apply to a single track and when taken together will show an Aspect. I hesitate to be absolutist, but I think for our purposes exceptions (like arms co-mounted on a doll for the reverse direction) can be treated as being a completely different mast.

The gantry or bracket in this case is a holder of masts (plural) although it can also be just one of course. It makes a difference visually but not as to signalling.

Once you have that distinct set of dolls and arms, you can see the routes being signalled as always left to right in dolls. The signal that is highest designates the "through"/principal route. The others are arranged to make the order of heights designate the relative importance of the diverging routes. It can be that they are all equal! That would imply a cautious for all routes - still they are left to right.

There is an exception here that very occasionally a single doll has more than one miniature stop arm in a set those are read top to bottom as left to right the highest is the most left, the second right of that, etc (always for a single mast, only for low-speed and goods yard work).

On a individual doll, let's talk about semaphores first - all the arms relate to activities from the track in question on that one route - on a passenger line they will basically have up to three arms, optionally a stencil and optionally a disc-signal (may be for a different route though).
? A Stop (always at the top if it exists).
? A Distant at the top or under the Stop.
? The stencil is what you have as a Group Head in Aspect Signalling. Rather than have a forest of dolls, in low-speed situations (like terminii) a single stop arm would be qualified by a head showing numbers or letters. This can also be used in association with the subsidiary as well to designate a platform for calling-on, for example
? If the Stop exists, there can also be a subsidiary arm (or a disc signal marked for the arm type) that allows restricted access along the same route as the home (either a call-on, a warning or a shunt).
? Call-on is for access into occupied tracks.
? Warning is for access to track sections where the track is clear, but there is a train within the clearing point of the next stop signal (in other words the driver should be REALLY certain they can stop before it). The clearing point is a safety margin built in to ensure that even if the train overshot the next stop aspect there would not be a collision. The use of a warning arm was only provided for those cases where otherwise there would be a routine delay. The most common example is at a junction for the branch-line train where the clearing point included the junction itself. If this wasn't provided, every branch-line train would obstruct the main-line.
? Shunt is to permit access to a clear main track section but the intent is not to go as far as the next stop, but to stop and reverse before it.
? There can also be a disc-signal(s) mounted at the foot of the post or doll. This will be to permit a shunt move(s) usually accessing sidings or crossing-over onto reverse running tracks. If there are multiple, they read left to right and/or from top to bottom.
Now to color!

The most important thing to know is that one aim in color light schemes was to reduce the need for route knowledge along the track. With semaphores you have to know if the next signal was to be a stop or a distant to drive the route safely but efficiently. Otherwise you could see a stop "off" and think you could increase speed until a distant but then hit another stop at "off". In color-lights you should always see a caution aspect (one yellow at least) before you see a danger. That is, any signal you see is giving you some indication of the state of the NEXT signal as well. (In four-color-light schemes, it is the next two signals or even these days three signals).

As color came in, in many cases the same dolls would be in the same arrangements as semaphores at first as the OP indicated. In very early schemes, the Stop would have been a two color red/green, the distant a yellow/green. Discs and subsidiary's would largely have been retained but perhaps with strong illumination. Even then, if the next signal has a stop signal, the replacement color-light would have been a three-color light so that the driver would know the state of the next signal, even if that meant a signal that never was above a yellow.

Often three-color lights would have been introduced to replace both the home and the distant semaphore combo. They were also used at isolated distant and isolated homes to increase train density (the aim was to have as an even signal spacing as as possible). Stencils were replaced with theatres (dot matrix light displays). Multiple discs and subsidiary arms would also have been replaced with one illuminated disc/signal and a set of lit stencils in an "eggbox" display (one bulb per indication behind some letters in a box) or completely done away with and replaced with position-lights mounted in the same area (the color-light equivalent of a disc signal) possibly with an associated eggbox or linked to the theatre. Note that stencils, theatres and eggboxes were unsuitable at high-speed and so multiple dolls would be retained unless there were junction indicators aka "feathers" - see below.

At the boundary between color and semaphores on the way into a color-light area, the pattern was the last stop arm would be retained and under it was a 3 color light where two of the lights were yellow. The signal would show red (stop) over unlit, green over two yellows, or green over green - this simulated the way the semaphores would have looked and provided some context that a change was occurring. When going from color to semaphore, no special signalling arrangement was needed.

The use of separate dolls largely ceased when the three- or four-color signals got "feathers" on a single head. There could in theory be up to 7 routes indicated by one head (no DI illuminated implies no route divergence) but in practice the combos where two feathers are opposed were rarely used because of the potential for confusion about which of the route was being displayed at night - so 4 routes per head would be the practical maximum. Once that was done, the need for multiple dolls for a single mast was largely eliminated.

Note - Multiple Masts on one bracket or on one gantry persist today - and due to restrictions in height and/or sighting the assorted heads may be closely mounted horizontally, for example, but the route is not communicated by relative position or head height.

=====

So - I think the right way to do this is not to treat a gantry or bracket as one signal but rather a repository on which multiple masts exist (each designated to a track or tracks by a user). Within that knowing about dolls allows the rules for doll heights and left-right positioning will provide a useful approach on route designation and therefore which Aspect can be shown - unless feathers or a theatre/stencil is used in which case it will be explicit, of course. For subsidiaries/position-lights/discs there is often too much to know to automate. They might be simply set if a turnout is thrown (goods yard entry, or reverse crossover) but they could be a calling on light or a reverse or shunt move over a facing crossover that needs a decision based on knowledge of the purpose of the train or trains. The most that can be done is probably to know which Turnout if any can be tested - and to ensure that the position only illuminates (of the subsidiary or disc only goes to off) if the associated head shows stop and a train is sitting in the Block in front of the Signal.

Adam

--
Bob Jacobsen
rgj1927@...

There are 2 elements to? Rolling Thunder; the transmitter and the receiver.

The Transmitter is part of the Paragon 3 decoder. The receiver is the the second element and is connected to the sub-woofer.

The Rolling Thunder definition in DecoderPRo is for the Receiver programming/ setup.

The Paragon 3 definition has the transmitter related CV's.

Here is a link to the Tech Ref manual for Rolling Thunder receiver.



Marc

--