Probably a 25ms delay between packets should solve it. There are multiple ways to do this in java but I am sure is a JMRI way to do it already. Pretty much like I was connecting to the base station with a generic terminal emulator. I would like to see the unparsed raw content as it comes across the wire. This probably only is useful for those like me that are tweaking the base station code itself.
Some more details on the flooding of the packets on SERIAL... I switched over to ESP WiFi and have not observed any issues yet with reading the full sheets. So something is very likely causing an overrun in the serial handler. With the ESP WiFi interface things are a bit more buffered so it operates a bit more smoothly. If you add any sort of flow control please only add it for SERIAL connections.
Will do. I've checked in some more changes... fixed a bug where the sensors were ignoring the invert checkbox in the sensor table. And made some fairly big reworks of the Configure Sensors & Turnouts dialog (now called Configure Base Station) to fix various problems. I'll take a look at the serial buffering next, maybe...
On your recent changes (just pulled em to try it out)... It looks good but the menu bar on Config Base Station doesn't seem to have any menus? It looks like the parser doesn't handle my base station exactly as expected though... here is a raw dump from the monitor: 07:23:15.072: [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 07:23:15.274: [] Unregonized reply: vals: 07:23:15.475: [X] No Sensor/Turnout/Output Reply 07:23:15.677: [X] No Sensor/Turnout/Output Reply ---- I connected to the WiFi serial console and it looks like it is failing on this line: <N1: 192.168.0.101>
OK, I *think* that is *just* the Monitor pane not knowing how to display the <N> response. The functional code basically ignores <N> (it doesn't need any of the contained information), so I don't think anything was broken there. I've just pushed a fix for the monitor pane, so it should display <N> responses now. I also took the opportunity to refactor some unnecessary complexity out of the reply parsing code, too, which is good.
I think I have JMRI's side of the Network-failure-reconnect problem implemented. It's an already supported feature, at least the infrastructure is, I just had to implement the hooks within the DCC++ code. BUT ... it appears there is some work needed on the Base Station side... JMRI knocks, but nobody is listening...
Also, I tweaked the Monitor output. It's not exactly what you asked for, but if you check the "Show Raw Data" checkbox, it will show the raw message data ... alongside the interpreted ... in the window... both TX and RX. I want to at some point add a second checkbox that will turn OFF the interpreted data and just give the raw data stream, but that requires some GUI work and I'd rather focus on fixing some of the other problems first. It might be easiest to tweak the SerialCommand.cpp code in Base Station to dump the raw data stream to the serial port from that end of the link.
TwinDad: I have an 'N' scale layout that is fully automatic train operations but is DC only. It runs 4 trains on a L-2-L and three trolleys on a P-2-P. I want to convert it over to DCC and have been watching the work being done on DCC++. Just moved closer to you and still unpacking, but will start soon converting the Loco's to DCC. I like what you are doing.
That is something I am also looking at for the ESP WiFi setup. I want to allow more than one COMM_TYPE simultaneously. I don't see any reason to prevent you from having both IP based and COMM based at the same time. Same for say IP and say LocoNet. They are just different interfaces and SerialCommand.cpp doesn't need to be the gateway for all, just the interpreter of the DCC++ text based protocol. Other interfaces can define their own and feed into the same parsers.
On the serial buffering... any command that expects a response from the Base Station *should* be waiting for that response before transmitting the next command... This would not exactly have the effect of pacing things out, but should at least make sure the Base Station has completed one operation before receiving the next...
True but reading a CV is an async operation as I read it and has callback values which should be unique for that CV read. As long as JMRI doesn't blast say 5+ CV reads concurrently it should be ok. When I switched over to the ESP WiFi which has internal buffering before passing off to DCC++ or back out to WiFi I was able to do a full sheet read on the CV tab in a bit over 5mins I believe it was. This was on an ESU LokPilot Micro though. I will retest again with an ESU LokSound to get a larger reading (this was one that ran for 12+ hrs on serial and I gave up on it!)
Mmm... I'm not seeing that... in PacketRegister.cpp, RegisterList::writeCVByte() for example, it sure looks like it loads up the registers, sends the packets, watches the current monitor pin for the response pulses from the decoder, and THEN formulates and sends the response back to the client (JMRI). Since JMRI is (supposed to be) waiting for the response from each command before sending the next, the Base Station should not be handling more than one thing at a time, and the traffic should be paced by the time the Base Station needs to process each write (or read) in sequence. Note the use of "should" and "supposed to be"... And yeah, particularly on those sound decoders with tons of CVs, readback takes FOREVER. It's a DCC thing, though, not a DCC++ or JMRI thing.
Yes, writes are for sure a SYNC operation. Reads though maybe not so much. I was seeing JMRI blast multiple CV reads across the serial line and then failing and not recovering gracefully. Such as a writeCV to the index registers being done possibly out of sequence and one failing and JMRI happily moving on to a readCV operation without any regard to the failed writeCV that is required for the readCV to get the right values. Perhaps with your modifications to JMRI to sequence the readCV/writeCV or perhaps even more generalized as write a packet, wait for response... maybe that will solve some of the issues that I was seeing as well. I plan on testing the WiFi "read all sheets" for the same LokSound loco later today possibly. I suspect a lot of the slow issues i was observing was not so much DCC but JMRI and DCC++ fighting over which writeCV/readCV was going to be used and JMRI failing to get an expected response in a timely manner and moving on anyway.
Reads, on the Base Station side, use the same code pattern as Writes... they should be completely synchronous. This is not expected behavior. JMRI should be waiting for the response before sending the next command. I'm looking into that, but have only gotten as far as "JMRI should be waiting..." Now THIS is expected behavior, though it may not be what we really want in this case. JMRI has a timeout value (used to be 5 seconds I've bumped it to 10). when the timeout hits, it will stop waiting for a response. I believe it is supposed to post an error to the user when this timeout trips, instead of happily going forward... but that doesn't mean that's what is actually happening. More clues...
Mark Pardon my jumping in and possible naïveté but I am curious why you and Atani are pursuing this path. I have tested and have successfully connected my ESP8266 Base station stack thru a JMRI DCC++ Ethernet connection and using the Digitrains app (https://play.google.com/store/apps/details?id=hu.digitools.digitrains&hl=en) which fully integrates throttles, CVs, Turnout control and route control) using an Android phone or tablet and can wirelessly do everything (and more) than you are attempting. I have used Digitrains on my layout for years and find that it has full control thru JMRI. While I am a big fan of Steve Lowrys (UKSteve) ESP8266 throttle which does not require a computer in the system, I would think that for those of you who want to include a computer and JMRI I do not see why you would not try the Digitrains app and your existing DCC++ stack instead of reinventing the wheel, so to speak. Am I missing something? Steve F
JMRI provides a lot of benefits, especially for programming decoders. The problem is the current JMRI code does a few things that are not ideal in all situations and Mark is trying to improve that experience. I have an interest in having it working smoother as well. This is certainly interesting and is an option for those that want to use that. I have also successfully tested JMRI using my ESP bridge layer (similar to what Steve put together, also doesn't require a computer).
Steve, I'm not sure you responded to the thread you meant to... this thread is all about identifying and fixing bugs and missing features from JMRI's existing support for DCC++. We're not inventing anything new, and the bug we are currently focused on appears to be a problem with serial -- not network -- connections.
Mark, your right ... wrong thread ..... I was referring to the discussions on throttle development. The work you do on JMRI is exemplary and I in no way meant to diminish that.
Thanks. I'm not so sure about "exemplary" ... after discovering the root cause of several of these bugs, "extraordinarily stupid" might fit better* ... but I appreciate the compliments! * That's the nature of code bugs... they almost always turn out to be something that appears "stupid" in retrospect... so don't worry that i'm "down on myself or anything like that" ... 'tis the nature of the beast (software development)
