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
|
I've got a number of BLI engines and no problems programming them using JMRI.? I'm using a Digitrax DCS100 command station with an isolated programming track with a PowerPax programming booster attached.? The only time I have a problem is if the PowerPax is switched out of the circuit, which I need to do when programming Tsunami2 or Econami decoders.? I assume that the Soundtraxx PTB 100 would work just as well.
David Witman
|
I totally agree with Bruce, get a Soundtraxx PTB 100, for your programing track. Money well spent.?
toggle quoted message
Show quoted text
On Jan 9, 2019, at 12:32 PM, Classic Auto Portraits < classicautoportraits@...> wrote:
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
On 1/9/19 10:24 AM, Mark Granville
wrote:
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
|
Locked
Re: Tables disappearing?
Chris...another important item (just in case). You need to load a panel first THEN your tables will show up.
--
Paul Davidson
Washita & Santa Fe RR
N scale:? Southern Oklahoma circa late 70's
|
Locked
Re: Programming locos with Fleischmann Twin-Center sw ver. 2.000 and DecoderPro 4.14
I have heard of a person with an IB-IR having exactly the same problem on the IBX mailing
list, but they claimed their unit had been working.
?
The obvious first question is what result do you get if you try and read a CV from a
loco using just the Twin-Center, without attempting to use JMRI to initiate the read? If the T-C cannot do that then JMRI is also not going to be able to do it. Read an basic CV like CV7 or 8 and see what value is reported on the T-C.
?
If this reads successfully then the problem MAY be in JMRI.
?
?
?
From:
[email protected] <[email protected]> On Behalf Of
cocco.bill.97@...
Sent: 09 January 2019 12:47
To: [email protected]
Subject: [jmriusers] Programming locos with Fleischmann Twin-Center sw ver. 2.000 and DecoderPro 4.14
?
Hello everybody from Italy, I understand these old command stations may not be the main focus of development at the present time, but, since there are many people who
still use them (they are quite cheap and provide more expansion options than the white Fleischmann z21), I hope this request for help will be useful anyway :).
My first trials date back to 4/5 years ago with JMRI version 3.x running on a laptop with Fedora Linux and the Twin-Center firmware version 1.100. As many users have already reported it was possible to toggle the power on/off switch from DecoderPro, but trying
to select a locomotive address with the throttle was most of the times impossible and eventually the connection would stop working completely. By searching in the newsgroup I understood that the Intellibox/Twin-center LocoNet serial port connection had always
been quite fragile and that there was a bug in JMRI releases after 2.9.1 which prevented the connection from working properly. So in the end I gave up (I didn't want too buy a LocoBuffer-USB at the time since I was not running a serious layout).
Recently I purchased and installed the software upgrade to version 2.000 for the Twin-Center from Fleischmann. Curious to see what the updated firmware + new JMRI combo would give, I downloaded the latest 4.14 production version and set it up again on Fedora
Linux. Connecting the Twin-Center using the instructions provided on the JMRI website seemed to work, toggling power on/off worked both from the PC and the keypad on the command station, so I opened up a throttle in DecoderPro, selected a locomotive address
and... it worked. The connection was stable even trying multiple locos multiple times. Nice! Excited by the improvement I decided to raise the stakes a little bit and try running trains with my smartphone. I fired up the DigiTrains app, opened the firewall
ports in the PC to allow communications with the phone and again everything was peachy. Now I have a setup (almost) on par with the newest command stations for less than a fraction of the cost, yay! :D Congratulations to all the team for the hard work, this
is impressive, thank you.
So far so good, last thing to try out is programming locos, but this his where I hit my snags. Reading CVs seems to be impossible, after I click the "Read type from decoder" I don't hear the typical click noise of the relay powering on the programming track
and DecoderPro hangs, eventually throwing this error on the console:
2019-01-09 13:19:40,086 jmrit.AbstractIdentify ? ? ? ? ? ? ? ?WARN ?- Stopping due to error: Timeout talking to command station (306) [AWT-EventQueue-0]
Also manually selecting the decoder type and reading CVs from the comprehensive programmer gives the same effect. Reading on the newsgroup I see that this issue appeared in the past and a user suggested setting Special option 25 to 1 and 907 to 4, but checking
on my command station shows that these options were already set this way from the factory, thus they are making no improvement. As I said, I know that the serial port connection of the Intellibox/Twin-Center has always been a source of problems but since I
noticed these interesting improvements I would like to know if there is any way to get the programming side working properly (without having to use a LocoBuffer-USB) because I know the DecoderPro programmer can do wonders :)
Any help will be much appreciated, I'm available and happy to test any solutions you can provide me :)
Thanks again and keep up the good work,
Best regards
Marco
|
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
On 1/9/19 10:24 AM, Mark Granville
wrote:
toggle quoted message
Show quoted text
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
|
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
|
SoundTraxx PTB 100 -- Bruce Petrarca, Mr. DCC; MMR #574
Dear Bruce, et. all,
Can you or one of our members recommend a programming track booster?
Regards,
Robert Diepenbrock
On 1/9/19 10:09 AM, Bruce Petrarca via
Groups.Io wrote:
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.
|
Dear Bruce, et. all,
Can you or one of our members recommend a programming track booster?
Regards,
Robert Diepenbrock
On 1/9/19 10:09 AM, Bruce Petrarca via
Groups.Io wrote:
toggle quoted message
Show quoted text
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.
|
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.
|
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
|
Bob Jacobsen
Paul Davidson
Bruce Petrarca
Ken Cameron