开云体育

Hi,

Trying a similar thing per a previous post with RPI 3 running JMRI 4.12, Java 191 but using the Loconet simulator for testing purposes.? The client is a Pi zero wireless with same pieces of software on the same network. (The zero with a small touch screen is actually cheaper that iPads, etc.).??

Set up the server start action in preferences.? Restarted JMRI on the RPI.? ?Opened a Panel Editor panel.? Started JMRI on the zero.??

No joy with any of the JMRI client/server options: Simple server, Loconet 'direct', Loconet over IP...

The zero says cannot connect to the server and opens the preference dialog to update.? The Loconet tab is highlighted in red.
The RPI does?not?seem to start the Loconet Server at init, even though I get?

INFO - Using jmri-n- as the JMRI Node identity [AWT-EventQueue-0]
INFO - lnPacketizer Started [main]?

in the console
and starting it manually gives:

WARN - Could not Create RMI Registry, Attempting to locate existing Registry for: LoconetServer [AWT-Eventque-0]

Both systems can ping each other across the network.
Please advise, and thanks,

Martin Booker
BTW: the Web pages for client server configuration need an update as those screens are not the same in 4.12

Another try with more robust iMac as client to same RPI server.

Log file:

2019-01-02 16:05:46,872 node.NodeIdentity? ? ? ? ? ? ? ? ? ? ?INFO? - Using jmri-lVjxtcZsGhNiaaypSc6P96-3eeb2581 as the JMRI Node identity [AWT-EventQueue-0]

2019-01-02 16:05:47,253 locormi.LnMessageClient? ? ? ? ? ? ? ?ERROR - Exception while trying to connect: java.rmi.ConnectException: Connection refused to host: 192.168.1.15; nested exception is:?

java.net.ConnectException: Connection refused (Connection refused) [main]

2019-01-02 16:05:47,255 configurexml.ConnectionConfigXml? ? ? ERROR - Error opening connection to 192.168.1.15 was: {} [main]

jmri.jmrix.loconet.LocoNetException: Failed to Connect to Server: 192.168.1.15

at jmri.jmrix.loconet.locormi.LnMessageClient.configureRemoteConnection(LnMessageClient.java:93)

at jmri.jmrix.loconet.locormi.configurexml.ConnectionConfigXml.load(ConnectionConfigXml.java:110)

at jmri.jmrix.ConnectionConfigManager.initialize(ConnectionConfigManager.java:106)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:264)

at jmri.implementation.JmriConfigurationManager.lambda$3(JmriConfigurationManager.java:260)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:259)

at jmri.implementation.JmriConfigurationManager.lambda$3(JmriConfigurationManager.java:260)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:259)

at jmri.implementation.JmriConfigurationManager.lambda$1(JmriConfigurationManager.java:183)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.load(JmriConfigurationManager.java:182)

at jmri.implementation.JmriConfigurationManager.load(JmriConfigurationManager.java:170)

at apps.Apps.<init>(Apps.java:261)

at apps.PanelPro.PanelPro.<init>(PanelPro.java:40)

at apps.PanelPro.PanelPro.main(PanelPro.java:120)

2019-01-02 16:05:47,286 locormi.ConnectionConfig? ? ? ? ? ? ? WARN? - Unexpected call to setInstance, multi-replica capability not yet present [main]

2019-01-02 16:05:47,293 jmrix.ConnectionConfigManager? ? ? ? ?ERROR - Unable to create jmri.jmrix.loconet.locormi.configurexml.ConnectionConfigXml for [Element: <connection/>], load returned false [main]

2019-01-02 16:05:47,295 plementation.JmriConfigurationManager ERROR - Exception initializing jmri.jmrix.ConnectionConfigManager: Unable to create connection "LocoNet" (L). [main]

2019-01-02 16:05:47,646 jmri.InstanceManager? ? ? ? ? ? ? ? ? ERROR - Should not set default of type jmri.CommandStation to null value [main]

2019-01-02 16:05:47,647 managers.ManagerDefaultSelector? ? ? ?WARN? - SystemConnectionMemo for LocoNet (class jmri.jmrix.loconet.LocoNetSystemConnectionMemo) provides a null interface jmri.CommandStation instance [main]

2019-01-02 16:05:47,648 plementation.JmriConfigurationManager ERROR - Exception initializing jmri.managers.ManagerDefaultSelector: System connection LocoNet provides a null manager for interface jmri.CommandStation [main]

2019-01-02 16:05:47,720 plementation.JmriConfigurationManager ERROR - Exception initializing apps.StartupActionsManager: jmri.util.prefs.InitializationException: Unable to run startup actions due to earlier failures. [main]


There is no firewall that I am aware of on the RPI.

Thanks,
Martin Booker

Martin, you mention several different connection mechanisms. If your target is Loconet, I suggest focusing on the LoconetOverTCP connection and ignore the others. I use it regularly on my home and club layouts with excellent results (Win10 laptop client to RPi server).
Make sure you are specifying the same port on the server and client sides. I believe the default for that connection is 1234, but check both sides anyway.
--SteveT

This looks like the LocoNet Simulator might not fully handle the connection as a server. (The Simulator connection isn’t intended to simulate an entire layout; it just has stand-ins for various things)

Try setting up the server as a real Loconet connection. There doesn’t need to be real hardware out there, just a serial port it dump commands out.

Bob

On Jan 2, 2019, at 4:09 PM, mabooker76 <mabooker76@...> wrote:

Another try with more robust iMac as client to same RPI server.

Log file:
2019-01-02 16:05:46,872 node.NodeIdentity INFO - Using jmri-lVjxtcZsGhNiaaypSc6P96-3eeb2581 as the JMRI Node identity [AWT-EventQueue-0]

2019-01-02 16:05:47,253 locormi.LnMessageClient ERROR - Exception while trying to connect: java.rmi.ConnectException: Connection refused to host: 192.168.1.15; nested exception is:

java.net.ConnectException: Connection refused (Connection refused) [main]

2019-01-02 16:05:47,255 configurexml.ConnectionConfigXml ERROR - Error opening connection to 192.168.1.15 was: {} [main]

jmri.jmrix.loconet.LocoNetException: Failed to Connect to Server: 192.168.1.15

at jmri.jmrix.loconet.locormi.LnMessageClient.configureRemoteConnection(LnMessageClient.java:93)

at jmri.jmrix.loconet.locormi.configurexml.ConnectionConfigXml.load(ConnectionConfigXml.java:110)

at jmri.jmrix.ConnectionConfigManager.initialize(ConnectionConfigManager.java:106)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:264)

at jmri.implementation.JmriConfigurationManager.lambda$3(JmriConfigurationManager.java:260)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:259)

at jmri.implementation.JmriConfigurationManager.lambda$3(JmriConfigurationManager.java:260)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.initializeProvider(JmriConfigurationManager.java:259)

at jmri.implementation.JmriConfigurationManager.lambda$1(JmriConfigurationManager.java:183)

at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382)

at java.util.stream.ReferencePipeline$Head.forEach(ReferencePipeline.java:580)

at jmri.implementation.JmriConfigurationManager.load(JmriConfigurationManager.java:182)

at jmri.implementation.JmriConfigurationManager.load(JmriConfigurationManager.java:170)

at apps.Apps.<init>(Apps.java:261)

at apps.PanelPro.PanelPro.<init>(PanelPro.java:40)

at apps.PanelPro.PanelPro.main(PanelPro.java:120)

2019-01-02 16:05:47,286 locormi.ConnectionConfig WARN - Unexpected call to setInstance, multi-replica capability not yet present [main]

2019-01-02 16:05:47,293 jmrix.ConnectionConfigManager ERROR - Unable to create jmri.jmrix.loconet.locormi.configurexml.ConnectionConfigXml for [Element: <connection/>], load returned false [main]

2019-01-02 16:05:47,295 plementation.JmriConfigurationManager ERROR - Exception initializing jmri.jmrix.ConnectionConfigManager: Unable to create connection "LocoNet" (L). [main]

2019-01-02 16:05:47,646 jmri.InstanceManager ERROR - Should not set default of type jmri.CommandStation to null value [main]

2019-01-02 16:05:47,647 managers.ManagerDefaultSelector WARN - SystemConnectionMemo for LocoNet (class jmri.jmrix.loconet.LocoNetSystemConnectionMemo) provides a null interface jmri.CommandStation instance [main]

2019-01-02 16:05:47,648 plementation.JmriConfigurationManager ERROR - Exception initializing jmri.managers.ManagerDefaultSelector: System connection LocoNet provides a null manager for interface jmri.CommandStation [main]

2019-01-02 16:05:47,720 plementation.JmriConfigurationManager ERROR - Exception initializing apps.StartupActionsManager: jmri.util.prefs.InitializationException: Unable to run startup actions due to earlier failures. [main]


There is no firewall that I am aware of on the RPI.

Thanks,
Martin Booker

--
Bob Jacobsen
rgj1927@...

Thanks Steve and Bob,

The Loconet over IP server generally works from the iMac to the RPI.? The status window on the RPI shows running and the client count 1.

Using the Loconet sim on the RPI, and the LocoBuffer (PS) as the command station type on the iMac (client) I am able to
manipulate the panel (which has to be on both computers) though the sensor states get out of synch, i.e. I am triggering routes
for yard ladders and though the switch positions are correct for the 'activated route' picked on the client the server shows a different active
sensor.? Do not think that it will be a problem as the virtual panel used by the yard master will be the 'system of record'.

I will go down to the club and try it 'for real' to see if there is still an issue.

Much appreciated,
Martin Booker

On Thu, Jan 3, 2019 at 09:05 AM, mabooker76 wrote:

Using the Loconet sim on the RPI, and the LocoBuffer (PS) as the command station type on the iMac (client)

Martin, if your "client" machine is using a Locobuffer to connect to the Loconet directly, then you are not using (or needing) the LoconetOverTCP Server connection.?

I'm not sure what your desired configuration is here. Can you describe it further?

--SteveT

Replacing old analog panels (and all the associated relay wiring) with virtual panels at the East and West end of 60' yards.

The thought was to use Pi's and touch screens talking to a 'larger' computer running the layout with PanelPro.? The testing was at home using
the RPi 3 (a Locobuffer sim since it is not really connected to anything) as the main system talking across wireless to Pi zeros.??

The problem with the zero's is that the browser uses 100% of the cpu, and response time is poor for updates just talking to the JMRI Web server for our size layout (5k square with about 100 Loconet devices).? Older iPads etc. need to use frames rather than panels, another poor response time option.
So I loaded JMRI on to the zero's, which consumed only roughly 30-50% of the cpu.? Then the decision is which client/server protocol to use to get a JMRI yard panel 'subset', a single panel 'screen' to work on the zeros for the yard operators.? Those yard screens are actually iconified on the main computer that is running primarily for dispatching functions.??

I was not able to get a test using SImple Server, or Loconet only to work...though Bob's thought that the Loconet sim is not robust seemed to be the issue.

At the club I was able to get Loconet over TCP working with good response, i.e. real time updates of the same panels located on both machines.? I guess what I was looking for was the ability to 'allocate' sub panels to different devices that do not necessarily need to share all the table data, i.e. the yard switches (and associated panel and tables) do not have to be known/controlled by the dispatcher's instance of JMRI who is concerned about the mainline.

Might be asking for too much,

Thanks for your assistance,
Martin Booker

Thanks for the details, Martin. Good to hear it's working for you.
In my experience, running the GUI desktop takes a large chunk of RPi memory, and I found it too slow for my taste until the RPi2 and RPi3, which bumped memory to 1Gb. The PiZeroW is still at 512Mb.
I'm curious why you're not using (newer) smart tablets for displaying your local panels? The /panel web client only gets updates for items defined on the specific panel shown.
--SteveT

[Moderator:? if this needs to be a new topic please advise]

I guess the decision is having a single instance of JMRI/Web versus multiple versions running specific 'applications', i.e. layout areas.? My old IT work was with multiple smaller systems (clusters, etc.) working across a network versus a monolithic single system.

We envisioned replacing 24 anodized push button/toggled real panels (heavily wired with tons of relay logic that no one understands anymore) with 6 or 7 'virtual panels' with mapping to the three large yards, 2 Engine service areas (for consisting, and loco roster), a couple displays in the operators' gallery (no walk around capability so something to show where trains are and virtual signals) and a two monitor dispatch area (the layout is 5k square feet - everything is at least 35 feet from everything else).? We have dismantled the 10 'cabs' already - replaced with DCC throttles and plugins as well as wireless.

iPads are $250-$300 (Amazon) and cannot run java.? A Pi ZW is $25 - touch screens $140ish, and can be embedded into the real panel - moving from the analog toggles/buttons to a virtual PanelPro screen as progress continues.? A Pi ZW attached to a donated 40 inch HDMI with just a block detected and virtual signal panel seems to work for operators (but that is for output only).?

There does not seem to be a lot of data on 'distributed JMRI', at least not what I can find in the blog?

Martin Booker?

If you want to connect to actual layout hardware, e.g. C/MRI or LocoNet or whatever, there really isn’t a true distributed option. Most hardware systems have a single point of connection; some (like LocoNet) allow more connections, but don’t make the complete state available that way. (OpenLCB was intended to be full distributed, but even that seems to have recently taken some steps toward localization)

But in the end, it’s just a model railroad. There’s not really a problem with having one machine connect to the layout and provide services to the rest.

So that’s the approach that most people have taken: One primary layout computer which handles the main connection, and some number of web browsers (i.e. tablets) and/or full JMRI instances (i.e. RPis) talking to it and hence to the layout.

The size you’re talking about below is not very hard for a JMRI instance on a real computer to keep up with. The remote RPs could work as web browsers or run JMRI to locally display the panels; that mostly depends on which you find simpler to set up and maintain.

Bob

On Jan 4, 2019, at 8:58 AM, mabooker76 <mabooker76@...> wrote:

We envisioned replacing 24 anodized push button/toggled real panels (heavily wired with tons of relay logic that no one understands anymore) with 6 or 7 'virtual panels' with mapping to the three large yards, 2 Engine service areas (for consisting, and loco roster), a couple displays in the operators' gallery (no walk around capability so something to show where trains are and virtual signals) and a two monitor dispatch area (the layout is 5k square feet - everything is at least 35 feet from everything else). We have dismantled the 10 'cabs' already - replaced with DCC throttles and plugins as well as wireless.

iPads are $250-$300 (Amazon) and cannot run java. A Pi ZW is $25 - touch screens $140ish, and can be embedded into the real panel - moving from the analog toggles/buttons to a virtual PanelPro screen as progress continues. A Pi ZW attached to a donated 40 inch HDMI with just a block detected and virtual signal panel seems to work for operators (but that is for output only).

There does not seem to be a lot of data on 'distributed JMRI', at least not what I can find in the blog?

--
Bob Jacobsen
rgj1927@...

If JMRI is running on an RPi and talking to the layout via LocoNetOverTcp, there’s no need for a panel to be open on the main machine. It can be opened independently on the client RPi (or not). As far as that client is concerned, it thinks it’s directly connected to the layout and can do whatever it wants independently.

If you’re talking about LayoutEditor panels, you have to be a bit careful because they’re also a way to instantiate layout _logic_. You want some machine, but only one machine, to be running the signals, for example.

Bob

On Jan 3, 2019, at 8:17 PM, mabooker76 <mabooker76@...> wrote:

Then the decision is which client/server protocol to use to get a JMRI yard panel 'subset', a single panel 'screen' to work on the zeros for the yard operators. Those yard screens are actually iconified on the main computer that is running primarily for dispatching functions.

--
Bob Jacobsen
rgj1927@...

[If JMRI is running on an RPi and talking to the layout via LocoNetOverTcp, there’s no need for a panel to be open on the main machine. It can be opened independently on the client RPi (or not). As far as that client is concerned, it thinks it’s directly connected to the layout and can do whatever it wants independently.

If you’re talking about LayoutEditor panels, you have to be a bit careful because they’re also a way to instantiate layout _logic_. You want some machine, but only one machine, to be running the signals, for example.]
So what it appears I can do is have the 'dispatcher' JMRI instance run with its LayoutEditor panels for real time and linkage.? PanelEditor panels on Pi ZX's with touch screens with their own JMRI instance(s).? As long as the switch addresses (tables) are congruent across all the instances (back end a front end of the yards have the same addresses - no conflict with the mainline). No signaling in the yards.??

The single Loconet-USB at the dispatcher station should not get overrun?

One benefit of this is that the main 'layout' xml file gets smaller (currently ~25k lines) and making changes for UI or operations at a particular area can be done independently?

Thanks for all your assistance,
Martin Booker

Yes, that's a good setup.
I don't think you'll overload anything (other than the track bus), but If you want to distribute the load more, you could have a locobuffer-usb on each RaspberryPi, and take a bit more off of the central machine.
--SteveT

A LocoNet-USB can’t get overrun without the LocoNet itself being over-run. That’s easier with multiple computers attached, not harder.

Bob

On Jan 4, 2019, at 2:18 PM, mabooker76 <mabooker76@...> wrote:

The single Loconet-USB at the dispatcher station should not get overrun?

--
Bob Jacobsen
rgj1927@...