Keyboard Shortcuts
Likes
Search
Locked Multiple Openlcb Conections
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 |
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 |
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:-- Bob Jacobsen rgj1927@... |
Don,
toggle quoted message
Show quoted text
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? |
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 |