Sorry Bruce,
I forgot, the new SOUND decoders cannot do that.?
But YES, YES, YES, that DOES work on non-sound decoders. Have you ever tried it ? You can even do it with Digitrax.
I have, and YES it does work.
BETA Tester for QSIsolutions.
Nick Kulp ? "I'm not a failure. I started at the bottom and I found it easily attainable. Life is too short to set unattainable goals"- Nick Kulp
NO! NO! NO! It doesn¡¯t work that way.
On Jan 9, 2019, at 12:46 PM, Robert J. Richter < rjr@...> wrote: 5. If you are trying to program a 4-digit address, simply write that into CV 18.
|
|
|
Hi Robert,
Not at all sure how it could have caused the ensuing mess, but there definitely is a hole in your way of working. Where you said 'wrote page' (after my first whoah...) you were writing information to the decoder that had not been read from it first. So anything that was in memory at the time, except for the address things you changed, would have been only slightly better than random.
Wouter
On Wed, 9 Jan 2019 at 19:25, Robert J. Richter < rjr@...> wrote: See below ? Robert J. Richter 283 Elm Street North Reading, MA 01864 ? From: [email protected] [mailto:[email protected]] On Behalf Of whmvd
Sent: Wednesday, January 9, 2019 11:52 AM
To: [email protected]
Subject: Re: [jmriusers] Broadway ltd ? I am totally unsure what you actually did. This is what I get from your description, but I cannot work out the rather important details. I put it on the program track It read as short address 174, correct long address but with short bulleted - Whoah. Corrected what, exactly? Am assuming short to long and nothing else. And also assume you wrote *something* back to the decoder. But what? Individual CVs? Changes? Entire sheet? All sheets? ????????????? CHANGED TO LONG BULLIT, WROTE PAGE, SAVED and read the decoder all CV¡¯s - Whoah again. That's too late. If you want to program, first get the entire decoder content in your sheets. ??????????? READ ALL CV¡¯S AND SAVED ? saved - Because now you have no real idea of what you saved. None at all. then it would not find it in the list - What list? ????????????? THE LIST OF LOCOMOTIVES IN MY (THE CLUB¡¯S) ROSTER and came back with short address (I had saved bulleted and wrote long) - So you read the address again? Just the address? Sheet? Indicidual CVs? All sheets? ??????????? DID AN IDENTIFY, COULD NOT IDENTIFY, AND THEN DID A NEW LOCOMOTIVE READ redid the whole thing - Hmmm.... WIthout the more exact steps it becomes even more difficult to follow what goes on. still would not find in list ????????????? LIST OF MY LOCOMOTIVES IN ROSTER - Glad to hear that - doing the same again on a digital system and getting the same result is in my view a Good Thing and then we went to the regular track and it had changed not only the short but also the long address as something completely different - Intrigued. I have no idea how you read the address on the non-program track? I fear you need to start over with this decoder, and start with reading all. I hope you'll see more consistency after that. ? On Wed, 9 Jan 2019 at 16:16, Robert J. Richter <rjr@...> wrote: Last knight a club member came to me with a Broadway ltd Pennsy K4 and I put it on the program track, It read as short address 174, correct long address but with short bulleted I corrected that and read the decoder all CV¡¯s, saved then it would not find it in the list and came back with short address (I had saved bulleted and wrote long)? redid the whole thing still would not find in list and then we went to the regular track and it had changed not only the short but also the long address as something completely different, made me look real stupid to the member who was kind about it but was really frustrating. ? Any thoughts on what I did wrong? ? Robert J. Richter 283 Elm Street North Reading, MA 01864 ?
|
Locked
Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style
Hi there,
I'm quite new to DCC but I'm very familiar with Arduino. I've developed two Arduino shields recently. One offers 5 channels of block detection per Arduino, and the other does 4-aspect signalling OR servo control for points.
The block detection shield uses TCRT5000 sensors set under the track to detect traffic overhead. It measures ambient light to reduce false positives, and can drive the inputs to an Arduino Mega that you would use for your DCC++ controller. Details are . You can hard wire a board, or I can send you a bare PCB to build up and test.
I've spent ages working on 4-aspect signalling for DCC/JMRI, and I actually received my production boards yesterday. After faffing about for ages, and going through 3 iterations, I eventually designed a shield that accepts a low-cost PCA9685 board. This simply saves the hassle of having a surface-mount board made abroad. The board offers 4 sets of signals, each with 4 aspects. The DCC address is set using a DIP switch, and it has a kludge switch to cope with the ambiguity in the EAP protocol. The board drives the signals very happily, and I'm just making a couple of tweaks to the code before open-sourcing the lot.
The great thing about the signalling shield is that is could also drive 16 servo motors, so that's a really inexpensive way of controlling points/turnouts. I have yet to write the code for this, but it's actually simpler than writing the 4-aspect signals.
So, ask me any questions, keep an eye on martinpeake.com and let me know if you want a sensor board. I will have spare boards of both types.
Martin?
|
1 + 2 We use NCE on the mainline, but the programming track is SPROG III to computer, USB interface 3 no 4 no I have not, will look into it??? Rick Knight? What do you think? 5 did not know that will do 6 only know that it was a Pennsy K4 probably recent model ? Robert J. Richter 283 Elm Street North Reading, MA 01864 ?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of Nick via Groups.Io
Sent: Wednesday, January 9, 2019 1:50 PM
To: [email protected]
Subject: Re: [jmriusers] Broadway ltd ? Just a few questions on your process. 1. What type of DCC system ? 2. How is it connected to the computer system. (Locobuffer USB for Digitrax or PR ? from Digitrax) or a PB100 from NCE. 3. If it is a Digitrax wimp system with low programming output, are you using the necessary programming track booster. 4. Have you disabled the "decoder talk-back" CV ? If not, the decoder will try to verbally repeat the CV and the following CVs will not get programmed. 5. If you are trying to program a 4-digit address, simply write that into CV 18. 6. What TYPE of BLI decoder ? Is it the OEM QSI decoder, The failure Blue-line from BLI, or one of the newer Paragon versions made by BLI ? These are important information. Anyone trying to answer your question without basic info is not helping . One of the most common questions about JMRI is "How do I get it to work?". This isn't really a problem with JMRI itself in most cases, but there are HUGE numbers of possible configurations for DCC systems, and Windows, Linux, and Mac computers out there. Just asking "How do I get it to work" is NOT going to get you any useful help.? When asking ANY question, you should utilize a meaningful subject line that indicates? the problem and include the following information in the body of the message: + If JMRI has started copy and paste the System Console into the body. (its under help on the start screen) + Has JMRI worked before on this computer? + Computer make and model ? + if you have just upgraded, from? which version + Any other DCC devices in use + Specific details of your difficulty including error messages if any,? Depending on the nature of the problem, you may need to supply even more information, but this is the absolute required for anyone to give you Signing you post helps keep the group friendly and personable! Please supply the required info for accurate answers. "I'm not a failure. I started at the bottom and I found it easily attainable. Life is too short to set unattainable goals"
- Nick Kulp ? Last knight a club member came to me with a Broadway ltd Pennsy K4 and I put it on the program track, It read as short address 174, correct long address but with short bulleted I corrected that and read the decoder all CV¡¯s, saved then it would not find it in the list and came back with short address (I had saved bulleted and wrote long)? redid the whole thing still would not find in list and then we went to the regular track and it had changed not only the short but also the long address as something completely different, made me look real stupid to the member who was kind about it but was really frustrating. Any thoughts on what I did wrong? ?
|
We are using a sprog III with it¡¯s power supply, I do not think it was in adequate power ? Robert J. Richter 283 Elm Street North Reading, MA 01864 ?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of Mark Granville
Sent: Wednesday, January 9, 2019 12:25 PM
To: [email protected]
Subject: Re: [jmriusers] Broadway ltd? From: Classic Auto Portraits
Date: Wed, 09 Jan 2019 08:35:59 PST Dear Robert,
This seems to be a problem encountered often with many owners of BLI locomotives. I own a number of BLI N Scale locomotives, both steam and diesels. BLI locos are notoriously poor in their response to JMRI. I've contacted BLI Tech Support regarding this and their stance is that JMRI is not an NMRA system.? I've been told that using a "Burst Module" to up the current during programming is the answer, but I've not pursued this. This may have to do with overcoming any onboard capacitors. BLI makes fantastic products. The detailing and sound are great, but this is their one major drawback. Any one out there with an answer?
Regards,
Robert Diepenbrock? ? I don¡¯t think this has anything to do with JMRI. It is a question of what programming hardware is being used. I have never had a problem with Paragon 2 or 3 programming with a Sprog IIv3. Have had problems using a PR3 as standalone, even with 18V supply and couldn¡¯t program at all with an NCE PowerHouse unless it had a PowerPax programming booster attached. So far, the Sprog IIv3 has not failed to deliver (unless there are keep alives or current keepers attached to the decoder), even with an MTH decoder. Maybe I¡¯m just lucky. ? Mark Granville
|
No booster, sprog, short track ? Robert J. Richter 283 Elm Street North Reading, MA 01864 ?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of Bruce Petrarca via Groups.Io
Sent: Wednesday, January 9, 2019 12:10 PM
To: [email protected]
Subject: Re: [jmriusers] Broadway ltd? There is no way to have a short address of 174. Only seven bits of CV1 are used for the address. Thus, the maximum number is 127.
One thought I had: are you using a programming track booster? Bruce Petrarca, Mr. DCC; MMR #574
On Jan 9, 2019, at 10:06 AM, Ken Cameron <kcameron@...> wrote:
I don't know of any system that supports 174 as a short address.
|
That is what has me mystified also, thanks Ken
Robert J. Richter
283 Elm Street
North Reading, MA 01864
toggle quoted message
Show quoted text
-----Original Message----- From: [email protected] [mailto: [email protected]] On Behalf Of Ken Cameron Sent: Wednesday, January 9, 2019 12:06 PM To: [email protected]Subject: Re: [jmriusers] Broadway ltd Robert, I don't know of any system that supports 174 as a short address. AFAIK, the NMRA standard says all with the long mode address from 128 and above. -Ken Cameron, Member JMRI Dev Team www.jmri.org www.fingerlakeslivesteamers.org www.cnymod.com www.syracusemodelrr.org
|
See below ? Robert J. Richter 283 Elm Street North Reading, MA 01864 ?
toggle quoted message
Show quoted text
From: [email protected] [mailto:[email protected]] On Behalf Of whmvd
Sent: Wednesday, January 9, 2019 11:52 AM
To: [email protected]
Subject: Re: [jmriusers] Broadway ltd ? I am totally unsure what you actually did. This is what I get from your description, but I cannot work out the rather important details. I put it on the program track It read as short address 174, correct long address but with short bulleted - Whoah. Corrected what, exactly? Am assuming short to long and nothing else. And also assume you wrote *something* back to the decoder. But what? Individual CVs? Changes? Entire sheet? All sheets? ????????????? CHANGED TO LONG BULLIT, WROTE PAGE, SAVED and read the decoder all CV¡¯s - Whoah again. That's too late. If you want to program, first get the entire decoder content in your sheets. ??????????? READ ALL CV¡¯S AND SAVED ? saved - Because now you have no real idea of what you saved. None at all. then it would not find it in the list - What list? ????????????? THE LIST OF LOCOMOTIVES IN MY (THE CLUB¡¯S) ROSTER and came back with short address (I had saved bulleted and wrote long) - So you read the address again? Just the address? Sheet? Indicidual CVs? All sheets? ??????????? DID AN IDENTIFY, COULD NOT IDENTIFY, AND THEN DID A NEW LOCOMOTIVE READ redid the whole thing - Hmmm.... WIthout the more exact steps it becomes even more difficult to follow what goes on. still would not find in list ????????????? LIST OF MY LOCOMOTIVES IN ROSTER - Glad to hear that - doing the same again on a digital system and getting the same result is in my view a Good Thing and then we went to the regular track and it had changed not only the short but also the long address as something completely different - Intrigued. I have no idea how you read the address on the non-program track? I fear you need to start over with this decoder, and start with reading all. I hope you'll see more consistency after that. ? On Wed, 9 Jan 2019 at 16:16, Robert J. Richter <rjr@...> wrote: Last knight a club member came to me with a Broadway ltd Pennsy K4 and I put it on the program track, It read as short address 174, correct long address but with short bulleted I corrected that and read the decoder all CV¡¯s, saved then it would not find it in the list and came back with short address (I had saved bulleted and wrote long)? redid the whole thing still would not find in list and then we went to the regular track and it had changed not only the short but also the long address as something completely different, made me look real stupid to the member who was kind about it but was really frustrating. ? Any thoughts on what I did wrong? ? Robert J. Richter 283 Elm Street North Reading, MA 01864 ?
|
I work with a Digitrax 240 system at my club and I have a Sprog at home. I never have problems reading/writing a BLI with the Sprog but always have issues with the Digitrax even with a PTB-100 added in. I wish there was a good fix for that.
Gary C.
|
Locked
Re: Continued ECoS Issues...think I am near a solution. It is the ECoSDetector RC 4 ports
Not an ECoS expert at all, but happy to work with you on tracking this down. Can you build & run JMRI from a GitHub branch? If so, I can push a version with a bunch more diagnostics in this area for you to try. Bob On Jan 9, 2019, at 3:58 AM, Nathan Tableman <nathan@...> wrote:
This one is making me nuts! So I started reading the code and I think I found the issue (maybe)¡I have these two devices:
ECoS - ECoS 50200
ECoSDetector RC - 50098 which only has four ports
Custom s88 module based on MQTT - unlimited ports (limited to the hard limit) (this doesn¡¯t work in JMRI either, but I am not certain that is ECOS/JMRI or me¡)
iTrain ¡°sees¡± all my ports coming from the ECoS, so I am pretty confident in the statement that this is a JMRI issue.
So I turned on debug on log4j.category.jmri.jmrix.ecos=DEBUG
This is what happens
There are a lot of which I think is related to me not having my turnouts setup right in JMRI, which is my fault...
2019-01-09 06:41:00,766 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,849 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
BUT this seems to be the doozie:
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Invalid number of ports returned for Module 200 [AWT-EventQueue-0]
This is the exchange
cmd: queryObjects(26, ports)
rep: <REPLY queryObjects(26, ports)>
200 ports[4]
<END 0 (OK)>
So I have JMRI/java/src/jmri/jmrix/ecos/EcosSensorManager.java open and taking a look a where it might need to be changed locally for me to work¡but before I get too far I wanted to see if anyone else has seen this and has input/solutions/I¡¯m crazy :)
Nathan
ps I am long overdue on posting on my blog all the MQTT work, but my goal is a FULLY MQTT setup.
Details below:
2019-01-09 06:40:52,640 util.Log4JUtil INFO - * JMRI log ** [main]
2019-01-09 06:40:53,911 util.Log4JUtil INFO - This log is appended to file: /Users/ntableman/Library/Preferences/JMRI/log/messages.log [main]
2019-01-09 06:40:53,912 util.Log4JUtil INFO - This log is stored in file: /Users/ntableman/Library/Preferences/JMRI/log/session.log [main]
2019-01-09 06:41:00,282 profile.ProfileManagerDialog INFO - Automatically starting with profile Cmd_Tableman_Rail.3e58af63 after timeout. [AWT-EventQueue-0]
2019-01-09 06:41:00,388 node.NodeIdentity INFO - Using jmri-o_sX5dfJrhNiaaDe7duAwF-3e58af63 as the JMRI Node identity [AWT-EventQueue-0]
2019-01-09 06:41:00,697 ecos.EcosPreferences DEBUG - creating a new EcosPreferences object [main]
2019-01-09 06:41:00,742 ecos.EcosTrafficController DEBUG - creating a new EcosTrafficController object [main]
2019-01-09 06:41:00,747 ecos.EcosLocoAddressManager DEBUG - Waiting for the Ecos preferences to be loaded before loading the loco database on the Ecos [Wait for Preferences to be loaded]
2019-01-09 06:41:00,765 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,766 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,766 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,773 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1, status)>
1 status[STOP]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,773 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,774 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,774 ecos.EcosPowerManager DEBUG - POWER OFF DETECTED [AWT-EventQueue-0]
2019-01-09 06:41:00,781 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,781 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(11, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,798 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,798 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(11, addrext)>
20000 addrext[90g,90r]
20001 addrext[91g,91r]
30000
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,799 ecos.EcosTurnoutManager DEBUG - Number of Address for this device is 2 [AWT-EventQueue-0]
2019-01-09 06:41:00,804 ecos.EcosTurnoutManager DEBUG - Number of Address for this device is 2 [AWT-EventQueue-0]
2019-01-09 06:41:00,808 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(26, ports)>
200 ports[4]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,808 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Found sensor object 200 ports 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,809 ecos.EcosSensorManager DEBUG - Invalid number of ports returned for Module 200 [AWT-EventQueue-0]
2019-01-09 06:41:00,816 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,818 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(20000,view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,819 ecos.EcosTurnoutManager DEBUG - Reply for specific turnout [AWT-EventQueue-0]
2019-01-09 06:41:00,839 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,839 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20000,state)>
20000 state[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,840 ecos.EcosTurnout DEBUG - newstate found: 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,849 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,850 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20000, name1, name2, name3)>
20000 name1["east"]
20000 name2[""]
20000 name3[""]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(20001,view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,858 ecos.EcosTurnoutManager DEBUG - Reply for specific turnout [AWT-EventQueue-0]
2019-01-09 06:41:00,879 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,880 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20001,state)>
20001 state[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:00,880 ecos.EcosTurnout DEBUG - newstate found: 4 [AWT-EventQueue-0]
2019-01-09 06:41:00,888 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:00,888 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(20001, name1, name2, name3)>
20001 name1["west"]
20001 name2[""]
20001 name3[""]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:01,489 roster.Roster INFO - Roster rebuilt, stored in /Users/ntableman/Documents/Model-Rail/JMRI/roster.xml [AWT-EventQueue-0]
2019-01-09 06:41:01,515 simpleserver.SimpleServer INFO - JMRI SimpleServer started on port 2048 [AWT-EventQueue-0]
2019-01-09 06:41:01,643 server.WebServer INFO - Starting Web Server on port 12080 [WebServer]
2019-01-09 06:41:01,749 ecos.EcosTrafficController DEBUG - Send a message and wait for the response [Wait for Preferences to be loaded]
2019-01-09 06:41:02,064 server.WebServer INFO - Starting ZeroConfService _http._tcp.local for Web Server with properties {path=/, json=4.1} [WebServer]
2019-01-09 06:41:09,279 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(10, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:09,279 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosTurnoutManager DEBUG - reply <REPLY queryObjects(10, addr, name, protocol)>
1000 name["MRCE 194.640"] addr[1060] protocol[DCC128]
1001 name["BR245 / Traxx DE"] addr[1000] protocol[DCC128]
1002 name["GySEV 1047"] addr[1020] protocol[DCC128]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:09,280 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:09,281 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:09,285 json.JsonServer INFO - Starting JSON Server on port 2056 [AWT-EventQueue-0]
2019-01-09 06:41:12,026 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1000, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,027 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,027 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, speed)>
1000 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,028 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, dir)>
1000 dir[1]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,029 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, cv[7])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1000, cv[8])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,030 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1001, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, speed)>
1001 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,031 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, dir)>
1001 dir[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,032 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, cv[7])>
<END 0 (OK, but obsolete attribute at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,033 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1001, cv[8])>
<END 0 (OK, but obsolete attribute at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - reply <REPLY request(1002, view)>
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,034 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, speed)>
1002 speed[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,035 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, dir)>
1002 dir[0]
<END 0 (OK)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - message received that is not within the valid turnout object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosSensorManager DEBUG - message receieved that is not within the valid Sensor object range [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, cv[7])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:12,036 ecos.EcosTurnoutManager DEBUG - reply <REPLY get(1002, cv[8])>
<END 22 (not possible at 11)>
[AWT-EventQueue-0]
2019-01-09 06:41:12,037 ecos.EcosTurnoutManager DEBUG - Message received from Ecos is in error [AWT-EventQueue-0]
2019-01-09 06:41:13,598 util.FileUtilSupport INFO - File path program: is /Applications/JMRI/ [main]
2019-01-09 06:41:13,598 util.FileUtilSupport INFO - File path preference: is /Users/ntableman/Documents/Model-Rail/JMRI/Cmd_Tableman_Rail.jmri/ [main]
2019-01-09 06:41:13,599 util.FileUtilSupport INFO - File path profile: is /Users/ntableman/Documents/Model-Rail/JMRI/Cmd_Tableman_Rail.jmri/ [main]
2019-01-09 06:41:13,599 util.FileUtilSupport INFO - File path settings: is /Users/ntableman/Library/Preferences/JMRI/ [main]
2019-01-09 06:41:13,600 util.FileUtilSupport INFO - File path home: is /Users/ntableman/ [main]
2019-01-09 06:41:13,600 util.FileUtilSupport INFO - File path scripts: is /Applications/JMRI/jython/ [main]
2019-01-09 06:44:29,939 mqtt.MqttAdapter WARN - Lost MQTT broker connection... [MQTT Rec: JMRI-MQTT]
2019-01-09 06:44:29,940 mqtt.MqttAdapter INFO - ...trying to reconnect [MQTT Rec: JMRI-MQTT]
-- Bob Jacobsen rgj1927@...
|
Locked
Re: Programming locos with Fleischmann Twin-Center sw ver. 2.000 and DecoderPro 4.14
Hello Alan, reading CVs by directly using the keypad on the Twin-Center works as expected. I can hear the relay switching the program track on when I enter programming mode and all basic CVs read and write successfully on different locos.
I did some more testing with JMRI and I noticed that at times the relay clicked some (long) time after I pressed the command to read CVs on the PC but then I got the same timeout error. In this case, after the click, one time I saw the command station crash and reset itself, and another time on the console screen another error message came up regarding an unrecognized incoming loconet package. I'm sorry, in the hurry I forgot to copy-paste it this morning.
My guess would be that for some strange reason the command station takes longer to answer in programming mode when controlled via the serial port and because of this JMRI believes that the request has been lost and sends a new request, eventually hogging the buffer of the serial interface with requests, which would explain the errors broken incoming packages and the crashes on the Twin-Center. This is only my assumption based on what I saw though, I have no knowledge the internal workings of the thing, so if you know something more about it I'll be glad to be corrected.
Thank you,
Marco
|
Locked
Re: MQTT Connection in JMRI
On Jan 8, 2019, at 4:00 PM, Dave <davemc@...> wrote:
Compatibility with the current arrangement is pretty much lost regardless. Perhaps it will need a setting on the connection page that says something like Use basic (i.e. the original) format topic for turnouts with this being selected by default if existing MQTT devices are found so existing use doesn't fail when the new release of JMRI gets installed and the user can migrate to the new format at their convenience. All other devices to use the new format. Don't display that option if no old format MQTT turnouts exist. NB: Just a warning that there are other systems that can use the system character 'M'. (Separate reply in case it becomes a separate thread) I think the goal is to create ¡°how JMRI works with MQTT¡± without a lot of attention to the (very small) number of existing setups. Any Light/Sensor/Report support will be entirely new. Any JMRI configurations that have working Turnouts can be converted via the JMRI tables or by editing their panel files: No changes to the external MQTT devices and broker(s) is necessary. (That panel-editing operation should be trivial for people who¡¯ve been doing some of the things being discussed here). I¡¯m not going to spend time coding migration steps. If somebody else wants to, that¡¯s maybe fine, maybe not. Bob -- Bob Jacobsen rgj1927@...
|
I only have one BLI loco, Mikado, I have not had any problems what so ever
reading or programming this loco.
My secret to programming locos, any brand (I haven't tried MTH though) is to use
JMRI and a SPROG, NCE, ESU, Digitrax, Bachman, Hornby, TCS, QSI, Soundtraxx,
Lenz and MRC have been no problem at all.
John
toggle quoted message
Show quoted text
---------- Original Message ----------
From: Classic Auto Portraits <classicautoportraits@...>
Date: January 9, 2019 at 10:35 AM
Dear Robert,
This seems to be a problem encountered often with many owners of BLI
locomotives. I own a number of BLI N Scale locomotives, both steam and
diesels. BLI locos are notoriously poor in their response to JMRI. I've
contacted BLI Tech Support regarding this and their stance is that JMRI
is not an NMRA system. I've been told that using a "Burst Module" to up
the current during programming is the answer, but I've not pursued this.
This may have to do with overcoming any onboard capacitors. BLI makes
fantastic products. The detailing and sound are great, but this is their
one major drawback. Any one out there with an answer?
Regards,
Robert Diepenbrock
On 1/9/19 9:15 AM, Robert J. Richter wrote:
Last knight a club member came to me with a Broadway ltd Pennsy K4 and
I put it on the program track, It read as short address 174, correct
long address but with short bulleted I corrected that and read the
decoder all CV¡¯s, saved then it would not find it in the list and came
back with short address (I had saved bulleted and wrote long) redid
the whole thing still would not find in list and then we went to the
regular track and it had changed not only the short but also the long
address as something completely different, made me look real stupid to
the member who was kind about it but was really frustrating.
Any thoughts on what I did wrong?
Robert J. Richter
283 Elm Street
North Reading, MA 01864
|
Robert,
Just a few questions on your process. 1. What type of DCC system ? 2. How is it connected to the computer system. (Locobuffer USB for Digitrax or PR ? from Digitrax) or a PB100 from NCE. 3. If it is a Digitrax wimp system with low programming output, are you using the necessary programming track booster. 4. Have you disabled the "decoder talk-back" CV ? If not, the decoder will try to verbally repeat the CV and the following CVs will not get programmed. 5. If you are trying to program a 4-digit address, simply write that into CV 18. 6. What TYPE of BLI decoder ? Is it the OEM QSI decoder, The failure Blue-line from BLI, or one of the newer Paragon versions made by BLI ?
These are important information. Anyone trying to answer your question without basic info is not helping .
====================== HOW to ask your question ======================
One of the most common questions about JMRI is "How do I get it to work?". This isn't really a problem with JMRI itself in most cases, but there are HUGE numbers of possible configurations for DCC systems, and Windows, Linux, and Mac computers out there. Just asking "How do I get it to work" is NOT going to get you any useful help.?
When asking ANY question, you should utilize a meaningful subject line that indicates? the problem and include the following information in the body of the message:
+ If JMRI has started copy and paste the System Console into the body. (its under help on the start screen) + Has JMRI worked before on this computer? + Computer make and model ? + if you have just upgraded, from? which version + Any other DCC devices in use + Specific details of your difficulty including error messages if any,?
Depending on the nature of the problem, you may need to supply even more information, but this is the absolute required for anyone to give you accurate answers.?
Signing you post helps keep the group friendly and personable!
Please supply the required info for accurate answers.
Regards, Nick Kulp
? "I'm not a failure. I started at the bottom and I found it easily attainable. Life is too short to set unattainable goals"- Nick Kulp
Last knight a club member came to me with a Broadway ltd Pennsy K4 and I put it on the program track, It read as short address 174, correct long address but with short bulleted I corrected that and read the decoder all CV¡¯s, saved then it would not find it in the list and came back with short address (I had saved bulleted and wrote long)? redid the whole thing still would not find in list and then we went to the regular track and it had changed not only the short but also the long address as something completely different, made me look real stupid to the member who was kind about it but was really frustrating. ? Any thoughts on what I did wrong? ? Robert J. Richter 283 Elm Street North Reading, MA 01864 ?
|
Locked
Re: MQTT Connection in JMRI
Two examples: If the system letter is M, then: *) MTfoo/bar/biff/21/mine is a turnout that uses foo/bar/biff/21/mine as the MQTT topic *) MSrailroad/stuff/notMentioningSensorsHere/yardOSwest is a sensor that uses railroad/stuff/notMentioningSensorsHere/yardOSwest as the MQTT topic Etc. The first letter (optionally followed by digits) is the system prefix; the following T/S/R/L defines the type, and all that follows is the specific topic for that item. Bob On Jan 8, 2019, at 4:00 PM, Dave <davemc@...> wrote:
Bob mentioned "system names should include a complete, unconstrained topic path (without wildcards)."
-- Bob Jacobsen rgj1927@...
|
From: Classic Auto Portraits
Date: Wed, 09 Jan 2019 09:32:45 PST Dear Mark, et. all,
I have a Digitrax DCS240 command station, with an isolated programming track. I have constant issues attempting to program BLI locomotives using JMRI.
Many will not recognize, read or write at all using JMRI.
Regards,
Robert Diepenbrock ? Again, this has nothing to do with JMRI. You probably have the same problems if you bypass JMRI and use your Digitrax throttle to program the loco. Have you tried reading a CV with your throttle to see if it works? ? Mark Granville ? If you are able to successfully program with your throttle, then it may mean there is a need for the JMRI coders to upgrade the DCS240 interface. Be sure you are using the most recent version of JMRI. ? Mark Granville
|
Locked
Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style
On Wed, Jan 9, 2019 at 10:19 AM, Kevin wrote:
Hi David
?
I¡¯m a UK modeller too, and a JMRI user. I¡¯m struggling to work out why you are looking at DCC++ on an arduino when you already have a?Dijikeijs DR5000. The DR5000 will act as the DCC signal supply and will connect directly to a PC running JMRI. The DR5000 already supports various feedback systems so all you need to add will be appropriate feedback detectors to whichever feedback system takes your fancy. I may be wrong here, but I?don¡¯t think the DCC++ solution supports a feedback bus.
?
Block detection is expensive¡The DR4088?isn¡¯t a bad option though, giving 16 channels for around ?50.
?
Another option that might reduce costs is using the Megapoints system for both turnout control and feedback. I¡¯m guessing that since you are planning a loft layout it?won¡¯t be small¡¡.lots of turnouts, blocks and signals? Megapoints can handle 192 turnouts or signals from a single DCC module, and also has a 192 channel feedback system. The feedback currently doesn¡¯t interface to JMRI, but a new computer control module is very close to release. Overall the?mega points?system?isn¡¯t cheap, but on a large layout can reduce the unit cost of powering turnouts and signals.?4 aspect colour lights might be a bit of a challenge. I¡¯m using?mega points to drive UK semaphore signals, but extending this to 4 aspect?·É´Ç³Ü±ô»å²Ô¡¯³Ù be straightforward. However Dave Fenton at Megapoints may have something up his sleeve so its always worth asking him.
?
Have you explored the TrainTech 4 aspect signal system? This would give you an easy route to a working signalling system, but?·É´Ç³Ü±ô»å²Ô¡¯³Ù?report the?signal setting or occupancy to JMRi.
?
Kevin
?Hi Kevin, Many thanks for your reply. I didn't get the Dijikeijs or Digitrax? stuff for Christmas. Santa didn't like me! Hence why I was trying to see if there were Audrino projects that would do a similar job and be cheaper as budget will be a factor sadly for me. I have seen some stuff at Megapoints so will definitely look them up and have a chat. I'm certainly finding out more and more all the time. With Audrino I saw so much online that I was surprised as yet I have not found any block detection or 4 aspect signalling projects of yet. I wanted to be able to drive trains why others were automated hence wanting a system that reported these.
|
From: Classic Auto Portraits
Date: Wed, 09 Jan 2019 09:32:45 PST Dear Mark, et. all,
I have a Digitrax DCS240 command station, with an isolated programming track. I have constant issues attempting to program BLI locomotives using JMRI.
Many will not recognize, read or write at all using JMRI.
Regards,
Robert Diepenbrock ? Again, this has nothing to do with JMRI. You probably have the same problems if you bypass JMRI and use your Digitrax throttle to program the loco. Have you tried reading a CV with your throttle to see if it works? ? Mark Granville
|
Locked
Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style
Hi David
I¡¯m a UK modeller too, and a JMRI user. I¡¯m struggling to work out why you are looking at DCC++ on an arduino when you already have a?Dijikeijs DR5000. The DR5000 will act as the DCC signal supply and will connect directly to a PC running JMRI. The DR5000 already supports various feedback systems so all you need to add will be appropriate feedback detectors to whichever feedback system takes your fancy. I may be wrong here, but I?don¡¯t think the DCC++ solution supports a feedback bus.
Block detection is expensive¡The DR4088?isn¡¯t a bad option though, giving 16 channels for around ?50.
Another option that might reduce costs is using the Megapoints system for both turnout control and feedback. I¡¯m guessing that since you are planning a loft layout it?won¡¯t be small¡¡.lots of turnouts, blocks and signals? Megapoints can handle 192 turnouts or signals from a single DCC module, and also has a 192 channel feedback system. The feedback currently doesn¡¯t interface to JMRI, but a new computer control module is very close to release. Overall the?mega points?system?isn¡¯t cheap, but on a large layout can reduce the unit cost of powering turnouts and signals.?4 aspect colour lights might be a bit of a challenge. I¡¯m using?mega points to drive UK semaphore signals, but extending this to 4 aspect?·É´Ç³Ü±ô»å²Ô¡¯³Ù be straightforward. However Dave Fenton at Megapoints may have something up his sleeve so its always worth asking him.
Have you explored the TrainTech 4 aspect signal system? This would give you an easy route to a working signalling system, but?·É´Ç³Ü±ô»å²Ô¡¯³Ù?report the?signal setting or occupancy to JMRi.
Kevin
|
Bruce Petrarca
Robert J. Richter
Bob Jacobsen