I'm taking a bit of time to scrub through the JMRI/DCC++ Interface and make some updates. You can help! I'll list below the changes and fixes that I already know about and am working on. If you are aware of any of the following types of things please post up and alert me. PLEASE INDICATE WHICH TYPE OF THING YOU ARE POSTING ABOUT UPDATES: New Base Station features that JMRI does not yet support CHANGES: Base Station features that have changed and are now broken in JMRI BUGS: Problems with JMRI that appear to be Base Station version-independent REQUESTS: New features you'd like to see (if you're not sure whether something broken is a CHANGE or a BUG, mark it as a BUG and I'll sort it out) Things I'm already working on: UPDATE: The <Q> command is new. I don't think this needs to be exposed to the user in JMRI (you can always use the "send command" dialog), but it may clean up some startup code internally. At any rate the protocol and the simulator need to support it. CHANGE: The <s> response apparently changed in Base Station 1.2.x and this broke JMRI. I have a fix for this. REQUEST: The DCCppOverTCP tags a "SEND" and "RECEIVE" prefix to the messages passed between host and client JMRI instances. This is redundant. I am removing these, while at least attempting to make the change backward compatible (so a "new" version JMRI can talk to an "old" version) Things I know about that should already be fixed in JMRI 4.6 and later: BUG: JMRI was complaining about lack of response from programming commands -- responses that the Base Station isn't supposed to send. This should be fixed already. If there are other things you know about, please bring them to my attention here. Please prefix your mention with "UPDATE", "CHANGE", "BUG" or "REQUEST" so I know how to handle/prioritize things. Thanks!!
BUG: allow JMRI to restart the connection to DCC++ over ethernet. during testing of the ESP<->BaseStation code I had to restart JMRI many times due to loss of connection or JMRI generally being unhappy about the response it got back from the base station. If we could have a way to tell JMRI "forget the existing connection to DCC++ and start a new one" without having to restart the application it would be great.
I'll take a look at this. I know there is a larger discussion going on amongst the JMRI developers about "what to do when a connection appears lost" ... I'll have to stay reasonably consistent with the program direction on that, but I don't know that it's settled. Certainly network connections can be handled differently from serial/etc., but there is reason to keep behavior consistent as well. Just saying, this one might end up being a policy decision outside my control.
Here's another one: BUG: DCCppOverTCP server does not fail gracefully if another instance of JMRI is already running the server on the same (e.g. default) port. Also, need to test that it WORKS if both running servers have their own port.
Follow-up question... obviously it would be ideal if JMRI were to automagically retry the connection... but would it be sufficient if there was a button or a menu item that would manually trigger the re-connect? Do you want to be able to modify the connection settings (IP/Port) before reconnecting? Or just retry with the same values, and only change the settings the usual way (through Preferences + reboot)? I'm interested both in what would be "ideal" and what would be "good enough"
I think this would work, some option to trigger JMRI to restart the connection process. As long as we can trigger it without needing a restart of the app it should be good enough. Ideally though JMRI would automatically reconnect and if that fails alert the user and give up. today on startup if JMRI can't connect it offers to take you into config (after it complains a few times about failing to connect). I think that if JMRI has connected with the current config but the connection got closed for whatever reason, it should be possible to reconnect (either automatic or triggered via menu option). If we need to redo the config, I think it should try and establish the connection after leaving the config screen so you don't have to restart. At least that would aide in the user experience.
The biggest issue I have with JMRI isn't JMRI, but Java.......If I leave thge systemm powered on for long periods, Java stops working, which in many cases required a reboot to restore operations. I don't know if it's HW related or OS (Win7 with 2GB of RAM) or something else, but it's a major PITA. Anyone else experience this issue?
Probably OS. Having to reboot seemingly daily is one of the reasons I switched to Mac years ago. My MacBook runs for weeks on end without needing a restart. And the Raspberry Pi (Linux) running my layout hasnt been rebooted in months.
I don't know the last time I rebooted my windows machine where I do java development from. I have at least one instance of Eclipse running always, usually two. I would check to ensure you have the latest java version installed (get java 8 and uninstall version 7 jre).
OK, sometime in the next few days, JMRI will be releasing development release 4.7.1 ... it should include the following: Fixed the <s> command response Removed the SEND/RECEIVE prefixes from the DCCppOverTCP connection. It also reverts back to using them for backward compatibility if either end of the link is version 4.6 or earlier. Fixed a few other bugs in DCC++ support that I found while I was in there. Still in the works: Auto-retry when a Network DCC++ connection is dropped (this is supported in general in JMRI, just not specifically in JMRI/DCC++ I'm about halfway there -- JMRI reconnects for receive but not for send, for some reason) "Fixing up turnout support" that's on the list too.
BUG: New Loco screen defaults to "INTERNAL" rather than "DCC++" causing the "id from decoder" option to not work.. not sure why this has now started happening but it could be due to having multiple DCC++ profiles over time. What is the best way to clear things up so it starts fresh again on the new version?
BUG: W packet doesn't decode always? here is a raw capture from the monitor: 18:46:10.226: [packet: W 31 16 0 87] Prog Write Byte Cmd: CV : 31 Value: 87 Callback Num: 0 Callback Sub: 87 18:46:10.476: [] Unregonized reply: vals: Other times it does decode: 18:47:46.160: [packet: W 32 2 0 87] Prog Write Byte Cmd: CV : 32 Value: 87 Callback Num: 0 Callback Sub: 87 18:47:46.464: [r0|87|32 2] Program Reply: Callback Num: 0 Callback Sub: 87 CV Value: 32 Not sure if this is a DCC++ issue or JMRI.
Atani I think the W packet problem is a symptom of several problems in the Monitor code. It's not displaying things correctly even though the internal stuff is working normally. Can you confirm whether the write actually happened in both cases? Also, not sure what you mean by the "New Loco screen defaults to INTERNAL" ... can you post up a screen shot or something?
Could be. I am not sure that it did what it was supposed to do. I picked up an Atlas S2 with sound on Sat and was trying to let it do a "Read all pages". It wasn't working properly for sure since it only got to CV16.2.430 after about 11hrs! I suspect there were errors coming back from DCC++ but without being able to see the raw serial stream it is difficult to know for sure. From the DecoderPro window I clicked the "New Loco" button and at the top of the "Create New Loco" window the first dropdown was defaulting to Internal rather than DCC++. When it is set to this mode clicking the "Read type from decoder" button always defaults to "Massoth Elektronik, GmbH". This only seems to happen when you first start DecoderPro, if you set the value to DCC++ it will retain that setting until you restart.
Which version JMRI are you running? There was a bug only just recently fixed (assuming I actually *fixed* it) that was causing JMRI to time out on a nonexistent reply message. Interesting... I'll look into that. It's possible there's some "registration" type thing the DCC++ interface isn't doing at startup to make itself the default. ETA: I'm not seeing this behavior. in 4.6.0 using the DCC++ Simulator (which should, for this purpose, behave exactly like the other interfaces), I click New Loco, the programming mode drop-down only has "Direct Bit" and "Direct Byte" (the two options available to DCC++), with "Direct Byte" being the default.
4.6-R81496dc If there is a new build available I will gladly test it. EDIT: I see 4.7.1 dev/test builds are available with your changes, do you know if these are good enough to test? As for the New Loco issue, I suspect that my profiles are corrupted somehow so I will be cleaning them out and starting fresh soon. I also noticed that DecoderPro is defaulting back to "Edit" as the programmer on startup, it used to work correctly but perhaps in my experimentation with DCC++ WiFi I corrupted something. Is there a clean way to have JMRI prompt for the profile on startup so I can switch between DCC++ Serial, DCC++ Simulator, DCC++ WiFi? Mike
Only thing I can think of re: profiles is to go into preferences and use the Startup Profiles tab to remove all the profiles and create new ones. If you want to be really thorough each profile is a sub directory of your JMRI preferences directory. I haven't tested the 4.7.1 release files yet but my DCC++ changes should be relatively stable. I haven't been working on CV function though. If that is broken in 4.6 then it is still broken in 4.7.1
I moved up to 4.7.2 dev build 4.7.2ish-201702221644-jenkins-Rd9e3a24 and things seem to be better after renaming my JMRI profiles directory. One thing I noticed is that JMRI might be overloading DCC++ when sending commands for CV read/writes in rapid succession. I can't say for sure though but it certainly seems that way. I just finished the install of a DZ126 into a dash 8-40CW and went to JMRI to set a better speed table than default and upon writing the page changes it failed on CV91 but succeeded on retry. monitor output: [packet: W 91 248 0 87] Prog Write Byte Cmd: CV : 91 Value: 87 Callback Num: 0 Callback Sub: 87 [] Unregonized reply: vals: [packet: W 91 248 0 87] Prog Write Byte Cmd: CV : 91 Value: 87 Callback Num: 0 Callback Sub: 87 [r0|87|91 248] Program Reply: Callback Num: 0 Callback Sub: 87 CV Value: 91 It looks like either JMRI is flooding DCC++ too quickly or DCC++ is intercepting a partial packet and rejecting it. Is there a way to get the raw serial stream within JMRI somehow?
It's possible we are flooding the packets. There is probably a way to throttle it back. In what form do you want to capture the raw stream?
