JMRI/DCC++ Updates

TwinDad Feb 15, 2017

  1. TwinDad

    TwinDad TrainBoard Member

    1,844
    551
    34
    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.
     
    Scott Eric Catalano likes this.
  2. TwinDad

    TwinDad TrainBoard Member

    1,844
    551
    34
    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.
     
    Scott Eric Catalano likes this.
  3. TwinDad

    TwinDad TrainBoard Member

    1,844
    551
    34
    Scott Eric Catalano likes this.
  4. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    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.
     
    Scott Eric Catalano likes this.
  5. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    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.
     
    Scott Eric Catalano likes this.
  6. TwinDad

    TwinDad TrainBoard Member

    1,844
    551
    34
    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.
     
    Scott Eric Catalano likes this.
  7. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    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.
     
    Scott Eric Catalano likes this.
  8. TwinDad

    TwinDad TrainBoard Member

    1,844
    551
    34
    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.
     
    Scott Eric Catalano likes this.
  9. TwinDad

    TwinDad TrainBoard Member

    1,844
    551
    34
    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.
     
    Scott Eric Catalano likes this.
  10. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    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.
     
    Scott Eric Catalano likes this.
  11. TwinDad

    TwinDad TrainBoard Member

    1,844
    551
    34
    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
     
    Scott Eric Catalano likes this.
  12. Atani

    Atani TrainBoard Member

    1,460
    1,697
    36
    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 :)
     
    Scott Eric Catalano likes this.
  13. Jimbo20

    Jimbo20 TrainBoard Member

    274
    178
    11
    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
     
    Scott Eric Catalano likes this.

Share This Page