¿ªÔÆÌåÓý

Locked Multiple Openlcb Conections


 

Will JMRI bridge multiple OpenLCB connections?
Will an event on one segment be seen on the other segment?


Regards
Nom d'Inet


 

JMRI will only bridge the events you place logic to connect them. Each
connection is treated as separate. So a Logix that watch a sensor on one
connection could then drive a turnout or sensor on the other connection.



But there are bridges available or look at the code from Robert Heller at
deepsoft.com. I seem to recall he has a number of tools like that for LCC.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org


 

Ken thanks.


I tried to create Sensors and Turnouts in both OpenLCB connections.
Selecting "Make Sensor" or "Make Turnout" creates sensors or turnouts in the first connection only.


Manually entering an entry in the second connection is fine.


Regards
Nom d'Inet


 

Nom,



Did you pick from the pull down for 'System Name' the 2nd connection?? It is
correctly creating table entries for the two systems.



What reason do you have for using 2 connections rather than having a single
LCC bus??



At this time tools like the traffic monitor does not show in its name which
connection it is showing. But while you get two windows, both labeled
'OpenLCB Monitor', they do show the separate traffic.



-Ken Cameron, Member JMRI Dev Team

www.jmri.org

www.fingerlakeslivesteamers.org

www.cnymod.com

www.syracusemodelrr.org


 

Ken,


The problem occurs when attempting to create a sensor or turnout in the node configuration window - not the table view for sensors or turnouts.


The two connections are for geographic separation of the two CAN segments.


Regards
Nom


 

I am also trying two different LCC/Openlcb buss's. The main one is RR-CIRKTS cards. The second is for testing with Raspberry PIs and Arduinos.
I would like an event to show up on both busses.

--
Don James
Member Detroit Model Railroad Club


 

Nom,

Your original posting does not indicate whether you want two-way communication or only need master-slave communication. Followup postings seem to indicate that you are concerned with Sensors and Turnouts, but perhaps other kinds of device messages might also be involved. Do your turnouts provide feedback status reports?

I have no hands-on experience with OpenLCB, but it seems fair to ask if one bus can be hardware connected to the other. If even remotely possible, that might provide a more robust method for sharing message events.

It is not clear to me that this TurnoutsMasterSlave script even partially answers your question or even provides some clues to your puzzle. The default prefixes for DCC connections have changed since it was written, so some careful editing would be necessary.

Even if it works for Turnouts Master-Slave messages, a lot of work would be needed for two-way communication. Some further work would also be required for Sensors in either case.

Cliff in Baja SoCal


 

If messages are to show up on both, why are you trying to keep them separate? Is there some other isolation you¡¯d like to enforce?

You could write a script to listen for frames on one interface and send them to the other, and vice-versa. JMRI also has the start of work on an internal hub that¡¯s meant to combine connections but (1) it was meant for network connections, not wired ones; I¡¯m not sure whether that makes a difference and (2) as far as I know it was never completed. It might be easier for somebody to finish that than to write a new script.

Bob

On Sep 6, 2019, at 1:57 PM, dsj782@... wrote:

I am also trying two different LCC/Openlcb buss's. The main one is RR-CIRKTS cards. The second is for testing with Raspberry PIs and Arduinos.
I would like an event to show up on both busses.
--
Bob Jacobsen
rgj1927@...


 

Don,

To amplify a little bit on what Bob has just said. The nature of LCC is that there will be no conflicts created by connecting the two systems to each other to make it into one. Because it is a peer-peer network, that extends to running multiple computers such as a Windows or Mac machine for one purpose and Linux on a Pi for experimenting or some other purpose. All messages will show up at any node that wants to use them. For example just as soon as you get some experimental Arduino talking to LCC, its functionality will be available to your 'main' system. You could build a JMRI CTC panel on one machine and do your CDI configuration with the other. The system can support both functions simultaneously on the same network bus.

If your wiring doesn't allow you to loop one network into the other easily, then use a Repeater to join the two segments. If your concern is power isolation, then place the Repeater between two Power Points. That will allow you to power down one segment without disturbing the other.

Dick :)

On 9/8/2019 11:05 PM, Bob Jacobsen wrote:
If messages are to show up on both, why are you trying to keep them separate? Is there some other isolation you¡¯d like to enforce?

You could write a script to listen for frames on one interface and send them to the other, and vice-versa. JMRI also has the start of work on an internal hub that¡¯s meant to combine connections but (1) it was meant for network connections, not wired ones; I¡¯m not sure whether that makes a difference and (2) as far as I know it was never completed. It might be easier for somebody to finish that than to write a new script.

Bob

On Sep 6, 2019, at 1:57 PM, dsj782@... wrote:

I am also trying two different LCC/Openlcb buss's. The main one is RR-CIRKTS cards. The second is for testing with Raspberry PIs and Arduinos.
I would like an event to show up on both busses.
--
Bob Jacobsen
rgj1927@...





 

Dear All,

I gave up with this experiment for many reasons and its some time ago so the some of the details have slipped my mind.

As I recall, the configuration was a USB/CAN connection to a local segment and TCP/IP to a remote layout.? I was attempting to use the remote layout for checking compatability with later versions of software in my nodes.? I gave up for because the then version of JMRI would only send events to the first connection and the latency in the TCP/IP connection caused issues if the local CAN segment was disconnected.

Nom