开云体育

If you send me the file(s) and instructions for recreating the fault, there's a tool called 'git bisect' that will rapidly find where it was introduced.

Bob

If every body would PLEASE start a new problem report and not pirate a thread! That would help keep things logical for each user. I suggest putting you name as the start of the subject. and then the problem.

I also am having problems with a turntable also jumping to the upper left.

If I disable Logix it jumps must faster. like it loads in the wrong place.


I think it something in the Layout Panel xml and am working on removing things,


Walt

rzeollaorcl
Please start a new thread for your problem, Maybe put you name in the subjecct with yuour problemt

All of a sudden this is happening to me as well. I double click the desktop shortcut and nothing happens. The first time this occured was after entering the ops mode programmer to set up a RR Cirkits Watchman per their instructions. Since then, I cannot start JMRI Panel Pro. Help!!!

We recently broke the Eclipse IDE with regards to the internal JAVA compiler.

There's a workaround, go to the end of this issue:






Dan

Gordon,

Other members of this list are better qualified, but so far you have waited with no response.


Some immediate thoughts are:


1 As stated in your note, you have provided an open-ended question. Without articulating some of the details of what you want to do with the result, it is difficult to provide useful details as to how to get to the goal.


2 You could try just using a large sheet of white cardboard or foam-board available from an office supply or an art supply store. With some black tape or felt tip pen for the lines and a label maker or just handwritten printed location and siding names for the layout and a pack if Post-It labels for the trains, you could keep your Dispatcher busy for at least the learning curve needed to decide what you want to do next.


3 If you have not already done so, spend some time reading the information provided at: and in particular, examine the examples provided there and also provided at the links found there. The features available for one type of panel and the associated operations capabilities may or may not be important to you. Follow up some of the easy tutorials to see what kind of efforts are needed too.


After comparing results from the second and third items listed above, you could either figure out which way you want to progress or else come back with specific questions or at least some better hints. At the least, we would have a better vision of your goal.


Best of luck to you and your adventure.


Cliff Anderson in Baja SoCal

Hello Steve W�
I too, was having the same issues of not starting JMRI under Win10. On the advice of someone here, I removed ALL traces of JMRI from the computer, then removed all traces of JAVA, then rebooted the computer.
While signed in as ADMIN to my computer, I downloaded J
The latest JAVA, 1.8.0_144, installed and rebooted.
Then again under ADMIN sign in, I downloaded and installed JMRI version 4.8+RbeOff15, then rebooted.
I can now run JMRI with no problems under Win10. I am no programmer or coder so I can抰 tell you why this worked. But now I can run JMRI under my own sign in and all is working very well. I use DecoderPro for re-programming my locos and have yet to try working with PanelPro.
Hope this might help you. I was getting really frustrated until I did this procedure. Now a happy camper.
Good Luck,
Rick Bell
Montrose, CO.

Sent from Mail<> for Windows 10

From: steveandglor@... [jmriusers]<mailto:jmriusers@...>
Sent: Tuesday, August 22, 2017 1:17 PM
To: jmriusers@...<mailto:jmriusers@...>
Subject: [jmriusers] Re: WIN10 - JMRI won'tstart. Help please



Thanks Walt,
Whether trying to start from the Windows apps menu list or from the the shortcuts on the desktop the response is the same. There is a bit of disk activity; short bursts then a pause then repeated a few times, then gives up (sorry, not very specific)

From the programs(x86)/JMRI folder there is LaunchJMRI app(45kb). Just tried this and got error message:-

No command line parameter.Usage 'LaunchJMRI.exe{/debug] [/noisy] [/32bit] [/profile <profileID>] [/JOPTION] [--cp:a=CLASSPATH] [--cp:p=CLASSPATH] [config]'

The message is headed Launch JMRI 0.1.21.0

Will take a closer look in this area later.

Thanks
Steve W

[Non-text portions of this message have been removed]




[Non-text portions of this message have been removed]

Ken,

The answer to your questions are as follows:

I am using a Toshiba laptop, 2.13Ghz Dual Core, 4Megs of Ram, 64 bit
Windows 10 Home Version 1607, JMRI 4.6, Java 1.8.0_121 and PR3 xtra on
Com port 4.� I am only using DecoderPro on a standalone programming track.

Paul


On 8/21/2017 2:47 PM, 'Ken Cameron' kcameron@... [jmriusers] wrote:

Paul,

Ok, that is back quite a ways. There have been a few points where some
patching or upgrading of roster entry files have happened. At least with
that being before ideas like profiles, that means it is an all new startup
for you. If you are only doing decoder programming, you don't have much to
worry about. But if you have panels and scripts, there will be some
editing
needed as you go.

So other things we'd like to know so we can help better:

1. Which OS are you running??

2. What version of Java are you running?? If you use a command
window/shell/command line, enter: "java -version" and report what
version it
displays.

3. What features of JMRI are you using??

But before doing anything, make sure you have a backup of your current
setup!! If you are unsure of this, lets answer those questions and we can
customize the answer for you.

-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

When the panel file is opened it starts to build in the correct position, then JUMPS to the upper left of the screen.


Could this be a hint? this is what is in the panel file if I save it after it has jumped


<LayoutEditor class="jmri.jmrit.display. layoutEditor.configurexml. LayoutEditorXml" name="B" x="10" y="0" height="1020" width="1902" windowheight="722" windowwidth="915" panelheight="1020" panelwidth="1902" sliders="yes" scrollable="both" editable="no" positionable="yes" controlling="yes" animating="yes" showhelpbar="no" drawgrid="yes" snaponadd="yes" snaponmove="yes" antialiasing="no" turnoutcircles="yes" tooltipsnotedit="no" tooltipsinedit="yes" mainlinetrackwidth="4" xscale="1.0" yscale="1.0" sidetrackwidth="2" defaulttrackcolor="green" defaultoccupiedtrackcolor=" red" defaultalternativetrackcolor=" yellow" defaulttextcolor="black" turnoutcirclecolor="black" turnoutcirclesize="3" turnoutdrawunselectedleg="yes" turnoutbx="20.0" turnoutcx="20.0" turnoutwid="10.0" xoverlong="30.0" xoverhwid="10.0" xovershort="10.0" autoblkgenerate="no" redBackground="192" greenBackground="192" blueBackground="192" gridSize="10" gridSize2nd="10" openDispatcher="no" useDirectTurnoutControl="no">


This what the same line is in the original panel file



<LayoutEditor class="jmri.jmrit.display. layoutEditor.configurexml. LayoutEditorXml" name="B" x="364" y="39" height="1020" width="1902" windowheight="722" windowwidth="915" panelheight="1020" panelwidth="1902" sliders="yes" scrollable="both" editable="no" positionable="yes" controlling="yes" animating="yes" showhelpbar="no" drawgrid="yes" snaponadd="yes" snaponmove="yes" antialiasing="no" turnoutcircles="yes" tooltipsnotedit="no" tooltipsinedit="yes" mainlinetrackwidth="4" xscale="1.0" yscale="1.0" sidetrackwidth="2" defaulttrackcolor="green" defaultoccupiedtrackcolor=" red" defaultalternativetrackcolor=" yellow" defaulttextcolor="black" turnoutcirclecolor="black" turnoutcirclesize="3" turnoutdrawunselectedleg="yes" turnoutbx="20.0" turnoutcx="20.0" turnoutwid="10.0" xoverlong="30.0" xoverhwid="10.0" xovershort="10.0" autoblkgenerate="no" redBackground="192" greenBackground="192" blueBackground="192" gridSize="10" gridSize2nd="10" openDispatcher="no" useDirectTurnoutControl="no">




note that the x and y values have changed.


This is th System console after opening the original file with 4.9.3 This file opens and hold position with JMRI 4.8


Walt

Hello All.


Beginning with 4.9.1 Layout Editor does not save Turntable Data correctly, i.e. the length dimensions don't save for the zoom properly. Also the window no longer saves at 0.0... rather 5.10...


Same is true for 4.9.2 & 4.9.3...


Donn


Using:
JMRI 4.9.3 Java 1.8.0_141 Windows 7

Steve: I think that is normal. JMRI can't launch from there. The shortcuts add info to that so it will launch.


No screen open when you try to launch from the short cuts of the apps menu. you are not even getting the little screen with just the JMRI logo in it, right?
Walt

Found the issue鈥� Looks like I over-optimized鈥� I'll post a fix ASAP.

Thanks Walt,
Whether trying to start from the Windows apps menu list or from the the shortcuts on the desktop the response is the same. There is a bit of disk activity; short bursts then a pause then repeated a few times, then gives up (sorry, not very specific)

From the programs(x86)/JMRI folder there is LaunchJMRI app(45kb). Just tried this and got error message:-

No command line parameter.Usage 'LaunchJMRI.exe{/debug] [/noisy] [/32bit] [/profile <profileID>] [/JOPTION] [--cp:a=CLASSPATH] [--cp:p=CLASSPATH] [config]'

The message is headed Launch JMRI 0.1.21.0

Will take a closer look in this area later.

Thanks
Steve W

I have a midsize layout. I would like to have a screen on a monitor for a dispatcher to keep track of trains as they OS so he / she could issue train orders as needed.

The layout is "dark territory" with no signals. Eventually I plan on train order boards. Turnouts are manual except for four motorized ones.

I would like to have a straight line track schematic with passing sidings. Train icons would show where the trains were. I was looking at Panel and Layout Editor. Not sure which one to use. Any thoughts. OR... something entirely different.

Gordon Spalty

OK,


There have been some recent posts with regard to problems with deconderIndex.xml in the latest test versions. I have the lastest master dowloaded from github and am using eclipse. Everything builds fine in eclipse. However, when I try to invoke either Panel or Decoder Pro from eclipse, I get the following error:


2017-08-22 11:43:36,023 util.Log4JUtil INFO - * JMRI log ** [main]
2017-08-22 11:43:36,070 util.Log4JUtil INFO - This log is appended to file: C:&#92;Users&#92;Michael&#92;JMRI&#92;log&#92;messages.log [main]
2017-08-22 11:43:36,072 util.Log4JUtil INFO - This log is stored in file: C:&#92;Users&#92;Michael&#92;JMRI&#92;log&#92;session.log [main]
2017-08-22 11:43:36,086 apps.Apps INFO - PanelPro version 4.9.3ish+Michael+20170815T0352Z+Rbc20a81 starts under Java 1.8.0_144 on Windows 10 amd64 v10.0 at Tue Aug 22 11:43:36 EDT 2017 [main]
2017-08-22 11:43:40,129 apps.Apps INFO - Starting with profile AVMRC.3f432da5 [main]
2017-08-22 11:43:40,553 node.NodeIdentity INFO - Using jmri-606C66781DBA-3f432da5 as the JMRI Node identity [main]
2017-08-22 11:43:42,216 util.FileUtilSupport INFO - File path program: is C:&#92;Users&#92;Michael&#92;git&#92;JMRI&#92; [main]
2017-08-22 11:43:42,218 util.FileUtilSupport INFO - File path preference: is C:&#92;Users&#92;Michael&#92;JMRI&#92;AVMRC&#92; [main]
2017-08-22 11:43:42,219 util.FileUtilSupport INFO - File path profile: is C:&#92;Users&#92;Michael&#92;JMRI&#92;AVMRC&#92; [main]
2017-08-22 11:43:42,220 util.FileUtilSupport INFO - File path settings: is C:&#92;Users&#92;Michael&#92;JMRI&#92; [main]
2017-08-22 11:43:42,221 util.FileUtilSupport INFO - File path home: is C:&#92;Users&#92;Michael&#92; [main]
2017-08-22 11:43:42,222 util.FileUtilSupport INFO - File path scripts: is C:&#92;Users&#92;Michael&#92;git&#92;JMRI&#92;jython&#92; [main]
2017-08-22 11:43:42,266 apps.Apps ERROR - Error in trying to initialize decoder index file java.lang.NullPointerException: Required nonnull default for jmri.jmrit.decoderdefn.DecoderIndexFile does not exist. [initialize decoder index]
2017-08-22 11:43:42,290 ptionhandler.UncaughtExceptionHandler ERROR - Uncaught Exception caught by jmri.util.exceptionhandler.UncaughtExceptionHandler [main]
java.lang.NullPointerException: Required nonnull default for jmri.jmrix.ConnectionConfigManager does not exist.
at jmri.InstanceManager.getDefault(InstanceManager.java:181)
at apps.Apps.statusPanel(Apps.java:864)
at apps.PanelPro.PanelPro.statusPanel(PanelPro.java:69)
at apps.Apps.<init>(Apps.java:414)
at apps.PanelPro.PanelPro.<init>(PanelPro.java:41)
at apps.PanelPro.PanelPro.main(PanelPro.java:104)



I downloaded the latest test executable bundle (JMRI.4.9.4ish+jenkins+20170822T0505Z+R2b8afdc.exe) and copied the decoderIndex.xml from it into eclipse (xml directory) and cleaned and rebuilt to no avail. Any ideas on how I might fix this would be appreciated...



Many Thanks.


Mike....

(whateveryournameis),

Is the data you posted from a MOD-RFID1356? It doesn't look that way - it looks more like data reported by a MOD-RFID125.

The MOD-RFID125 aparantly reports 40 bits of message using a "minus sign" plus 10 characters plus line-feed and carriage-return characters. That is what JMRI seems to be reporting in your case.

The MOD-RFID1356 aparantly reports 64 bits of message using a "minus sign" plus 16 characters plus line-feed and carriage-return characters. I do not see evidence of this in the messaging you reported.

Regards,
Billybob

If using a WiFi capable phone with a web browser, this is entirely doable as a plugin to recent (maybe 4.6, definitely 4.8) versions of JMRI without having to change a line of the JMRI code, as plugins can extend the JSON server and web server of JMRI applications (internally these two servers are entirely plugin architecture based), so this could be developed separately from JMRI and released when ready.

Randall

On Aug 22, 2017, at 09:31, jawhugrps@... [jmriusers] <jmriusers@...> wrote:

Blair,

It would be possible. And I think that some such system seems viable, if carefully implemented.

I'll make a few comments from the perspective of one who is something of a "TT&TO purist". Some of these comments echo those already posted.

Typical "text messaging" mechanisms are not going to cut it.

Firstly, traditional text messaging mechanisms do not guarantee delivery, and, so far as I know, there is no mechanism which reports back to the sender when a text message does not go thru. Secondly, I do not consent to pay $0.20 per fragment of a train order (I pay by the text message), for the privilege of operating on a railroad operating with such a system! Thirdly, I think that most train orders I have written exceed the 144 (or 128, or whatever) character limit which is a traditional text message length. Fourthly, I know that I would have extreme difficulty mentally managing multiple train orders, and especially train orders split across multiple text messages.

Fifthly, do all cell providers have equally-good cell service in your basement? One layout where I operate consistently has zero or very poor cell service across all providers, account location and, apparantly, the standing-seam steel roof. Another layout where I operate is ok for most users, but Sprint has poor service which frequently drops.

It would seem that WiFi may be a better solution than cellular, because the owner has direct control over the WiFI quality-of-service around his layout.

Will your such a system have provisions for "31 orders" and signatures? It would be nice... And "clearances" ought to be handled, too, both when issued with orders and when issued without any attached orders.

In the context of electronic delivery of train orders, "delivery" should require some sort of positive response by the operator, not just a response that indicates that "my phone received the train order". There are just too many reasons why a given operator might not know that he has received a message!

An additional thought: train orders are delivered at open train order stations, while electronic communication allows instantaneous communication, no matter where the train crew is. This purist thinks it isn't "fair" for a crew to receive a train order before they have reached the train order station. And it isn't "right" for a crew to receive a train order after they have left the station from which it was issued. So maybe delivery could be tied-in with an electronic "OS" reporting feature.

I personally think that an electronic messaging system which provides some sort of positive notification of delivery, which requires operator acknowledgment of delivery, and which does not chop-up a train order into multiple messages would resolve 90% of my concerns.

This is really sounding like a custom App and appropriate support in JMRI. I'm thinking WiFi instead of over-the-air cellphone service.

As one who is not a smart-phone user, and one who is not a smart-phone App developer, I can only speculate on how such an App would work, and perhaps how it would interact with the user and perhaps interact/interfere with a WiThrottle/EngineDriver app.

At least we know that it should be at least feasible, as evidenced by the JMRI WiThrottle Server and its interactions with WiThrottle and EngineDriver "Apps".

Regards,
Billybob

[Non-text portions of this message have been removed]

[Non-text portions of this message have been removed]

Other than introducing a huge anachronism, in the day, crews did not OS, station operators did. So We have the model railroad convention of the conductor magically morphing into operators to OS and then morphing back.

Then there is the issue of accuracy in OSing on cell phones. As I mentioned in the discussion in ry-ops the intent of printers is to avoid providing space for station operators in the aisles.

Pre-writing orders is OK but takes away a lot if the challenge of dispatching. It also gets you into a lot of hard meets which you could do just as easily with any other dispatching method. The real appeal of tt&to is that the crews have work out their meets.

Seth Neumann
Mountain View, CA

Sent from my iPhone, please excuse the typing.

On Aug 22, 2017, at 5:38 AM, Blair & Rasa smithbr@... [jmriusers] <jmriusers@...> wrote:

Hi

Recent discussions with a friend with operating experience in TT&TO
centered around the possibility of using smartphones for receipt of
train orders, possibly using a dedicated app, though another possibility
would be to utilize texting. For example, on arrival at station X, the
conductor would text "Extra 9999 West by X 10:35" to the DS, and might
receive train orders to proceed to Station Y. Etc. etc. Has this been
thought of, and if it was discarded, was the reason technical, or
because it's too far from the reality of TT&TO? If it's actually
viable, has anyone tried it? Or would it be better done with an app
instead of texting? Personally, I think the biggest limitation might be
that some operators won't own a phone, but other than that are there
other gotchas?

On the Opsig list, this discussion has deviated into a discussion of
local printers at every station, which I understand from the viewpoint
of replicating reality without having to have operators at every
station, or sneakernetting orders around the layout room during a busy
session; I'm more curious about the paper-free option of having a DS
capable of emitting orders to multiple trains without the paper, and
without the extra operators.

I can envisage drawing up a large percentage of the orders for a session
before the session even begins, so having the ability to put a series of
orders in queue, then selecting which one to send to which location,
etc. would be important. Having not explored JMRI Ops, I'm not sure how
this would fold into it's current state, so comments from those using
JMRI in this area would be appreciated as well.

Regards

[Non-text portions of this message have been removed]

Blair,

It would be possible. And I think that some such system seems viable, if carefully implemented.

I'll make a few comments from the perspective of one who is something of a "TT&TO purist". Some of these comments echo those already posted.

Typical "text messaging" mechanisms are not going to cut it.

Firstly, traditional text messaging mechanisms do not guarantee delivery, and, so far as I know, there is no mechanism which reports back to the sender when a text message does not go thru. Secondly, I do not consent to pay $0.20 per fragment of a train order (I pay by the text message), for the privilege of operating on a railroad operating with such a system! Thirdly, I think that most train orders I have written exceed the 144 (or 128, or whatever) character limit which is a traditional text message length. Fourthly, I know that I would have extreme difficulty mentally managing multiple train orders, and especially train orders split across multiple text messages.

Fifthly, do all cell providers have equally-good cell service in your basement? One layout where I operate consistently has zero or very poor cell service across all providers, account location and, apparantly, the standing-seam steel roof. Another layout where I operate is ok for most users, but Sprint has poor service which frequently drops.

It would seem that WiFi may be a better solution than cellular, because the owner has direct control over the WiFI quality-of-service around his layout.

Will your such a system have provisions for "31 orders" and signatures? It would be nice... And "clearances" ought to be handled, too, both when issued with orders and when issued without any attached orders.

In the context of electronic delivery of train orders, "delivery" should require some sort of positive response by the operator, not just a response that indicates that "my phone received the train order". There are just too many reasons why a given operator might not know that he has received a message!

An additional thought: train orders are delivered at open train order stations, while electronic communication allows instantaneous communication, no matter where the train crew is. This purist thinks it isn't "fair" for a crew to receive a train order before they have reached the train order station. And it isn't "right" for a crew to receive a train order after they have left the station from which it was issued. So maybe delivery could be tied-in with an electronic "OS" reporting feature.

I personally think that an electronic messaging system which provides some sort of positive notification of delivery, which requires operator acknowledgment of delivery, and which does not chop-up a train order into multiple messages would resolve 90% of my concerns.

This is really sounding like a custom App and appropriate support in JMRI. I'm thinking WiFi instead of over-the-air cellphone service.

As one who is not a smart-phone user, and one who is not a smart-phone App developer, I can only speculate on how such an App would work, and perhaps how it would interact with the user and perhaps interact/interfere with a WiThrottle/EngineDriver app.

At least we know that it should be at least feasible, as evidenced by the JMRI WiThrottle Server and its interactions with WiThrottle and EngineDriver "Apps".

Regards,
Billybob