Hello AllLast week we installed a few of the LNRP's at the club. Shortly after we noticed that the dispatch computer was unable to control just one of the DS64 outputs. Happended to be address 19. All others worked.The outputs worked fine with a throttle. The computer was interfaced on one of the outputs of the LNRP and not the protected side. When we switched it to the protected side the affected DS64 began working.
Anyone see this issue before?
Springfield PA
DS64 on UNprotected side had one output fail, but same DS64 moved to Protected side worked? Sounds like there is a problem on the unprotected side, perhaps another device with a duplicate address, or something chattering on the address of that one DS64 port. Moved to the protected side, the 'junk' is blocked.
--Randy
Modeling the Reading Railroad in the 1950's
Visit my web site at www.readingeastpenn.com for construction updates, DCC Info, and more.
No,
The All of the outputs of the DS64 would not respond to the JMRI program, however they responded to the Throttle. Moving the DS100 on the PC to the protected side cleared the problem.
Even more wierd. What was the actual order of connections? JRMI/Locobuffer or PR3 or whatever sends the exact same commands as a throttle in switch mode. Or it's SUPPOSED to. I suppose it is posisble the timign on the interface is clightly off and triggered the LNRP's threshold to protect the protected Loconet and not allow the command through.
It is a weird one. Before the change all devices were on the loconet with no LNRP's It includes DCS100, 1 UR92, 3 UR91's, 7 Boosters, About 10 or 12 DS54's, About 15 to 20 DS64's, 4 BDL168's, a Loco Buffer and MS100 for computer interface. Also a couple of Dozen UP5's, none of which have power applied.
We added 4 LNRP's with only the DS100 and Boosters on the protected Buss.
With this setup we had the problem wiht the computer operating one particular DS64. Moving the Computer's MS100 to the protected side fixed the problem. By doing so we removed one step in boosting. Instead of going through 2 LNRP's (Computer to LNRP to Protected Bus to LNRP to DS64) we are now going through one. Computer to LNRP to DS64.
The reply you got on the Digitrax list might be the clue. Double LNRPs might introduce too much latency in the signal for things to work properly. I think that was Martin - reported the issue with a Locobuffer, but I can REALLY see it happening with an MS100 since they are so touchy and can easily miss Loconet messages even in the simplest setups (I witnessed Digitrax's own demo module blow up at a show - the one that shuttles an N scale RDC back and forth using a BDL168 and SE8C for signals, and a RR&Co (or maybe Winlok) program to detect the last block, stop, and reverse the RDC. The MS100 missed a BDL168 report and the RDC just kept trying to move forward into the bumper at the end of the track).
Looks like we'll keep the PC's on the protected side. Seemed to correct the problem.
When a command is sent from the computer does it go directly to all devices on the BUS or does it first have to route and re-transmit from the DS100?
Depends on the command. Loconet is peer to peer, so a command to a certian device address like a DS64 output will go right to that DS64. But there are also Loconet packets that tellt he command station to generate a certain NMRA DCC packet and put it on the rails, so you cna 'back door' a command by makign it a Loconet command that generates an NMRA accessory packet to a secific address - that would go to the CS first, then to teh DS64 via the rail connections. Sort of silly because you'd really never want to do that, the only time you need to send accessory commands other than via Loconet is for non-Loconet accessories, say an NCE Switch-It. The cool thing is that any device can see any command - so when you have a panel in JMRI with a control for a DS64 but you change the state of the turnout via the throttle - the panel in JMRI will update as well, even if you don't use the DS64 inputs for feedback. No other system does that. To get that sort of updating you must use an input deivce for feedback. JMRI can also see any throttle operations, which means you can potentially take notice when a throttle sends an F8 command to a certain loco address and make soemthign happen with a JMRI script.