On Jul 29, 2018, at 6:21 PM, jamespetts via Groups.Io <jamespetts@...> wrote:

Thank you for your reply. What is not clear from what you have written is whether this relates just to the warnings or to the inconsistent behaviour - can you elaborate on whether, and, if so, how this directional ambiguity would relate to the inconsistent behaviour? Also, would this directional ambiguity be resolved if the blocks in question were set to be unidirectional?

On Jul 29, 2018, at 5:53 PM, rummy@... wrote:

Dave,

Yes, Options - Allow Layout Control has always been checked. I uploaded the panel xml file to a folder called something like "Rummy's panel only operates turnouts in closed direction" or something like that. It's strange that it only operated in 1 direction for all turnouts. In the past, they did operate in both directions, but since learning to create sensors in the table before putting sensors on the panel, this has been happening.

Thanks for looking into this. You guys are a great resource!
Rummy

On Jul 29, 2018, at 4:47 PM, jamespetts via Groups.Io <jamespetts@...> wrote:

Thank you for your reply. I am aware of the issue with separate blocks for turnouts, which is why I am testing with a simple loop representation of the layout at present. I can add the Logix simulation for turnout blocks once I have consistent behaviour with just the basic loop, and that is the principal concern at present.

In relation to the number of blocks, I am not entirely clear why the behaviour should be inconsistent in the way reported above as a result of the number of blocks - can you elaborate? You do correctly surmise the block description of the layout. To answer your other question, in this setup at present, all trains go only clockwise and there are only clockwise transits set up.

As to the corrected BR-2003 signal aspects, I have already downloaded the fix for this from the MERG forum, but it is good to note that this will be included in the next official release so that I do not have to remember to patch this manually in future.

On Jul 29, 2018, at 12:36 PM, jamespetts via Groups.Io <jamespetts@...> wrote:

I am in the process of trying to test JMRI's automation capabilities using a small testing layout in (UK) N gauge especially built for this test. The layout consists of a straight topped and bottomed oval of track with loops on the straight parts and a siding at the ends of one of the loops.

I have been testing JMRI against the demonstration versions of Traincontroller Gold and iTrain, but find those unsatisfactory for several reasons (using Traincontroller Gold is like trying to control a model railway with Microsoft PowerPoint and it only runs on Windows whereas I should like my train control computer to run Linux; iTrain's demonstration version does not allow me to use train routes, which I would need to test thoroughly before considering paying money for it; and neither allow the use of MERG hardware which would be a good thing to be able to use on the layouts that I am planning, if I find that RailCom, which the MERG hardware does not yet support, is not necessary).

At this juncture, I am representing the layout in JMRI as just a plain loop consisting of the outer sections with no turnouts (I had not realised the necessity when wiring the layout to have each turnout in its own block, and so the turnouts are in the same block as the track following on from the nose part of the turnout, which prevents me from setting up signal mast logic properly; attempting to rectify this by putting the turnouts in their own blocks in JMRI but not connecting these to any sensor on the layout resulted in automatic trains never stopping and a null reference exception being recorded in the system console). The plan in due course is to use this layout to test JMRI's ability to automate operations involving a locomotive hauling a train into a loop, uncoupling, another locomotive coupling up to the train from the siding and then hauling the original train back around the other way into the loop on the other side of the layout.

That plain loop of track as represented in JMRI at this stage of testing has four sections: upper, right curve, lower and left curve. At the boundary of each of these sections is a virtual signal mast, comprising one three aspect signal head in the BR 2003 specification. The signals are set for clockwise operation only. I have set up several transits, two of which in particular I use for testing purposes: one is a full circle from rear back to rear, and another is a full circle from front back to front.

Using those transits, I can get two trains to navigate the circle automatically in the same direction without crashing into one another. However, there are some significant anomalies which are not consistent with the documentation or from what I understand of the interface.

Firstly, the speed at which the trains travel appears to bear no relation to the "default maximum speed" setting specified in the "Activate new train" dialogue. Changing this setting appears to have no effect on the speed of the train, which appears to accelerate to a high speed in some cases. The ramp rate setting seems to work well, however. I should note that both of the locomotives have speed profiles defined and I have selected "use speed profile" and "stop by speed profile" for both active trains. Also, all the sections have defined lengths based on my measurements of the track.

Secondly, the behaviour is inconsistent between runs. I carried out the following test: I set up one train in the rear section and one in the front, then created active trains and assigned the train in the rear section to the transit from rear to rear and the train in the front section to the transit from front to front and ran them. This first run produced acceptable results: the rear train set off slowly and then advanced slowly into the right curve section, slowing as it approached the (virtual) signal protecting the section where the front train was waiting to go; the front train then set off when I set it up and advanced into the left curve section and both precoded at a moderate pace around the layout, slowing down if they were about to get to a (virtual) signal showing danger, until both were back in their original sections. The trains, on entering their stopping sections, slowed down gently and stopped near the middle or end of those sections. On the second run, I removed one of the trains and restarted the other. This time, the train sped up to a very high speed, and failed to stop, looping continuously until I terminated the train. However, after about two loops, it slowed down to a much more moderate pace, wherein it remained until I terminated the active train to which it had been reassigned. For the third test, I left the second train removed from the track and created a new active train from the first, with exactly the same settings as before. This time, it accelerated to a high speed, went around the circuit once, but stopped suddenly immediately on entering the final section, rather than stopping smoothly as in the first run, seeming to ignore the "stop by speed profile" command.

I should note that I have been able to use the Zimo distance controlled stopping to prevent this sudden stop, but this is not very satisfactory compared to the built in stop by speed profile system, as this requires that the stopping point be always a fixed distance from the stopping sensor, which is not workable with different lengths of trains as I plan to have on my actual layout (as opposed to this small test layout).

For reference, the system console output shows some errors and warnings the meaning for which I cannot find anywhere in the documentation (or anywhere on the internet so far as search engines are concerned). The full output from my latest session is as follows:
2018-07-29 17:57:25,125 util.Log4JUtil INFO - * JMRI log ** [main]
2018-07-29 17:57:25,139 util.Log4JUtil INFO - This log is appended to file: C:\Users\James\JMRI\log\messages.log [main]
2018-07-29 17:57:25,140 util.Log4JUtil INFO - This log is stored in file: C:\Users\James\JMRI\log\session.log [main]
2018-07-29 17:57:25,148 apps.Apps INFO - PanelPro version 4.12+Rb6a9bb1 starts under Java 1.8.0_171 on Windows 7 amd64 v6.1 at Sun Jul 29 17:57:25 BST 2018 [main]
2018-07-29 17:57:26,549 apps.Apps INFO - Starting with profile Automation_test_layout.3f6acf02 [main]
2018-07-29 17:57:26,704 node.NodeIdentity INFO - Using jmri-dG1h9cpHGhNiaahg7KpNdQ-3f6acf02 as the JMRI Node identity [AWT-EventQueue-0]
2018-07-29 17:57:26,842 xml.AbstractSerialConnectionConfigXml INFO - Starting to connect for "LocoNet" [main]
2018-07-29 17:57:27,237 locobufferusb.LocoBufferUsbAdapter INFO - LocoBuffer-USB adapter set hardware flow control, mode=2 RTSCTS_OUT=2 RTSCTS_IN=1 [main]
2018-07-29 17:57:27,238 locobuffer.LocoBufferAdapter INFO - COM8 port opened at 57600 baud with DTR: true RTS: true DSR: true CTS: true CD: true [main]
2018-07-29 17:57:27,302 loconet.LnPacketizer INFO - lnPacketizer Started [main]
2018-07-29 17:57:27,690 util.FileUtilSupport INFO - File path program: is C:\Program Files (x86)\JMRI\ [main]
2018-07-29 17:57:27,690 util.FileUtilSupport INFO - File path preference: is C:\Users\James\JMRI\Automation_test_layout\ [main]
2018-07-29 17:57:27,691 util.FileUtilSupport INFO - File path profile: is C:\Users\James\JMRI\Automation_test_layout\ [main]
2018-07-29 17:57:27,691 util.FileUtilSupport INFO - File path settings: is C:\Users\James\JMRI\ [main]
2018-07-29 17:57:27,691 util.FileUtilSupport INFO - File path home: is C:\Users\James\ [main]
2018-07-29 17:57:27,691 util.FileUtilSupport INFO - File path scripts: is C:\Program Files (x86)\JMRI\jython\ [main]
2018-07-29 17:57:28,868 PanelPro.PanelPro INFO - Main initialization done [main]
2018-07-29 17:59:26,819 dispatcher.AutoTrainsFrame INFO - No Throttle[47715 "Haymarket"/IZ5(Full circle from front)] [AWT-EventQueue-0]
2018-07-29 17:59:26,896 loconet.LnThrottleManager WARN - slot 1 address 4715 is already in-use. [AWT-EventQueue-0]
2018-07-29 18:01:50,566 dispatcher.AutoTrainsFrame INFO - No Throttle[47715 "Haymarket"/IZ5(Full circle from front)] [AWT-EventQueue-0]
2018-07-29 18:02:11,735 roster.RosterSpeedProfile WARN - Throttle destroyed before zero length[-42.03595] remaining. [Auto Engineer 4715]
2018-07-29 18:03:16,514 dispatcher.AutoTrainsFrame INFO - No Throttle[47573 "The London STANDARD"/IZ6(Full circle from rear)] [AWT-EventQueue-0]
2018-07-29 18:03:23,205 jmri.Block WARN - count of 2 ACTIVE neightbors with proper direction can't be handled for block Right curve but maybe it can be determined when another block becomes free [AWT-EventQueue-0]
2018-07-29 18:03:23,205 dispatcher.AutoActiveTrain WARN - Stopping train [47573 "The London STANDARD"/IZ6(Full circle from rear)] in section [IY:AUTO:0002(Right)], as next section [Front] is not allocated [AWT-EventQueue-0]
2018-07-29 18:03:23,294 roster.RosterSpeedProfile ERROR - Speed not available to compute distance travelled [Auto Engineer 4573]
2018-07-29 18:03:25,337 jmri.Block INFO - Block Right curve gets LATE new value from Rear loop, direction= East [AWT-EventQueue-0]
2018-07-29 18:03:39,458 jmri.Block WARN - count of 2 ACTIVE neightbors with proper direction can't be handled for block Front loop but maybe it can be determined when another block becomes free [AWT-EventQueue-0]
2018-07-29 18:03:39,458 dispatcher.AutoActiveTrain WARN - Stopping train [47573 "The London STANDARD"/IZ6(Full circle from rear)] in section [IY:AUTO:0003(Front)], as next section [Left] is not allocated [AWT-EventQueue-0]
2018-07-29 18:03:39,489 roster.RosterSpeedProfile ERROR - Speed not available to compute distance travelled [Auto Engineer 4573]
2018-07-29 18:03:40,978 jmri.Block INFO - Block Front loop gets LATE new value from Right curve, direction= West [AWT-EventQueue-0]
2018-07-29 18:03:48,133 dispatcher.AutoActiveTrain WARN - Stopping train [47573 "The London STANDARD"/IZ6(Full circle from rear)] in section [IY:AUTO:0004(Left)], as next section [Rear] is not allocated [AWT-EventQueue-0]
2018-07-29 18:03:48,139 roster.RosterSpeedProfile ERROR - Speed not available to compute distance travelled [Auto Engineer 4573]
2018-07-29 18:03:48,663 dispatcher.AutoActiveTrain WARN - Stopping train [47715 "Haymarket"/IZ5(Full circle from front)] in section [IY:AUTO:0002(Right)], as next section [Front] is not allocated [AWT-EventQueue-0]
2018-07-29 18:03:48,715 roster.RosterSpeedProfile ERROR - Speed not available to compute distance travelled [Auto Engineer 4715]
2018-07-29 18:03:57,008 jmri.Block WARN - count of 2 ACTIVE neightbors with proper direction can't be handled for block Rear loop but maybe it can be determined when another block becomes free [AWT-EventQueue-0]
2018-07-29 18:03:57,092 roster.RosterSpeedProfile ERROR - Speed not available to compute distance travelled [Auto Engineer 4573]
2018-07-29 18:03:58,536 jmri.Block INFO - Block Rear loop gets LATE new value from Left curve, direction= East [AWT-EventQueue-0]
2018-07-29 18:03:59,479 roster.RosterSpeedProfile ERROR - Speed not available to compute distance travelled [Auto Engineer 4715]
2018-07-29 18:04:33,321 dispatcher.AutoActiveTrain WARN - Stopping train [47573 "The London STANDARD"/IZ6(Full circle from rear)] in section [IY:AUTO:0002(Right)], as next section [Front] is not allocated [AWT-EventQueue-0]
2018-07-29 18:05:43,435 dispatcher.AutoTrainsFrame INFO - No Throttle[47573 "The London STANDARD"/IZ6(Full circle from rear)] [AWT-EventQueue-0]
2018-07-29 18:06:01,880 roster.RosterSpeedProfile WARN - Throttle destroyed before zero length[63.1073] remaining. [Auto Engineer 4573]
For reference, I should note that I am using a Digikeijs DR5000 command station together with a DR5088RC feedback module. I am connecting to JMRI via USB using the Loco Net interface.

I should note that I have also experienced some other inconsistent behaviour, but I thought that it would be more efficient at present to confine the query/report to these core issues as the fix for these might also prevent the other issues from arising.

Thank you in advance for any assistance, which would be much appreciated.

On Jul 29, 2018, at 3:49 PM, jeff coll via Groups.Io <jeffcoll2000@...> wrote:

Thanks Dave.

That's kind of what we thought we might have to do, but wanted it confirmed before I took that route.

I'm guessing using text edit , or another basic text editor.

I will get back there this week and see what is involved as there are a lot of routes on the file.



Jeff

On Jul 29, 2018, at 3:29 PM, rummy@... wrote:

On the panel I created in PanelPro to represent the current state of my layout, clicking on the turnouts on the panel will operate the turnouts in the closed direction only. However, clicking on them to throw the turnouts has no effect. Operating the turnouts using the turnout table, a few LRoutes I have created, or by the turnout control dialog box work great in both directions, close and throw. In all cases, the panel shows the correct state of the turnout (closed or thrown), the physical turnout also operates (closed or thrown) as directed, and the state in the turnout table shows the correct state. But using the panel only works when closing the turnouts - this applies to all 11 of the turnouts I currently have installed. When the turnout is closed, clicking on it, which should throw the turnout, has no effect on the panel, the turnout table, or the layout. Any suggestions or ideas?

I haven't uploaded the configuration file yet, but I can if need be.

Thanks in advance,
Rummy