JMRI Throttle control may be laggy at times

[roadsnail]

Hi.

My setup is ESP32 board ESPDUINO-32 with L298 shield running your latest build. My CommandStation connects to local wifi and the latest stable JMRI is running on my W10 laptop. I connect to my commandstation by ethernet to the address allocated to the ESP32.

I select my loco at DCC address 1200 from the roster, then start a throttle window.

Observations: Change loco direction appears to be okay, speed control seems to be okay but maybe a little laggy on some speed changes? So I start a serial comms monitor window to check traffic on ESP32 serial port (MicroUSB). Next with power off to loco (toggle Throttle power toggle), I then toggle between FWD and REV and observe serial traffic on ESP32 serial. Mostly the response to direction toggle is very fast but on occasions, there is a noticeable lag in the commandstation responding as seen on serial traffic window.

Noticed the same with ramping speed up and down. On occasions, there is a noticeable lag before there is a response in the serial port traffic.

Then I ran loco in REV direction and brought it to a stop (speed 0), I then hit STOP! button, and loco races away in the FWD direction!

I turn off power to track using throttle power toggle button

Now when I switch between REV and FWD I observe 'Set speed to 255' then 'Set direction to FWD' regardless of which direction I choose. See cut and paste of serial traffic and my comments below. Maybe I have set up something wrong, but I have double checked as much as possible. Also the same JMRI/laptop has been used to control the same loco/setup via my DCC++ 'classic' reference hardware.

Chris

Serial Traffic

[DCC++ loco 1200] Set speed to 4 [DCC++ loco 1200] Set direction to REV [DCC++ loco 1200] Set speed to 5 Slow loco down in reverse... [DCC++ loco 1200] Set direction to REV [DCC++ loco 1200] Set speed to 4 [DCC++ loco 1200] Set direction to REV [DCC++ loco 1200] Set speed to 3 [DCC++ loco 1200] Set direction to REV [DCC++ loco 1200] Set speed to 2 [DCC++ loco 1200] Set direction to REV [DCC++ loco 1200] Set speed to 1 [DCC++ loco 1200] Set direction to REV [DCC++ loco 1200] Set speed to 0 Loco now stopped in REV direction [DCC++ loco 1200] Set direction to REV [DCC++ loco 1200] Set speed to 255 Activate STOP! and loco races away in FWD direction [DCC++ loco 1200] Set direction to FWD [DCC++ loco 1200] Set speed to 255 [DCC++ loco 1200] Set direction to FWD [OPS] 260.74 mA / 2000 mA Commandstation pops up a current report [Track] Disabling track output: OPS (if enabled) I hit STOP! button on JMRI throttle [Track] Disabling track output: PROG (if enabled) [TaskMon] uptime: 00:17:18 freeHeap: 177276, largest free block: 113792, tasks: 16, mainBufferPool: 0.70kB [DCC++ loco 1200] Set speed to 255 Now with power off, I toggle between FWD and REV [DCC++ loco 1200] Set direction to FWD [DCC++ loco 1200] Set speed to 255 [DCC++ loco 1200] Set direction to FWD [DCC++ loco 1200] Set speed to 255 [DCC++ loco 1200] Set direction to FWD [DCC++ loco 1200] Set speed to 255 [DCC++ loco 1200] Set direction to FWD [TaskMon] uptime: 00:18:03 freeHeap: 177308, largest free block: 113792, tasks: 16, mainBufferPool: 0.70kB

[atanisoft]

@roadsnail Can you also capture (with timestamps) the DCC++ traffic in JMRI? I'll do some testing with JMRI/DCC++ interface and see what I can find with it.

[roadsnail]

I presume that can be turned on in the menuconfig file and recompiling? If so, I'm happy to try to get that information.

[atanisoft]

It would be an option in JMRI itself.

[roadsnail]

Okay, was just reading about it. I'll take a look at JMRI then

[roadsnail]

Okay, think I found logging in JMRI... Please see log below showing REV/FWD rapid switching which exhibits some lagging. Followed by reversing loco then bringing it to a stop before hitting STOP! which is when direction changes to FWD and it races forward! At this point I switched power off to track within JMRI throttle control.

Hope the log throws some light on what I am seeing.

Thanks Chris

---

Log follows, with my time stamp comments at the start... CS is at IP add 192.168.20.11 (although I also see 192.168.4.1 mentioned?) Isn't 192.168.4.1 the esp32 softap default address?

Anyhow, the following actions were:-

Throttle at 0 and direction set to reverse.

Then I fast toggled REV/FWD (21:06:18 to 21:06:43) and noticed that most responses were fast, although some were laggy. Maybe the time stamps will show which?

Then I increased speed in REV direction, then decreased it.

Then hit STOP! at 21:06:55? This is where the direction control changes by itself to FWD and the loco runs away. That is why I hit power off at 21:07:13? to stop the loco flying off the end of my test track.

21:05:13.760: [TX: s] Status Cmd 21:05:13.774: [RX: iDCC++ ESP32 Command Station: V-v1.5.0-beta1 / Oct 7 2020 17:00:21] Base Station Status: Version: DCC++ ESP32 Command Station Build: V-v1.5.0-beta1 / Oct 7 2020 17:00:21 21:05:13.788: [RX: p0 OPS] Power Status: Name:OPS Status:OFF 21:05:13.796: [RX: T 0 0 1] Throttle Reply: Register: 0 Speed: 0 Direction: Forward 21:05:13.802: [RX: X] No Sensor/Turnout/Output Reply 21:05:13.806: [RX: N1: 192.168.20.11] Comm Type Reply Type: 1 Port: 192.168.20.11 21:05:13.811: [RX: N1: 192.168.4.1] Comm Type Reply Type: 1 Port: 192.168.4.1 21:05:43.761: [TX: s] Status Cmd 21:05:43.774: [RX: iDCC++ ESP32 Command Station: V-v1.5.0-beta1 / Oct 7 2020 17:00:21] Base Station Status: Version: DCC++ ESP32 Command Station Build: V-v1.5.0-beta1 / Oct 7 2020 17:00:21 21:05:43.775: [RX: p0 OPS] Power Status: Name:OPS Status:OFF 21:05:43.780: [RX: T 0 0 1] Throttle Reply: Register: 0 Speed: 0 Direction: Forward 21:05:43.785: [RX: X] No Sensor/Turnout/Output Reply 21:05:43.790: [RX: N1: 192.168.20.11] Comm Type Reply Type: 1 Port: 192.168.20.11 21:05:43.794: [RX: N1: 192.168.4.1] Comm Type Reply Type: 1 Port: 192.168.4.1 21:06:00.053: [TX: 1] Track Power ON Cmd 21:06:00.074: [RX: p1 OPS] Power Status: Name:OPS Status:ON 21:06:05.559: [TX: t 2 1200 12 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 12 :Direction: Reverse 21:06:05.593: [RX: T 2 12 0] Throttle Reply: Register: 2 Speed: 12 Direction: Reverse 21:06:13.761: [TX: s] Status Cmd 21:06:13.773: [RX: iDCC++ ESP32 Command Station: V-v1.5.0-beta1 / Oct 7 2020 17:00:21] Base Station Status: Version: DCC++ ESP32 Command Station Build: V-v1.5.0-beta1 / Oct 7 2020 17:00:21 21:06:13.778: [RX: p1 OPS] Power Status: Name:OPS Status:ON 21:06:13.781: [RX: a OPS 0] Current: 0 / 1024 21:06:13.792: [RX: T 0 0 1] Throttle Reply: Register: 0 Speed: 0 Direction: Forward 21:06:13.795: [RX: T 1 12 0] Throttle Reply: Register: 1 Speed: 12 Direction: Reverse 21:06:13.802: [RX: X] No Sensor/Turnout/Output Reply 21:06:13.809: [RX: N1: 192.168.20.11] Comm Type Reply Type: 1 Port: 192.168.20.11 21:06:13.815: [RX: N1: 192.168.4.1] Comm Type Reply Type: 1 Port: 192.168.4.1 21:06:18.398: [TX: t 2 1200 0 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Reverse 21:06:18.423: [RX: T 2 0 0] Throttle Reply: Register: 2 Speed: 0 Direction: Reverse 21:06:22.518: [TX: t 2 1200 0 1] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Forward 21:06:22.903: [RX: T 2 0 1] Throttle Reply: Register: 2 Speed: 0 Direction: Forward 21:06:24.593: [TX: t 2 1200 0 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Reverse 21:06:24.612: [RX: T 2 0 0] Throttle Reply: Register: 2 Speed: 0 Direction: Reverse 21:06:25.364: [TX: t 2 1200 0 1] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Forward 21:06:25.392: [RX: T 2 0 1] Throttle Reply: Register: 2 Speed: 0 Direction: Forward 21:06:25.826: [TX: t 2 1200 0 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Reverse 21:06:27.903: [RX: T 2 0 0] Throttle Reply: Register: 2 Speed: 0 Direction: Reverse 21:06:27.904: [TX: t 2 1200 0 1] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Forward 21:06:27.933: [RX: T 2 0 1] Throttle Reply: Register: 2 Speed: 0 Direction: Forward 21:06:27.934: [TX: t 2 1200 0 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Reverse 21:06:27.963: [RX: T 2 0 0] Throttle Reply: Register: 2 Speed: 0 Direction: Reverse 21:06:29.567: [TX: t 2 1200 0 1] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Forward 21:06:29.592: [RX: T 2 0 1] Throttle Reply: Register: 2 Speed: 0 Direction: Forward 21:06:30.068: [TX: t 2 1200 0 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Reverse 21:06:30.092: [RX: T 2 0 0] Throttle Reply: Register: 2 Speed: 0 Direction: Reverse 21:06:30.557: [TX: t 2 1200 0 1] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Forward 21:06:30.583: [RX: T 2 0 1] Throttle Reply: Register: 2 Speed: 0 Direction: Forward 21:06:31.090: [TX: t 2 1200 0 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Reverse 21:06:32.902: [RX: T 2 0 0] Throttle Reply: Register: 2 Speed: 0 Direction: Reverse 21:06:43.761: [TX: s] Status Cmd 21:06:43.772: [RX: iDCC++ ESP32 Command Station: V-v1.5.0-beta1 / Oct 7 2020 17:00:21] Base Station Status: Version: DCC++ ESP32 Command Station Build: V-v1.5.0-beta1 / Oct 7 2020 17:00:21 21:06:43.773: [RX: p1 OPS] Power Status: Name:OPS Status:ON 21:06:43.784: [RX: a OPS 0] Current: 0 / 1024 21:06:43.790: [RX: T 0 0 1] Throttle Reply: Register: 0 Speed: 0 Direction: Forward 21:06:43.799: [RX: T 1 0 0] Throttle Reply: Register: 1 Speed: 0 Direction: Reverse 21:06:43.807: [RX: X] No Sensor/Turnout/Output Reply 21:06:43.822: [RX: N1: 192.168.20.11] Comm Type Reply Type: 1 Port: 192.168.20.11 21:06:43.824: [RX: N1: 192.168.4.1] Comm Type Reply Type: 1 Port: 192.168.4.1 21:06:46.837: [TX: t 2 1200 57 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 57 :Direction: Reverse 21:06:47.902: [RX: T 2 58 0] Throttle Reply: Register: 2 Speed: 58 Direction: Reverse 21:06:49.747: [TX: t 2 1200 0 0] Throttle Cmd: Register: 2 Address: 1200 Speed: 0 :Direction: Reverse 21:06:49.773: [RX: T 2 0 0] Throttle Reply: Register: 2 Speed: 0 Direction: Reverse 21:06:55.888: [TX: t 2 1200 -1 1] Throttle Cmd: Register: 2 Address: 1200 Speed: -1 :Direction: Forward 21:06:57.902: [RX: T 2 256 1] Throttle Reply: Register: 2 Speed: 256 Direction: Forward 21:06:57.903: [TX: t 2 1200 -1 1] Throttle Cmd: Register: 2 Address: 1200 Speed: -1 :Direction: Forward 21:06:57.932: [RX: T 2 256 1] Throttle Reply: Register: 2 Speed: 256 Direction: Forward 21:07:00.202: [TX: 0] Track Power OFF Cmd 21:07:00.223: [RX: p0 OPS] Power Status: Name:OPS Status:OFF 21:07:06.035: [TX: t 2 1200 -1 1] Throttle Cmd: Register: 2 Address: 1200 Speed: -1 :Direction: Forward 21:07:07.902: [RX: T 2 256 1] Throttle Reply: Register: 2 Speed: 256 Direction: Forward 21:07:08.496: [TX: t 2 1200 -1 1] Throttle Cmd: Register: 2 Address: 1200 Speed: -1 :Direction: Forward 21:07:08.522: [RX: T 2 256 1] Throttle Reply: Register: 2 Speed: 256 Direction: Forward 21:07:10.192: [TX: t 2 1200 -1 1] Throttle Cmd: Register: 2 Address: 1200 Speed: -1 :Direction: Forward 21:07:10.224: [RX: T 2 256 1] Throttle Reply: Register: 2 Speed: 256 Direction: Forward 21:07:11.994: [TX: t 2 1200 -1 1] Throttle Cmd: Register: 2 Address: 1200 Speed: -1 :Direction: Forward 21:07:12.902: [RX: T 2 256 1] Throttle Reply: Register: 2 Speed: 256 Direction: Forward 21:07:13.762: [TX: s] Status Cmd 21:07:13.771: [RX: iDCC++ ESP32 Command Station: V-v1.5.0-beta1 / Oct 7 2020 17:00:21] Base Station Status: Version: DCC++ ESP32 Command Station Build: V-v1.5.0-beta1 / Oct 7 2020 17:00:21 21:07:13.772: [RX: p0 OPS] Power Status: Name:OPS Status:OFF 21:07:13.781: [RX: T 0 0 1] Throttle Reply: Register: 0 Speed: 0 Direction: Forward 21:07:13.790: [RX: T 1 256 1] Throttle Reply: Register: 1 Speed: 256 Direction: Forward 21:07:13.799: [RX: X] No Sensor/Turnout/Output Reply 21:07:13.812: [RX: N1: 192.168.20.11] Comm Type Reply Type: 1 Port: 192.168.20.11 21:07:13.814: [RX: N1: 192.168.4.1] Comm Type Reply Type: 1 Port: 192.168.4.1

[roadsnail]

Just a quick follow up... after I stopped the loco runaway by turning track power off (in the log file above)... I then went on to turn track power back on within throttle control without touching any other controls. At this point, the loco started speeding up in FWD direction, thus requiring me to cut the power again. I didn't log that but can do if required.

[atanisoft]

Isn't 192.168.4.1 the esp32 softap default address?

Yes, it won't be used by JMRI since it can't connect to that IP unless it accesses the SoftAP interface. Though it shouldn't be a problem.

At this point, the loco started speeding up in FWD direction, thus requiring me to cut the power again.

When the power-off is processed it simply cut's the power to the track and does not alter the loco speed/etc.

21:07:10.192: [TX: t 2 1200 -1 1] Throttle Cmd: Register: 2 Address: 1200 Speed: -1 :Direction: Forward 21:07:10.224: [RX: T 2 256 1] Throttle Reply: Register: 2 Speed: 256 Direction: Forward

This looks like part of the issue in that it is not correctly picking up the -1 as e-stop.

[roadsnail]

This looks like part of the issue in that it is not correctly picking up the -1 as e-stop.

Okay. Thanks for taking a look and getting back. I'll leave that with you and continue my testing Other points noted. Thank you.

[atanisoft]

I'll be preparing a few fixes based on your log as it looks like there may be a few issues occurring.

[atanisoft]

@roadsnail can you test the updates linked above to see if they improve the issues you were facing?

[roadsnail]

Initial testing would indicate that STOP! (from JMRI throttle) bug is fixed. Would like to do some more testing though, but I'm optimistic!

I still seem to be seeing random lags between commands being issued from JMRI throttle and an observed response on my test track. But I will do some other checks to ensure that I am not observing response issues due to bottlenecks somewhere on my ethernet/wifi network.

Watch this space!

Thanks, Chris

[roadsnail]

Oops sorry, hit the close instead of comment button. So re-opening

[atanisoft]

I still seem to be seeing random lags between commands being issued from JMRI throttle and an observed response on my test track.

There shouldn't be much time between when the command is issued by JMRI and when it is processed by the CS. We might find more clues in the JMRI traffic monitor.

[roadsnail]

Yes, I'll turn on JMRI logging again with timestamps and try to keep the number of commands to a minimum until I experience what a deem to be lag, which is very much a subjective thing until the delays become quite noticeable. Will keep you updated.

[roadsnail]

I am pretty sure you've nailed the e-stop issue. Thanks. WRT Perceived lags, I don't think network bottlenecks are an issue. I will investigate further with logging on in JMRI.

Would you like me to open a separate issue for the lagging, then you can close the e-stop issue. Or keep this ticket open?

[atanisoft]

Would you like me to open a separate issue for the lagging, then you can close the e-stop issue. Or keep this ticket open?

Let's keep this one for now and I'll merge the PR that fixes at least the e-stop issue.

[roadsnail]

Okay. This is what I have done so far...

In order to test for lags, I have simplified my approach. My method is:- open JMRI throttle (on W10 laptop) for a loco with lighting. Toggle lighting by clicking the 'Light' button on function panel opened up by throttle. When I observe a loco light toggle change, then I click the 'light' button again. Obviously, my reaction times may vary, but I have noticed a big difference in light toggle response times comparing latest ESP32 CS with another system I am testing here, a very new build of DCC++Ex connected to the same W10 laptop running the same version of JMRI by ESP8266-01. (I am trying to keep variables to a minimum).

Here are two logs recorded in JMRI of my light toggle test. One produced by connecting via DCC++Ex and another connected via ESP32CS. You can see the timestamps created each time I click the 'light' button give or take a fraction of a second for me to react to what I see.

There is a difference in the rate of timestamps for ESP32CS compared with DCC++Ex.

Using the DCC++Ex controller I observe that the time between clicking 'light' and the loco light responding is very rapid (around half a second maybe?) compared to what I observe using ESP32CS (sometimes fast, other times a second to a couple of seconds). My conclusion, there appears to be a lag in ESP32CS

Two logs follow. The first for DCC++Ex and the second ESP32CS

Hope this helps

---

! Log from DCC-Ex follows:

---

13:44:39.857: [TX: s] Status Cmd 13:44:40.099: [RX: p1] Power Status: ON 13:44:43.479: [RX: iDCC-EX V-0.2.0 / MEGA / STANDARD_MOTOR_SHIELD G-9db6d36] Base Station Status: Version: Build: 13:44:45.214: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 13:44:45.814: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 13:44:46.398: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 13:44:46.932: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 13:44:47.512: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 13:44:48.014: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 13:44:48.770: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 13:44:49.403: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 13:44:50.028: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 13:44:50.642: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 13:44:51.245: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 13:44:51.853: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 13:44:52.467: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 13:44:53.068: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected)

---

! Log from ESP32CS

---

14:07:42.198: [TX: s] Status Cmd 14:07:42.246: [RX: iDCC++ ESP32 Command Station: V-v1.5.0-beta1-2-gb28a0f2 / Oct 8 2020 11:25:56] Base Station Status: Version: DCC++ ESP32 Command Station Build: V-v1.5.0-beta1-2-gb28a0f2 / Oct 8 2020 11:25:56 14:07:42.246: [RX: p1 OPS] Power Status: Name:OPS Status:ON 14:07:42.250: [RX: a OPS 0] Current: 0 / 1024 14:07:42.255: [RX: T 0 0 1] Throttle Reply: Register: 0 Speed: 0 Direction: Forward 14:07:42.259: [RX: T 1 0 1] Throttle Reply: Register: 1 Speed: 0 Direction: Forward 14:07:42.264: [RX: X] No Sensor/Turnout/Output Reply 14:07:42.270: [RX: N1: 192.168.20.11] Comm Type Reply Type: 1 Port: 192.168.20.11 14:07:42.274: [RX: N1: 192.168.4.1] Comm Type Reply Type: 1 Port: 192.168.4.1 14:07:43.926: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 14:07:44.746: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 14:07:47.491: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 14:07:48.208: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 14:07:48.953: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 14:07:49.882: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 14:07:52.559: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 14:07:53.405: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 14:07:54.109: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 14:07:55.156: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 14:07:57.518: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 14:07:58.501: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 14:07:59.457: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 14:08:00.187: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected) 14:08:02.489: [TX: f 48 144] Function Cmd: Address: 48 Byte 1: 144 Byte 2: null (No Reply Expected) 14:08:05.135: [TX: f 48 128] Function Cmd: Address: 48 Byte 1: 128 Byte 2: null (No Reply Expected)

[atanisoft]

Thanks for testing. I'll do some digging but I have some ideas of where the perceived "lag" may be coming from, which is likely unrelated to JMRI.

[roadsnail]

I'm happy to help out with any testing. I like where your project is headed.

Best, Chris

[roadsnail]

Hi Mike, I added my observations to your pull request. Am I doing something wrong? I can confirm that my HW is okay as I reverted to an earlier build which starts up okay. Thanks

Chris

[atanisoft]

Am I doing something wrong?

That looks like a bug in the startup code for the DCC generators. It doesn't appear to be invoking notify() even though the AutoNotify class should do that on delete. I'll add a fix for that and do some more testing.

[roadsnail]

Okay, thanks for getting back. I'll await your fix/tests

[atanisoft]

@roadsnail I think the PR should be in a good state now for testing. It appears to work in my limited testing so far, I'll continue with more testing in parallel with you.

[roadsnail]

Okay. Thanks. I'll run some tests tomorrow as it's getting late here. (UK time)

[atanisoft]

JMRI support is being dropped in v2.0