Re: Broadway ltd

#155687

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

Re: Tables disappearing?

#155686

Chris,

Are you sure the panel file is being loaded at startup time?

-Ken Cameron, Member JMRI Dev Team
www.jmri.org
www.fingerlakeslivesteamers.org
www.cnymod.com
www.syracusemodelrr.org

Re: Tables disappearing?

#155685

Hi Chris,

Apologies if I'm being too obvious, but - you did save your panels before quitting?

Wouter

Show quoted text

On Wed, 9 Jan 2019 at 16:51, <chrisast10@...> wrote:

Hello All,

I am fairly new to JMRI but have used it in the past. I am using V4.14, (Java is updated), Windows 10. I am setting up my new layout and am having issues with all my turnout data disappearing from my table when I quit and reopen the program. This is happening with my sensor table as well. These are the only two I'm trying to set up so I haven't tried the other tables yet. All my operations tables show up just fine. This didn't happen on my old layout. I am using all the same hardware but I did update JMRI a couple weeks ago.

Is there something simple I've missed maybe?

Thank you.
--
Chris
Dogtown & Western N-Scale?

Re: Broadway ltd

#155684

Hi Robert,

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

- Check.

It read as short address 174, correct long address but with short bulleted

- Check.

I corrected that

- 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?

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.

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?

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?

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

- 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.

Wouter

Show quoted text

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
?

Tables disappearing?

[email protected]

#155683

Hello All,

I am fairly new to JMRI but have used it in the past. I am using V4.14, (Java is updated), Windows 10. I am setting up my new layout and am having issues with all my turnout data disappearing from my table when I quit and reopen the program. This is happening with my sensor table as well. These are the only two I'm trying to set up so I haven't tried the other tables yet. All my operations tables show up just fine. This didn't happen on my old layout. I am using all the same hardware but I did update JMRI a couple weeks ago.

Is there something simple I've missed maybe?

Thank you.
--
Chris
Dogtown & Western N-Scale?

Programming locos with Fleischmann Twin-Center sw ver. 2.000 and DecoderPro 4.14

#155682

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

DCC++ Audrino current detection and block detection and colour light signalling. DIY Style

#155681

Hey newbie here so please be gentle!

I have sent the last few months looking at you tube videos and systems until I am blue in the face. I am looking to build a layout in my loft. So initially I wanted to buy Traincontroller / iTrain? and either Digitracks (BDl168's) or Dijikeijs DR4018's/4088's. Unfortunately Santa wasn't kind to me and I have got a low budget then I found Audrino and JMRI and my prayers seem to have been answered!! I can get an Arduino and a Motor shield and I have a (PR4/DR5000) control station woo!! I also can get JMRI and looks just as good as Traincontroller / Itrain :).?

However I am not finding much on how to do the block detection (using current) and running the UK colour light signals (4 aspect).

Does anyone have any suggestions - Appreciate this isn't directly a JMRI thing but presume you have all been there before me!?

Re: Broadway ltd

Classic Auto Portraits

#155680

开云体育

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:

Show quoted text

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

?

Broadway ltd

#155679

开云体育

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

?

Re: MQTT Connection in JMRI

#155678

I believe JMRI wants a Connection Prefix, an Optional Number (I tested 9999) and then the Unique part. [So club layouts might need to put a "module serial number" in their Topics]

The JMRI setup is usually done after your boards are installed, so I would discourage making the Connection Prefix part of the Topic ... we should stick to the leading MT in?MTtopic or in my example M9999Ttopic. The leading slash is not recommended and creates two more characters to send, so I'll suggest avoiding it.

Speed

Continued ECoS Issues...think I am near a solution. It is the ECoSDetector RC 4 ports

#155677

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]

Re: Trying to get on top of jython

#155676

Hi Spuds,

Thanks for your reaction!

The fun I'm going to have is building stuff on top of the very basic JMRI things linke turnouts, signalling, sensors and throttles. I have no doubt that JMRI can do things that will make the layout appear and function the way I want, but as a programmer, I'd like to use it as a library to build my own things on top of. If you look very far back that was even the original aim of JMRI - to be a platform to build on. Knocking those signal boxes into shape is simply going to be fun! And I'm simply going to ignore routes, warrants, autotrains - whatever, just to see what I can come up with. Something nice to get my teeth into.

By the way: detection will be via current detectors, and I'm hoping them to be reliable enough for the virtual drivers to make their decisions on (with their 'route knowledge' I think that should be workable). All wheel sets are metal, and every wagon will have at least one resistor wheel set at each end. I don't intend to have real signalling, as it's much too fragile to have around in the garden what with roaming squirrels, cats, hedgehogs and deer. I suppose I could add signalling inside, but as inside is the test track for outside, there's not much point.

Thanks again!

Wouter

Show quoted text

On Tue, 8 Jan 2019 at 20:43, Spuds McCat <spudsmccat@...> wrote:

Your end (and intermediate) goal, as written needs no custom or external scripts.

All the functionality is already within JMRI.

The hard part for you will probably be detection. For automated train running, JMRI will need to know where the train is ALWAYS. As such, most people use area sensors, such as current sensors. Using point sensors, such as? light-beam sensors may be of use to you to give exact locations, such as near stations.

I'm assuming that eventually, you'll be installing physical signals.? As such, as you build your panels, you should use the signal type that you've decided on.? I've not found a way of converting a signal to a different type (eg virtual mast to DCC signal mast or 2turnout controlled head).

Basically, don't use Virtual Signal Head/Mast if it's ever going to be real. The signalling system will work fine while software only, and then your hardware will be drop-in.

On Sun, Jan 6, 2019, 02:49 whmvd <vandoornw@... wrote:
Bob and Dave,

Since you both asked after my plans for the future of my railway, here's the summary of where I want to go with my layout. Or rather, layouts.

What I want to do has intermediate stages. Although I have in the past already successfully connected to a tiny circle of track and a program track (NCE PowerCab and NCE USB) and programmed all decoders to my satisfaction, the first stage is entirely virtual. There will be an indoor layout consisting of a single track circle with three passing places. No further frills at all. That's all measured out, and exists in JMRI as a Layout Editor panel with a Panel Editor panel for each of the three passing places. So six switches/turnouts/points. Signal system in place, everything working fine under simulator and everything (so far) virtual.

Eventual goal is a more complicated garden railway (still nothing fancy, but more stations and more involved than the extremely simple test track). Type of operation is almost exclusively passenger trains, occasional goods train in between, but fixed rakes of wagons, so no switching other than engines being replaced by others or running around at a terminus (it will be point-to-point). To that end, all locos have DCC-controlled automatic couplings installed.

Stage 1: that's where I am - JMRI able to control my indoor layout that doesn't exist yet. All the hardware for stage 2 is available (rails, locos, PowerCab, NCE USB, detectors, two AIUs, switch decoders) and a lot for stage 3 as well (though no Power Pro yet).

Stage 2: Actually build the virtual layout and make JMRI control it all. Two trains in opposing directions, halting at all stations, totally automatic. Right-hand traffic. Trains to run autonomously, but heeding (virtual) signals (more on this a bit later). Single track sections secured by (virtual) signal boxes. Each end of each station has one signalbox, that communicates with the one in the next station. In tandem, they prevent cornfield meets, each controlling their own switch and the signal (only held/not held) of a train departing into the single track to the next station. Signalling (signal masts, my further simplified version of 'basic' signalling) is working, the signalboxes and the state machines inside them was where I was going to use python. That makes six instances of identical signalboxes (I love OO). No timetabling; each train just runs as and when it can. Apart from the signal boxes, I'll also need a 'driver' object, able to control a JMRI throttle with knowledge of the way around, speeds, time it takes, distance to next signal, and ability to 'see' the appropriate signals.

Stage 3: Expand on this into the garden, with more, and more complex, train movement, at least one larger station, timetable control (an additional OO object that both signalboxes and drivers need to be aware of) and a 'plan' for the driver to follow. Again, I mean to have the signals control train movement rather than the other way round, even when the signal system already works by being controlled by the trains. So: playing with 'held' alone. Add into that mix the ability to take control of any train myself.

Quite ambitious, I think, but nothing undoable as far as I can see.

There's also a live steam loco ready to go, but mixing that in isn't something I'm really prepared to think about yet. It has no decoder (and don't plan one) but at least the wheels are isolated.

Enough to keep me ging for a number of years to come!

Thanks again, both, for your time, patience and insights.
Wouter

On Sat, 5 Jan 2019 at 21:10, Bob Jacobsen <rgj1927@...> wrote:
There are quite a few developers who work via JMRI via Eclipse.? The Eclipse support (see ) occasionally has rough edges because Eclipse evolves pretty fast.? If you’re experienced with it, though, I think it’s probably a good entry point.

Most of the instructions are about working with the JMRI code itself, which isn’t entirely required.? You could just include the jmri.jar and work with it as s formal library, but pulling the while thing gets you (a) an environment that a bunch of people know works and (b) easy access to Javadoc, etc, within Eclipse.

(Even with Java code, a bit of scripting can be the easy way to invoke your new classes, etc, so that might still be a bit on the table.)

Could you remind me of what you’re working on as your first project?? I can perhaps point you to some examples and docs that’ll help you pull together a starting point.

Bob

> On Jan 5, 2019, at 12:55 PM, whmvd <vandoornw@...> wrote:
>
> I will ask for more advice, though. And that is: what's good tooling for me to start out with (on Linux)? I'm familiar with Eclipse, but not so in-depth that I'd hate to use anything else. And what are gotchas with how I set up my coding bit separately enough so that a new JMRI-release slots in nicely and easily?

--
Bob Jacobsen
rgj1927@...

Re: MQTT Connection in JMRI

#155675

So there's some conflict here -
System names commence with MT
We want channel name first
Best practice as per?? (which I recognize as one view of what best practice should be and there may or may not be other, perhaps better, views of what best practice should be, I'm far from an expert here so have no opinion of my own regarding what ought to be best practice but also accept that we don't necessarily have to follow whatever is considered as best practice)
includes:

Never use a leading forward slash

Never use spaces in a topic? [or any form of white space]

Keep the topic short and concise

Channel name seems to be a convention used somewhere rather than a requirement.

Personally, I'm happy with? /trains/MT/...? trains/MT/...? or? ?MT/trains/...? ? but feel more comfortable without the leading slash.
but having MT forced into one or other of these positions does avoid potential problems with having 'turnout' included somewhere or other further down the topic levels.

- David

Re: Can JMRI interconnect two DCC systems? (i.e.NCE & Digitrax).

#155674

SwissChris,
Thanks helpful info!!

Kind regards,
Joseph

Re: Can JMRI interconnect two DCC systems? (i.e.NCE & Digitrax).

#155673

Bob,
Went to the website great info!!? I think I'm heading in the right direction now.

Thanks for the help
Kind regards,
Joseph

DS64 KATO switches

#155672

Dick L

I'm running DCC++, JMRI 4.14+Rd060e0b, Java 1.8.0_191 on a
Windows10 computer.? Model is KATO N gauge.?
I have 3 KATO turnouts connected to a Digitrax DS64
defined as follows.
?
DCCPPT1??? DCCPPT2??? DCCPPT4

Configure base station shows:

Index??? Address??? Subaddress
1????????? 1?? ? ? ? ? ? ?? 0
2????????? 2 ?? ? ? ? ? ? ? 0
4 ??????? 4?? ? ? ? ? ? ? ? 0

Activate 1 by using the turnout table or layout panel, shows the turnout
position has been thrown, and the actual turnout throws.

Activating either 2 or 4, causes the turnout table and layout panel,
to show the turnout thrown.
No reaction to the actual turnout.

Sending packets to DCC++ has the same reaction as using the turnout
table or layout panel.

Digitrax has confirmed that the DS64 inputs or working

Any and all help greatly appreciated

Re: MQTT Connection in JMRI

#155671

Actually the way it should be is /channename/MT, so /trains/MT/01?

The channel name should always be first in the MQTT topic.?

Chris?

Re: MQTT Connection in JMRI

#155670

Folks,

I'm seeking some clarification on the finer details of what topic structure we are proposing and how the system name will get defined for each MQTT device.

?

Bob mentioned "system names should include a complete, unconstrained topic path (without wildcards)."

?

System names normally commence with system letter and device type letter,? e.g. MT for turnouts.

?

The current implementation has the MQTT "channel" defined on the system connection options page (/trains/) as the top two levels of the topic (the top level technically is the text that precedes the first /, null in this case). I think everyone agrees that using the channel should continue though with a name of the user's choice.

?

So, does this mean that when an MQTT turnout gets created, MT/channelname/ will be prepended to the text entered for the hardware address to make the full topic as the system name?? MT therefore replaces the null top level of the topic so that is fine and means we don't need "turnout" as part of the topic because "MT" already defines it as a turnout and enforces consistency, even better!? That works for me.

?

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'.

Regards, David.

?

Re: Trying to get on top of jython

#155669

Your end (and intermediate) goal, as written needs no custom or external scripts.

All the functionality is already within JMRI.

The hard part for you will probably be detection. For automated train running, JMRI will need to know where the train is ALWAYS. As such, most people use area sensors, such as current sensors. Using point sensors, such as? light-beam sensors may be of use to you to give exact locations, such as near stations.

I'm assuming that eventually, you'll be installing physical signals.? As such, as you build your panels, you should use the signal type that you've decided on.? I've not found a way of converting a signal to a different type (eg virtual mast to DCC signal mast or 2turnout controlled head).

Basically, don't use Virtual Signal Head/Mast if it's ever going to be real. The signalling system will work fine while software only, and then your hardware will be drop-in.

Show quoted text

On Sun, Jan 6, 2019, 02:49 whmvd <vandoornw@... wrote:

Bob and Dave,

Since you both asked after my plans for the future of my railway, here's the summary of where I want to go with my layout. Or rather, layouts.

What I want to do has intermediate stages. Although I have in the past already successfully connected to a tiny circle of track and a program track (NCE PowerCab and NCE USB) and programmed all decoders to my satisfaction, the first stage is entirely virtual. There will be an indoor layout consisting of a single track circle with three passing places. No further frills at all. That's all measured out, and exists in JMRI as a Layout Editor panel with a Panel Editor panel for each of the three passing places. So six switches/turnouts/points. Signal system in place, everything working fine under simulator and everything (so far) virtual.

Eventual goal is a more complicated garden railway (still nothing fancy, but more stations and more involved than the extremely simple test track). Type of operation is almost exclusively passenger trains, occasional goods train in between, but fixed rakes of wagons, so no switching other than engines being replaced by others or running around at a terminus (it will be point-to-point). To that end, all locos have DCC-controlled automatic couplings installed.

Stage 1: that's where I am - JMRI able to control my indoor layout that doesn't exist yet. All the hardware for stage 2 is available (rails, locos, PowerCab, NCE USB, detectors, two AIUs, switch decoders) and a lot for stage 3 as well (though no Power Pro yet).

Stage 2: Actually build the virtual layout and make JMRI control it all. Two trains in opposing directions, halting at all stations, totally automatic. Right-hand traffic. Trains to run autonomously, but heeding (virtual) signals (more on this a bit later). Single track sections secured by (virtual) signal boxes. Each end of each station has one signalbox, that communicates with the one in the next station. In tandem, they prevent cornfield meets, each controlling their own switch and the signal (only held/not held) of a train departing into the single track to the next station. Signalling (signal masts, my further simplified version of 'basic' signalling) is working, the signalboxes and the state machines inside them was where I was going to use python. That makes six instances of identical signalboxes (I love OO). No timetabling; each train just runs as and when it can. Apart from the signal boxes, I'll also need a 'driver' object, able to control a JMRI throttle with knowledge of the way around, speeds, time it takes, distance to next signal, and ability to 'see' the appropriate signals.

Stage 3: Expand on this into the garden, with more, and more complex, train movement, at least one larger station, timetable control (an additional OO object that both signalboxes and drivers need to be aware of) and a 'plan' for the driver to follow. Again, I mean to have the signals control train movement rather than the other way round, even when the signal system already works by being controlled by the trains. So: playing with 'held' alone. Add into that mix the ability to take control of any train myself.

Quite ambitious, I think, but nothing undoable as far as I can see.

There's also a live steam loco ready to go, but mixing that in isn't something I'm really prepared to think about yet. It has no decoder (and don't plan one) but at least the wheels are isolated.

Enough to keep me ging for a number of years to come!

Thanks again, both, for your time, patience and insights.
Wouter

On Sat, 5 Jan 2019 at 21:10, Bob Jacobsen <rgj1927@...> wrote:
There are quite a few developers who work via JMRI via Eclipse.? The Eclipse support (see ) occasionally has rough edges because Eclipse evolves pretty fast.? If you’re experienced with it, though, I think it’s probably a good entry point.

Most of the instructions are about working with the JMRI code itself, which isn’t entirely required.? You could just include the jmri.jar and work with it as s formal library, but pulling the while thing gets you (a) an environment that a bunch of people know works and (b) easy access to Javadoc, etc, within Eclipse.

(Even with Java code, a bit of scripting can be the easy way to invoke your new classes, etc, so that might still be a bit on the table.)

Could you remind me of what you’re working on as your first project?? I can perhaps point you to some examples and docs that’ll help you pull together a starting point.

Bob

> On Jan 5, 2019, at 12:55 PM, whmvd <vandoornw@...> wrote:
>
> I will ask for more advice, though. And that is: what's good tooling for me to start out with (on Linux)? I'm familiar with Eclipse, but not so in-depth that I'd hate to use anything else. And what are gotchas with how I set up my coding bit separately enough so that a new JMRI-release slots in nicely and easily?

--
Bob Jacobsen
rgj1927@...

Re: Can JMRI interconnect two DCC systems? (i.e.NCE & Digitrax).

#155668

A variation of this issue came up about 18 months ago. See the message thread starting with #139664.

At that time, with a lot of help from Dave Sand, I was able to modify a script written by Bob Jacobsen. A copy of that file has now been uploaded to /g/jmriusers/files/ProblemsBeingWorkedOn/Master%20and%20Slave%20Turnout%20Control/TurnoutsMasterSlave.py

Some of the comments concerning the Identifier Prefix strings may be out of date.

Editing may be required at lines # 50 & 51 for the prefixes on your layout, because as-is, this script will translate an instruction to a real or hypothetical turnout LT1234 into the same instruction to a real hardware turnout NT1234.

There may be some subtle portion of the original posting in this thread that I have not picked up on, so some additional investigation may be necessary.

Cliff in Baja SoCal