I've not yet used an Ethernet board with an Arduino but from what I can see in the specs for the Arduino Ethernet Shield, there may be a conflict with DCC++. The Ethernet shield (and similarly, the WiFi shield) uses the SPI bus for communication and this in turn uses digital pins 10, 11, 12, and 13 on the UNO. Unfortunately, this is smack in the middle of the DCC++ signal generation (pin 10), the motor shield direction inputs (pins 12 and 13), and one of the motor shield signal enable pins (pin 11). -Gregg
Steve, I tagged the existing DCC++ Controller code as release v1.0.0 and made some initial changes to the cab buttons that allow for run-time edits as you requested. To change the cab number associated with one of the cab buttons, right-click on the cab button and it will change to a white editing box. Click the editing box to activate. Then edit the cab number to whatever value you want. When finished, hit RETURN: the new cab number is saved and the editing box closes. If you want to exit without saving hit TAB instead of RETURN. Note that if you right-click multiple cab buttons, each will change to a white editing box, but only one can be active at a time (clicking on any one editing box makes it activate, and de-activates, but does not close, any other editing boxes). These changes have been uploaded GitHub -- please give them a try and let me know what you think. Also note that unfortunately cab number edits are not yet saved when you quit the Controller program. I have to give some thought to how to keep track of these in the XML status file. Just keeping track of the cab numbers would not be that difficult but it doesn't really make sense to store user-defined cab numbers with a series of hard-coded cab function buttons. In other words, I think it's "in for a penny, in for a pound." I'll need to come up with a generic way of letting users add and edit functions buttons, and store all of that info along with the cab number in the XML file. Probably won't be able to get to this for a while, but hopefully the changes posted will help out a bit. -Gregg
Good update Gregg.....I will have to try it out...I've already done that with my own home brewed GUI....when the GUI starts you can add 2 locos at a time as this is based on the digitrax throttle....and each loco is saved to a flat file database....when each function on the throttle is selected it corresponds to the correct locomotive: lights, bell, horn etc. I have to finish up with the throttle itself for speed steps to accelerate/decelerate...that should be done soon and load testing will begin this weekend on the demo layout at the mall Christmas show.
(1) PWM=1 means 100% PWM. (2) at 4A, an L298 is going to need a pretty big heat sink and/or some active cooling (3) I figure you will connect the direction inputs to the driver board to the two timer outputs from the Arduino (pins 10/5 Uno or 12/4 Mega), and then either tie the PWM inputs high or connect them to unused Arduino pins that are driven high. This should give you full power output with the direction controlled by the Arduino. Good luck!
Gregg Genius! ........ Works like a dream ...... Thank you for addressing this so promptly. Once again, I am a happy puppy. Steve
TwinDad I was anxiously awaiting some kind of JMRI interface ...... sorry to see that it will not make the next release ...... stay on it, as it opens up DCC++ to the use of so many established GUIs ..... Steve
The Ethernet code is too big to fit on the Uno. On the Mega (and maybe on the Uno as well?), the newer Ethernet shields use the ICSP pins for the SPI bus, so pins 11-13 are ignored. DCC++ doesn't use Pin 10 on the Mega, so it appears the only conflict for the Mega is Pin 4, which is the SD card chip select on the Ethernet shield and the Program track DCC++ signal. For that, I wonder if we could move the Program output from Timer 0 to Timer 3 on the Mega?
JMRI 4.1.4 will support the V1.0 interface. I just don't know if I can get the V1.1 changes made, tested, and merged before they cut 4.1.4. It's already late, due to some unrelated problems the other programmers have run into, so I'm on borrowed time, and the holiday weekend is looming. Which raises a question; Should I make the JMRI code detect and support both V1.0 and V1.1 messaging, or just drop the V1.0 support starting with JMRI 4.1.5? I think I can handle this particular set of differences. It's the precedent I'd be setting that concerns me going forward long term. If the V1.0 interface is already effectively obsolete, i'd prefer to drop it, but later on there may be major interface changes that we want to suppor
I Found another sales add on http://www.amazon.com/RioRand-Controller-Circuit-H-bridge-IRF3205/dp/B00MGESELA its information was the same except stop barke dir=x pwm=0 which would make sense that would be regenerative braking turning the motor into a generator. The l298 is already 4A its 2A motor 1 (main track) and 2A motor 2 (program track) if setup as 1 output it would have the same limit of 4A max but only 1 output. If i understand the code right for DCC++, the signal enable or turn on pin is pwm pin at %100 or +5v and the two pwm output pins 10/5 or 12/4 are 10 or 12 for main track and 5 or 4 for the program track to control the direction that makes the pulsed signal. The l298 is using a logic inverter chip built in so when half of 1 bridge is set for positive the other has to be negative and vice versa so there is no possibility of a dead short due to programming or wireing errors. The same can be done externally with a 74hc1g04 its a single channel inverter, 1 side of the h-bridge is hooked to the input pin directly the other is hooked the input thru the inverter chip. Thank You I"ll need it. I easily get addicted to diy tech projects. I can easily envision My layout Running on a DCC++ Base Station with a local Throttle based on a arduino that is capable of sending commands to the DCC++ directly or used as a serial throttle to a PC running JMRI. Maybe arduino RFID stickers in the locos and cabooses for tracking the train and triggering events like lights in houses and rail crossings. Using JMRI and RFID to trigger a Video Projection Mapping animated background at the trains location of snow falling or water running and smoke coming out of chimneys or smoke stacks. The possibility's are endless...
That's a very good idea. I think Timer 3 on the mega has the same parameters as Timer 1 and I should be able re-assign as an option. I might as well make it generic so you can pick which timer to use and thus choose from a selection of output pins.
Yeah, but you still have to look at the thermal situation. It has a max junction temperature of 130˚C. With the Multiwatt package used on the Arduino shield (at least the SparkFun Ardumoto version), the thermal resistance from junction to ambient is Tja = 35˚C/W ... Working backward from an ambient temperature of 25˚C and no heat sink, the max current output at 12V is really only 250mA. Total. For both channels. (P = (130 - 25)/35, I = P/12V) The situation is somewhat better with the Power SO20 package (13˚C/W), which works out to 673mA max. Total. For both channels. That's enough to run a couple of N scale locos, but nowhere near 4A, I'm afraid. Without a heat sink, you're not likely to get 4A out of an L298 without smoking it. The outputs can be paralleled, but that's not really going to change the thermal situation. Other drivers will differ somewhat but will have the same limitation, just different numbers. You really need a heat sink and/or some active cooling to get serious current out of these chips.
I agree completely, but that would also mean that in 2 full bridge mode without cooling, it would only handle 336.5mA each for the main track and the programming track at 12v. That's why i was worried about 2/4 amp limit of the board for HO scale. The HO scale nce-d135 decoders are rated at 1.2A with a 2.0A stall each, meaning 1 loco at best or maby 2 if bridged providing it does not overheat. My actual thought was to bridge one just for the programming track for ho scale. I'm looking into the parts to make a dual h bridge for higher amps using power mosfets and a h-bridge driver to meet the need, using thru-hole parts so it can be a DIY for people to make themselves. The mosfets in the one i referenced are actually 110A and 55v with a max of 200W, but closer to 8A at 18V without cooling (I didn't do the math for the cooling) but that should run 4 HO scale trains at stall current of 2A ea. I understand that all the spec #'s are the limit and 200W for the irf2305 is the real number 50v@4A=200W as does 2v@100A=200W. My eyesight probally would not allow for n scale modeling for long and besides if the cat got on the layout it would look like the old godzilla movies.
Gregg, this would be great. I'm trying this with the Mega and some other motorshield and there's a buzzer on pin 4 where the pwm signal for the prog track is going. Would it be possible to change the output of Timer0 to pin 13, which should be on the same timer? This way I wouldn't need any wires at all!
The outputs of the Timers are actually hardwired into the chip itself and unfortunately can't be changed. However, by using a different timer we can generate signals on alternative pins. On the Uno, Timer0 generates the PWM we need on pin 5, and on the Mega this is on pin 4. But since the Mega has 3 additional timers we should be able to use one of them instead. It will require a little bit of code-changing (above I compared Timer 1 to Timer 3, but that was the wrong comparison --- it should have been Timer 0 to Timer 3). Timer 0 uses an 8-bit counter whereas Timer 1 (and 3/4/5 on the Mega) all use 16-bit counters. In moving the Prog signal to Timer 3, 4, or 5, I'll also need to put some logic in the code to change all of the configuration parameters to reflect the correct settings for a 16-bit Timer (which I will simply copy from the Timer 1 settings). I should be able to do this over the weekend. ALSO...in reviewing the ATMEL hardware timer specs, I realized that on the Mega, Counter Timers 1, 3, 4, and 5 have not 2, but 3 matching registers. On the Uno each timer (including Timer 1) only has 2 matching registers. Why is this important? Because DCC++ used one of the registers (register A) of each timer to dynamically control the timing of the DCC zero and one bits. And it used the second register (register B) to trigger the corresponding pin to flip from a HIGH state to a LOW state with a 50% duty cycle. This is what creates the DCC logic signal. And it's why we need to use a motor shield that has a small circuit to convert this single logic signal into two signals (one opposite of the other) to control the H-Bridge. This is why, for instance, you may not be able to use some of the higher-current motor shields that don't have this circuit built in. BUT...with 3 matching registers per timer, in principle I could configure the counter to use register B for producing there usual DCC logic signal, AND use register C to produce an identical but opposite signal on another pin. These two signals can then be connected directly to motor shields that do not have the needed built-in circuit. Food for thought over a weekend to be filled with a lot of food! -Gregg
Not quite working... So I'm trying to test my JMRI implementation with a live setup. I have: * Arduino Mega 2560 connected via USB to the host * SeedStudio MotorShield V2.1 atop the Mega. * Pin 4(Mega) jumpered to Pin 13. * 5V power disconnected between Mega and Shield. * 14V DC power to the Motor Shield * Program track connected to Motor B outputs. * Known-good DCC locomotive on the track. Here's what I'm seeing: * With the loco OFF the tracks, I'm only reading about 0.35V AC with a meter. * With the loco ON the tracks, when I try to read CV8 & CV9 I get 255 for the response value. * All of the data going back and forth between JMRI and the Mega appear correct (except the 255 read value). * The above was verified using the Arduino Serial Monitor. * I also tried with an ArduMoto shield... similar results. Advice?
In other news, I have a tool written (under test right now) that will allow the user to add and delete Sensors on the Base Station. I will add Turnouts as well. It queries the Base Station for the currently defined Sensors, shows a list of them in table form, and allows you to add, delete, or change them, then write back to the Base Station. This function will be in 4.1.5 which should only be a week or two. Raises a question: What about *changing* a Sensor/Turnout? Right now, I handle it by issuing a Delete and then a new Add. Do we want to implement a Change command?
The seeedstudio shield is not going to work. It is quite a bit different from the Arduino and Pololu shields. It uses in1-4 instead of direction, and its pins are different at that.
That's correct - the Seeed Studio Motor Shield requires two pins per channel to drive the direction. I'm going to see if I can create that on the Mega using a the third register on Timers 1, 3, 4, or 5.
TwinDad/Gregg I have a similar setup as you do , except I have an Arduino Motor Shield (I am using Greggs latest Base Station sketch) ...... everything works with Greggs Controller sketch GUI and Processing 3 ........ when I run JMRI (DCC++ connects to the Mega on Comm 4) ..... I get no power (no A/B power lights on the Motor Shield) and the JMRI throttle freezes with no output to the track. JMRI Power Panel shows "Layout power state unknown". BTW is it me or is the latest test release of JMRI very very slow in response? Steve
