开云体育

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

Randall,

Worked like a charm.

I think that the only quibble I have remaining at the moment for Web Server and Ops is one I mentioned a while back (Groups.io discussion here) is related to the display of the hyphen feature for location and track names in certain instances. As an example, the manifest view will show a location of 63108 and a track name of Connell Yard-(Team), and the conductor view will show the same information as 63108-(Connell) and Connell Yard-(Team). A printed manifest shows everything correctly, e.g. 63108 and Connell Yard.

Sam

OK, my bad, sorry. The second menu appears as soon as you do "Change to Text" .

Hi again. Still learning, and finding out some fascinating stuff in PanelPro. Like the awesome backup feature, discovered by accident, which saved my bu** , where panels previously saved under the same name are saved with different names.

And now, discovering the great flexibility in how you make sensors and other objects look on the panel. "Debugging"" my problems, I'm finding it great to be able to show the sensors' names. And on some sensors I'm able to give different text and colors to the active and inactive state.

So here's my question: I said for SOME sensors, and I don't understand why that is: some sensors seem to have one context menu (what you get when you right-click), others have another. Those two menus have about half or their items identical, others different. For instance, some have "Set Text for Sensor States" which I find VERY useful, while others don't. As I said, the sensors are otherwise identical (as far as I can tell). I'd be happy to put the pictures of the entires menus in a message, but I don't know how to insert pictures.

Thanks!

If you want JMRI (or any other software) to talk to a particular hardware device, you have to tell it _which_ hardware device. JMRI uses system names for that. If you don’t yet have hardware definitions (no Turnouts, Sensors, etc defined) for a particular hardware system, and you want to use those devices, you’re going to have to create them before JMRI can talk to them.

If your JMRI-internal (i.e. starts with the letter I) definitions are _exactly_ those that map to the hardware, you could imagine doing this automatically by just defining a new connection, i.e. for LocoNet, with a system letter of I and using your existing definitions. But that _never_ works, at least in my experience, because any significant size layout has some really-should-be-internal devices, needs to have options set on Turnouts/Sensors/Lights, etc.

Somebody could write a script to help automate the conversion, but there’s been little interest in doing that because it’s likely to be so very much layout specific.

It might be a bit faster to edit the configuration file (after saving it with the new device definitions; don’t forget to back up!) with find-and-replace. Particularly if you have a consistent naming convention, that might be quite quick.

But if you don’t want to do that, JMRI provides a way to do it via the tables, one item at a time. Since doing that for each item takes significantly less time that actually installing the hardware on the layout, that’s generally seen as a reasonable solution.

If you have more extensive needs, or think there’s a more general need here and others might appreciate some new tool, it would be _great_ if you worked on code for your solution. Here’s a link to help you get started:



Bob

On Jun 10, 2019, at 8:58 AM, Dave Roberts <dccdaveroberts@...> wrote:

Hi Dick,

Fortunately, when I first started out with JMRI I had already developed a Unique User Name system that was flexible enough to meet both my immediate and future requirements to cope with the layout as it grew in size over the years. This 'User Name' system easily slotted into the JMRI User Name field in the Tables and required no changes to be made to any of the names so providing the stability within the program.

As you rightly point out it is the 'System Name' that causes the problem because of the Stability requirement - it has to be both Unique and formatted according to the Manufacturer’s Hardware System being used although, on reflection, this may not be so if the Internal type is used throughout?.

Thus my question regarding “Which one do I use? ‘Lenz' because the DCC Train Control System is the new Lenz one and the wireless WI Throttle throttles and iPad2/2 Tablets used or do I use ‘MERG' because the Layout Control side is split from the Train Control System and deals specifically with all Turnouts, Signals, Block Occupancy Detectors and Positional Feedback data in the data flow between Tablet layout diagram (JMRI) and the actual layout or do I just leave the whole lot set to Internal?

When these Configuration and Defaults have been decided, at the very beginning, then we can move on to using the Layout Editor to create our ‘Whole Layout' file whilst JMRI creates the appropriate 'System Name’, based upon our original setup profile choices for the track work and control devices we want to put onto the layout and adds these entries into the appropriate Table.

The big problem is that once an entry is made into a Table the System Name is then ’Set in Concrete’ and cannot be changed for the reasons of Stability within the program and which is used throughout the program. There is no allowance at this early stage for mistakes made by the new user and so, over time, several erroneous entries are added into the tables that will eventually slow the processing down unless they can be removed but that’s another story!

Whilst learning JMRI I also used the “AnyRail” program to help me design the layout and create lists of track requirements. As you know, working with Dave at “AnyRail” and his team, a method of converting the “AnyRail” format file into xml format that could be read by JMRI was developed and has proven to be a reliable conversion with few errors. It is important to remember here that at this stage there is no actual physical layout.

The Conversion process now creates all of the Tables required within JMRI and populates the tables with all of the components used to design the layout using the User Names only and leaves the System Name field blank.

The user now starts to build their actual layout, part by part, section by section adding in actual real Turnouts, Signals, etc as they go. In so doing the Unique System Names for every component are being created as the Turnout/Signal motors are added into the layout and given their Unique identity, created by the Manufacturer using their own naming rules. Hopefully, these are being written down somewhere for future reference (Excel Spreadsheet perhaps?)

It is only now that we get to your comments regarding using Unique User Names and ignoring System Names. Whether the user enters the components, one by one, into the appropriate Table directly in JMRI or the ‘Whole Layout' data is imported into JMRI is it JMRI that will create the Unique System Name for each entry? The User does not have access to this field to edit it. You say: “...then you can move that association to a new system connection. (one by one) The importance of this is that you will not need to change all the places that use each item like you would when using the system names to identify items.”

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

On 10 Jun 2019, at 14:40, dick bronson via Groups.Io <dick@...> wrote:

Dave,

If you only use 'System Names' then you are stuck because those are the actual hardware connections, and changing the hardware obviously requires different connections. However if you have used 'User Names' for each item, then you can move that association to a new system connection. (one by one) The importance of this is that you will not need to change all the places that use each item like you would when using the system names to identify items.

Dick :)

On 6/10/2019 5:21 AM, Dave Roberts wrote:

For those users who have spent hours and hours creating their 'Whole Layout' file using 'Internal', perhaps over several months of learning, does the act of changing to a specific DCC manufacturer automatically change the 'System Names' already created within the xml file or do we have to go through the whole file again and edit each System Name bearing in mind the need to maintain stability within the file? This question also applies to those of us who decide to adopt a second Manufacturer when we hive off the Layout Control from the Train Control. If I read the responses correctly, in my case, the Default was originally 'Internal' Naming within JMRI.

--
Bob Jacobsen
rgj1927@...

I’m able to use Safari on my old iPad 1 using the frame server option. I don’t recall the exact text of the url to use/append at the end but I didn’t have any hassle once I enabled that.?
When I get home I can respond with the exact setup on mine that’s working.?

Hi Dick,

Fortunately, when I first started out with JMRI I had already developed a Unique User Name system that was flexible enough to meet both my immediate and future requirements to cope with the layout as it grew in size over the years. This 'User Name' system easily slotted into the JMRI User Name field in the Tables and required no changes to be made to any of the names so providing the stability within the program.

As you rightly point out it is the 'System Name' that causes the problem because of the Stability requirement - it has to be both Unique and formatted according to the Manufacturer’s Hardware System being used although, on reflection, this may not be so if the Internal type is used throughout?.

Thus my question regarding “Which one do I use? ‘Lenz' because the DCC Train Control System is the new Lenz one and the wireless WI Throttle throttles and iPad2/2 Tablets used or do I use ‘MERG' because the Layout Control side is split from the Train Control System and deals specifically with all Turnouts, Signals, Block Occupancy Detectors and Positional Feedback data in the data flow between Tablet layout diagram (JMRI) and the actual layout or do I just leave the whole lot set to Internal?

When these Configuration and Defaults have been decided, at the very beginning, then we can move on to using the Layout Editor to create our ‘Whole Layout' file whilst JMRI creates the appropriate 'System Name’, based upon our original setup profile choices for the track work and control devices we want to put onto the layout and adds these entries into the appropriate Table.

The big problem is that once an entry is made into a Table the System Name is then ’Set in Concrete’ and cannot be changed for the reasons of Stability within the program and which is used throughout the program. There is no allowance at this early stage for mistakes made by the new user and so, over time, several erroneous entries are added into the tables that will eventually slow the processing down unless they can be removed but that’s another story!

Whilst learning JMRI I also used the “AnyRail” program to help me design the layout and create lists of track requirements. As you know, working with Dave at “AnyRail” and his team, a method of converting the “AnyRail” format file into xml format that could be read by JMRI was developed and has proven to be a reliable conversion with few errors. It is important to remember here that at this stage there is no actual physical layout.

The Conversion process now creates all of the Tables required within JMRI and populates the tables with all of the components used to design the layout using the User Names only and leaves the System Name field blank.

The user now starts to build their actual layout, part by part, section by section adding in actual real Turnouts, Signals, etc as they go. In so doing the Unique System Names for every component are being created as the Turnout/Signal motors are added into the layout and given their Unique identity, created by the Manufacturer using their own naming rules. Hopefully, these are being written down somewhere for future reference (Excel Spreadsheet perhaps?)

It is only now that we get to your comments regarding using Unique User Names and ignoring System Names. Whether the user enters the components, one by one, into the appropriate Table directly in JMRI or the ‘Whole Layout' data is imported into JMRI is it JMRI that will create the Unique System Name for each entry? The User does not have access to this field to edit it. You say: “...then you can move that association to a new system connection. (one by one) The importance of this is that you will not need to change all the places that use each item like you would when using the system names to identify items.”

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

Dave,

If you only use 'System Names' then you are stuck because those are the actual hardware connections, and changing the hardware obviously requires different connections. However if you have used 'User Names' for each item, then you can move that association to a new system connection. (one by one) The importance of this is that you will not need to change all the places that use each item like you would when using the system names to identify items.

Dick :)

Dear Jan And Dave

Thank you both for your responses and time taken to do this.

If I may answer Jans question, “Why have am I setting up LocoNet when I have a detection system already?”? A great question and probably Dave’s explanation of where we evolve from is apt here. ?I think the basic question is understanding the principles of operation of the component parts and how they can interrelate to each other is where I struggle. I read the Digitrax data sheets several times and still think I understand it or do I? ?As Dave said its their jargon not railway collectors’ jargon.?

So how have I got here.? Having built the first set of boards and installed solenoids, I found I needed a better way to drive the Solenoids add a CDU was not working reliably, I chose to use Mega points to drive my old Solenoid point control. Megapoints can drive both Solenoid (In my case 35yr old solenoids) and provided a cost-effective ecosystem to drive all types of point systems. Solenoid, Kato and servo motors etc.? I got it running wonderfully my old solenoids are now going great and now going forward I ditched using further Solenoids and have started to try servos. ?I wish I started with these. The Megapoints accepts DDC commands from the command station and now as in my first post, accepts commands from JMRI wirelessly via the MRC DDC system.?Ie a push down to the hardware.

Megapoints also offers block detection sensors and point position feed-back (I installed only 10 blocks to date), but whilst on the same Megapoints network, this is designed to feedback to a mimic panel if you had one (I don’t as planned utilising JMRI I can miss this step and go straight to PC interface) the detection works well with Mega points and is a cost effective approach. However, it does not yet feedback into JMRI. But there is a plan to enable that later, so I was happy to wait.??

In parallel to this whilst I was retrofitting locos with decoders, I got circa 60+ to do it was going to be a very costly exercise to do them all especially with sound as once you tried that there is no going back! ?I discovered and purchased a Soundtracks surround sound system. (its still in its box) I then realised it needed BDL168s with RX4s for this to really work well, assuming my decoders have transponding as well. (That’s another story). But then as I acquired these BDL168s I realised I also bought a block detection system that is today working with JMRI. (The light went on this week reading this post) assuming I have read the threads, right?? So leaning as I go I think it makes sense to utilise these for block detection, I have already got two BDL168s so far and that gives me 32 detection points, (Well I think they do if I read the jargon?). ?I presume they also have 4 transponding points as well? This increases with the RX4s to another 8 each? ?Not sure I fully understand the difference between responding and detection? I am thinking you can group multiple detection under 1 transponder for a given area of the layout. But the text does not say that. ??

So in conclusion I think?if I had not?invested in a surroundtrax system I would have stuck with the mega points detection and future integration. However, even though I have these MegaPoints detection hardware they also offer some clever control of signalling and stopping locos independently of JMRI, which I think I would utilise to allow automounts control.? But tomorrow I might learn something new that changes all that??

Sam:

Can you try a build from to see if the proposed fix works for you? This will not require rebuilding the manifests to test.

Hello Howard,
?
I am sure that you hit the nail squarely on the head? when you initially said : "...just about anything is possible if you know what your doing." That is the recurring? problem! Not all Railway Modellers are Electronic Engineers and so they may not understand what the hardware and software are doing most of the time. They just know what they would like it to be able to do. The problem, quite often, is that it is a highly experienced and dedicated electronics engineer that has created the Hardware or Software who are writing the 'Help' files and their associated 'Notes' using language that is commonly used within that field every day and that ends up becoming/being a complete mystery to those users that are not technically minded! I am pleased to see that another member of this Forum is able to help you and guide you to where you need to be.

I have studied all of the replies to this thread to try to get to a simple distillation of what the JMRI Help Files and Notes have to say about "initial Setup" and moving on to a more complex Control System using Multiple Systems. Both Randall and SwissChris provided a good place to start using a 'Multi-System' version of JMRI and Jim provided the Wireless Throttle explanation. A sincere "Thank You, All" for your input.

To get the setup right is all about setting the "Defaults" correctly as well as the order of setting the defaults and this depends on what the user wants for 'Train Control' and 'Layout Control' but the basic steps required to go through to achieve the desired result are the same. Get this bit right and the rest will fall into place!

One start point is with a 'Clean Slate". Nothing but the installed JMRI software to start with.
A second start point, which is essentially the next step in the process, is to go through the learning curve of JMRI and its 'Layout Editor' to create a 'Whole Layout' file using just the 'Internal' type and 'Simulation Mode' with no layout to worry about, just the plan in my head.?
A third 'Start Point' is for those Users may have chosen to start with what they already, using their own system hardware.

We now have three possible 'Start Points' when creating our initial Configuration File. We need to use Randall's suggestion as a proforma for each Start Point to get to the original single JMRI Configuration profile but it could do with adding in further Notes or Comments for Guidance/Explanations as to why we do it the way we do. This is most likely to be either a No System, No Layout approach or a known DCC System Manufacturer. We need to get these simple, Single JMRI Configuration Profiles right first before even thinking about adding in a second or even a third manufacturer's Control System.

The user who starts with nothing will learn of the importance of? having unique 'System Names' and 'User Names'? as they learn about JMRI because they will use the 'Internal" type to create these 'Names" and allow JMRI to create the file for them as they proceed. The User who already has a system needs to select the appropriate coding for their particular manufacturer's DCC sytem and allow JMRI to create the required file automatically This may use their DCC system for just 'Train Control' or both Train Control' and 'Layout Control' of the various 'Devices' (Turnouts/Signals/Block Occupancy Detectors and 'Positional Feedback' Detectors.) around their layout. It is the more advanced user that will consider splitting off the 'Train Control' from the 'Layout Control' and so create two or more separate systems. It is this more advanced use of JMRI that was the subject of my original post.

For those users who have spent hours and hours creating their 'Whole Layout' file using 'Internal', perhaps over several months of learning, does the act of changing to a specific DCC manufacturer automatically change the 'System Names' already created within the xml file or do we have to go through the whole file again and edit each System Name bearing in mind the need to maintain stability within the file? This question also applies to those of us who decide to adopt a second Manufacturer when we hive off the Layout Control from the Train Control. If I read the responses correctly, in my case, the Default was originally 'Internal' Naming within JMRI. This is to change to using the Lenz system (Code Change) for Train Control and then to add in the Merg system (Code Change) to control all of the devices on the layout. Does changing the original 'Internal' Configuration Profile to Lenz and saving it under another Profile Name also convert the System Names? Again, adding in the second manufacturer (MERG) to handle the devices does this too require a change of System Name? Which system is the Default and how do we go about editing the xml file to reflect these changes?

Dave

Hi Don.
There are issues with the priority.
The pause allocation was working correctly, I will check tomorrow.
Train should stop at end of transit, unless continious is used, mine do. Is there a signal mast at the end of the stopping block and is it at danger/stop?
I've never heard the horn not stopping, the bell occasionaly yes, and it's normally associated with the stop action being on an exit event. Is this play a pattern or single timed blast? When ever I've checked the log it seems to be caused by never sending the off, so never sending twice won't change anything.
If you are using NMRA dcc signal decoders, lite-its etc you might want to use the strict appetizer (preferences loconet advanced) which will throw warning in the log if you losing messages.
Steve G.

Peter, thank you. I will try that.
Dan

Yes, it's as though the files were erased, which I doubt JRI did. I'm perplexed
Dan

Ian,

On 10 Jun 2019, at 6:42 AM, Ian Birchenough via Groups.Io <ian.birchenough@...> wrote:

Is there a method of selecting locomotives with their pictures, address and function numbers/descriptions from their throttle details to provide prompt sheets for ease of multiple operators at a club exhibition?

You could always use your computer operating system's window snapshot facility to capture a throttle window image.

- On Mac that is ??4 followed by spacebar to get a camera icon and click on a window to make an image file.
- On Windows that is alt-PrtScr and paste into WordPad (not NotePad) or similar.
- On some Linux versions (Ubuntu, Mint) alt-PrtScr apparently creates an image file (I'm not sure if I've ever tried it).

There are other variants, methods. Ask if you need help.

Dave in Australia

Thanks Bob,

Running again today (long weekend).? I will send you log files tonight Oz time).? Turnouts, signals and block occupancy were rock solid.? Only messages to locos occasionally lost but speed messages are repeatedly sent across the LocoNet, so even if one was missed the loco should get the next. ?

The two major issues were two trains being started almost simultaneously, one of which was facing a held signal, or a loco failing to stop at the the end of its transit, again running a red.
I will look at the log files and try and capture the LocoNet monitor of a problem occurrence.

Cheers
Don

Is there a method of selecting locomotives with their pictures, address and function numbers/descriptions? from their throttle details to provide prompt sheets for ease of multiple operators at a club exhibition?
Ian_B