Mike, when you set COMM_INTERFACE = 1 and open the Arduino Serial Window, the code should respond with an initial message showing the IP address (if you are using DHCP it may take 10-20 seconds before the full message with the IP address is shown). After that message is written, all communication is then via the ethernet -- you can type things into the serial window but they are ignored by the Arduino. I could probably create a serial diagnostic that indicates when a new connection is made from an external device. Need to check the library to see for certain. In the interim, is the initial status message appearing in the serial window, and if so, does it show the correct IP address? -Gregg
I picked up an 1156 tail light today and tried the same tests I did with the circuit tester probe. Unlike the probe, the tail light never lights up and the Pololu shuts down. I'm resigning myself to not being able to use an AR or power districts with the Pololu. If someone else wants to take a crack at it I'd love to hear their results. Note - the EB1's lowest trip current is 2.5A so it wouldn't work with the Arduino Motor Shield which only outputs up to 2A. The AR1 has a range of .25-8A so I suspect it will work just fine with the Arduino Motor Shield. I have not tested the AR1 with the Pololu.
Pololu Mapping Update: I just uploaded a new "beta-version" of the Motor Shield Mapping PDF to GitHub (under DccPlusPlus/Documentation) reflecting revised recommendations. With the exception of the two jumpers needed to connect the DCC Signal Pins to the Motor Shield Direction Pins, the mappings are identical for both the Mega and Uno. In both cases the recommendation is to cut traces #10, #4, and #12. We originally needed to cut #10 on the Pololu for Uno to avoid a conflict with the DCC Main Track Signal generation pin. Cutting it on the Pololu for Mega is also a good idea to avoid potential conflict with an Ethernet Shield (that always seems to use pin 10). We originally needed to cut #12 on the Pololu for Mega to avoid a conflict with the DCC Main Track Signal generation pin. Cutting it on the Pololu for Uno is also a good idea since we are going to eventually need to re-map the SF signal, which was on pin #12, to another pin that is monitored for short-circuit triggers by the Base Station (not yet implemented, but hope to be in a few weeks). We originally tied pin #4 high on the Pololu for both the Mega and Uno. This is the D2 Motor Shield Master Enable (there is no equivalent on the Arduino Motor Shield). It needs to be HIGH for the board to be enabled. BUT... we have learned that it needs to be toggled LOW and the back to HIGH to reset the fault/short detection circuit embedded in the Pololu. Rather than have to cycle the power on the whole stack, we need to move the D2 signal somewhere else where it can be toggled LOW and then HIGH. The recommendation is to jumper this to pin #9, which is the SIGNAL_ENABLE_MAIN pin. Base Station turns this pin on and off in accordance with the <1> and <0> commands. Now instead of controlling just the motor shield output for the Main channel, it will also control the D2 signal, allowing recovery from a Pololu internal fault condition by issuing a <0> and then a <1> command (note that until we find a new input pin for the SF signal that was tied to pin 12, and add some code to monitor this pin, we won't be able to auto-detect an internal fault on the Pololu -- the trains will just stop running!). -Gregg
Gregg and Team. I have a Leland Arduino UNO RV3 $5.99 and Original Arduino Motor Driver $4.85, 15Vdc 1amp setup running JMRI 4.3.2 and Engine Driver 2.11 on a Samsung Galaxy that's working great so far. Thank you. Looking at this from an mature DCC industry and client point of few regarding throttles. In the future it would be nice to have some backward compatibility to say the top four wired throttles. DCC++ is my first adventure into this arena and I'm the first in my club (31 members) to use it. 80 % of them use one of the DCC mfg below and their astonished and excited to see what you have done with DCC++. Their first question is can I run my current throttles? An over simplified vision; Have a DCC++ Wired Throttle Controller manage a Bus Strip that has maybe four Female plugs, one from each vendor i.e. Digitrax, NCE/MRC, Lenz, ETC. This strip would allow a visitor to bring their favorite throttle over, plug in and run on our DCC++ Base Station. If not directly connected to the Base Station the Bus Strip would be connected to a second UNO or AT Tiny85 i.e. DCC++ Wired Throttle Controller which would act like a throttle manager keeping track of which throttle made a request and package it and send it to the Base Station via a direct piggy back wired or a IP Ethernet network connection. The DCC++ WiredThrottle Controller could offload the DCC++ Base Station from this work and in essence act like a Serial Router on one side and a IP node on the other . Maybe this throttle register could come in handy and help keep track of the throttle characteristics in the Throttle Controller. When you add up the costs of existing user inventory the DCC Throttles tend to be the larger DCC expense (excluding decoders) over the base station. Again this is a high level view and food for thought and free time down the road. Thank you and your Team for All your Hard work, Kevin
Okay - give this a try: Line 313 of SerialCommand.cpp reads - Code: INTERFACE.print("<p1>"); Directly below this line add a new line - Code: Serial.print("<p1>"); With the Base Station set for Serial mode, issuing a <1> command should result in a duplicate response of <p1><p1> in the Serial Window. With the Base Station set for Ethernet, sending the <1> command should result in a single response of <p1>. If you don't see the response, the Ethernet connection is either not working, or the <1> is not being correctly issued. If you do see the <p1> response but the motor shield does not turn on then something must be interfering with the pins, perhaps from the Arduino Ethernet library (I've only tested things with the Wiznet 5200 and Wiznet 5500 chips and their corresponding libraries). One other thing to check if you don't get a <p1> response -- the PORT settings. The default in the Base Station software is 2560.
so using a Motor Shield -- total amps = (value / 1023 )* 3.0303, where 3.0303 = 5/1.65 - for example = 338/1023 * 3.0303 = 1.001214 or 1.00 amps as mentioned above. Oddly, my Motor shield is shutting down at value of about 260 or so ... need to due more checking .. .but that is only 0.75 amps or so ... any thought? Just a note of interest/caution - the latest version (v1.2.1+) - defaults to the Pololu Shield .. easy to change -- just caught me off guard Gregg - Keep up the good work ... and thank you for your effort !! Thanks Paul.
Whoops - good catch Paul! I just updated 1.2.1+ so it defaults to the Arduino once again. And yes, your formula is correct. Simplified, the conversion is 2.96 mA per unit of value when using the Arduino Motor Shield on a 5V Arduino Board. Not sure why the board is shutting down at a value of only 260 but it may be spiking up to the 300 max. Try raising CURRENT_SAMPLE_MAX in CurrentMonitor.h from 300 to 600 (should still be fine at that level). -Gregg
Gregg, Confirmed that JMRI has the port set to 2560 (JMRI indicates the IP and port it is connected to). Confirmed that when set for Serial mode, I see <p1><p1> in the Serial Window. When I click the On button in JMRI, nothing shows up in the window. I punted and tried adding Code: Serial.print(c); after line 66, hoping to see if something was coming in but improperly formatted - I saw nothing when I clicked the On button in JMRI. I added an else to the Code: if(client){ section to print "no client" - I get a steady stream from that so the line Code: EthernetClient client=INTERFACE.available(); apparently isn't returning anything even after JMRI says it has connected.
Thanks for the suggestion ... I have an old engine and the motor draws a lot, and has poor contacts ... a candidate for an new can motor. Will revised the value ... and continue testing my Client Program. Paul.
Hmm... You should be able to Telnet into the board at its given IP address and port number, to confirm that you can connect to the Ethernet shield. You'll just have to type in the commands properly formatted by hand. If JMRI is changing the color of the Power button between Red and Green as expected, then it is receiving the responses from the Base Station. If the button is remaining in the "Unknown" state (yellow), then it is not. In the Monitor pane, if you see the line "Power Status: ON" (or OFF) after clicking the power button, then JMRI is receiving replies from the Base Station.
In other news, I've wired up my 2A 5V power supply (arrived in the mail yesterday). The bad news is, it didn't fix my problem. A bit more Google searching has turned up another possible root cause... apparently a thermal/performance problem with the 74HC4050 buffer chip on the board (actually apparently it's a problem with counterfiet 74HC4050 chips on some boards...) ... I'll get hold of some freeze spray and test it out ASAP. If that is the case, I'll have to replace the chip... another few days waiting for DigiKey to deliver...
Using Gregg suggestion to revise the CURRENT_SAMPLE_MAX to 600 (from 300) solved issue of Motor Shield shutting down without notice. Able to get two engines working with Client LCP_working_v2 by tz3p9v posted Jan 17, 2016 at 10:29 PM Paul.
TD, I had no idea you can just telnet directly to the board! Thought I would need to have a telnet service of some sort in the software. But it works perfectly! Just opened a terminal screen and typed telnet 192.168.1.169 2560 and I'm communicating with board just as if I opened the serial window. This is very cool. Thanks for the tip! Mike, when I first re-loaded my code to set my Arduino to use the Ethernet shield, it looked like it worked but the DHCP IP address I received seemed strange. I think almost all DHCP within a home network should begin with 192.X.X.X, so when I received a random-looking IP address I thought there might be a problem. Then I realized I selected the wrong COMM_INTERFACE. I set it to 1 and it should have been 3 (I'm using the SEEED Studio Ethernet Board). When I changed to 3, it then worked fine and I received my usual 192.168.1.169 address. But there were no other symptoms of a problem (except that I could not connect using telnet). From the perspective of the Arduino, it looked like everything was working, even though I had selected the wrong library. Are you using DHCP to assign your IP Address? If so, are the first three bytes the same as the other components on that network (only the last should be different). If not, then I suspect there is a library mismatch between whatever library is selected and your specific Ethernet board. -Gregg
The issue seems to be isolated to JMRI. I can connect via telnet and toggle power. JMRI 4.3.2 shows that it connects but the power button is always in an Unknown state and the Monitor pane shows no responses.
Okay, so at least the problem has been isolated. TD, the only change made to Base Station recently has been in the status message upon initialization and as returned by the <s> command --- I added in a version number and deleted the word "BUILD." I only mention this in case JMRI was reading that info and is expecting a very specific format of these messages.
Ethernet cable is perfect.....I've been working on an RFID program and the hardware will be using ethernet cables to communicate with the master Arduino and the RFID scan heads
I had to map pin 10 to pin 11 using the UNO as well....this is documented at the very beginning of this thread as I was the only one at the time using HO Scale and everyone else posting was using NScale and I needed a heftier motor shield to drive HO Scale trains.
Gregg With no jumper on pin 5 Serial Monitor shows a blank IP address ...... Jumping pin 5 to ground and inserting an IP address in config.h (removing commenting) … program reports “ IP ADDRESS: 0.0.0.0 (STATIC) but not the IP address entered. Could this be becauseof the Arduino WiFi shield (waiting for Ethernet shield) Steve
That's correct. The only interface types implemented in the current version of Base Station are Serial, Ethernet using the W5100 chip, Ethernet using the W5200 chip, and Ethernet using the W5500 chip. Each of the Ethernet chips requires its own library and that is automatically selected based on the COMM_INTERFACE parameter. Using a WiFi board would require two changes to the code. The first is the addition and selection of that library via a new COMM_INTERFACE option (and a corresponding code change to select that library in the Comm.h file). The second is some new logic that initializes the WiFi. Though the currently-supported Ethernet libraries all use different chip-sets, their library APIs are identical (only their inner workings are different) and the same code to initialize the board, get an IP address, and communicate is used in Base Station. Makes it easy to add a support for a new Ethernet library. But WiFi is different. We not only need a shield-specific library but also need to add code to store the SSID of the WiFi network you are trying to connect to, store and send the WiFi password, etc. It's only a few lines of new code, but it's not presently in Base Station. When you run diagnostics in Base Station, the IP Address reported is based on what the board thinks its address is, after initialization. It does not just echo back the address you specified in Config.h. This is why you are getting zeros - a confimation that the board is not in fact being correctly initialized. I do not have a WiFi shield but if you are willing to experiment a bit, I can add what I think the code should be and you can try it out on your system. I'll need to know the exact model of the WiFi shield you have so we can ensure the right library is being used.
