Locked
Re: Continued ECoS Issues...think I am near a solution. It is the ECoSDetector RC 4 ports
Setting it up now, I have code I am ready to test¡might need some help making sure I am complying with the community guidelines for submitting it back, but¡here I go¡
Be back soon!
toggle quoted message
Show quoted text
On Jan 9, 2019, at 13:59, Bob Jacobsen <rgj1927@...> wrote:
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@...
|
NO! NO! NO! That is a shortcut that a few DCC command stations understand but nothing close to universal rule. Sound decoder or non-sound coder.
toggle quoted message
Show quoted text
On Jan 9, 2019, at 1:18 PM, Nick via Groups.Io < cornwall9@...> wrote: But YES, YES, YES, that DOES work on non-sound decoders. Have you ever tried it ? You can even do it with Digitrax.
|
Locked
Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style
David,
If you DM me over the weekend I'll pack something up. Extremely busy with work until then. I'll send you a sensor board, and when you've mastered that the 4-aspect stuff should be perfected.
Martin
|
No problem Tom.
It was not meant to be a point of conflict. Way back in the stone ages when I started using DCC, it was a method I used using the Digitrax throttle. This was before DecoderPro was even conceived. Digitrax used hexadecimal numbers on their throttles when programming . Using their DCS100, and a throttle on a programming track, it was one of the "tricks" we used . At the time, the group was called the Loconet Hackers. I still have the plans for the original Locobuffer designed as a kit with a 25-pin Comm Port plug. We did a lot of things that "shouldn't" have worked , but did.
Just an old guy playing with trains, 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
That seems odd to be able to write a 4 digit address to cv18 when the NMRA spec for a 4 digit address is spread out on cv 17 and cv 18 and also requires a change to cv 29.?? I dont logically see any way that what you are saying can work with any decoder. Tom Wilson
Colorado Springs, CO
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.
|
And, the spread on cv 17 and 18 is not a direct entry of 2 digits each of loco number.? It has a convoluted formula which is why most DCC systems have a programming routine built in to handle the cv changes for you.? So, again, I dont see how that could work.? Tom Wilson
Colorado Springs, CO
That seems odd to be able to write a 4 digit address to cv18 when the NMRA spec for a 4 digit address is spread out on cv 17 and cv 18 and also requires a change to cv 29.?? I dont logically see any way that what you are saying can work with any decoder. Tom Wilson
Colorado Springs, CO
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.
|
That seems odd to be able to write a 4 digit address to cv18 when the NMRA spec for a 4 digit address is spread out on cv 17 and cv 18 and also requires a change to cv 29.?? I dont logically see any way that what you are saying can work with any decoder. Tom Wilson
Colorado Springs, CO
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.
|
Locked
Re: DCC++ Audrino current detection and block detection and colour light signalling. DIY Style
Hi Martin,
I would absolutely love to try these out and am more than happy to pay for boards.
I have heard mixed reports about sensors so was ideally looking for a current detecting block detection but if you havent actually seen the sensors you are using before so maybe they are the ones!! Clearly you know more than me on the subject
I haven't even started building yet but wanted to create a test circuit so I can plan all the systems and wiring pre build. Please feel free to DM details .
|
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@...
|
Bruce Petrarca
Robert J. Richter
Bob Jacobsen