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

--

This topic is now locked.

With over 50 messages the topic has degenerated and I believe Larry (the original poster) is no further
ahead from reading his 4 posts to the topic.

I am asking Larry to start a new topic with his issue and for everyone except Dave Heap (the resident NCE expert on this and the NCE list) and Ken Cameron
to stay out of the discussion so that Larry can get his problem rectified.

--
Peter Ulvestad

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

Marcus,

You only snip a portion of what I said.......I said.............."I think he up and running and that's what counts".??

I said long time ago I got it working. As soon as I did the power connection "work around" it came up.? Now people who are knowledgeable and just stating facts are chiming in and answer the?
"Quirks" I spoke of......
For example the disconnect "work around" I mentions actually initializes the jumper settings. A user can make jumper changes and never disconnect from the Power Cab causing the?
setting to remain the same. So when I was disconnecting the coiled cable I was causing the reset hence the connection.?

I'm going to make sure that I answer your questions. '

I have asked this a few times now, can the RPi4 with Steve’s image be used to program loco decoders.

Steve's Image does work but the user must be aware of a few potential snags......

Steve's Image opens to Panel Pro. Panel Pro does not respond to an initial setup like Decoder Pro. The Default setting in his image starts
Panel Pro with Version 6 and 9600 baud. If the user go through the motions of making the setting changes while the NCE USB Interface is in the 20
second cycle. This timing? miss could potential miss alignment. The user will make another change thinking something else is wrong. This pushes him
deeper into the rabbit hole. This is why a specific procedure need to be written for the RPi's with the Image.?

I imagine if it could be done, you’d have connect a Keyboard and Monitor to do it – some would find much easier to do with a Laptop.

The raspberry pi can be connected to a TV or any HDMI port as well. Users with unix experience can set up one in what's called headless. Actually
the Raspberry is better in that you can it runs on 5 volts and is compact. I would image that the RPi5 will make the laptop obsolete.

This is a RPi Zero w look at the size. It boots by itself and you can connect via the web server from another PC.?

Once a solid procedure is written for it there wont be many complaints.?

Inobu

开云体育

Marcus,

I have 14 computing devices that support everything from XP to 10, Laptops, tablets and all the way down to the Raspberry Pi Zero. Ipads, Ipods the only thing I dont
have is a Mac. What ever my customers have I have.?

The reason I have all of these devices is......When my customer (Larry just reference example) calls with a problem I don't try to duplicate his problem on a Laptop. My objective
is to resolve his issue so I have to repeat what he is doing. To address his problem RPi 4 problem I need to use and test with a PRi4 and nothing else.

I think he up and running and that's what counts.??

What I find hilarious is I lead teams testing $17 Million systems and this NCE USB Interface is what $49.00. lol

Inobu ?

FYI, the jumpers are only read when the USB is first powered up.? Changing the jumpers while the card is powered up does NOTHING.

From NCE:

开云体育

Marcus,

Inobu is not encountering any issue with the Powercab and RPI4.. He was simply trying to help LARRY ( from a different thread )? who reported his issue with this, same,? setup.

Inobu? was reporting? the condition he discovered while trouble shooting the issue using the Steve Todd supplied? RPI4 image and Powercab/NCE USB setup.

Seems like in many cases it is a question of JUMPERS being set wrong.?

Providing the System Console Log should be a prereq in ALL CASES? people reported.

Marc