Found another problem with the programming code that may be related to the overruns... the DCCppProgrammer (the top level component that does the actual programming operation) was not reporting back to the higher level JMRI management code when a read or write operation failed. So the higher level code would go right ahead as though all was well. I've got that fixed, am running regression tests, and will have it pushed up to my personal fork of JMRI tomorrow... but it's likely too late to get the fix into 4.7.1. We'll see though. There's still a good deal of other (unrelated) stuff folks are working on... there may be time. However, it still looks to me like things are operating in lock-step, with JMRI waiting for the response from the base station before moving on. One thing that *might* be going on, though, occurs to me... I'm probably also not correctly reporting timeout failures... if we hit the timeout because the Base Station is just taking too long, JMRI may move on to the next command, thinking all is well. I'll check on that.
JMRI 4.7.1 is released. If you have the time and inclination, I'd appreciate verification of the following fixes and improvements: Sensors and Turnouts should respond correctly to the Invert checkbox EXACT (now called BSOUTPUT) mode JMRI turnouts should now control DCC++ Outputs correctly "Configure Sensors & Turnouts" dialog is now called "Configure Base Station" Behavior of "Configure Base Station" should be MUCH more sane... Better (more correct) display of data in the Monitor window. In short, Sensors, Turnouts, and Outputs should be fairly sane and bug-free at this point. Programming will still have some hiccups, especially around failure conditions. Also, the bit about the programmer going to the "Internal" programmer instead of "DCC++" ... does that still happen with 4.7.1 with a FRESH Startup Profile? There were some unrelated/more-general problems with profiles changes between 4.6 and 4.7 that may have contributed to that. I ran into the problem last night, and creating a new profile fixed it. Network attach retry is still not working. I believe I have the JMRI side of things working, but when JMRI attempts to reconnect, the Base Station does not respond. I think when the connection is dropped, Base Station gets in a state where it is no longer open to new connections. Haven't proven that yet.
Also, please check out these two new Help pages, and give me some feedback on whether they help clear up how to use JMRI with DCC++ for sensors and turnouts. There were (are?) plenty of bugs messing with stuff, but I think much of the trouble folks have had in this area is a lack of clear direction on how the various parts work together. I hope this helps. http://www.jmri.org/help/en/html/hardware/dccpp/Sensors.shtml http://www.jmri.org/help/en/html/hardware/dccpp/Turnouts.shtml
I don't have sensors or turnouts wired up on my test bench so can't verify (yet) This looks good. After reading the page for Turnouts I was able to figure out how to toggle outputs and it did appear to issue a Z command for HIGH (thrown) / LOW (closed). I was finally able to verify things after re-adding the "turnout" (output) to JMRI with the right hardware index. It would be good if there was an automatic way to add the output when you define it in the "Configure Base Station" window. Almost. It prompted multiple times to save data to base station and eeprom. from traffic monitor: 08:12:47.254: [O] Sensor/Turnout/Output MADC Success Reply 08:12:48.063: [packet: E] Unknown Message: 08:12:48.066: [e 0 0 1] Write EEPROM Reply... Turnouts: 0 Sensors: 0 Outputs: 1 08:12:49.017: [packet: E] Unknown Message: 08:12:49.018: [e 0 0 1] Write EEPROM Reply... Turnouts: 0 Sensors: 0 Outputs: 1 Looks a lot better, still seeing some unrecognized reply values from <s>: 08:14:06.352: [packet: s] Status Cmd 08:14:06.358: [p0] Power Status: OFF 08:14:06.562: [iDCC++ BASE STATION FOR ARDUINO MEGA / ARDUINO MOTOR SHIELD: V-1.2.1+ / Feb 23 2017 18:40:29] Base Station Status: Version: DCC++ BASE STATION FOR ARDUINO MEGA / ARDUINO MOTOR SHIELD Build: V-1.2.1+ / Feb 23 2017 18:40:29 08:14:06.768: [] Unregonized reply: vals: 08:14:06.972: [X] No Sensor/Turnout/Output Reply 08:14:07.171: [Y0 0] Output Command Reply: Output Number: 0 OutputState: CLOSED Likely this is the <NXXXX line we discussed previously. As for the help pages, I think they are certainly a great start. It would be good to add some cross checking of IDs if that is an option. I got tripped up by setting the values on the turnouts (outputs) incorrectly.
Also gave 4.7.1 a try with the ESP WiFi for a "read all sheets"... It didn't go very well. It failed after about 2mins of reading CVs (got a bad reply from DCC++ it seems) but it didn't give up on the "read all sheets". I think your latest commits might help fix this up though. I am waiting for them to show up in a dev build (saw your pull req this morning). Once the dev build completes and has your changes I will pull it down and give it another go. Also I haven't seen the "internal" default except for once on the 4.7.2ish dev build I was on previously (it was 4.7.1 essentially). I suspect it was due to switching from TCP -> SERIAL for the profile. I am going to start clearing the JMRI directory between switches like that and see if it shows up again.
Thanks for the feedback, Atani. The reason for the multiple prompts on saving is that it's two different things. First it asks if you want to save changes to the Base Station. This triggers the <T> and <Z> and <S> commands to actually write to the Base Station's table. Second, it asks if you want to write to EEPROM. This triggers the <E> command to actually write to EEPROM. I could probably consolidate these... maybe add a checkbox to the "Save" dialog to indicate whether an EEPROM write is in order, or (if unchecked) not. I assume by this you mean to auto-populate the JMRI Turnout Table? I could do that. The easiest (and perhaps most sensible) way would be to force a read back of the Base Station tables during a Save operation. This would (a) not create new JMRI objects until you're ready to commit changes, and (b) act as a confirmation that the Base Station accepted the changes. I'll keep looking into making the Monitor behave. One thing I want to do is "loosen up" the REGEXs I'm using to parse some of the messages so that JMRI is more tolerant of slight changes in the Base Station responses.
It prompted twice for save to eeprom I think. I had also clicked the save button on the dialog before closing it. I believe there were three or maybe four dialogs. I will try it out again later today. Yes exactly that. It would help new users (like me) not shoot themselves in the foot so to speak. Having the base station be the source of truth sounds like a great idea. With JMRI sending the <s> periodically (every 5min?) it could even trigger a sync operation at that time, or prompt the user if they want to sync possibly. This could be an optional behavior and not the default. It is certainly better than it was previously. It seems a lot more tolerant to the messages coming in which is a great thing.
Please do check this. The expected behavior is: Press "Save" Button -> * Prompt for Save OK * if OK Write data for the current tab only to the Base Station * Prompt for EEPROM Write OK * if OK send the <E> command. Press "Close" Button -> * Prompt for Save OK * if OK Write data for the current tab only to the Base Station * Prompt for EEPROM Write OK * if OK send the <E> command. * Close the window. In either case, there should be exactly two prompts per button click. But if you click both buttons, you will get a total of four prompts. There's no attempt (yet) to be "smart" about whether a prompt is necessary. Note that the "save to base station" step will ONLY write "dirty" or "new" rows. Not the whole table. Oh, and it will do deletes too. That counts as "dirty". I'm modifying the "Close" behavior so that it saves all three tables, whereas the "Save" button will only save the current table, not the other tabs. The thinking here is that if I'm "Saving" I may have changes on the other tabs that I'm not ready to commit. If I'm "Closing" I'm done, and all dirty stuff needs to be written.
Some progress... If I just do the Telnet to Serial Monitor with just the ESP, everything works fine. So I tried hooking it up to my Arduino. Mounted the two, connected RX/TX pins on ESP to TX/RX pins on Arduino... have both devices plugged into my laptop's USB ports for power... Arduino Serial Monitor connected to the Arduino's USB, and CoolTermMac connected to the ESP. I then tried to connect my phone's WiThrottle to the ESP ... It will try to connect... I can see the phone's transmits on both monitors, and I can see the Arduino's responses on the Arduino monitor... but I do not see the Arduino's responses on the ESP monitor, nor does it appear that the phone is receiving them. I've also tested with (alternately) the CoolTerm and Arduino serial monitors turned off... I can't disconnect the USB because that's power but at least there wasn't a terminal on the other end. So it appears my Arduino can receive through the ESP but it cannot transmit. OH and just for fun (and because I was in a place where I didn't have a network) I tweaked the TelnetToSerial script for the ESP to turn on the Access Point. Seems to work great! ETA: Tried Telnet from my PC to the setup. I get a connection, but then it is almost immediately closed by the remote host (the ESP). Bummer.
are you using a TTL converter or voltage divider circuit on the Arduino -> ESP TX? Also be sure to connect Arduino RX to ESP RX and similarly for TX. I had it originally wired as Arduino TX -> ESP RX, etc and saw similar behavior.
Dang wrong thread. I meant to post this status to the ESP thread. Oh well. Not using a voltage converter. Kind of assumed the NodeMCU already had that. I do have the serial hooked up TX<->RX and RX<->TX though. That might be the issue I'll fix that and try again
If your Arduino is 5VDC you will need to use a converter or divider circuit, on the TX line especially. You don't want to fry the ESP when you just got it
I'm not sure what your usb is plugged into, I had a problem with an Arduino communicating with an ESP8266-01. Data would only flow one way with the arduino usb plugged into the PC (a conflict with the serial or transmit lines). It was fine if I just provided power to the USB from a wall wart (thus the USB data lines were not connected) HTH Jim