Keyboard Shortcuts
ctrl + shift + ? :
Show all keyboard shortcuts
ctrl + g :
Navigate to a group
ctrl + shift + f :
Find
ctrl + / :
Quick actions
esc to dismiss
Likes
- Jmriusers
- Messages
Search
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
Dave,
JMRI already has a separation between "Train Control" and "Layout Control¡±. ?It is not always clear and there are certainly overlaps. ?Train Control is defined in Preferences >> Defaults. ?The assigned Connection Prefix character in Preferences >> Connections defines Layout Control. ?For layout control hardware that receives commands via the track such as some turnout controllers, the command station will be involved. Creating a script to transfer user names from a source system name to a destination system name is not difficult. ?All it requires is a CSV file that provides the mapping. ? Of course, the effort to create the script and CSV file will probably exceed the effort to just move the user names within JMRI. Dave Sand |
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
Bob,
toggle quoted message
Show quoted text
I am not suggesting major changes to JMRI but simply a tidying up of the initial Setup part where, it would appear, that perhaps it would be a good idea if the ¡®Configuration' and ¡®Default' screens were re-configured or re-designed to reflect the difference between the Train Control System side (the choose DCC System) of the program and the Layout Control System side of the program When the user decides to move away from having just the one original DCC System to control everything and chooses to add in a second (or third, etc) system to control the devices within the layout. Dave On 11 Jun 2019, at 15:01, Bob Jacobsen <rgj1927@...> wrote:On Jun 11, 2019, at 6:37 AM, Dave Roberts <dccdaveroberts@...> wrote:This is what user names are for. |
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
Looks like your right.? I plan to continue with creating a loconet for detection and feed back to JMRI.? So I hope I got that part right.? Might have a unused sourrundtraxx for sale soon!!?
|
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
On Jun 11, 2019, at 6:37 AM, Dave Roberts <dccdaveroberts@...> wrote:This is what user names are for. System names _describe_ a particular piece of hardware. (Technically, they¡¯re parsable keys to that description, but for the purposes of this long thread there¡¯s no distinction) User names are a flexible format, updatable pointer to a piece of hardware. If you want to have multiple sets of hardware, you (1) need to specify how to specify the specific hardware items, which you do via system names _and_ lots of other configuration information and (2) you need to access it to tell that hardware what to do, i.e. to hook up bottoms on a panel or bits of control logic. If you want flexibility in that, you use user names. These arguments can go on and on, which is why I am suggesting that we should have a step back and look back and remind ourselves how JMRI was originally created and what was available at that time and compare that to what we are being offered today.Agree with the first part; the arguments do go on. If you want to do the second part, I suggest it might be time to do it elsewhere. I see no reasonable prospect that JMRI will stop having it¡¯s current system names and user names, because they work for thousands and thousands of people. You¡¯re pursuing a major change that AFAIK _nobody_, including yourself, actually needs in practice because there¡¯s already a solution that would require less work. Bob -- Bob Jacobsen rgj1927@... |
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
Dave,
toggle quoted message
Show quoted text
It has already been mentioned why the following concept breaks down. There is little, if any, similarity or consistency between different systems. It is not too different to conceive how to convert between manufacturers on the DCC side because there is at least a common target. (the rails) But even there, as you can see from Mark's table, things are not guaranteed to work from one manufacturer to another. Ask anyone that has programmed a loco to 0042 on an NCE system and then tried to operate it on ANY other DCC system. When you get to the Layout control side there is essentially no standard at all that will allow you to do any sort of automated conversion from one system to another. This might appear possible on the surface, but only when the actual target is a DCC accessory command. For example LT137 and NT137 may make it appear to be easy to automatically convert between systems. However this is NOT a layout control message, it still a train control message because it is based on the DCC (train control) standard. As soon as you even step even one foot off of the DCC standard reservation, then you are dead in the water. Take the simple example of converting LS15 (sensor 15 on a LocoNet system) to an AIU sensor on an NCE system. What will the NCE sensor ID be converted to? (the answer is not NS15) Changing how JMRI works isn't going to change the underlying issue that system names are actually shorthand for hardware specific information, and different hardware uses different addressing methods and schemes. There simply are not any conversion rules that will ever convert LocoNet Hardware addresses to LCC hardware addresses, nor NCE hardware addresses to CMRI hardware addresses, nor XPressNet addresses to MERG addresses. (and the list goes on) Dick :) On 6/11/2019 5:44 AM, Dave Roberts wrote:
It is at this point that the problems associated with using the Unique System Name and Stability come into play. Any change to the Configuration and Defaults for both the Train Control system and/or the Layout Control System will need to be reflected throughout the xml file and with all of the Tables. This means that any changes has created the need to change every instance where the System Name changes, be this in the Tables or the xml program itself. Automate this process in some way rather than doing it one-by-one. |
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
¿ªÔÆÌåÓýHi Steve,If I am reading you correctly, what you are saying that is actually happening on users layouts would most certainly make it impossible, let alone feasible! You said: ?"How would JMRI know which one is a MERG Turnout, or an XpressNet Turnout if you've got both hardware types on your layout? How would you change an internal Turnout system name "IT123" to OpenLCB Turnout system name "MT0102030405060708;0102030405060709" ? I can appreciate why a user might choose to have the major groupings of devices - Turnouts, Signals, Occupancy Detectors, Positional Feedback Devices, Lights, etc - all operated using different manufacturers Control Devices for each type but why would they suddenly change from one type to another for individual Turnouts or Signals or any of the major groups of devices? Why would any user choose to deliberately complicate their Layout Control System by using different manufacturers equipment every time they purchased new equipment of a similar type? To my way of thinking this would be like me, having decided originally, to use the Lenz DCC system to control everything (Both Systems) and then later on, when I have created the next part of the layout, to change from Lenz to using the Merg CBUS Modules (because it is cheaper) to control my devices (This is where the conscious decision has been made to separate out both Train Control from Layout Control) at the new location on the layout. The logical extension to this is that I might choose a different Manufacturer every time I developed a new location on the layout for whatever reason or worse still, allow every device to have its own Controlling Device? (Thankfully, the hardware can service at least four devices at a time) This is the only viable argument for having to change each single line entry in every Table, one-by-one, but you still have to deal with the inability to access the original System Name allocated to that device when it was first created as a Table entry. You can¡¯t! It is this impasse that has been overcome using a different method. Is this where we have to create a new line entry in a particular Table that is using the new coding system for the new device?and let JMRI creates the new association with the new record? Perhaps remove the old line entry from the table? This would still require that all references to the old System Name be located and changes everywhere it occurs within the xml file to permit it to work or do we simply ignore it and let it sit there allowing the file to grow and grow with junk coding whilst using the new entry?? These arguments can go on and on, which is why I am suggesting that we should have a step back and look back and remind ourselves how JMRI was originally created and what was available at that time and compare that to what we are being offered today. I agree that there is an implied distinction within the original Set Up Configuration and Defaults screens between the Train Control System and the Layout Control System within JMRI but they have become so mixed together over time, that I believe they need to be parted and seen to be two separate systems within JMRI, to regain clarity of purpose. To me, it is a bit like using the ¡®LayoutPro' and ¡®PanelPro¡¯. Both cover different aspects of the same program. Dave
|
|
Locked
Re: Missing CBUS events on Raspberry Pi system
Hi Andy,
Have tried various ways of recreating the dropped CAN Frames but no joy. Out of interest how are you powering the CANUSB4's? I've got mine using the main 12v CBUS supply rather than the 5v Pi USB supply. Steve |
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
Hi Dave R,
Converting Internal to MERG CBUS Sensors / Turnouts isn't to bad as long as you use Short event addressing ( ie. no Node numbers ). Copy / paste each Sensor from within <sensors class="jmri.jmrix.internal.configurexml.InternalSensorManagerXml"> <sensor inverted="false">
? ? ? <systemName>IS777</systemName>
? ? ? <userName>Internal Sensor 777</userName>
</sensor>
to within <sensors class="jmri.jmrix.can.cbus.configurexml.CbusSensorManagerXml"> <sensor inverted="false">
? ? ? <systemName>MS+777</systemName>
? ? ? <userName>MERG Short Event Sensor 777</userName>
</sensor>
Even with 200 sensors it'd be quicker to cut / paste / correct address rather than write a script imho. If you get stuck with this, upload your xml file here and I'll assist. If you're using CBUS Long event addressing it gets a bit more complicated in that the system name will need to include which node the event is coming from. "a script behind each selection should set these parameters throughout the entire program?" How would JMRI know which one is a MERG Turnout, or an XpressNet Turnout if you've got both hardware types on your layout? How would you change an internal Turnout system name "IT123" to OpenLCB Turnout system name "MT0102030405060708;0102030405060709" ? How about a valid CBUS Light hardware address of "MLXFD01010102010203;XFE01010102010203" being moved to a Loconet system? It just isn't feasible, there's much more information in a typical hardware address, it's definitely not just a table pointer reference. Eg. a MERG CBUS event hardware address of "MT+1" is actually a convenience version of "MTX9800000001;X9900000001". Train Control from DCC ( or DC ) vs?Layout control is already split in JMRI, hence JMRI needs to know which hardware type you want a particular Turnout to refer to. From the users point of view, the hardware type is selected in the Add New XX to Table. "unless you use an NCE command" For info Mick, the main MERG command station CANCMD can use 1 as a long address, hence I personally avoid specific "unless you use" statements ;-) Steve. |
|
Locked
Re: New Macbook Air, Mojave, PR3 - problems...
Good thought, but usually additional or downloaded drivers are not needed for a PR3 on Macs and I didn't install any.? There's no block notification in the security panel either. - Steve Haworth RGS history - Blog - ?????????????? FB - On Tue, Jun 11, 2019 at 2:43 AM <forfoum@...> wrote: A solution might be to check in Security & Privacy? to see if a 'BLOCKED' message is indicated.? |
|
Locked
Re: Web Server / Operations manifest view problem
#operationspro
Randall Wood
Sam: Glad it works. I missed that discussion about the inconsistencies with the hyphenated location names. If you could open a GitHub issue describing the issue, I'll be able to track that as something to fix. Randall |
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
¿ªÔÆÌåÓýI am becoming more and more convinced that there is a need to step back a few paces and re-look at the whole issue of both 'Train Control' and 'Layout Control'. Perhaps there is now a need to split these two within JMRI?The Initial Setup screens already allow the user to choose which DCC System they wish to use, if any at the very beginning and the Defaults screen give a more detailed breakdown. I think that developments in Model Railway Train and Layout Control has in many respects outgrown the original JMRI program. Would it be more beneficial to change the approach used to the Initial Setup within JMRI? It looks like a combination of the two screens - Configuration and Defaults ?- into Train Control System and Layout Control System many be the way to go?? From the user¡¯s point of view, they currently make their choices on these two screens. It is changes in these choices that need to be capable of change as the user¡¯s layout changes and develops over time. Under the Configuration Screen we first select which Train Control System (DCC System manufacturer) they wish to use. Then they can select which Default system they want to use for the Layout Control side of things. Initially, these choices will dictate how the resulting xml file will turn out as well as what the Default Control System will be for each of the Tables. That approach is fine for the user who starts with nothing. The user who has already decided which systems to use will usually start by using the DCC system they have chosen to use, probably to run everything in both systems. It is these choices that may develop/change over time as the layout develops - adding in a second manufacturer for example. This is where the split between Train Control and Layout Control comes into play. It is at this point that the problems associated with using the Unique System Name and Stability come into play. Any change to the Configuration and Defaults for both the Train Control system and/or the Layout Control System will need to be reflected throughout the xml file and with all of the Tables. This means that any changes has created the need to change every instance where the System Name changes, be this in the Tables or the xml program itself. Automate this process in some way rather than doing it one-by-one. Such an automated system would help the user who has learnt JMRI by creating a layout using the Internal type only with no layout and no DCC System chosen - the worst case scenario. When a choice has been made at a later date, then all of this work must be capable of being amended within the JMRI xml file as well as within all Tables to reflect the change of DCC System or reflect a change to which system is going to be used to control the various devices within the layout. I am hoping that Dave Sand will drop in here because he will know if the required changes can be implemented in the form of ¡®Scripts¡¯ that are activated behind each of the ¡®Choices' Buttons made either in the initial or change to these at a subsequent date. Dave
|
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
All,
On 11 Jun 2019, at 5:47 PM, Dave Heap via Groups.Io <dgheap@...> wrote:- Broadcast Address: Short Address 0. - Short Addresses: 1-127 inclusive.Sorry, an omission. Dave in Australia |
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
Mick,
On 11 Jun 2019, at 4:10 PM, Mick Moignard <mick@...> wrote: The NMRA standards specify as valid address ranges: - Short Addresses: 1-127 inclusive. - Consist Addresses: 1-127 inclusive (overlaps with Short Address range). - Long Addresses: 0-10239 inclusive. The NMRA Standard also states: "It is acceptable for Digital Command Stations to restrict the number of valid addresses supported so long as this restriction is clearly and plainly labeled on the package and in the instructions." The following table lists most major systems in use at the time it was compiled and their permissible ranges: <> One significant omission is SPROG Command Station mode, which implements the full NMRA range. ** (A less significant difference is that a JMRI throttle connected to an NCE Power Pro also implements the full range.) ** ** That information was correct at the time I was working on the JMRI code for each of those particular items. If it is no longer the, case someone has changed the code in that respect since then. I know that Digitrax command stations always treat 1 and all varieties of 1 (01, 001, 0001) as a short address, and won¡¯t allow you to control a loco whose address is long 1, because it just won¡¯t create and send packets with that address. I¡¯m pretty sure most other systems won¡¯t do that either.See above. Dave in Australia |
|
Locked
Re: Simple spdt sensor
¿ªÔÆÌåÓý? The cheapest is a DIY solution (or semi DIY), which is to use a ¡°LocoIO¡± module.? There are several routes to this;? there are fairly recent published designs
to use an Arduino processor to create such a device, or there are the original LocoIO designs which are available in kit form from Hans De Loof in Belgium.?
http://users.telenet.be/RedDeBist/MBAAN/LocoNet projecten.htm ? There will be ready to use modules, but costing more money.? ?The options from Digitrax seem to be very expensive because they do far more than just report a switch position eg. BDL168 with 16 channels for around $150. There are other manufacturer¡¯s devices which should report a switch position for less outlay ¨C try the TeamDigital and RR-Cirkits ranges to see what options exist. ? ? ? -????????? ??Nigel ? ? From: [email protected] [mailto:[email protected]]
On Behalf Of jimwor@...
Sent: 11 June 2019 02:44 To: [email protected] Subject: [jmriusers] Simple spdt sensor ? I am a new arrival to JMRI. I want to use the spdt switch on my Smail machine to provide feedback to JMRI as to actual switch position. Is there some simple interface to send this signal via LocoNet to JMRI? |
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
¿ªÔÆÌåÓýIt just goes to show how difficult it can be to get a workable solution in a complex environment if you don¡¯t keep your eye on the ball!To enter the Configuration and Defaults selection is a simple selection process within each screen so what do we do with this data? I would have to defer to Dave Sand on this one but to me a script behind each selection should set these parameters throughout the entire program? Select once use many times. The question has already been asked. Is it possible to create a short script that is triggered by the selection process on these two Setup Screens that sets the correct code to be used in a particular Table? This would overcome the possible problems that Bob referred to when using the ¡®Internal' type only to start with but it does mean that using the setup configuration and Defaults would have to allow the System Name to be edited to suit the selection, especially when we import or change the configuration from one to another but only if the data from an all Internal type file and use the Find and Replace to change every instance of it throughout the program file. Dave ?
|
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
Actually, you cannot have both long and short mobile addresses of 1 in use at the same time unless you use an NCE command starvation. ?I know that Digitrax command stations always treat 1 and all varieties of 1 (01, 001, 0001) as a short address, and won¡¯t allow you to control a loco whose address is long 1, because it just won¡¯t create and send packets with that address. ? I¡¯m pretty sure most other systems won¡¯t do that either. ? |
|
Locked
Re: PanelPro 4.15 Dispatcher and Auto Train Running
Hi Steve,
Thanks for the heads up on Priority, I suspected it was currently "an undocumented feature". I will investigate the Pause allocation feature again once I have my layout up and running again. ?I was a bit pressed for time before the show so if something did not work as I expected I did not spend a lot of time playing. ?Other more pressing issues to solve and simply used workarounds if possible. Trains failing to stop at the end of a Transit were definitely ignoring the held signal at Stop. ?The Auto trains window still showed the throttle as being at the speed setting the train had when it entered the section. ?I was using continuos running but with a fixed delay time 10-60 fast clock minutes before that train was "scheduled" to be re dispatched. ?Fortunately this did not cause dramas for the show because all the staging tracks have a dead section before the departure road which only becomes active when the turnouts for that road are aligned (belts and braces). ?This feature was a hangover from previous hardwired train sequencing but was similar in operation to another recent thread on this forum about stopping trains running into turnouts. I suspect the horn issues were loco pickup related. ?Poor contact at the instant the command was sent resulted in it being lost. ?It became more common towards the end of the day when track and loco wheels were becoming less than pristine. ?In any case sending a second turn off command did seem to work and is not difficult. ?I will look at using a text editor to find and replace the horn commands in the transits to send a delayed function 2 off command after each sound horn command. ?I was only using single timed blasts as my quick investigation of play a pattern did not appear to function as I expected. ?More play time is required. At the moment all the signal masts are virtual; (CTC, track circuits and automatic signalling did not feature in the location and time period of my layout), ?I just have some Logix controlled semaphores (signal heads) on the layout which follow the appropriate signal masts. ?(My drivers running the Automatic Trains use "In Cab" signals.) Many thanks for yours and others great contributions to JMRI. ? Don |
|
Locked
Re: PanelPro 4.15 Dispatcher and Auto Train Running
Thanks Bob, it was a lot of fun for all concerned.
? ?It sounds like you may have a reliability issue with LocoNet communications when things get very loaded (lots of trains moving). I think LocoNet reliability was OK, the Monitor LocoNet window was not overly busy. Generally there were no more than 3 trains actually moving at any given time. ?In future I will reduce LocoNet traffic by optimising my Loco momentum settings rather than having auto trains doing a lot of speed ramping. ?The lost "horn function turn off" commands {only happened about once in every few hundred horn blasts) were most likely momentary contact issues. ?Sending a second turn off command worked fine. The times when I had locos failing to stop at a held red did not seem to correlate with messages in the system log. ?It would have been nice to simply stop everything after a SPAD to investigate but in an train show situation "the show must go on". Here are a couple of extracts from the System Console Log of stuff I don't quite understand. 2019-06-10 12:41:02,713 jmri.Block ? ? ? ? ? ? ? ? ? ? ? ? ? ?ERROR - Mil-Mer got exception during fireProperTyChange(2,4) in thread AWT-EventQueue-0 13: ?[AWT-EventQueue-0]
java.lang.NullPointerException
at jmri.jmrit.dispatcher.AllocationRequest$3.propertyChange(AllocationRequest.java:204)
at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
at jmri.implementation.AbstractNamedBean.firePropertyChange(AbstractNamedBean.java:237)
at jmri.Block.setState(Block.java:324)
at jmri.Block.goingInactive(Block.java:677)
at jmri.Block.handleSensorChange(Block.java:628)
at jmri.Block.lambda$0(Block.java:192)
at java.beans.PropertyChangeSupport.fire(PropertyChangeSupport.java:335)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:327)
at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:263)
at jmri.implementation.AbstractNamedBean.firePropertyChange(AbstractNamedBean.java:237)
at jmri.implementation.AbstractSensor.setOwnState(AbstractSensor.java:206)
at jmri.jmrix.loconet.LnSensor.message(LnSensor.java:116)
at jmri.jmrix.loconet.LnTrafficController.notify(LnTrafficController.java:119)
at jmri.jmrix.loconet.LnPacketizer$RcvMemo.run(LnPacketizer.java:364)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
These messages appeared occasionally but only for this section. Mil-Met is a moderately long section with a road crossing towards the east end. ?Eastbound trains have a delayed horn blast and the error could be arising from a delayed on section entry "Sound Horn" command being issued after the train had left the section. 2019-06-10 14:39:04,035 jmri.Block ? ? ? ? ? ? ? ? ? ? ? ? ? ?WARN ?- count of 2 ACTIVE neightbors with proper direction can't be handled for block Mil #3 long but maybe it can be determined when another block becomes free [AWT-EventQueue-0]
2019-06-10 14:39:17,695 jmri.Block ? ? ? ? ? ? ? ? ? ? ? ? ? ?INFO ?- Block Mil #3 long gets LATE new value from Mil o/s up, direction= West [AWT-EventQueue-0]
2019-06-10 14:47:25,116 jmri.Block ? ? ? ? ? ? ? ? ? ? ? ? ? ?WARN ?- count of 2 ACTIVE neightbors with proper direction can't be handled for block Mil #3 long but maybe it can be determined when another block becomes free [AWT-EventQueue-0]
2019-06-10 14:47:27,654 jmri.Block ? ? ? ? ? ? ? ? ? ? ? ? ? ?INFO ?- Block Mil #3 long gets LATE new value from Mil o/s up, direction= West [AWT-EventQueue-0]
2019-06-10 15:10:55,496 jmri.Block ? ? ? ? ? ? ? ? ? ? ? ? ? ?WARN ?- count of 2 ACTIVE neightbors with proper direction can't be handled for block Mil #3 long but maybe it can be determined when another block becomes free [AWT-EventQueue-0]
2019-06-10 15:11:14,053 jmri.Block ? ? ? ? ? ? ? ? ? ? ? ? ? ?INFO ?- Block Mil #3 long gets LATE new value from Mil o/s #2 dn, direction= East [AWT-EventQueue-0]
These are interesting warnings and occurred occasionally but only occurs for this section. Block Mil #3 is one of the passing loops in the central station yard. ?It should the same as Block Mil #2. ?Mil o/s up is the block of yard ladder at the east end and Mil o/s #2 dn the block of the west yard ladder. ?Both Block Mil #2 and Block Mil #3 share the east and west end ladders. ? Block Mil #2 was only being used for west bound traffic and Block Mil #3 was only used for east bounds. ? I did not get these warnings for Block Mil #2 but that may just have been due to arrival times of trains. Ultimately these should not occur as both Mil #2 and Mil #3 are virtual blocks each created from a physical east and west block. ?I made them longer virtual blocks using Logix for the show to ensure trains did not overrun the section. ?With a bit more time to fine tune stopping distances using shorter blocks will be OK and as a train enters the block only one end will be active. My interpretation is that the "WARN ?- count of 2 ACTIVE neighbours" messages occur when an eastbound is entering the yard at the same time as a westbound. ?In this case both the yard ladder blocks would be active resulting in potential confusion. ?As Block Mil #3 was only used for East bound trains getting messages for west bound traffic could cause issues. ?Is the "Late new value" referred to in the INFO messages the direction or the train identifier? Most other Error messages in the log occurred from actions arising from the chair side of keyboard. Cheers Don |
|
Locked
Simple spdt sensor
I am a new arrival to JMRI. I want to use the spdt switch on my Smail machine to provide feedback to JMRI as to actual switch position. Is there some simple interface to send this signal via LocoNet to JMRI?
|
|
Locked
Re: USING JMRI WITH MULTIPLE SYSTEMS
Stephen,
Most users I've worked with are only adding one piece of hardware at a time and testing it. That is a strongly recommended practice. They then move the usernames to the new hardware system address. Many times the addressing and even device types may change between the time you started design and build some sections of the layout. This also makes it simpler on the case of which pin did I connect this to? You can make your connections and then make the move. Your testing via the system name confirms which entry it ended up being. Even on layouts I've designed, parts changed from the planning days to the implementation days. New designs come along etc... So I've only got lucky on bulk moves (using text edit tricks) being usable only for some sections. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org |
Howard Witt
Bob Jacobsen
Steven Haworth
Ken Cameron
to navigate to use esc to dismiss