Nigel, Bob
Thanks for the suggestions.
Unfortunately neither have helped.? I am an experienced JMRI user and was aware of the possible settings issue.? I also can confirm the correct program option for me, Programming Track, has been selected.
At my model railway club, I run three more JMRI installations.? I'm due to upgrade these and the hardware they run on.? As one of these also has a PanelPro design that runs a layout, I am concerned that this issue will impact these installations.? They running on old hardware, old versions of Java/JMRI and Windows XP so are desperately needing upgrading.? Budget has been approved but I don't want to hit this issue there!
I can program existing roster entries but not read from them.? As standard I do look to adjust the running characteristics of each locomotive using DecoderPro as a minimum and the lighting for suitably equipped ones.

This is a very interesting area, and it’s great that you want to think about it!

You might want to look at some of the existing code.

In particular, some of the complexity of the Path class ( or ) exists because “Block” on many railroads can’t be topologically condensed to a point: They can contain turnouts, sometimes more than one, that can lead to complicated relationships between i.e. turnout state(s) (c.f. ) and possible routings through the trackwork. They’re not even commutative: A local railroad uses spring switches, so the specification from A to B is not the reverse of B to A.

The train-following code has to deal with the cases you mention (c.f. ) but also cases like “a sensor goes active and none of the neighbors show active” (c.f. ) or the converse, where two neighbors show active (c.f. ), with and without directional information.

JMRI is by no means robust in all this. I’m sure that new ideas and eventually new code would be greatly appreciated.

Bob

On Aug 29, 2018, at 6:25 AM, halasz <halasz.gabor@...> wrote:

Dear JMRI users and developers,

In my topic entitled Scripts I was asking for help in a problem that arose from my drinking in advance for the skin of the bear as we say in my native language, when I was installing fewer sensors on my layout than the general practice was, in the conviction that their RailCom capability will make up for their small number.

Let me describe below how I imagine in general saving sensors, i.e. hardware at the expence of more sophisticated software. I wonder if you are, maybe in the long run, interested.

Blocks - by a block I am meaning here and in the sequel an irreducible section of track, electrically isolated from the rest of the layout where trains change their movement or, more generally, trigger some action - form a g r a p h . A graph in the sense of mathematics is just a collection of objects, called the v e r t i c e s of the graph, together with a selection of certain pairs of vertices. If a pair of two vertices is selected, we say that the two vertices are joined (virtually) by an e d g e , or a d j a c e n t.

The graph I have in mind has the blocks as its vertices and we join two such vertices by an edge if there is a route leading from either of them to the other, not going through any other block. Let us call such a route
m i n i m a l .

Next we are c o l o u r i n g our graph, in other words partitoning the vertices into groups - vertices belonging to the same group are said to be of the same "colour" - in such a way that two adjacent vertices invariably have different colours.

Now we are connecting blocks belonging to the same group electrically to each other and attaching to them a detector capable of RailCom. A RailCom detector can send more detailed reports than an ordinary occupancy sensor can, among other things also the decoder address of the locomotive staying in the block being monitored by the detector

I state that such a system can be fully automated by a computer, provided that it knows where the trains are located at the outset.

In fact, suppose that Train is in Block1 connected to Detector1 and we want to move it along a minimal route to the adjacent Block2 connected to Detector2. We set speed, turn-outs, etc as appropriate. Since Detector1 is different from Detector2 by definition, when Train arrives in Block2, Detector2 changes its status, so when it first reports the arrival of Train (owing to its RailCom capability) the computer knows that Train has arrived in Block2. True that, as far as Detector2 is concerned, Train could be in any other block being monitored
by it, but the route of Train being minimal, it can only be Block2. This way the computer can keep track of each train both in regard to time and location.

And we have only used as many detectors as there are colours and they may be much fewer in number than the number of vertices, that is the number of blocks! In general it is a hard problem to find the best colouring for large graphs, i.e. the one needing the fewest possible colours, but there are reasonable algorithms. For example, I leave it to the reader as an excercise to colour a graph with k+1 colours, if each vertex has at most k neighbours, i.e. k vertices adjacent to it. (Hint. Use the so called greedy algorithm: colour the vertices in an arbitrary order, in each step taking care of not violating the condition with respect to vertices coloured already.)

Summary. If we want to find every train based on the current state of detectors then, of course, we cannot do with less detectors than there are blocks and no saving is possible. The system I have been describing determines occupancy by the entire past, thus allowing, in cases, substancial saving.

The devil lurks in the details, another saying in my language. For instance, a faulty turn-out may drive Train to an unknown destination or we may want to allow other controllers intervening in the computer program. In this case we impose the stricter condition on the colouring that even second neighbours, I mean neighbours of neighbours be of different colours. (This second neighbour colouring is equivalent to ordinary coluring of the graph having the same vertices but joining two vertices by an edge if they are negighbours or second
neighbours in the original graph.) You easily see that no matter which detector, say Detector3 catches sight of Train first, there is a unique block, say Block3 connected to Detector3 Train can arrive in along a minimal route. The result is the same, except that in order to locate Train the computer has to be watching all the detectors of neighbouring blocks like Detector3, not just Detector2 and due to the stricter condition on the colouring we may need more colours. However, in the excercise not more than k^2+k+1, for each vertex has
at most k^2 second neighbours.

A hardware related problem is that as far as I know a RailCom detector can only take care of two (or four?) mobile decoders at a time. This can be helped, if I am not mistaken, by cyclicly disabling RailCom capability in all but two of the decoders in the blocks connected to the detector - this is just a matter of setting a configuration variable in the decoders, also made feasible by RailCom - allowing any number of trains, restricted only by the time factor. (CV writng by RailCom is said to be very fast.)

I feel that one way or other one should be able to overcome any other difficulty, as well, that may arise.

Gabor Halasz

--
Bob Jacobsen
rgj1927@...

Dave, Tom, interested parties, I don't get to install as many Lok sound decoders as i would like as the customer decides not me. At 70 years I get a little rusty between lok installs. Toms comment, "it reads what is there". Actually the template for the function mapping is what possibly Dave has written in the software when the D. P. function map was created. I am a devoted user of D.P. and maybe wishing the more current F.T. definitions would appear in Decoder pro. I have no doubt the Lok programmer did its job just fine. The Function and sound slots printed out from the lok website are correct. So it is just the discrepancy between what Decoder pro shows on the Function Pane and what Lok shows on its Function list. I now remeber I need to make the D.P. fuction pane match up to what is programmed in the decoder. I will do that and test it later. As long as the F.T. features are there I will be happy. I hate to admit I went to the files of the Lok Yahoo sight and could not find Daves instructions. I hope this makes some sense. Rick.

Gabor,

Right now they are tracking down the issues in the code for the rest of the
reporters to work. It's just a matter of time to get it right. From the
discussion, it will be fairly quick as software goes. The talk points to
seeing where some things were missing due to other implementations being
focused on very specific cases instead of the usual JMRI idea of start with
the general case and then have implementations off of that. Sensors and
turnouts, very global concepts and then specific vendor connections tweaks
from that base idea. It seems the code is showing that reporters didn't grow
up that way.

Your description of how to deal with the reporters and sensors by matrixing
may be accurate to show the goals, but for just about everyone on this list,
if you could restate it using layout terms or examples, it would help
everyone greatly.

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

Check in the lower-right quadrant of the main DecoderPro (roster) window that you don’t have “Edit Only” selected.

Bob

On Aug 29, 2018, at 2:41 AM, Clive Williams <clivew@...> wrote:

Have been using JMRI DecoderPro for several years now but getting issue with latest installs.
Set up is programming track accessed via Digitrax PR3. Running JMRI 4.12 (had identical issue on 4.10). Java version 1.8.0_171(en_NZ) Laptop running Windows 10 Home version 1803 OS Build 17134.228.
Whan I fire up DecoderPro, it comes up with my roster (approximately 60 locomotives). All looks fine at this stage.
If I try 'New Loco', "Create New Loco" comes up with a list of Decoder installed but both 'Read type from decoder' and Open Comprehensive Programmer' are greyed out.
If I go to a Roster Entry, I can see the current details but both Read buttons are greyed out, I can change an entry and it appears to work - for example I changed a DCC address and confirmed it had been changed.
If I try 'Identify', DecoderPro will read the CVs (can see the messages in the status bar plus it picks the right roster entry However as above, cannot read the CVs when you open the programmer.
I'm set up to use a Digitrax connection via the Loconet PR3 as a stand-alone Loconet using COM3 as the serial port. Connection defaults are all Loconet. As far as I know everything else is set to default.
I've had things running properly in the past from another laptop running Windows 7. The roster file and the xml files were copied from the original laptop and I've added some new ones. All have the same issue.

--
Bob Jacobsen
rgj1927@...

Ken,

Reading through earlier posts, I am sorry for misreading your " ...does confirm.." for "...does not confirm...", making our already hard-to-follow topic even harder to follow.

Gabor

开云体育

Have been using JMRI DecoderPro for several years now but getting issue with latest installs.
Set up is programming track accessed via Digitrax PR3.? Running JMRI 4.12 (had identical issue on 4.10).? Java version 1.8.0_171(en_NZ) Laptop running Windows 10 Home version 1803 OS Build 17134.228.
Whan I fire up DecoderPro, it comes up with my roster (approximately 60 locomotives).? All looks fine at this stage.?
If I try 'New Loco', "Create New Loco" comes up with a list of Decoder installed but both 'Read type from decoder' and Open Comprehensive Programmer' are greyed out.
If I go to a Roster Entry, I can see the current details but both Read buttons are greyed out,?? I can change an entry and it appears to work - for example I changed a DCC address and confirmed it had been changed.
If I try 'Identify', DecoderPro will read the CVs (can see the messages in the status bar plus it picks the right roster entry.? However as above, cannot read the CVs when you open the programmer.
I'm set up to use a Digitrax connection via the Loconet PR3 as a stand-alone Loconet using COM3 as the serial port.? Connection defaults are all Loconet.? As far as I know everything else is set to default.
I've had things running properly in the past from another laptop running Windows 7.? The roster file and the xml files were copied from the original laptop and I've added some new ones.? All have the same issue.
:

Dear JMRI users and developers,

In my topic entitled Scripts I was asking for help in a problem that arose from my drinking in advance for the skin of the bear as we say in my native language, when I was installing fewer sensors on my layout than the general practice was, in the conviction that their RailCom capability will make up for their small number.

Let me describe below how I imagine in general saving sensors, i.e. hardware at the expense of more sophisticated software. I wonder if you are, maybe in the long run, interested.

Blocks - by a block I am meaning here and in the sequel an irreducible section of track, electrically isolated from the rest of the layout where trains change their movement or, more generally, trigger some action -
form a?? g r a p h . A graph in the sense of mathematics is just a collection of objects, called the v e r t i c e s?? of the graph, together with a selection of certain pairs of vertices. If a pair of two vertices is selected, we say that the two vertices are joined (virtually) by an?? e d g e , or? a d j a c e n t.

The graph I have in mind has the blocks as its vertices and we join two such vertices by an edge if there is a route leading from either of them to the other, not going through any other block. Let us call such a route
m i n i m a l .

Next we are?? c o l o u r i n g?? our graph, in other words partitioning the vertices into groups - vertices belonging to the same group are said to be of the same "colour" - in such a way that two adjacent vertices invariably have different colours.

Now we are connecting blocks belonging to the same group electrically to each other and attaching to each group a single detector capable of RailCom. A RailCom detector can send more detailed reports than an ordinary occupancy sensor can, among other things also the decoder address of the locomotive staying in the block being monitored by the detector.

I state that such a system can be fully automated by a computer, provided that it knows where the trains are located at the outset.

In fact, suppose that Train is in Block1 connected to Detector1 and we want to move it along a minimal route to the adjacent Block2 connected to Detector2. We set speed, turn-outs, etc as appropriate. Since Detector1 is different from Detector2 by definition, when Train arrives in Block2, Detector2 changes its status, so when it first reports the arrival of Train (owing to its RailCom capability) the computer knows that Train has arrived in Block2. True that, as far as Detector2 is concerned, Train could be in any other block being monitored by it, but the route of Train being minimal, it can only be Block2. This way the computer can keep track of each train both in regard to time and location.

And we have only used as many detectors as there are colours and they may be much fewer in number than the number of vertices, that is the number of blocks! In general it is a hard problem to find the best colouring for large graphs, i.e. the one needing the fewest possible colours, but there are reasonable algorithms. For example, I leave it to the reader as an exercise to colour a graph with k+1 colours, if each vertex has at most k neighbours, i.e. k vertices adjacent to it. (Hint. Use the so called greedy algorithm: colour the vertices in an arbitrary order, in each step taking care of not violating the condition with respect to vertices coloured already.)

Summary. If we want to find every train based on the current state of detectors then, of course, we cannot do with less detectors than there are blocks and no saving is possible. The system I have been describing determines occupancy by the entire past, thus allowing, in cases, substancial saving.

The devil lurks in the details, another saying in my language. For instance, a faulty turn-out may drive Train to an unknown destination or we may want to allow other controllers intervening in the computer program. In this case we impose the stricter condition on the colouring that even second neighbours, I mean neighbours of neighbours be of different colours. (This second neighbour colouring is equivalent to ordinary colouring of the graph having the same vertices but joining two vertices by an edge if they are neighbours or second
neighbours in the original graph.) You easily see that no matter which detector, say Detector3 catches sight of Train first, there is a unique block, say Block3 connected to Detector3 Train can arrive in along a minimal route. The result is the same, except that in order to locate Train the computer has to be watching all the detectors of neighbouring blocks like Detector3, not just Detector2 and due to the stricter condition on the colouring we may need more colours. However, in the exercise not more than k^2+k+1, for each vertex has at most k^2 second neighbours.

A hardware related problem is that as far as I know a RailCom detector can only take care of two (or four?) mobile decoders at a time. This can be helped, if I am not mistaken, by cyclically disabling RailCom capability in all but two of the decoders in the blocks connected to the detector - this is just a matter of setting a configuration variable in the decoders, also made feasible by RailCom - allowing any number of trains, restricted only by the time factor. (CV writing by RailCom is said to be very fast.)

I feel that one way or other one should be able to overcome any other difficulty, as well, that may arise.

Gabor Halasz

开云体育

开云体育

Here is the link for Tripp Lite and the Keyspan adaptor.?

I think Rick is expecting the Function Labels to be read from the decoder...

This only happens with a Marklin mfx decoder on a controller that uses the mfx protocol.

I am not familiar enough with railcom to know if that will do it too.

Either way a standard v3.5 decoder will not do it.

开云体育

开云体育

Allen,

The first thing that needs to be fixed are the Section direction sensors. You are currently using the neighboring block's occupancy sensors. The Section direction sensors are Internal sensors for the exclusive use of Dispatcher. I recommend names that are based on the section name such as sect_OL_8_Fwd and sect_OL_8_Rev.

If there are still issues, upload the updated panel xml file and the custom icons.


Dave Sand

The current download of DecoderPro has been installed
on an iMac running High Sierra.

Previously I had been running DP under Windoze 7
using a Keyspan adapter.

Is there a post among all those containing "High
Sierra" that describes all the steps needed to get
DP working on this machine?

As an indication of my ignorance, the link to keyspan
for drivers fails with a time out.

Thanks!
--
Rod Miller
Handcraftsman
===
Custom 2-rail O Scale Models: Drives, | O Scale/S Scale West/Narrow Gauge West
Repairs, Steam Loco Building, More | 2019 O Scale National Convention
| 2019 Dates Are May 23 - 25
|

Hi,
Working on automating trains with Dispatcher and am getting an error regarding a particular turnout:

2018-08-28 20:33:53,534 jmri.Section????????????????????????? ERROR - Unexpected error in getDirectionStandardTurnout when working with turnout NT14 [AWT-EventQueue-0]
2018-08-28 20:33:53,534 jmri.Section????????????????????????? ERROR - Unexpected error in getDirectionStandardTurnout when working with turnout NT14 [AWT-EventQueue-0]

Signals appear to be working as expected (but it has been quite a challenge to get this far). I am using the SSL type signaling. The turnout in question is "inside" a block, not sure if that is an issue. All blocks are contiguous. Another part of the same panel worked ok with Dispatcher so this seems localized.
Running:
JMRI 4.12
Linux Ubuntu 16.04
NCE

I have read the online help and searched the user messages (very helpful to get me this far btw) but could not find this problem.

Panel is in problem area folder: 'Allen House SSL Dispacter signal issue'

Any help appreciated.
Thanks,

Allen
Mtn RR