with an appropriate definition in "MotorDrivers.h" ofcourse. Have a look at it, it is not hard to understand. sth like should keep your setup working as is #define LMD_MOTOR_SHIELD F("LMD_MOTOR_SHIELD"), \ new MotorDriver(3, 12, UNUSED_PIN, UNUSED_PIN, A0, 4.89, 3000, UNUSED_PIN), \ new MotorDriver(11, 2, UNUSED_PIN, UNUSED_PIN, A1, 4.89, 3000, UNUSED_PIN) should get you going. Don't forget to change config.h to reflect your motorshield. If it worked with old DCC++ it should work with new modular DCC++EX. edit: sorry, took a little longer to calculate MAX471 conversion factor
Here is the Locoduino link: https://www.locoduino.org/spip.php?article187#forum5062 If anyone needs help with French, let me know.....
ok, my last patch had a little flaw because I didn't realise there are 2 versions of stop and emergency break packets for 28 speedstep, so we now loose first 16 (of 126) steps. Broadcasts are sent in 28step mode, should be compatible. Here is the corrected version.
oh my ... looks like I have to patch at least DCC::getThrottleSpeed() and DCC::getThrottleDirection() too... any other hidden pitfalls?
Hi All, I am using DCC++ control and would like to replace it with DCC++ EX. The change will also involve a hardware change and the transition from the ATMEGA328 to the ATMEGA2560 processor. Currently, I do not use a complete Pololu dual MC33926 shield in my controller, but two small independent MC33926 boards (also manufactured by Pololu). I need two PWM signals to drive each of the MC33926: PWM and PWM negation. To get these signals from one PWM I am now using the differential line driver AM26C31. And here I have questions: 1. Do I understand correctly that in DCC++ EX I can get both signals directly from the CPU? Do I understand correctly that in the definition of custom shield these are the fields: signal_pin (PWM) and signal_pin2 (PWM negation)? 2. When using a shield with the ATMEGA2560 processor, do I have to use hardware timer outputs as PWM outputs like in 328, or can I use any outputs, not necessarily hardware timers? 2. One more question: does the DCC++ EX development team plan to add support for the popular S88 bus? I will be grateful for the answers and explanations. Greetings, Kuba
And I'll add a new motorboard type to DCC-EX. I have about 7 different Motor boards and all sorts of current sensors. I have been meaning to hook this exact setup to my test track and use all the resistor packs I soldered together to measure current to calibrate our sense factor so we know how this behaves. I want to hook the MAX471 to every board whether it has current sense or not and use it instead actually. The Arduino Motor Shield is not the most accurate thing on the planet, plus it only uses 0-3.3 Volts to cover the entire range of current from 0-2Amps, so its resolution is a bit poor also. Fred DCC-EX
That is correct You can use any available digital pin Not sure yet. When looking for challenges, we have LocoNet, S88, C/MRI, and what we have done work on, and which is available today, the nRF24 boards. The "LCN" system is in the productization stage so you will be able to buy pre-configured nodes from a hobby store. http://thenscaler.com/?p=1552 However, the extensible nature of DCC++ EX allows you to have "User Functions". This means that any commands that go to the Command Station and are processed by our parser, can be overriden. So let's say you want to control a turnout. JMRI sends <t ID THROW/CLOSE> to us, we convert that to a packet and send it to the rails. BUT, you can easily tell the CS to intercept that and give it to you to process. So you define a "filter" and our parser sends you back the command that you filtered out. Then you can take that and do whatever you want with it. That may be to take the parameters it gives you, the ID and action in this case, and then call your routine you would add to our .ino file that sends whatever data out to whatever device you want. That can be an NRF24 radio board, a Serial.Write() to a spare Mega Serial port, etc. Very simple to do.
We have talked about this a bit. It may be easier to join the conversation on Discord where the development team hammer out how to create new features. Fred DCC-EX
Hi and happy new year to all. Maybe i missed something, tried the installer at https://github.com/DCC-EX/exInstaller/releases/tag/v2.3.1-beta.1 but get this error when launched: Maybe it could be windows firewall blocking. So I downloaded the sourcecode at https://github.com/DCC-EX/CommandStation-EX and used arduino IDE (note: "config.example.h" to be renamed and edited, and the folder name to be changed according to ide regulations). Then I compiled and uploaded to the board, everything worked fine. Both track and program output were tested and worked under rocrail software. My question now is: on dcc++x webpages there is no mention to the available pins on the mega, for adding sensors inputs. In dcc++ classic there were reserved pins on both uno and mega. May I have a complete pin mapping guide for connecting sensors on mega? Thanks
There is an issue with the Arduino CLI, which we download, that causes an issue with some virus checkers. That is the cause for the error. Was there a list posted anywhere for the old DCC++ for reserved pins? With DCC-EX, the pins used depend on your motor board settings. In order to eliminate the need for jumpers, each motor board type uses the pins that connect to the correct pins on the shield. For non shields, like the IBT_2 boards, we just arbitrarily chose pins. You can create a new motor board type in your .ino file to change the pins, don't change them manually in the code since they would get overwritten in an update. Here is where you can see the pins we use: https://github.com/DCC-EX/CommandSt...ecd130ad95ac3d9d6f3e45e212/MotorDrivers.h#L20
Ok, got the point. Anyway using Arduino IDE to compile and upload to the board some more actions are requested: - Change the unzipped folder name according to .ino file - Rename and edit example.config.h file Yes there was (and still is) at: https://github.com/DccPlusPlus/Documentation/blob/master/Motor Shield Pin Mappings.pdf Sorry but I'm not a programmer expert, so I cannot see the meaning of "UNUSED_PIN" and he numbers near it 3, 12, UNUSED_PIN, UNUSED_PIN, A0, 2.99, 2000, UNUSED_PINand 11, 13, UNUSED_PIN, UNUSED_PIN, A1, 2.99, 2000, UNUSED_PIN In my case, I have a standard original arduino motorshield v3, which ones are reserved pins? Thanks
@ardsuppi Since you are using a standard motor shield, the reserved pins will be mostly/all the same - and you should not need to customize the motor board parameters. DCC++ required a jumper on pins 2 and 13 for the Mega -- remove it for DCC++EX. Also, RX/TX pins are used for wifi. Prior post.
Thanks Ash. I still think that a full explanation should be given in the instructions on the dcc++ex webpage about reserved pins on MEGA cards. I can therefore assume that with the standard motor shield the pins n. 0 1 2 3 4 8 9 10 11 12 13 and A0 A1 are reserved? I'm sorry for the fuss, but I need to use pins as input from block occupancy sensors.
Hi, on the standard motorshield the pins (0,1,)2,(4),5,6,7,(10),SDA,SCL,A2,A3,A4,A5 are not used for onboard electronics, so are free for user options on dcc++EX. Pins 4,10 are used on ethershield, 0,1 are serial.
Ah, I see. We also have that PDF file for Classic. It doesn't apply DCC-EX. But I can make something that shows what pins each board uses, including wifi boards, displays, etc. It isn't what's free on the arduino, it is what other hardware uses that takes up pins on the Arduino. The definition of those pins is in the function and detailed in the motor boards config on the web page. Thanks for the input. Let me know anything we can make easier and put in our references.
Thank you @FlightRisk I tested the sensors on all usable pins and it worked fine. However, I noticed a ~1sec delay in the response to the ON/OFF status changes, that with DCC++ classic were instantaneous. I read somewhere that is possible to adjust the reaction time by changing the code. Since Rocrail allows you to set a delay in the reaction to the ON/OFF state, allowing you to eliminate instantaneous and random changes of state (in my case any wheel that passes on a sectioning connects two sections, even if for a very short time), to me it would be useful to have no delay in the communication of the state, Rocrail itself would take care of it. Speaking of rocrail, I suggest you contact the author Robert Jan Versluis (info@rocrail.net) to be able to activate full compatibility with DCC ++ EX with all its new features. It shouldn't be that hard for him to implement DCC ++ EX as a new compatible command station. Regards, and keep going on on this project
Than you Ciro. Robert just added a feature to Rocrail we asked him for, so I'm hoping to do just as you ask with other features. Let me look into the sensor issue.
I have now installed DCC++ EX on a Mega and connected it to my test-track and everything seems to be working fine. Thank you for all your effort! Now I just have to rewrite a good part of the code on my wireless controls to benefit of the changes on the EX code, that is the throttle and function commands. It will make my development a lot easier later on. I just have 2 small questions that are more of principal art. 1: I know I have read somewhere (on the DCC++ EX site?) that it is possible to control up to 20 locos on an Uno and up to 50 locos on a Mega. But I can not find that info now. Is that correct? 2: Hope I can explain this. In the DCC++ code there is a register for throttle commands which it sends out to the track over and over again. And in the DCC++ EX code that also apply for function commands. There is a lot of coaches/waggons that have decoder for light, and they have separate addresses. In the "original" DCC++ code function commands where just sent out once and not stored. Thus (in my mind) the limit of addressable coaches/waggons where quite high, about 2000. The question is then, are function commands stored in the same register as throttle commands, and is limited to 50 on a Mega? Or is it a separate register (sounds odd)? This is not a problem, we will probably cope with 50, but it would be interesting to know.
@FlightRisk Sensors-late issue solved, it was my fault on RocRail setup. I notice that locos on program track are moving a bit on read/write cvs. And this is not fine as moving, loco may run on a bad pickup position hence stops reading/writing. Maybe I can adjust the power on prog out anyway? Regarding Rocrail implementation of DCC++EX, I suggest to propose Robert the ability (in Rocrail is possible) to power tracks and prog separately as in DCC++EX not in DCC++ classic.
