Keyboard Shortcuts
Likes
- Jmriusers
- Messages
Search
Re: udev rules on Raspberry Pi not working
开云体育Steve_G, Thank you!!! I have been a developer for 30 years and I'm well aware of the need of exact syntax but I missed this one. Daniel
On 2025-04-09 14:14, Steve_G via
groups.io wrote:
.rules |
Re: Chaining transits with a different locomotive
#dispatcher
Steve, I'm now facing a different issue. Using three transits with two locomotives, at the end of each transits: Transit A runs loco A then load transit B Transit B runs loco A, then load transit C Transit C runs loco B then load transit A It should run in a loop with two locomotives, but sometimes it does and sometime the loop stops. Any idea? JeanLouisDelestre@... De: "Steve_G via groups.io" <RailRodder22@...> ?: [email protected] 贰苍惫辞测é: Mercredi 2 Avril 2025 15:11:14 Objet: Re: [jmriusers] Chaining transits with a different locomotive #dispatcher Jean Build 2264 or later, found here?. As with all updates make sure you have a backup?before installing. Steve G. On Wed, 2 Apr 2025 at 04:18, Jean-Louis Free via <jeanlouisdelestre=[email protected]> wrote:
-- ---------------------------------------------
Jean-Louis Paris-France
---------------------------------------------
JRMI 5.9.5 on Windows
DCC EX? on Arduino Mega
Java version 17.1.12
? |
Re: WiThrottle server "readLine from device failed" messages
#withrottleserver
On 4/7/25 9:16 PM, danielb987 via groups.io wrote:
Tim, Thank you for that suggestion, that is a very handy app. Beats lugging a laptop over there, at least for the initial survey. I'm finding the 2.4gHz channels swamped with stuff, unusual for a rural area but then he's got the the main router, three mesh boxes, smart tvs and printers and who knows what else. 5gHz is pretty much wide open, so I'm going to set up a totally separate wifi access point on a totally separate network and push everyone to 5gHz and see what happens. -- Tim D. Childs tim.d.childs@... Lansing Model Railroad Club - lmrc.org (who had this silly notion that he wouldn't have to do this kind of stuff anymore after he retired) |
Re: Need help: computer connection to LocoNet freezes
开云体育You are most likely experiencing “Command Station Turnout Command Rejection”.? I see BillyBob already provided a link to the JMRI webpage that covers this.? Things to think about: ? Is Track Power OFF?? Some command stations reject Turnout commands when track power is OFF once their internal command buffer gets filled.? This would be a very common reason for what you are seeing. ? Robin ? Robin Becker N3IX Engineering LLC San Diego CA ? ? ? From: [email protected] <[email protected]> On Behalf Of Nick Brownsberger via groups.io
Sent: Wednesday, April 9, 2025 7:49 AM To: [email protected] Subject: Re: [jmriusers] Need help: computer connection to LocoNet freezes ? Attached files are here. |
Re: Need help: computer connection to LocoNet freezes
Attached files are here. initialize.py
initialize.py
computer connection fails-Loco Mon.pdf
computer connection fails-Loco Mon.pdf
|
Need help: computer connection to LocoNet freezes
I’ve been using a script I copied and modified from script examples a couple of decades ago (attached) which “for turnouts in turnouts.getNamedBeanSet() :” sets all but a few of my turnouts to CLOSED. I have a very large basement size layout.? An iMac is connected via a LocoBuffer-NG to a Digitrax DCS 240+ which controls 4 DB150 and DB100 boosters. I have confirmed all are working correctly. ? Recently, this script is causing the connection between my computer and the layout to freeze, for example, I can no longer turn the layout on or off from the computer.? Looking at the LocoNet Monitor (attached) I can see some turnouts being set to CLOSED but then the connections begin to fail. As the system keeps trying to set new turnouts and re-trying to set previously failed connections, it stops. ? This problem has been getting worse over many months, so I can no longer says what I did that might have caused it. And it has taken me several months to narrow down the symptoms this far and figure out how to recover the connection. ? To recover, I have to quit PanelPro, disconnect the LocoBuffer USB from the computer, reconnect it, and restart PanelPro. ? My railroads XML file looks OK. All the turnouts that failed to set are included in the XML file and are in the PanelPro turnout table. I don’t know how to access “NamedBeanSet()” to further troubleshoot the problem. Something has probably become disconnected but I can’t find the problem. Any help you can give would be appreciated. ? Thanks, Nick Brownsberger |
Re: Train creeps into turnout collision
Steve Mac
It depends on how you are stopping your train.
If the block lengths and train lengths are accurate then:
When not using speed profiles:, and not using stopping sensors:
The train stops if it doesnt fit in the block, else it stops when the penultimate block it fits in goes inactive.
When using a stopping ensor (these are used when a train needs to stop, not always stopping):?
The train stops when the sensor fires.
When using speed profiles:
The train stops in the length? of the block/section.
?
Other reasons for creep:
At some point the blocks fired out of order and it thinks its stopping somewhere else.
The signal is "Permissive".
The train speed has been overidden by an action.
Wrong scale.
?
Steve G.
?
?
? |
Re: Train creeps into turnout collision
>has to totally be in a block before coming to a stop
Thanks for the insight. I wish I knew this before setting up blocks. I thought train would halt if "held" irregardless of length.
?
I can combine this block with the preceding block below but it would have the T8 (bottom of screenshot) ghost block so technically there's no way to have the train in same block except below . Would that be the same issue? |
Re: udev rules on Raspberry Pi not working
This is what I have in my /etc/udev/rules.d/90-locobuffer.rules file:
SUBSYSTEM=="tty", ATTRS{product}=="LocoBuffer-USB", ATTRS{serial}=="FTNO3P86", SYMLINK+="ttyUSBLB" SUBSYSTEM=="tty", ATTRS{product}=="USB-Serial Controller D", SYMLINK+=“ttyUSBLBII" and in 91-dccex.rules: SUBSYSTEM=="tty", ATTRS{serial}=="75435353934351F0B121", SYMLINK+=“ttyUSBDCCEX" and these do the trick for my three USB command station interfaces from my pi. Your serial number is probably different. david zuhn |
Re: udev rules on Raspberry Pi not working
Dave,
toggle quoted message
Show quoted text
Thanks. The problem is that it doesn't work for me. I have the file: /etc/udev/rules.d/90-serial-ports.rule With the line: SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{interface}=="LocoBuffer-USB", SYMLINK+="ttyUSBLocoBuffer" And nothing happens. I have also tried with the line: ATTRS{idVendor}=="0403", ATTRS{idProduct}=="c7d0", KERNEL=="ttyUSB*", SYMLINK+="ttyLocoBuffer" But that doesn't work either. --- Daniel Bergqvist JMRI developer 2025-04-09 04:42 skrev Dave Sand: Daniel, |
Re: udev rules on Raspberry Pi not working
Daniel,
toggle quoted message
Show quoted text
Here is what works for me. SUBSYSTEM=="tty", SUBSYSTEMS=="usb", ATTRS{interface}=="LocoBuffer-USB", SYMLINK+="ttyUSBLocoBuffer" Dave Sand ----- Original message -----
From: danielb987 <jmri@...> To: [email protected] Subject: [jmriusers] udev rules on Raspberry Pi not working Date: Tuesday, April 08, 2025 7:02 PM I have a LocoBufferUSB and a FT232 serial adapter and I need permanent links for them, for example /dev/ttyLocobufferUSB and /dev/ttyTurntable . lsusb shows: Bus 003 Device 005: ID 0403:c7d0 Future Technology Devices International, Ltd RR-CirKits LocoBuffer-USB Bus 003 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC I have tried different udev rules but I don't get any links. For example: SUBSYSTEM=="tty", ATTRS{interface}=="LocoBuffer-USB", SYMLINK+="ttyUSBLocoBuffer" SUBSYSTEM=="tty", ATTRS{interface}=="Ltd FT232 Serial (UART) IC", SYMLINK+="ttyUSBTurnTable" and ATTRS{idVendor}=="0403", ATTRS{idProduct}=="c7d0", ENV{ID_MM_CANDIDATE}="0", KERNEL=="ttyUSB*" SYMLINK+="ttyLocoBuffer" ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ENV{ID_MM_CANDIDATE}="0", KERNEL=="ttyUSB*" SYMLINK+="ttyTurnTable" The rules are in the file /etc/udev/rules.d/90-serial-ports.rule . I have tried both restarting the RPi and this command: sudo udevadm control --reload-rules && sudo udevadm trigger -- Daniel Bergqvist JMRI developer |
Re: udev rules on Raspberry Pi not working
On April 9, 2025 5:32:04 AM GMT+05:30, "danielb987 via groups.io" <jmri@...> wrote:
Hi Daniel, a few thoughts: - I've found all my udev rules include ACTION==add IIRC (not on my PC right now, can't check) or some other ACTION match - There's 'udevadm monitor' to watch the events coming in and what udev makes of them when you plug in a device - There's also 'udevadm info -a /dev/ttyUSB0' to show you all the properties of a device and its parent devices you can match against - IIRC, if you have multiple filters ending in S (SUBSYSTEMS, ATTRS etc) they need to match the same parent device Hope this points you in a good direction, Heiko -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |
Problems with both DCS210+ and PR3 with programming
开云体育Quick details: ? 5 ports designated in config… Loconet (Com4), Loconet2 (Com5), Loconet3 (virtual), Programmer (COM6), Command Station (COM3). ? When trying to program/read with DecoderPro, it always goes to the Command Station. Configuration is set for both programming options assigned to the PR3 (Programmer). All other options assigned to CS. ? Programmer is connected to computer via USB (Com6) and also to Loconet from command station. All other Loconets are set up via USB connections for secondary Loconet via LocoBuffer-USB’s. No combination of USB or LocoNet connections will affect operation of the PR3. When I first start up Panel/DecoderPro, the Program LED on the Command Station begins rapidly flashing red. I CAN still do the quick programming option through the DT602D throttle. Engines will read into DecoderPro on the programming track connected to the DCS210A+. ? I’m at a loss here. Anyone have a solution? Thanks!!! Jim Duncan ? 73 de Jim, KU0G Warrensburg, MO EM28rs ? |
udev rules on Raspberry Pi not working
I have a LocoBufferUSB and a FT232 serial adapter and I need permanent links for them, for example /dev/ttyLocobufferUSB and /dev/ttyTurntable .
lsusb shows: Bus 003 Device 005: ID 0403:c7d0 Future Technology Devices International, Ltd RR-CirKits LocoBuffer-USB Bus 003 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC I have tried different udev rules but I don't get any links. For example: SUBSYSTEM=="tty", ATTRS{interface}=="LocoBuffer-USB", SYMLINK+="ttyUSBLocoBuffer" SUBSYSTEM=="tty", ATTRS{interface}=="Ltd FT232 Serial (UART) IC", SYMLINK+="ttyUSBTurnTable" and ATTRS{idVendor}=="0403", ATTRS{idProduct}=="c7d0", ENV{ID_MM_CANDIDATE}="0", KERNEL=="ttyUSB*" SYMLINK+="ttyLocoBuffer" ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", ENV{ID_MM_CANDIDATE}="0", KERNEL=="ttyUSB*" SYMLINK+="ttyTurnTable" The rules are in the file /etc/udev/rules.d/90-serial-ports.rule . I have tried both restarting the RPi and this command: sudo udevadm control --reload-rules && sudo udevadm trigger -- Daniel Bergqvist JMRI developer |
Re: Looped Layouts With SML (Part 2)
Paul, If you upload the version without the proposed fix, I can take a look at it. ? Dave Sand ----- Original message ----- From: Paul Wash <paul.wash@...> Subject: [jmriusers] Looped Layouts With SML (Part 2) Date: Tuesday, April 08, 2025 5:49 PM 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 ? ? ? ? |