Ignoring the DCC++ server (correct name??) for now, in order to get more small to medium clubs using the system, DCC++ needs to allow for multiple power districts (using an Arduino NANO, 8 analog inputs for current sensing are available). Without getting into the complexities of what Greg wants to do with the server, just a simple satellite device to receive the DCC signal and feed it to a motor driver board is all that's needed. To accomplish this, the most releiable communication would simply be a unidirectional RS485 connection for the DCC signal and the enable signal to the MD board. Greg wants to add all sorts of magic with multiple MEGA stations communicating and parceling out commands and responses, and although that's a cool goal, we really need something simpler....that also would require minimal effort to modify the DCC++ code to sense multiple MD current data and shut down JUST the district that's showing the overload. I'm an old C programmer who never really used any of the facy constructs available in the language, but just used it as a replacement for assembly programming. I used C to bit-bang code to control hardware, but nothing very fancy as compared to other people. So, with a little experience (20+ years with C), I started to attempt to modify the base code to simply only turn off the offending MD board that has reported the overcurrent condition, and not both the program and main outputs. I'm here to report my complete and utter failure to accomplish even such a seemingly simple feat, and it has now become obvious that my C coding experience cannot be applied th the C++ code. BUMMER!!! I can do hardware and the coding needed, usually, but since DCC++ is almost entirely written in C++ code, I need help. Greg seems to be busy, so I'm wondering if someone else (maybe more than one) could help with the project. The RS485 stuff will require NO CODE, as it'll be nothing more than an electrical extension of the 2 signals with no interaction from the 'remote' hardware. But, up to 8 total analog inputs need to be monitored, hopefully with individual current sense parameters/limits, and as I stated before, only the offending district(s) need(s) to be shut down, not everything. Having individual current parameters will allow different MD boards to be used if required. Monitoring remote current sense lines may be an issue, but if there is a distance limitation, we will cross that bridge when we need to. Greg's C++ is so far beyond what I can do that I'm embarassed to say that I program in C code. Does anyone think this is a good idea and can contribute time to the SW modification effort?
this should be doable with limited modifications... in the CurrentMonitor struct add a new field like "enablePin" in the CurrentMonitor constructor() declaration in the struct add a new param for the enable pin. in the CurrentMonitor check() method switch from the #define SIGNAL_ENABLE_PIN_PROG and SIGNAL_ENABLE_PIN_MAIN to use enablePin (remove this line as well) in the CurrentMonitor constructor() method add a new parameter for the enablePin. in DCCpp_Uno.ino where mainMonitor instance is declared add the #define SIGNAL_ENABLE_PIN_MAIN as a new param to the constructor. in DCCpp_Uno.ino where progMonitor instance is declared add the #define SIGNAL_ENABLE_PIN_PROG as a new param to the constructor. That should do it. If you want to add more "districts" you can by connecting the dcc signal, enable and current sense pins from the base station to any remote woo woo woo and add a new instance of the CurrentMonitor to add it to the base station and add a call to CurrentMonitor check() in this block. I can submit a diff/pull request on github later today with this sort of implementation.
I've previously searched/looked at trhe code in question, and there are a few instances of code that are confusing, to say the least..... The place where the actual current is read and checked appears to ONLY look at the program track current. Am I missing something? I tried to add some logic to ONLY shut down the appropriat MD board by using tne value pin that's sent to the function, assuming that would show either the prog or main value, but that didn't work as planned. Adding extra power districts will be attempted once I can actually only disable either the prog or main output individually first. I appreciate your response, and am looking forward to see what you upload to GitHub. Here's what I tried just to control the enable pins, more or less, inserted after the function had determined there was an over-current: /* if(pin=CURRENT_MONITOR_PIN_MAIN){ digitalWrite(SIGNAL_ENABLE_PIN_PROG,LOW); // disable Motor Shield Channel } if(pin=CURRENT_MONITOR_PIN_PROG){ digitalWrite(SIGNAL_ENABLE_PIN_MAIN,LOW); // depending on which caused current overload } */
The CurrentMonitor::check() method is looking at the pin provided via the constructor. This in theory should work but is going to be a maintenance nightmare as you add more pins. The approach I suggested would simplify the logic in CurrentMonitor::check() so that it only knows about one current sense pin and one enable pin. I should have the diff ready shortly.
I have an interest in this, but I'm not sure I follow what is being done. It seems to me that all is needed is 1. Main Base Station that has the standard Main and Prog DCC signal generation, and puts the Main DCC signal on a bus (12Ga wire like DC and Ground) 2. Multiple "minion" Base Stations that take their DCC signal from the bus rather than locally generated, but still have current sensing and motor shield enable/unenable for their motor shield. The "minions" have no need for Prog track functionality so both their channels would be functionally Main. Is it more complicated than that? Current sensing is independent of the DCC signal itself, isn't it? I'm a mechanical guy and not as conversant with the software as you guys so I'm probably overlooking something fundamental... Thanks, Randy
Randy, what you propose is a solution as well. What my changes will do is not disable both PROG and MAIN when only one goes over current. This can then be extended to support more motor boards (on diff pins for enable/sense) to be controlled from the base station.
OK, thanks, Atani. I guess I haven't paid attention closely enough (I just have a test track wired for now)--I didn't realize a short on either Main or Prog would shut both down. Is there a reason that the overcurrent-shutdown isn't on a "channel-by-channel" basis even on the standard Base Station? Randy
I don't know the specifics as to why it shuts down both but it likely was simpler code wise to only check one pin and disable all when it was written. The modification I am proposing is to pass down the enabled pin and have the CurrentMonitor::check() method use it. With this adjustment it should be possible to then setup a large number of "districts" from one base station or to have multiple stations controlling multiple motor boards via some sort of bus system.
I haven't tested it fully yet (been too busy with work to do much with trains) but it does compile and upload to the Mega 2650 without failures so that must be a start right? https://github.com/atanisoft/BaseStation/commit/145a47d4a956fc9c5b39d24a9c37804bc3da9d59 Its a relatively small change and should work to split up the MAIN/PROG shutdown if only one shorts.
At the risk of sounding DUMB, I recently tried to use GitHub to upload some public domain code for a block detection system, and was completely lost as to how to use it without a very steep learing curve, which I didn't want to do. Simply stated, your link shows all the changes, but if I try to modify the source code by editing, the likelyhood of me making mistakes is HIGH. Is the changed code available so I could juist download the 3 changed files? BTW, my code example didn't work as expected, but just kept turning off the prog track.....doing it your way (the correct way) is much more maintainable......I'm retired, but I guess I need to learn C++......
Great! Hopefully it works as you expect. As I mentioned I haven't had a chance to test it yet but plan to this weekend after cleaning the track and testing a couple decoders that seem to be on the fritz.
Have to do some more work......I was working from the BaseStation version 2, the one with the Diagnostic command, and there was a .h file that wasn't in that version. I'll re-do the edits and use version 1 of the code. Any idea how much is different between v1 and v2?
Copied the 3 changed file to the v1 of the code, and I get many compile errors......that sucks. BTW, I'm targeting a UNO, not a MEGA.....
which code did you start with, I suspect it is not in sync with the latest code? You may find downloading a full copy of the code via zip would be easier, https://github.com/atanisoft/BaseStation/archive/master.zip Targeting an UNO vs MEGA should not be too critical, that is in Config.h which is not one of the modified files.
if you want a version that is based on the old v1.0.0 code I can create one, looking at the 1.0.0 code there are a number of differences so that would explain most of the compilation failures you are likely seeing.
I started with the V2 code initially, and then went to the original release version 1.2.1...... I have 3 versions of supposedly v1 code, all of different sizes......I have no idea where I got the 1.2.1 version. I'll try again with the master you referenced. All the dowenloads I've done were full zips, not partial downloads.
It is the absolute latest. The only changes that are in that vs what is in the official repository is adding a project file for eclipseArduino and this enhancement to CurrentMonitor. Its close to 1.2.1 I believe based on the tags and diff to latest code on master.
If I compile from DCCpp.ino, it compiles clean, but if I compile from DCCpp_Uno.ino I get lots of errors.....your changed file is the DCCpp_Uno.ino, so I'm officially confused. I deleted the DCCpp.ino file, and it compiles clean......the IDE doesn't make alot of sense to me.....I'll test it tomorrow afternoon.....
