Don't double-click on the roster entry line to open it. You haven't even checked what programming mode it will open in (I've been caught many times).Single click to select the wanted roster entry. Then single-click on the Program button below the roster entry list?after?having checked and selected the correct mode.?
Dave: You are correct of course that the clicking idiosyncracies can be avoided quite simply (and the roster entry method you describe is exactly what I usually do) but the fact remains that click/double-click behaviour is different in different columns of the Roster and that is peculiar to JMRI and not what computer users expect on the basis of their experience with other apps. Would it not be possible to open a loco by clicking on ANY column in a row that has been selected and use right-click or CTRL-click to edit the text in the 3-4 columns where text editing is possible? That would more closely align with the way other apps work. I hasten to say that none if this is critical and I truly appreciate the enormous amount of volunteer effort that goes into JMRI. I am sure volunteers are more motivated by working on additions to the substance of JMRI than tweaking details of the user interface - and that's a good thing. Jan
|
Lee, On May 31, 2019, at 12:07 PM, Lee Cashmore < cardy165@...> wrote: I have uploaded a debug log file into a folder (Hornby Elite XpressNet) in?the files area of the forum.?
This was simply running 1 train around the track (the train did hit a few dead spots on the track at once or twice)
It looks like all that worked as expected. I followed that with trying to use the identify loco option to detect the decoder in another loco on the programming track.?
This I find really interesting, and frustrating. ? Here¡¯s an example of part of the read sequence:
16:55:41.184: [packet:22 15 08 3F] Service Mode Request: Read CV 8 in Direct Mode 16:55:41.184: [61 02 63] Broadcast: Service Mode Entry 16:55:41.184: [packet:21 10 31] REQUEST: Service Mode Result? 16:55:41.184: [61 02 63] Broadcast: Service Mode Entry? 16:55:46.428: [61 01 60] Broadcast: Normal Operations Resumed? 16:55:46.444: [61 01 60] Broadcast: Normal Operations Resumed Everything looks like we expect until we ask for the service mode results. On a Lenz system, we would expect to see the results after the second service mode entry broadcast.
Can you try something for me? Start logging. Open the send packet tool ( in the XpressNet menu ) Enter 22 15 08 3F into the text box in the tool, then press send. What I want to see is if the command station automatically sends the Normal Operations Resumed broadcasts, or if it is doing this in response to the request for results.
If you would like, you can also send?21 10 31, but wait a few seconds before doing that.
Thanks, Paul
|
Locked
Re: DECODERPRO VERY LONG IDENTIFICATION TIME
Hello Ken,
?
No it is not a serial ethernet, but an arduino ethernet shield that comes plugger on the Mega Arduino.
?
It uses the classic ethernet protocol.
?
Thank you :-)
|
Thinking Dave down under, had to many Kangaroo Juices.
Just teasing. Thank for all the help you provide to this forum
Dave
Mount Joy, PA
Sent from my iPhone 6 Plus
toggle quoted message
Show quoted text
On Jun 1, 2019, at 06:09, Dave Heap <dgheap@...> wrote:
All,
On 1 Jun 2019, at 7:56 PM, Dave Heap <dgheap@...> wrote:
(just the same as happens if you double-click on a filename in Mac, Windows or Linux). I apologise. That statement was in error. Behaviours for editing a filename are not consistent across platforms (nor is the "Open" behaviour). Too late at night...
Dave in Australia
|
Locked
Re: DECODERPRO VERY LONG IDENTIFICATION TIME
Fcot,
Are you using some serial to ethernet adapter? If that is the case I suspect
your setup for things like how it knows when to send packets is not correct.
I've seen a lot of those devices that default for expecting some sort of
text or other form with a known delimiter to trigger sending the buffer as
one packet. But this traffic isn't like that. It needs to do something like
raw and a very short timeout, so it will complete the packet to JMRI (or the
other way, to the DCC+++ device).
OTOH, if somebody knows the protocol for DCC+++ and it is formed with a
known 'end' character, then making sure the interface knows that character
might make the difference.
That's my guess, but that's only if the interface is a serial to ethernet
buffer. If the DCC+++ command station is native ethernet, then I would doubt
this is related to your problem.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: DECODERPRO VERY LONG IDENTIFICATION TIME
Hello boy's
?
Bad news ! Yesterday I mounted a brand new DCC ++ Ethernet for a friend, and the problem of slowness is reproduced.
?
We switched to a USB serial and everything is ok.
?
Thank you Jim Albanowski for your comment, but I see that you are in USB serial and no problem, like us here.
?
The problem only comes in Ethernet mode ...
?
Someone would have any idea ?
?
Thank you for reading us (and for helping us too :-) )
|
Locked
Re: OpenLCB - Lights - Help
PS
Apologies all for getting the release numbers wrong, should read 4.15.7 and 4.14.4, oops!
Steve
|
Locked
Re: OpenLCB - Lights - Help
Hi Tim,
Fix contained in upcoming JMRI release 15.7
The Light Controls showing this message in JMRI 14.4 OpenLCB will still operate, it's just that the very first Light ON command may not trigger correctly.
This shouldn't be much of a problem with a FastClock at 90x speed, it'll just get updated 0.6 seconds later than normal on startup.
More of a problem with Light Controls that use a Sensor or Turnout as an input trigger, but at least you get an error popup if there's an issue!
I've only got a v basic knowledge of OpenLCB so not sure about the Light table interface thing.
Perhaps write up the feature request in more detail on Github to inspire one of the developers more fluent in OpenLCB?
Steve.
|
Locked
Re: IR Block Occupancy Sensors - Entrance and Exit
Jerry,
One of the main reasons that most use current detection is then anything, even a single wagon with resistor wheels, in the block will show up and that is what I would use but I was just trying to work with what Steve has on the layout now in the most economical way.
Tony
https://ozfreemo.com
|
You want to do two things:
- In your profile, using PanelPro, under "Preferences->Start Up", you want to add an Open File (pointing to your Turntable.xml file) and Run Script action (referring to your script)
- Use the command "/opt/JMRI/jmriHeadless --profile=/home/brian/.jmri/My_JMRI_Railroad.jmri" (the config option points to instructions about which profile to use if --profile is not specified, and the profile is a directory with a potentially large number of files).
You may also want to consider:
- Use VNC, not X-over-SSH, to access your Raspberry Pi -- this way, once you configure the default account to auto-login, PanelPro can be configured to be automatically launched by that user, and you can use VNC to connect to the running instance of PanelPro instead of only being able to launch PanelPro after you connect with Putty.
|
All, On 1 Jun 2019, at 7:56 PM, Dave Heap <dgheap@...> wrote:
(just the same as happens if you double-click on a filename in Mac, Windows or Linux). I apologise. That statement was in error. Behaviours for editing a filename are not consistent across platforms (nor is the "Open" behaviour). Too late at night... Dave in Australia
|
All, On 1 Jun 2019, at 3:27 AM, John <jonie41@...> wrote:
I have also noticed this several versions back, I figured that it is a quirk of
either JMRI or JAVA, I can live with it now that I know about it.
This behaviour has been around ever since the main DecoderPro3 window replaced the old clumsy and extremely dated dropdown list interface that was unworkable if you had more than 5 or 10 locos in your roster. No one has mentioned the simplest way of avoiding the "double-click to edit" behaviour (just the same as happens if you double-click on a filename in Mac, Windows or Linux). Don't double-click on the roster entry line to open it. You haven't even checked what programming mode it will open in (I've been caught many times). Single click to select the wanted roster entry. Then single-click on the Program button below the roster entry list after having checked and selected the correct mode.?
Dave in Australia
|
Rance, On 1 Jun 2019, at 4:02 AM, RANCE THOMPSON <thompsonrance@...> wrote:
I could not find System Console or Debug. You need to find the JMRI system console. It will tell us if JMRI is encountering an error opening the roster entry. When you start DecoderPro and the main roster window appears (all the loco entries you have created) there will be a menu bar across the top edge of that window. There will be the word "Help" there. Click on the "Help" word and you see a list. One of them will say something like "System Console". Click on test and a window will open (usually green text on a black background). The information in that window may be meaningless to you, but very helpful to us. That's why there is a "Copy to Clipboard" button so you can copy and paste into a message for us to see. I'd like to reiterate Ken's comment: Reinstalling JMRI when you have a problem is probably the worst thing to do. It almost never fixes the problem. Installing an older version of JMRI is highly likely to make the problem harder to solve. Dave in Australia
|
Locked
Re: Missing CBUS events on Raspberry Pi system
Hi Steve,
Some great ideas there - particularly about using MERGCBUSServer. I'd forgotten about that. I used it for a while after we had it demonstrated at one of the MERG meets. At the time I saw it as a convenient way to connect MERG FCU and JMRI to the same USB. Since then I've had little reason to use the FCU since much of my work is with home grown Arduino projects, so it fell 'out of favour' (not to mention ditching my last rarely used Windows machine in favour of linux). I shall definitely give it a go again!!
You also mention some of the growing list of JMRI tools available for CAN/CBUS. I've not used most of them at all. Clearly there has been a great deal of hard work with their development - again a big thank you to all the JMRI team!
Cracking this problem is quite important to me as it's the first time I've managed to get some traction within the club to use 'computers' at all, so I need it to go well!! It can be a lonely place as the only person in our club interested in this type of technology, so it's great to have the support of yourself and others on the forum.
Thanks
Andy
|
Locked
Re: What is the most recent "User's Guide" ? - looking for 4.14
If you are looking for a printable pdf, on the Jmri website> manuals tab at the top>far left edge is a pdf for 3.4
After that its all online as best as I know. Tom Wilson
Colorado Springs, CO
Hi,
?
I¡¯ve just updated to version 4.14 and looking for a ¡°User¡¯s Guide¡± for
version 4.14
?
I had an old User¡¯s Guide for version 2.12 and found it very useful but I
cannot find a similar Guide for version 4.14
?
I¡¯ve searched for? Manuals for 4.14 but can only find basic
information not the comprehensive notes in my old ¡°Guide.¡±
?
I¡¯m running Windows 7 and a SPROG Mk 2 and everything appears to be working
OK but I miss the detailed information in my 2.12 Guide.
?
If there is no ¡°Guide¡± for Version 4.14, what is the most recent ¡°guide¡±
available ?
?
Any help would be gratefully received.
?
Regards,
Warren
?
|
Locked
What is the most recent "User's Guide" ? - looking for 4.14
Hi,
?
I¡¯ve just updated to version 4.14 and looking for a ¡°User¡¯s Guide¡± for
version 4.14
?
I had an old User¡¯s Guide for version 2.12 and found it very useful but I
cannot find a similar Guide for version 4.14
?
I¡¯ve searched for? Manuals for 4.14 but can only find basic
information not the comprehensive notes in my old ¡°Guide.¡±
?
I¡¯m running Windows 7 and a SPROG Mk 2 and everything appears to be working
OK but I miss the detailed information in my 2.12 Guide.
?
If there is no ¡°Guide¡± for Version 4.14, what is the most recent ¡°guide¡±
available ?
?
Any help would be gratefully received.
?
Regards,
Warren
?
|
Greetings, I think I've got my configuration working to control the Walther 130' DCC-controlled turntable from our LCC control panel. As a reminder, I've got a Raspberry Pi mounted under the module, along with several Tower-LCC nodes (connected by a LCC-Buffer-USB to the Raspberry Pi) and another Serial cable going to the NCE Command Station. I've spent the evening in PanelPro, pressing buttons, making the turntable go where I want it. NOW, it's time to "productionize" this... to configure it so that I don't need to have Putty and XMing running, all I want to have to do is connect power to the module and the Command Station, and have the R-Pi start up JMRI "Headless" automatically (to many in the club, that's pronounced "automagically.") I'm looking for command-line prompts, and while I've found a couple of useful ones, I don't see how to:
- Specify the "Panel" (actually, just a configuration of Sensors listening to the LCC Events, and Turnouts that generate the requisite DCC Events via the Command Station), and
- Specify to run a particular Jython script upon startup (it listens to the Sensors, identifies which lead is intended from their UserName, remembers which direction the turntable was facing last time the requested track was selected, and then determines to either Throw or Close the "turnout" to send the turntable a-spinning.)
Basic command (probably to be run via systemd, although I haven't committed yet):
- /opt/JMRI/jmriHeadless --config=/opt/JMRI/jmri.conf --profile=/home/brian/.jmri/My_JMRI_Railroad.jmri/profile/profile.xml
This specifies the configuration and profile files, per the instructions on the JMRI website. I've also go: script: /home/brian/.jmri/turnoutListener.py
"panel" definition
/home/brian/.jmri/My_JMRI_Railroad.jmri/Turntable.xml
How can I indicate to use those when jmriHeadless is run?
Thanks,
Brian Pickering
|
On Fri, May 31, 2019 at 07:49 PM, <forfoum@...> wrote:
On Fri, May 31, 2019 at 06:53 PM, Breezlys wrote:
Anyway, the legacy interface is what I've been using all along so I haven't encountered this issue.
I tried the "legacy" alternative and it does not change or resolve the issue Jan and I are speaking of; the roster window itself acts the same:? single click puts the field in edit mode, double click working depends on the field. Weather you are in LEGACY or DP3 the roster is the same.
Marc
Marc, I'm not talking about the .? Yes, I'm sure it'll behave the same whichever interface you use to access it (DP3 or legacy). But again, when using the legacy interface I don't need to use that roster window. I simply select the roster entry I want from , then click on "Open Programmer". Steve "Breezlys"
|
Locked
Re: Minor bug in DCC++ track current meter
Mike,
There has been some discussion of the problem of "proper" system-specific interpretation of current meter information as of 27May2019 on the "jmri developers" e-mail list. This is getting some amount of attention from at least a couple of developers. It is unclear to me when any action on this issue may occur.
Regards,
Billybob
|
Locked
Minor bug in DCC++ track current meter
With JMRI 4.15.6, DCC++ (Arduino Uno and Pololu motor shield) hosted on PC running Linux the values reported by the track current meter (DCC++ => track current meter) are off by a factor of 100. For example a value of 512 reported by the DCC++ traffic monitor is shown as 00.5 % on the current meter; it should be 50.0%. I suspect the code divides the value by 1024 but does not multiply the result by 100 to convert to percent.
To verify this I modified the Arduino base station code to add two zeros to the current value (for example 51200 instead of 512). The JMRI track current meter then displayed the correct 50.0% value.
-- Mike
|
FCOT2002
Ken Cameron