开云体育

开云体育

It just goes to show how difficult it can be to get a workable solution in a complex environment if you don’t keep your eye on the ball!

Hi Steve,

Thanks for the heads up on Priority, I suspected it was currently "an undocumented feature".

I will investigate the Pause allocation feature again once I have my layout up and running again. ?I was a bit pressed for time before the show so if something did not work as I expected I did not spend a lot of time playing. ?Other more pressing issues to solve and simply used workarounds if possible.

Trains failing to stop at the end of a Transit were definitely ignoring the held signal at Stop. ?The Auto trains window still showed the throttle as being at the speed setting the train had when it entered the section. ?I was using continuos running but with a fixed delay time 10-60 fast clock minutes before that train was "scheduled" to be re dispatched. ?Fortunately this did not cause dramas for the show because all the staging tracks have a dead section before the departure road which only becomes active when the turnouts for that road are aligned (belts and braces). ?This feature was a hangover from previous hardwired train sequencing but was similar in operation to another recent thread on this forum about stopping trains running into turnouts.

I suspect the horn issues were loco pickup related. ?Poor contact at the instant the command was sent resulted in it being lost. ?It became more common towards the end of the day when track and loco wheels were becoming less than pristine. ?In any case sending a second turn off command did seem to work and is not difficult. ?I will look at using a text editor to find and replace the horn commands in the transits to send a delayed function 2 off command after each sound horn command. ?I was only using single timed blasts as my quick investigation of play a pattern did not appear to function as I expected. ?More play time is required.

At the moment all the signal masts are virtual; (CTC, track circuits and automatic signalling did not feature in the location and time period of my layout), ?I just have some Logix controlled semaphores (signal heads) on the layout which follow the appropriate signal masts. ?(My drivers running the Automatic Trains use "In Cab" signals.)

Many thanks for yours and others great contributions to JMRI. ?

Don

Thanks Bob, it was a lot of fun for all concerned.

? ?It sounds like you may have a reliability issue with LocoNet communications when things get very loaded (lots of trains moving).

I think LocoNet reliability was OK, the Monitor LocoNet window was not overly busy. Generally there were no more than 3 trains actually moving at any given time. ?In future I will reduce LocoNet traffic by optimising my Loco momentum settings rather than having auto trains doing a lot of speed ramping. ?The lost "horn function turn off" commands {only happened about once in every few hundred horn blasts) were most likely momentary contact issues. ?Sending a second turn off command worked fine.

The times when I had locos failing to stop at a held red did not seem to correlate with messages in the system log. ?It would have been nice to simply stop everything after a SPAD to investigate but in an train show situation "the show must go on".

Here are a couple of extracts from the System Console Log of stuff I don't quite understand.

I am a new arrival to JMRI. I want to use the spdt switch on my Smail machine to provide feedback to JMRI as to actual switch position. Is there some simple interface to send this signal via LocoNet to JMRI?

Stephen,

Most users I've worked with are only adding one piece of hardware at a time
and testing it. That is a strongly recommended practice. They then move the
usernames to the new hardware system address. Many times the addressing and
even device types may change between the time you started design and build
some sections of the layout. This also makes it simpler on the case of which
pin did I connect this to? You can make your connections and then make the
move. Your testing via the system name confirms which entry it ended up
being.

Even on layouts I've designed, parts changed from the planning days to the
implementation days. New designs come along etc... So I've only got lucky on
bulk moves (using text edit tricks) being usable only for some sections.

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

Rummy,

On 11 Jun 2019, at 10:19 AM, rummy@... wrote:

I have the same desire, so I have a network drive that is accessible by both my laptops via my wifi network. The JMRI on either laptop does not actually use the files on the network drive. I make updates on the "remote" laptop, copy the files to the network drive, then using the layout laptop, I copy the files from the network drive to it for use on the layout.

It also has the benefit of having several copies in case of a hard drive crash!

That's a manually updated local equivalent of using Dropbox:
<>

Dave in Australia

I have the similar setup: ?JMRI 4.14.0, Mojave 10.14.5, and latest Java. ?However, my Mac is 3 years old and I'm using a PR4. ?Everything works as it should. ?I don't know what you can glean from that, other than your issue probably relates to the PR3 and/or new type of USB.

Good luck,
Rummy

I have the same desire, so I have a network drive that is accessible by both my laptops via my wifi network. ?The JMRI on either laptop does not actually use the files on the network drive. ?I make updates on the "remote" laptop, copy the files to the network drive, then using the layout laptop, I copy the files from the network drive to it for use on the layout. ?

It also has the benefit of having several copies in case of a hard drive crash!

Rummy

Stephen,

Since the system name format is specific to a particular connection type, it is not feasible to change just the connection type.

For example, “LS101" on LocoNet might be "MS1.2.3.4.5.6.7.8;1.2.3.4.5.6.7.9” on LCC or CS1001 on CMRI.

If you look at the panel xml file, you will see a class specification for each connection type and object type. For example: class="jmri.jmrix.loconet.configurexml.LnSensorManagerXml” for saving and loading LocoNet sensors.

Some objects have type specific features such as available feedback options for turnouts. Trying to load such an item in a class that does not support the option will result in an error.

The bottom line is that the system name is a LOT more than just the connection character. It is a lot of work to move hundreds of user names from one system name to another, but for most people it is a one time project. They are not going to replace all of their hardware frequently.


Dave Sand

SwissChris,

On 11 Jun 2019, at 6:59 AM, SwissChris <chris@...> wrote:

Thanks Dave. I was not aware of that. I'll set up test decoders of both types and see how they run together. So in effect we can have Signals, Turnout and mobile decoders using the same addresses on one system.

Correct. In fact, you can have four different decoders in operation at the same numeric address, with each accepting only their own intended command.. For example:
- A mobile decoder set to short address 1.
- A mobile decoder set to long address 1.
- A turnout decoder set to turnout address 1.
- A signal decoder set to signal address 1.

I'd like to give you the sample actual address byte format for each packet type (all specified in S9.2.1) but such things get time-consuming and fiddly on an iPad.

The other thing to be aware of is that there was some ambiguity of interpretation of NMRA S9.2.1 when it comes to signal addresses. Different manufacturers have interpreted the standard differently, with a result that the values in the signal packet address bytes can differ by 4 between decoder manufacturers. In JMRI we mainly use raw DCC packets to control accessory decoders, so we have code to deal with this when generating a packet. From a user point of view, if you are using NCE signal decoders you need to check the "Offset Address" box when you enter the DCC address for the signal decoder in the Signal Head table. This is irrespective of the brand of DCC system actually sending the DCC packets.

Now, if I only I could configure the Light its to act as directional lights running the same address as the mobile decoders.

Unfortunately the Light-It is direction-insensitive in Mobile Decoder mode.

Dave in Australia

Hi All.

Dave says
------------------------------------------------------------------
why is there a need to ‘associate’ each line entry when there could be hundreds of line entries to go through? I understand the need to tie the System Name to the User Name of the actual component on the layout but having to do this one-by-one! Surely if the records are stored within a Table why can’t we use something like ‘Find and Replace’ within the System Name Field to change the Code Letter from using the original ‘I’ Internal to using the ‘M’ MERG code or whatever system code is appropriate when we actually change the Configuration Profile from Internal to our chosen system type? The same could also apply to when we are changing DCC Systems, say from ZTC to Lenz?

Dave
-----------------------------------------------------
Is it possible to have JMRI change the system name depending on the dcc system in use?
ie when changing from a simulated DCC++ system to real DCC++ hardware that the appropiate internal name is used?

Or have I completely misunderstood what the quoted paragraph is saying?

Stephen

开云体育

Re?DiMAX? 800Z

That does seem strange. I am not at all an expert but I simply copy them onto my USB and take it into the house. I have done this many times with no problem.

Thanks Dave. I was not aware of that. I'll set up test decoders of both types and see how they run together. So in effect we can have Signals, Turnout and mobile decoders using the same addresses on one system. Now, if I only I could configure the Light its to act as directional lights running the same address as the mobile decoders.

SwissChris and others,

On 11 Jun 2019, at 2:42 AM, SwissChris <chris@...> wrote:

NCE light-it signal decoders through the standard DCC track bus.
<snip>
The 3 systems I use together mean that I have 6144 accessory addresses to play with. <snip> Signals are in the 801 - 900 range

As you probably already know, if you configure your NCE Light-Its to function as NMRA-conforming Signal Decoders (also known as Extended Accessory Decoders), they use the completely separate Extended Accessory address range of 1-2044 and in no way overlap with your Turnout Decoders (also known as Basic Accessory Decoders) as they use the completely separate Basic Accessory address range of 1-2044.

There's no confusion or overlap between NMRA-conforming signal decoder addresses and turnout decoder addresses. The DCC packet format is different and the decoder only responds to its own address type. JMRI knows how to send both packet formats and you select that when you create your Signal Heads.

Just mentioning this because it's a common source of confusion among DCC users.

Dave in Australia

To make customizing "sensors as text" even easier, select Properties from the context menu. ?