开云体育

I posted about a solution to a looped layout SML validation failure when using layout editor paths, block and turnout details. This worked until we started making updates to the layout. The original post here: /g/jmriusers/message/238981 - not sure how relevant this is to the discussion at this point but it offered a hack for weird behavior at the time. Now I question my understanding of what SML is trying to do when connected to the layout. I realize this is long and confusing - but it is driving me nuts. To level set - the "correct" path below (1050/1060/1070/1000) is between source mast 1050 eastbound and destination mast 1000 westbound (green line/square). The problem is the SML gets confused and tries to go the other "wrong" path (1030/1020/1010/1000) and then warns that 1070 eastbound mast already exists between the blocks (red line/square). The logic is not wrong per se - but it's not what we want and there is no way to force it without brute force... The only way we figured out how to brute force the SML to take the "right" path is to merge the 1000 block tracks into a single track without the anchor points (see below image). The 1000 block is the the dashed line from 1000 on the left to 1070 on the right (above image) before merging. Is there any other way to force the path between signal mast pairs in a looped layout? Why would the extra anchor points between "tracks" confuse the SML - it is all the same block - the anchor points were just to bend the visual? Minor issue - the fix goofs up the visual symmetry of the layout (below) since the dashed part of the 1000 block is normally hidden and the layout is conceptually linear. By the way - we validated the same issues on track 4 (4000 block) and merging multiple splits in the same block fixed the issue there as well. More info below: - The routing table shows the metric is higher for the 4 hops East (the correct direction). Is it the extra anchors connecting the track? Does this even impact the SML or is this just routing? - You can see the signal masts set at the block boundaries - And then you see the signal mast pairs dialog box

I'm still learning Dispatcher/Transits but have my three loops working independently. Next I tried adding a second train that has to share a turnout as shown below. Each train/transit works fine as long as they're the only train running. If I set a turnout opposite desired state is is set properly on allocation. But this fails if I run two trains coming into the turnout as above and sharing a section of track before one diverges again. Specifically I had train 4 running a transit loop and started a new transit for train 5. Train 4 had a "HELD" red because train 5 allocated the turnout. However, train 4 creeped up and collided with 5. I don't have much stopping distance because the detection is between two ghost turnouts. Train 4 had slowed way down at the yellow and came to a stop then creeped forward to collide.

My original project was to combine two LE Panels, the Main railroad panel and the 5 track passenger station panel. Knowing there isn’t a quick way to join them, I proceeded to redraw the 5 track station onto the Main panel. Without realizing that the > Track Options > Automatically Assign Blocks to Tracks was turned on, every piece of track was assigned an AUTOBLK: ##, which I didn’t want nor need. I won’t need block detectors nor signaling. Any signals will be SSL to determine the turnout positions. Now I want to know how to remove block assignments from the newly drawn tracks since, as I see it, nothing can be deleted while they are assigned. I attempted to rename the unwanted blocks to a common name so when I could break the assignments I might only need to delete one large block. What I ended up with was, upon restarting JMRI everything opened properly the Main LE panel, The WiThrottle window, and the JMRI (center of screen) logo. The PanelPro control window did _not_. I didn’t have a way to close the program or make any preference changes. Since I put in so much work, so far, is there a fix to get JMRI to launch completely or is it easier to cut my losses and go back to a previous .xml file. Still how do I remove block assignments properly? I’m stumped. Thanks in advance for reading. John Bauchiero - NCE PH-Pro & PowerCab, RasPi4, DCC-EX - JMRI 5.11.4 - Java 17.0.12

Hopefully this can help others who experience the same problem. This has happened 3 or 4 times in the last 5 years - so not often. When opening JMRI, you get the dreaded unexpected EOF error loading the profile. Sure enough - the profile file is zero bytes. Easy fix - in the active jmri-profile folder there is a backupPanels folder under the railroad name. Simply copy that file back under the railroad folder - rename to whatever the profile file is called in your settings. Hopefully it is recent enough you didn't lose much of anything. The backup interval looks like when the profile is saved. All shutdowns have been nominal. No idea why it happens...Maybe it's an RPI thing, maybe it took to long to write and I did a system shutdown before it was ready? Who knows. The folder structure is below. For more info - Specs: RPI 5 bookworm with all latest updates running JMRI 5.10. The log file is below - it shows whenever this happens there is a compare failure. Guess that writes out 0 bytes and keeps on truckin...

I created/uploaded a small test case to show the issue I'm having with my layout. /g/jmriusers/files/ProblemsBeingWorkedOn/sml_test_5_multiple_turnouts.xml I may be confused but I'd expect both of these incoming masts to display aspect similarly. The top row works as expected based on which route is clear based on exiting turnout. The bottom row for diverging works differently.