Again, @Keith Ledbetter requested that we separate hardware and software threads, and here is the software thread. Let's bring the discussion over here.
Hi all, I know that JMRI is the "preferred" controlling software, but as Rocrail also has implemented support for DCC++ base station, and I'm one of the thousands Rocrail users. here are my results of DCC++EX testings. So I downloaded the sketch and compiled/transferred on ArduinoUno/ArduinoMotorshield Launched Rocrail loading my test workspace configured for DCC++ No OK! response from serial comm In the rocrail log (trace) file, got these lines about controller: ... 20200429.091226.061 r9999I main OControl 2842 devices: "" 20200429.091226.062 r9999I main OControl 2321 initDigInts lib=[dccpp] iid=[DCC++] 20200429.091226.063 r9999I main OLib 0038 rocs_lib_load OK [C:\Users\Suppi\AppData\Local\Programs\Rocrail\dccpp.dll] 20200429.091226.063 r9999I main OLib 0052 rocs_lib_getProc OK [C:\Users\Suppi\AppData\Local\Programs\Rocrail\dccpp.dll:rocGetDigInt] 20200429.091226.064 r9999I 0000020C ODCCPP 1237 ---------------------------------------- 20200429.091226.064 r9999I tick0266 OSystem 0103 Ticker thread has started. 20200429.091226.064 r9999I 0000020C ODCCPP 1238 DCC++ 2.1.0 20200429.091226.065 r9999I 0000020C ODCCPP 1239 IID : DCC++ 20200429.091226.065 r9999I 0000020C ODCCPP 1240 nr.slots : 12 20200429.091226.066 r9999I 0000020C ODCCPP 1241 sensor off delay: 0 20200429.091226.066 r9999I 0000020C ODCCPP 1242 sublib : serial 20200429.091226.066 r9999I 0000020C ODCCPP 0092 device : com4 20200429.091226.067 r9999I 0000020C ODCCPP 1262 ---------------------------------------- 20200429.091226.067 r9999c usbreade ODCCPP 0019 DCC++ USB reader started. 20200429.091226.067 r9999I main OControl 2388 send sensor list to digint... 20200429.091226.068 r9999c dccpprea ODCCPP 1167 DCC++ reader started. 20200429.091226.068 r9999c dccppque ODCCPP 1093 DCC++ Queue writer started. 20200429.091226.071 r9999I main OControl 2407 initDigInts OK 20200429.091226.072 r9999I main OPowerMa 0601 Power Manager instantiated. 20200429.091226.072 r9999I main OControl 0188 Init short circuit sensor... ... 20200429.091226.181 r9999I usbreade OSerial 0085 Opening serial[com4] [return code=0] [0] [OK] 20200429.091226.181 r9999I usbreade OSerial 0106 blocking[1] directIO[0] ... On the practical side, no power on/off to track/prog on motor shield, so no loco controls at all.
Hello Ciro. First let's test the hardware setup to see if it is responding. How did you upload the sketch? Did you use the Arduino IDE or our Installer? Did you make any changes to the config.h file? MOTOR_SHIELD_TYPE and COMM_INTERFACE should both be "0" What voltage are you using? Did you cut the trace on the motorboard "Vin Connect" if you are using more than 12V to the motor shield? Do you have a 5V power suppy on the Uno and another one connected to the motorboard? Are your jumpers set with one connecting pins 13 and 5 and another connecting 10 and 12? See here: https://wiki.rocrail.net/lib/exe/fetch.php?media=dccpp:dccpp-motorshieldpinmappings.pdf Use a serial monitor like the one in the Arduino IDE. You probably already have the correct com port and baud rate of 115200. When you connect with the serial monitor, you should immediately see the boot information with your Arduino type, the motor board name and the software version. Does that work? You can turn off power connect pin A5 to ground, reboot and get more information from the serial monitor to check all your settings. Remove the A5 jumper and reboot. Next, Enter "<1>", so a less than symbol, 1 and greater than symbol. You probably already know this too, but I just want to make sure you know all DCC++ commands are entered with these brackets around them. As soon as you enter <1>, all 4 lights on the motorboard should light. do they? <0> will turn off the power and all 4 lights will go off. There is also the D command here: https://github.com/DccPlusPlus/BaseStation/wiki/Diagnostics---D---Command. But let's see what the above does for you. I don't know anything about RocRail, so I hope someone else can help there. Looking at your log it DOES look like it is reading from DCC++ because it picks up the name and the number of registers.
@FlightRisk I forget to mention that I already use DCC++ standard Gregg's basestation within Rocrail and I'm happy with this 'til now. I just wanted to test DCC++EX in order to contribute to the developing. So, I modified config.h in respect of my Hw, so: register=12 motorshield=0 and comms=0, I think was right. The rocrail log trace file I mentioned was reporting as stated. There were no response at all even power on/off of system.
That's why I was thinking something went wrong with the upload to the Arduino. We need to test with the serial monitor if manual control works. There are no changes in DCC++ EX and Gregg's DCC++ that would cause the simple function of power on and off to break. If Rocrail sends a "<1>", power to the motorboard will turn on. I don't know if Rocrail is looking for anything else. I don't know how to read that log because there is no error and no raw data for what it sends to DCC++ and what it sees back. Thank you for joining us and wanting to help! Check using the Arduino serial monitor and let us know what happens.
Editing this post. I was about to give up after an hour of trying every menu option I could find and reading through the online documentation and finally figured it out. It works fine for me. I figured out that one of the two preference menu items, the rocrail one, had a controller tab, there, you can click on a dropdown and add a new device and select DCCpp. The software apparently does not read the operating system for available com ports. It defaults to com1, which is just text, not a source list. I had to go into another piece of software to tell me what com port my Arduino Mega was using (com3) and then go back into rocrail preferences and change it. I just clicked modify and typed in "com3". The log showed me it was still trying to do things on com1. So I restarted everything. Then I went to the menu where there is an item for "power on" and clicked it. It worked. I don't know how to do anything else yet, but I can turn the power on and off There are things I don't understand, such as 3 lines in the log for something dccpp related that says "not ok", and when I turn the power on it gives error 144 and a different error when I turn power off. It works though. I turned echo commands on hoping I would see more, but I didn't. I realize now that if we change anything regarding the return messages, we have both JMRI and Rocrail that we are also going to have to make changes to. In particular, if we go with our change to report current in milliamps and some other things in response to the "get current" command (<c>), those other programs will have to know how to parse the extra pieces of information
@FlightRisk Now I just tested the IDE serial monitor with DCCppEX sketch uploaded to the board. this is the first line I got: <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 1 2020 12:11:06><N0:SERIAL><Q -15865><Q 311><q 8ØK><Q 0><Q 0><Q 0><q 8250><Q 0><Q -2042><q -15865><q -2042><q 0> giving <1> I got: <p1><q 16248><Q 1341><Q 14>⸮<Q 31493><Q 0><Q 0><Q 0><Q 0><Q 0><Q 0>⸮⸮or <p1><p1 PROG><q 30564><q 30757><Q 0><Q 1792><Q 0⸮<q ⸮<92><Q 0><Q 1792><Q 0><Q 0><q 1792> giving <0>: =p0or <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 1 2020 12:11:06><N0:SERIAL><Q 1341><Q 0><Q 0><Q 0><q 20992><Q 0><Q 6><Q 20992><Q 0><Q 1596><Q 0><q 20992><q 0> Indeed the response at commands are unpredictable, sometime leds switched ON at <1> sometimes not. They never switch OFF at <0> command. Re-uploaded base station DCC++ Gregg's original and these are results: <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-1.2.1+ / May 1 2020 12:05:58><N0: SERIAL><Q20><Q21> giving <1>: <p1> giving <0>: <p0> Leds on motorshield switched ON/OFF in accordance.
I'm now reading on page https://dcc-ex.github.io/starter-kit.html that Mega (or clone) board is required. I have a Uno.
NOOOOOO! Thank you for catching this. We were starting on the web page to create a "Starter Kit" and try to settle on a "recommended" base system. With Mega Clones for 8$ US, there just isn't reason to buy an UNO when the MEGA gives more memory, pins, etc. However, we know the UNO is a good board and many people just have them lying around, so we want to keep supporting them. I will change the page to add you can use an UNO. So you have 2 sensors set? That seems to be the difference in what I tested. It looks like the sensor detection is too sensitive. Rocrail doesn't know what to do with all those sensor readings going out the serial port. Did you save those sensors in EEPROM? Are they connected to anything? Clearly something is wrong because the code that reads the sensors in the loop seems to be seeing floating pins. It is reading the all sorts of transitions from high to low and back for random sensors. I will take a look and get back with you UPDATE: Is this the SAME board or are you using two UNOs, one with DCC++ and one with DCC++ EX? We suspect something with EEPROM needing to be cleared, but that wouldn't necessarily explain the same board working with the old code. The routines are identical. In the main loop, we check the sensors. If any are set, we out put a "Q" message whenever a watched sensor changes state. Those are garbage messages. The backwards question marks don't belong there either.
I'm in the way to buy a Mega board due to more input pins needs. The board I'm using is 1 and works good with DCC++ (very good) and Rocrail. When I upload DCCpp_EX things are not going as well. I will try to erase EPROM for sensors I defined with Rocrail (do there is a command to erase EPROM within serial monitor?). Indeed, even if I defined more inputs than the board supports, it never hangs with DCC++ standard.
The "garbage" in the string bothers me. Why are some closed brackets ">" missing? Where are the ? marks coming from? To erase EEPROM there are a few ways: In DCC++ and DCC++ EX: < e > Lower Case e: Command to Erase ALL (turnouts, sensors, and outputs) definitions from EEPROM in Rocrail https://wiki.rocrail.net/doku.php?id=dccpp:dccpp-en and the sure fire way to put zeroes/zed in all EEPROM memory: https://www.arduino.cc/en/Tutorial/EEPROMClear
EEPROM cleared with the arduino.cc sketch Loaded DCCpp-EX sketch In serial monitor got this: <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 1 2020 19:01:30><N0:SERIAL> giving <1> <p1><p⸮ > giving <0> <p0><p MAIN><p > Leds light ON after first <1> command, lights OFF after first <0> command, then always ON, with a little blink on giving either <1> or <0> commands. Resetting board gives different response to power ON/OFF commands they vary from: <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 1 2020 19:01:30><N0:SERIAL>in a loop mode, with lo led activity, or <p0><p PROG><p >when giving <0> command. Anyway looks like it is not usable with Rocrail. When I revert to DCC++ classic all things go ok.
Are these commands coming from Rocrail or are you using the Arduino IDE for your tests? Are you connected to the tracks with Rocrail running? If so, what happens if you disconnect the Arduino from the tracks or make sure it is not on and running? I have been using this build with JMRI and had no issues so I went into the Arduino IDE to play for a while with the serial monitor. I know everything points to the code since when you upload DCC++ it works, but it makes no sense! If I ignore that it works with DCC++ Classic, I would say it is a bad cable or a bad build or the baud rate is not 115200. Or maybe a bad download of the code? I wish I had an UNO to test to see if things would be different. I am using an Elegoo Mega clone. But look at what you are seeing. You enter <1> and get <p1><p? >. So I see a "p" a REVERSE question mark, a space, and the closing bracket. I don't see how that is possible unless there is noise or something echoing on the com line. A <1> gets a <p1> back. Period. Nothing else. There is nothing that can cause that second response unless DCC++ EX thinks it got another command. Do you see a backwards question mark too, or is that something else on your display? When you give <0> you should get <p0>, nothing else. For you to see <p0><p PROG><p > points me to a difference between Classic and EX. We can handle multiple motorboards. At the same time. Technically, each channel is its own "motorboard". If you have configured only 1 physical board, we give you 2 channels, PROG and MAIN. They are named in the code. When you enter a <1> or <0>, we turn on or off both channels (tracks). BUT... If you enter <1 PROG>, it would turn on only the service track. But everything is still not correct! Something is going wrong on the serial line. EX is getting commands and responding to them that it should not. All the characters are not displaying. The response to <1 PROG> is <p1 PROG>. You are only seeing <p PROG>. That doesn't seem possible. Where did the 1 or the 0 go? DCC++ EX sends that in the same string; CommManager: Printf("<p1 %s>", name); What's more, and truly confusing, is that something had to know the name of the channel! The code does this: Is the length of the command 1? (<1>) then print "<p1>" else if the command is longer than 1 character (<1 PROG>) then find a channel that matches "PROG" turn it on print "<p1 PROG>" The only other possibility is that EX thinks it got an <s> command. But that would print all the other status information. Part of that is the status of all the channels you have enabled, so if the tracks were off you would see: <p0 MAIN><p0 PROG> There is no network connected to your Arduino?
@FlightRisk Not using Rocrail for these testings, just Arduino IDE and serial monitor, no tracks connected. Tried 2 situations, 1 with no power to the motorshield, 1 with power at motorshield. With no power, either <1> or <0> commands gives <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 1 2020 19:01:30><N0:SERIAL>as result on serial monitor with power on, <1> command gives <p1><p⸮ 1>⸮> and <s> gives <p1 MAIN><p0 ⸮><iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 2 2020 11:22:00><iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 2 2020 11:22:00><N0:SERIAL> <0> gives <p0><p1 MAIN><p1 ⸮> <s> gives <p0 MAIN><p1 ⸮><iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 2 2020 11:22:00><iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 2 2020 11:22:00><N0:SERIAL> <1 main> gives <p1 MAIN>or random <X>N>>AIN>1 MArandomly prog or main leds light on <1 prog> gives <X><p1 >or resetting board <p1 PROG>and no leds operating <0> gives nothing resetting board <0 MAIN> gives <p0><p1 PROG> <0 PROG> gives <p0 PROG><p0 MAIN>no leds activity <s> gives nothing It appears like resetting the board every time, makes the code accept the first command well, then goes crazy to subsequent commands.
One of the developers said it looks like data overrun. As if the code is corrupted somehow. Could you try to download it again and upload it? There is also the development branch you can try. A lot of us are using the the "master" branch that you downloaded and haven't seen anything like this. Also, don't change anything in the code. The default is an Uno, An Arduino motor shield, and serial communication through the USB port. So that should work for your setup. I also wonder if editing the config file could have inserted special characters into it that could effect operation.
Re downloaded the sketch, Compiled&Uploaded to Uno. No changes in config.h Serial monitor from IDE shows the following: at start <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 2 2020 18:08:41><N0:SERIAL> issuing <1> <p1><p1 ⸮ 4 leds power ON issuing <0> <p0><p1 ⸮ leds MAIN OFF, PROG still ON issuing <s> no answers, leds as above resetting board <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 2 2020 18:08:41><N0:SERIAL> 4 leds OFF issuing <1 MAIN> <p1 MAIN> 4 leds OFF issuing <0 MAIN> <p0 MAIN><p1 MAIN> 4 leds OFF issuing <1 PROG> <X><p1 ⸮> 4 leds OFF issuing <s> <p0 MAIN><p0 ⸮><iDCC++ BASE STATION FOR ARDUI 4 leds OFF resetting board issuing <1 PROG> <p1 PROG> leds PROG ON leds MAIN OFF issuing <0 PROG> <X><p1 > leds PROG ON leds MAIN OFF issuing <s> <p0 MAIN><p0 s><iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 2 2020 18:08:41><iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-2.0.1 / May 2 2020 18:08:41><N0:SERIAL> ----------------------------------- resetting board compile&upload DCC++_Uno.ino at start <iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-1.2.1+ / May 2 2020 18:26:52><N0: SERIAL> issuing <1> <p1> 4 leds ON issuing <0> <p0> 4 leds OFF issuing <s> <p0><iDCC++ BASE STATION FOR ARDUINO UNO / ARDUINO MOTOR SHIELD: V-1.2.1+ / May 2 2020 18:26:53><N0: SERIAL><X><X>
Last time I tested the EX (with UNO), It switched on for the first time and it did not take any commands. The ON state on JMRI Wifi client window goes to UNKNOWN (yellow) state. I will check this again with serial monitor ON and share my findings.. (Response to your PM) Sent from my GM1901 using Tapatalk
Ehm, I think there are dangerous waters around here. I just tested the current DCC++-EX git-master sketch on my UNO. That did not work, as reported above the serial commands are not doing at all what they should. I think when loaded on the limited RAM of the UNO there are undetected memory issues which break the code. Then I tried to debug by adding more Serial.print() to get the F command working again to determine the amount of RAM. Did not work. Yet worse, that code probably screwed my bootloader. because after that I counld not upload anything any more. Then I had the fun to take another UNO and with that reload the bootloader. That took several hours because I needed to tie up the reset pin of the programming UNO with 10k (which some recomended) AND use the 10uF capacitor against ground (which others recommended), one alone would not work. But now I am back where I was 3 hours ago and I don't think I will try the code again unless you use a Mega and analyse RAM usage so that we know the code really fits into an UNO. Now eat and sleep. Well well CU, Harald.
