Jim:

I am using JMRI as a stand alone programmer.? I am not using it through a DCC
system.? The setup consists solely of a piece of track, Digitrax PR3, and a
computer with the JMRI software on it.?

I will need to check the current output of the power supply that I am using,
but it is 18 V output.? I have had trouble with power supplies of lower
output (14-15 V).? The problem seems to be that JMRI is not getting a
response back from the decoder (Error 308).

I tried manually selecting the Paragon3 Steam definition, but that did not
solve the problem.

Michael

Andy,

The short answer: JMRI does not.

As far as JMRI knows, it is just two parallel tracks. Since only one train can be in the gauntlet it needs to be protected like a single track line.

The initial inclination is to treat the gauntlet as one block. That leads to a lot of potential issues relating to block routing, signaling and automation.

It is a lot cleaner to declare the gauntlet as two blocks. Depending on the requirements this may require Logix. For basic signaling the SSL or SML needs to look at both blocks.

Dave Sand

On Nov 27, 2018, at 5:55 PM, Andy Reichert <andy_r@...> wrote:

Just an off the wall thought from a not yet active user, triggered by this thrread

Hows does JMRI view gauntlet track sections?

Andy

---
This email has been checked for viruses by AVG.

On Nov 27, 2018, at 5:55 PM, Andy Reichert <andy_r@...> wrote:

Just an off the wall thought from a not yet active user, triggered by this thrread

Hows does JMRI view gauntlet track sections?

Andy

---
This email has been checked for viruses by AVG.

On Nov 27, 2018, at 5:32 PM, Dave Roberts <dccdaveroberts@...> wrote:

Dave,

Once again, thank you for your insight. I believe that you may be correct in your supposition - Wood and Trees springs to mind!

If the appropriate Signals are also considered at the initial stage of the layout design then that would explain some of the apparent anomalies and these, as you suggest, are to eliminate accidental Pairing of Turnouts.

However, since Crossovers require two Turnouts then it does follow that, just as with Slips, the Crossovers, when selected, should also be allowed to select the "Additional Name” field too.

I think it is still worth pursuing the request to have this change applied to the Tool Bar of the Layout Editor.

Dave.

On 27 Nov 2018, at 21:25, Dave Sand <ds@...> wrote:

Dave,

It appears to me that you are assigning an attribute to position A that does not exist. A to D are track segment connection points and provide a handy means of identifying the routes through a cross-over or slip, such as A <--> B.

JMRI knows that the point ends for a left hand cross-over are at B and D. And are at A and C for a right hand cross-over.

On the tool bar, the "Additional Name" field is only active for slips. They require two turnouts. I don’t know the reasoning behind the design. One thought is that requiring explicit actions in the Edit screen to select the additional turnout eliminates accidental turnout pairs.

Dave Sand

On Nov 27, 2018, at 2:23 PM, Dave Roberts <dccdaveroberts@...> wrote:

Dave,

Thank you for the explanation. I understand the convention being used to identify the attached Blocks and see the underlying logic.

What I am also seeing in the actual icons used for both RH and LH Crossovers in the Tool Bar of the Layout Editor is a breakdown in the logic. With the RH Crossover icon position A is identified as the Top LH corner and this is correctly shown as being on the Throat of the Turnout. As you say, going clockwise, A & B are on one route and C & D are on a separate route.

It is not possible to repeat this for the LH Crossover - using the Throat of the turnout as A - without placing A at the Top RH Corner and reversing the direction. Given that this may prove to be problematic to implement and the fact that the Blue is only to identify the 'Start Position A' in the sequence then it should not matter which connection is made first so long as the pairings are maintained.

With regard to the Turnout Name and Associated Turnout Name fields. In the Tool Bar of the Layout Editor when I select a Crossover I am allowed to enter a Name in the Turnout Name field but I cannot select the Associated Turnout field and enter data here. This is in line with the Notes that say there is usually only one turnout in the Turnout Table since both turnouts are operated as one, at the same time. However, this is a connection that JMRI need to be aware of. This is dealt with using the Turnout Editor where this Associated Turnout can be edited in. I was just asking that the Field in the Tool Bar of Layout Editor be changed so that the Alternative Turnout's Name can be added here too.

A final thank you for the Mac keystroke info. I'll try this when I get to the next Crossover/Slip/Double Crossover.

Dave

On 27 Nov 2018, at 21:25, Dave Sand <ds@...> wrote:

Dave,

It appears to me that you are assigning an attribute to position A that does not exist. ?A to D are track segment connection points and provide a handy means of identifying the routes through a cross-over or slip, such as A <--> B.

JMRI knows that the point ends for a left hand cross-over are at B and D. ?And are at A and C for a right hand cross-over.

On the tool bar, the "Additional Name" field is only active for slips. ??They require two turnouts. ?I don’t know the reasoning behind the design. ?One thought is that requiring explicit actions in the Edit screen to select the additional turnout eliminates accidental turnout pairs.

Dave Sand

On Nov 27, 2018, at 2:23 PM, Dave Roberts <dccdaveroberts@...> wrote:

Dave,

Thank you for the explanation. I understand the convention being used to identify the attached Blocks and see the underlying logic.

What I am also seeing in the actual icons used for both RH and LH Crossovers in the Tool Bar of the Layout Editor is a breakdown in the logic. With the RH Crossover icon position A is identified as the Top LH corner and this is correctly shown as being on the Throat of the Turnout. As you say, going clockwise, A & B are on one route and C & D are on a separate route.

It is not possible to repeat this for the LH Crossover - using the Throat of the turnout as A - without placing A at the Top RH Corner and reversing the direction. Given that this may prove to be problematic to implement and the fact that the Blue is only to identify the 'Start Position A' in the sequence then it should not matter which connection is made first so long as the pairings are maintained.

With regard to the Turnout Name and Associated Turnout Name fields. In the Tool Bar of the Layout Editor when I select a Crossover I am allowed to enter a Name in the Turnout Name field but I cannot select the Associated Turnout field and enter data here. This is in line with the Notes that say there is usually only one turnout in the Turnout Table since both turnouts are operated as one, at the same time. However, this is a connection that JMRI need to be aware of. This is dealt with using the Turnout Editor where this Associated Turnout can be edited in. I was just asking that the Field in the Tool Bar of Layout Editor be changed so that the Alternative Turnout's Name can be added here too.

A final thank you for the Mac keystroke info. I'll try this when I get to the next Crossover/Slip/Double Crossover.

Dave

On Nov 27, 2018, at 2:23 PM, Dave Roberts <dccdaveroberts@...> wrote:

Dave,

Thank you for the explanation. I understand the convention being used to identify the attached Blocks and see the underlying logic.

What I am also seeing in the actual icons used for both RH and LH Crossovers in the Tool Bar of the Layout Editor is a breakdown in the logic. With the RH Crossover icon position A is identified as the Top LH corner and this is correctly shown as being on the Throat of the Turnout. As you say, going clockwise, A & B are on one route and C & D are on a separate route.

It is not possible to repeat this for the LH Crossover - using the Throat of the turnout as A - without placing A at the Top RH Corner and reversing the direction. Given that this may prove to be problematic to implement and the fact that the Blue is only to identify the 'Start Position A' in the sequence then it should not matter which connection is made first so long as the pairings are maintained.

With regard to the Turnout Name and Associated Turnout Name fields. In the Tool Bar of the Layout Editor when I select a Crossover I am allowed to enter a Name in the Turnout Name field but I cannot select the Associated Turnout field and enter data here. This is in line with the Notes that say there is usually only one turnout in the Turnout Table since both turnouts are operated as one, at the same time. However, this is a connection that JMRI need to be aware of. This is dealt with using the Turnout Editor where this Associated Turnout can be edited in. I was just asking that the Field in the Tool Bar of Layout Editor be changed so that the Alternative Turnout's Name can be added here too.

A final thank you for the Mac keystroke info. I'll try this when I get to the next Crossover/Slip/Double Crossover.

Dave

On Nov 27, 2018, at 12:27 PM, michelplouffe4748@... wrote:

Dave, thanks for the high level explanation. My problem is the values that I have to set in the decoder itself to set it to receive messages from JMRI, i.e. the address of the decoder and the cv values for each output. I am programming them via signal mode on my handheld. Secondly, once I have set those values in the decoder, how do I transfer that information to the JMRI tables. In other words, what corresponding values do I set in the signal head table to match the 3 outputs of the signal decoder? I really need an example of steps to take. Cheers. Mike from Canada

-----Original Message-----
From: [email protected] <[email protected]> On Behalf Of Dave Sand
Sent: Tuesday, November 27, 2018 11:49 AM
To: [email protected]
Subject: Re: [jmriusers] NCE Light-IT decoders used with JMRI for Signals - Issue is Programming Addresses and Outputs for Signal Heads

Is the Light-It configured as a mobile, accessory or signal decoder? For signal head purposes, signal decoder is recommended.

When the signal head is defined, "DCC Signal Decoder" is selected, the hardware address is entered and "Offset Address" is selected. Depending on the connection type and command station, the "Offset Address” option may or may not be required.

BTW: Signal masts and signal mast logic work fine with Light-It. The Light-Its are driven by signal heads and the signal mast is defined as a "Signal Head Controlled Mast" with the proper signal heads assigned.


Dave Sand

On Nov 27, 2018, at 10:10 AM, michelplouffe4748@... wrote:

I am in the process of building a signal system for my HO Layout using NCE Light-It decoders. My system is a NCE Powerhouse Pro hooked up to a desktop computer via a serial cable I am running JMRI version 4.12 and have built a Panel with the track plan including "Internal" signals. I have programmed the signals with SSL and all works fine when I run an engine through the blocks on my physical layout. The signal heads on the panel give the correct aspect on the 3 color signal heads. Now, I am ready to replace one by one each "internal" signal head with a BLMA signal on the layout itself.To do this, I program the Light-It Decoder to the same address (IHXX) as the internal signal and set the 3 outputs (CV 137,138,139) on the decoder to show a steady on "value of 1" effect. At this point, I am lost as to how to set the signal head table for the Light-IT decoder in JMRI. I tried hooking up a BLMA signal on my workbench with the Light-It tied to the cab bus and programmed the same signal address in the decoder and the 3 outputs as I had in the Internal signal but it failed to replicate the virtual signal indication. Can someone take me through all the steps needed to program the Light-It decoder in JMRI. I am not using signal masts as I have a decoder for each signal head. Thanks. Cheers. Mike from Canada

On Sun, Nov 25, 2018 at 8:48 PM Bob Jacobsen <rgj1927@...> wrote:

Very impressive group of components!

IIRC, when JMRI is connected to OpenLCB CAN, each new Sensor or Turnout will cause a few (3-4) messages on the wire. Each new OpenLCB-connected signal is probably a few more.? Even at 1000 messages/second, the file below looks like a full wire for 15 seconds or more.

Any thoughts on where JMRI needs work to stay ahead of that?? (Not talking about slow; asking about not able to keep up, i.e. dropping messages, etc)

Yeah, good point, we had quite a major problem about that a while ago. Right now JMRI performs infinite length input buffering ()?on the reader thread of the serial CAN adapter so that when the layout thread is behind in consuming the messages, we are still not losing data. This is good enough to catch bursts of traffic like startup, layout startup (with a similar number of messages), startup of another JMRI machine, GIE messages, CDI downloads and maybe firmware uploads, etc.??

It won't help if we have a permanently 100% loaded bus. At that point the only thing we can do is improve the performance of message processing inside JMRI so that it can keep up with the wire speed. That's probably going to be a major undertaking with far-reaching consequences that are hard to estimate right now: we may have to revise the threading model to take openlcb message processing off the AWT thread; we may have to add filtering and optimized lookup data structures to route messages; we may have to revise the TrafficController component and/or how the Sensor, Turnout, Mast objects interact with it.

This is all for incoming traffic.

For outgoing traffic, we will always be limited to producing traffic (to the network) roughly at the same speed as we are able to process that on the layout thread, unless we do some of that major surgery. I think the file above takes about 27 seconds to generate all outgoing startup events when writing to network (not throttled by a CAN bus). Exact stats are 56 olcb signal masts, 447 olcb turnouts, 1278 olcb sensors.

Balazs

?

Bob

> On Nov 24, 2018, at 3:16 AM, Balazs Racz <balazs.racz@...> wrote:
>
> Here are the statistics from Leo's file. Given that they have almost 30 panels, averaging about 300-500 kbytes, it's not super surprising that the file size is large.
> Here are the toplevel entries in the file, how many lines and bytes within them:
>
> [lines] [bytes] [toplevel tag]
> 9 369? ?</jmriversion>
> 4688 152618? ?</sensors>
> 13572 475930? ?</sensors>
> 199 8660? ?</turnouts>
> 514 22581? ?</turnouts>
> 4818 179016? ?</turnouts>
> 4669 129238? ?</memories>
> 4100 148110? ?</signalmasts>
> 14071 774815? ?</oblocks>
> 7167 557358? ?</warrants>
> 1080 43248? ?</signalmastlogics>
> 2129 123542? ?</logixs>
> 17092 1913210? ?</conditionals>
> 1365 93844? ?</paneleditor>
> 944 68485? ?</paneleditor>
> 1135 104049? ?</paneleditor>
> 1394 100462? ?</paneleditor>
> 1577 112003? ?</paneleditor>
> 8103 567587? ?</paneleditor>
> 8085 586349? ?</paneleditor>
> 9089 521530? ?</paneleditor>
> 1841 128889? ?</paneleditor>
> 4046 283386? ?</paneleditor>
> 6838 473988? ?</paneleditor>
> 22295 1347682? ?</paneleditor>
> 1136 93124? ?</paneleditor>
> 8723 581088? ?</paneleditor>
> 8372 519126? ?</paneleditor>
> 354 23946? ?</paneleditor>
> 600 40767? ?</paneleditor>
> 249 16619? ?</paneleditor>
> 2909 210890? ?</paneleditor>
> 18106 1054396? ?</paneleditor>
> 1573 117227? ?</paneleditor>
> 4229 276282? ?</paneleditor>
> 1597 122579? ?</paneleditor>
> 505 36567? ?</paneleditor>
> 5689 395440? ?</paneleditor>
> 4049 281057? ?</paneleditor>
> 5302 367983? ?</paneleditor>
> 2846 200725? ?</paneleditor>
> 20327 1205349? ?</paneleditor>
> 102 3864? ?</filehistory>
> 227490 lines 14464076 bytes
>
> As for the load time, I have observed extreme load times for openlcb layout files myself as well and fixed the openlcb load speed as of 4.13.5.
>
>
> On Wed, Oct 31, 2018 at 12:40 AM leo pesce <lpescester@...> wrote:
> Ken,
>
> A few thousands of (all together) sensors, turnouts, blocks and logix. About 2K external data points and many Ks of active icons.
>
> 99% of standard icons and a few custom ones.
>
> BTW, this is the Cumberland West of David Parks.
>
> LeoP
>
> On Tue, Oct 30, 2018 at 3:30 PM Ken Cameron <kcameron@...> wrote:
> LeoP,
>
> How many sensors, turnouts, blocks, and logix are there? Do you have a lot
> of custom graphic files, or just the system standard stuff?
>
> Yes that is a lot of panels. And you are right, presuming the file has not
> changed (size) over the period, it has jumped a bunch on time, and that's
> not right.
>
> -Ken Cameron, Member JMRI Dev Team
>
>
>
>
>
>
>
>
>
>
>
>
>

--
Bob Jacobsen
rgj1927@...

On 28 Nov 2018, at 4:28 AM, Classic Auto Portraits <classicautoportraits@...> wrote:

While JMRI is excellent software, manufacturers such as BLI will point out that JMRI is not NMRA compliant. I've not taken the time to research what "NMRA Compliant" is...