Locked
Configure DS64 tool trouble
Digitrax Empire Builder, DB150, PR3, Lenovo laptop w/Win 10-64bit, JMRI 4.11.
I have two DS64's, one of which I have successfully programmed with two output addresses and three routes using the Configure DS64 tool some time ago.
The second one I am trying to do today will not accept more than the first output address. When entering address #2 the box turns blue but I continue to enter #'s 3 and 4. When I hit 'Write Full Sheet' it writes box #1 but box #2 turns blue and everything stops. If I click another tab and then come back to the output addresses they all appear to have been written and show up without a background color. If I try to 'Read Full Sheet' only address #1 is read, address #2 turns blue and addresses #3 and #4 turn yellow. I appear to be able to enter Routes and have them recorded correctly in that tab in the tool. The turnout associated with address #1 can be operated individually from all my devices and will also operate correctly when the routes containing it are activated. I don't see anything wrong with my entries in the Turnout Table but maybe I just don't know what 'wrong' looks like.?
Any help and/or advice will be appreciated.
|
Locked
Re: MQTT Connection in JMRI
Bob,
With unconstrained topic path with no mandated device type component, it means the JMRI MQTT client will need to subscribe to all events under the channel top level ( channelname/# ) for all device types and then search all JMRI MQTT objects for a match. I think regardless of the object type, the desired action is to update the state if it differs though without re-publishing the message.
I think any outgoing message published by JMRI will be echoed in the subscribing process so will be seen as another incoming message to deal with. I don't know if there is a way to filter those out.
- David.
|
Locked
Re: Tables disappearing?
Chris,
Once you have a panel with data you either have to loaded after starting
JMRI or have that happen as part of the startup. Most use the startup
services (Edit->Preferences->Startup) to load the panel. Thing to keep in
mind, it is good to save big changes as a different file name, that means
you then have to edit the startup file name to match. I leave a trail of
files behind as I develop the panel. Just in case some great idea turns out
to be not so great.
-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org
|
Locked
Re: Tables disappearing?
Chris, On 10 Jan 2019, at 11:08 AM, chrisast10@... wrote:
Ken - no my panel are not loading at start up. is it supposed to? You need to go to Preferences->Start Up->Add->Open File... and select the Panel File you want to open. -- Dave in Australia
|
Locked
Re: MQTT Connection in JMRI
Speed,
The optional number I think comes when there is a second connection that uses the letter M, the connection code becomes M2 and then followed by the device character T for turnouts.?
- David.
|
Locked
Re: Jython as a teaching tool
|
Locked
Re: Tables disappearing?
Thank you all for the responses.?
Ken - no my panel are not loading at start up. is it supposed to?
Paul - That was what was happening. I am looking for my tables with the panels closed, once I open it all my tables show up.
Thanks again.
--
Chris
|
Locked
Re: Programming locos with Fleischmann Twin-Center sw ver. 2.000 and DecoderPro 4.14
Operations and Programming with an IB2 (and IB-Com) connected to JMRI work fine;? this was fully updated a few years ago (Jan. 2015) and exhaustively tested.
The work remains unfinished with the IB1 (or IB-IR or TC) both in operations and programming; the IB1 anyway has always been slow and with mine I never achieved to read a speed table in full, as it timed-out before completion. I moved to SPROG for programming with JMRI.
The IB2 is able to follow the pace and programming with JMRI works satisfactorily.
--
Alain LM
|
Locked
Re: MQTT Connection in JMRI
Sorry I put the slash at the beginning by accident.
Chris
|
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?
|
Ken Cameron
Bruce Petrarca