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

PS
Apologies all for getting the release numbers wrong, should read 4.15.7 and 4.14.4, oops!

Steve

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.

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

开云体育

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

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

开云体育

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:

1. 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
2. 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

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"

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

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

Charlie,

Letting the PC go to sleep will disrupt the device driver. It will not
recover. That's why you have to close JMRI and reopen it.

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

On Fri, May 31, 2019 at 01:09 PM, Jan Carr wrote:

This single click/double click idiosyncrasy I, personnally,? find annoying. I do not see the need for it. Plus the fact the field could be edited accidentally and the change saved to roster non-intentionally.

Me too. The convenience of being able to edit certain fields directly from the roster panel seems to have been added at the expense of making access to individual locos more difficult, confusing and accident-prone.

Jan

I've always felt that the "DecoderPro 3" interface was beneficial only to the person(s) who wrote/promoted it. ISTR there was a lot of discussion about it, so much so that when it was made the default, instructions were provided for accessing the "legacy" interface:? ? (Yes, I know "code wins", but not everyone is proficient at coding (or any other given skill), so those who aren't are at the mercy of those who are.)

Anyway, the legacy interface is what I've been using all along so I haven't encountered this issue. With the legacy interface, you scroll through and select the roster entry from a drop-down list, and then click "Open Programmer". No muss, no fuss!

If they ever take that away, It'll really hurt...

Steve
"Breezlys"

Hi Andy,

I have to say well done for narrowing the fault down as far as you have already :-)
A major bonus that you have a known working system to test against!

I'm assuming this is always happening when you have a panel loaded, is it possible to test a fresh new profile without Logix / Sensor tables / panels?

Changing error logging won't make much difference I think, what I've found with a Pi is the GUI processing for VNC takes up magnitudes more resource than logging. ( though I could well be wrong )

For JMRI development I'm testing with a Pi2 + CANUSB4, class 10 SD Card, cable networked to a router.
No missed frames observed when I've done peak then back-off testing, but thinking this through realised one key difference.
I don't have the CANUSB4 direct to JMRI.
I'm running on the Pi so that the CAN frames are on the local network.
JMRI on the Pi connects to MERGCBUSServer as localhost via a Network Connection, not a USB connection.

Perhaps repeat the test to see if frames are ever lost when running via CBUSServer on the Pi??

Note that missed CBUS CAN frames will be a lot more obvious in the startup of JMRI v 15.5+ compared to v 14.4.
The JMRI? will error log if there's an issue with a dropped frame ( approx. 1,000 frames on an average CANPAN ).
We can't do this routinely for all frames as it's only certain sequences where frames should 100% be expected back in response.

The can be handy for debug as well.
With nothing else apart from 2 JMRI's on the network, leave the sequencer on 1 JMRI sending an event every 20ms, then put the kettle on.
After your cuppa, check if totals in each of the JMRI console logs match.

Steve.

The files are processed in alpha order. If the mfg or mfg/family is the same as the previous one, then the new file is added as a leaf on the existing tree branch. If not, that change means a new branch will be created.

If you want your decoder to appear in an existing branch, have the name be alpha before or after the one you want to have as a neighbor.

Bob

On May 31, 2019, at 9:20 AM, Marco Kr?mer <mkraemer1@...> wrote:

Hello,
I have created a new, extended file based on the file "Lenz_Plus_2010.xml",
Saved under a new name, imported with "Import Decoder File" and then executed "Recreate Decoder Index".
After restarting "JMRI Decoder Pro" "Lenz" appears twice in the window of "+ New Loco".

Here is the modified header of the file:

<Decoder>
<family name = "KM1" mfg = "Lenz" highVersionID = "255" lowVersionID = "9" comment = "Lenz Gold + decoder, KM1 SUSI-Sound / SUSI-Steam module">
<model model = "KM1 DVI - Lenz +, KM1 Sound / Steam" numOuts = "5" numFns = "31" maxMotorCurrent = "1.0A" formFactor = "HO" maxTotalCurrent = "1.0A">
<versionCV highVersionID = "91" lowVersionID = "91" />
<output name = "1" label = "A" maxcurrent = "0.5A" />
<output name = "2" label = "B" maxcurrent = "0.5A" />
<output name = "3" label = "C" maxcurrent = "0.5A" />
<output name = "4" label = "D" maxcurrent = "0.5A" />
<output name = "5" label = "E" maxcurrent = "0.5A" />
</ Model>
</ Family>

Why ?

The new, additional branch looks like this:
Lenz
KM1
KM1 DVI - Lenz +, KM1 Sound / Steam


If you look at the window, you will notice that there are seemingly several sorting errors in the upper level ...
(Example: Electronicsript, Inc).

In the 2nd level... "LENZ" is "function decoder" in the middle of the list ....
Why ?
What is the sorting process?

If necessary, I can provide the entire file ...

JMRI 4.15.3

Kind regards
M.K.

Virenfrei. www.avast.com

--
Bob Jacobsen
rgj1927@...