Man do I feel dumb, never noticed the tabs since there were no words there...duh! Keep trying to just remove items from your sketch, just to see if I can get a switch or piece of track to disappear to give me an idea of where I am, but it just gives me error's when I do that. Can't wait for the simple oval and one switch. That I should be able to figure out, I hope! As a matter of fact you have an oval on the far inside of your layout, and I figured if I removed all the other stuff around it I would eventually get there. But apparently I don't completely understand the coding yet. BTW, and way to have a DCC++ Beginner thread (Get Started with DCC++, sub forum, whatever, that list the very basics of Arduino hardware you need, power supply, Arduino IDE link, Processing link, even loco decoder (or loco as I need a DCC loco too) very simple oval layout with one switch for us very beginners like me? And a few videos to go with it. I do better with visuals! This is all very new to me, just DCC in general!
Gregg, I thinking I keep running into problems testing the RPC UNO interface because my pin definitions keep getting changed. I wrote a quote module that I think is right for the board definitions IF/ELSE block in DCCpp_Uno.h Code: #elif MOTOR_SHIELD_TYPE == 2 #define MOTOR_SHIELD_NAME "RPC ELECTRONICS UNO MOTOR SHIELD" #define SIGNAL_ENABLE_PIN_MAIN 7 #define SIGNAL_ENABLE_PIN_PROG 8 #define CURRENT_MONITOR_PIN_MAIN A0 #define CURRENT_MONITOR_PIN_PROG A1 #define GPIO_1 3 #define GPIO_2 6 #define GPIO_3 9 #define GPIO_4 11 #define GPIO_5 13 #define GPIO_6 A3 #define GPIO_7 A4 #define GPIO_8 A5 //#define DIRECTION_MOTOR_CHANNEL_PIN_A 12 //#define DIRECTION_MOTOR_CHANNEL_PIN_B 13 I think since we are not trying to use the standard motor shield, the DIRECTION_MOTOR_CHANNEL_PIN_A and B lines can be removed. Right now, I just have them commented out. My only question right now is, since I defined this board are condition "2", when do I change the code to identify the board as "2"?
Good idea to create specific definitions for the RPC shield. The code that allows you select which board definition to use is at the top of Config.h file. The idea is that users only need to edit that file to triggers the appropriate definitions in DCCpp_Uno.h. You are correct that DIRECTION_MOTOR_CHANNEL_PIN_A and PIN_B are no longer needed, but they are used in the main DCCpp file. You'll need to comment out the lines of code in that file where they are referenced (since the code itself will no longer be needed). Alternatively, you can keep the definitions as placeholders, in which case I recommend setting DIRECTION_MOTOR_CHANNEL_PIN_A to 12 and DIRECTION_MOTOR_CHANNEL_PIN_B to 5 which matches the DCC LOGIC Signals and the UNO are we know won't be used for your GPIO connections.
Gregg, OK, sounds good! I uncommented those lines and assigned them to 12 and 5 respectively as you suggested. I went ahead and created a block in the IF/THEN for the RPC Mega pinout: Code: #elif MOTOR_SHIELD_TYPE == 2 #define MOTOR_SHIELD_NAME "RPC ELECTRONICS UNO MOTOR SHIELD" #define SIGNAL_ENABLE_PIN_MAIN 7 #define SIGNAL_ENABLE_PIN_PROG 8 #define CURRENT_MONITOR_PIN_MAIN A0 #define CURRENT_MONITOR_PIN_PROG A1 #define GPIO_1 3 #define GPIO_2 6 #define GPIO_3 9 #define GPIO_4 11 #define GPIO_5 13 #define GPIO_6 A3 #define GPIO_7 A4 #define GPIO_8 A5 #define DIRECTION_MOTOR_CHANNEL_PIN_A 12 #define DIRECTION_MOTOR_CHANNEL_PIN_B 5 #elif MOTOR_SHIELD_TYPE == 3 #define MOTOR_SHIELD_NAME "RPC ELECTRONICS MEGA MOTOR SHIELD" #define SIGNAL_ENABLE_PIN_MAIN 12 #define SIGNAL_ENABLE_PIN_PROG 2 #define CURRENT_MONITOR_PIN_MAIN A0 #define CURRENT_MONITOR_PIN_PROG A1 #define GPIO_1 3 #define GPIO_2 6 #define GPIO_3 9 #define GPIO_4 11 #define GPIO_5 13 #define GPIO_6 A3 #define GPIO_7 A4 #define GPIO_8 A5 #define DIRECTION_MOTOR_CHANNEL_PIN_A 12 #define DIRECTION_MOTOR_CHANNEL_PIN_B 5 I'll try selecting this in the Config.h file to test this.
I think you may be mixing the use of SIGNAL_ENABLE_PIN with DCC_SIGNAL_PIN. The later tells DCC++ which pins on the Arduino will output the DCC logic signal. This is independent of which motor shield you are using and is automatically determined in DCCpp_Uno.h by detecting whether you are using an Uno or or Mega. For the Uno, MAIN is on pin 10, and PROG is on pin 5. For the Mega, MAIN is on pin 12, and PROG is on pin 2. You won't need to add or modify anything in this section of the code to use the RPC shield. SIGNAL_ENABLE_PIN is a separate digital output that enables or disables a given channel on the L298. I believe based on spreadsheets we put together (I think these messages are in the inbox discussion) you are using pin 7 (MAIN) and pin 8 (PROG) for this. These should be same regardless of whether you are using the Uno or Mega, meaning that you only need one new motor shield option type. I think the your option #2 above would work, and you can delete the option #3. Also, can just rename the shield so that it does not specify Uno or Mega.
Gregg, I was doing this fast at lunch and didn't pay attention to what I posted. Yes, you are correct, I was mixing up the terms. Also, I noticed in my code I posted above I forgot to delete the Direction A and B lines, since they are not needed. I'll fix that when I get home. I'm trying to eliminate any firmware confusion as I debug the hardware. I realized I was chasing my tail because every time something wasn't working, it turned out a pin definition was changed or I had grabbed the latest code and forgot to change it. I wanted to get the definitions in to just set that part in stone. EDIT: Actually, I left those direction lines in there since you suggested they needed to be there for the various calls in the program.
All, I have created a new branch for DCC++ Controller called "sample-layout." You can select that branch from within GitHub and download this version of the Controller. In this version I've replaced my specific layout with a generic layout containing a single oval and a few sidings. More so, the code in the controllerConfig tab that creates this layout is very heavily commented and designed as a virtual tutorial. It describes each layout command and how the oval, the turnouts, the sidings, and the route buttons are built one step at a time. Let me know if you have any questions. -Gregg
Same GitHub link? Let me go find the link. And thank you very much for this. BTW, do we have to have a separate power supply other than our old DC train coontroller's. I have an old Tech II I use. If not please explain why a separate one is needed. I do not see the "sample layout"! Is it in the Controller download? Found it. Sample layout branch: https://github.com/DccPlusPlus/Controller/tree/sample-layout DCC++ GitHub https://github.com/DccPlusPlus?tab=repositories Thanks again,
Hello Gregg, I assembled a DCC++ system yesterday and I am very empressed. Kudos to you. I have been able to run a train on a test track. I have also been able to read CVs in programming mode. Now I have run into a problem, I cant program a Digitrix TF4 function decoder. This decoder is installed in a boxcar and operates two solenoids. I need to set a four digit address. Please respond if you have any insight as to what I may need to do. Maybe because there is no "load" on the decoder? I'm at a loss here. Rob
Hi Gregg, Is there possibility to include S88 with the DCC++ system? I saw a video that used Arduino for S88. Just wondering. Thanks, Rob
Hi Rob - based on your description it sounds like you've correctly configured DCC++. Are you using the serial monitory window of the Arduino IDE to control the system? As for the TF4, it seems like it responds just as if it were a mobile decoder, so the usual DCC++ function controls should be able to operate this decoder. You won't be able to read it, however, since it does not control a motor. Details on how to send DCC++ function commands can be found in the following post: http://www.trainboard.com/highball/...ation-and-interface.84800/page-19#post-954710 -Gregg
Rob, Assuming you are not using the motor-output, you could connect two small-12v-incandesent-bulbs in series to the motor-output. This should allow the read-back of signals from the decoder. But be careful not to inadvertently leave the motor-drive turn-up, you might over-heat your box-car. Bob
Hi Bob, That may be what I have to do. I can't get DCC++ to recognize the decoder in the boxcar. I have tried using the programmer in JMRI as well as Simple Programmer that is also in JMRI.Is it possible to use a resistor in line or a capacitor on the motor leads? Thanks, Rob
Rob, Using a capacitor would most likely be a bad idea. A resistor should also work, but I would email the decoder-manufacturer for specific resistor information, so you could use a larger-ohm resistor for less heat buildup. Bob
Rob, When you say you can't get DCC++ to recognize the TF4, do you mean you cannot read it, or that you cannot operate it. Note that the TF4 has no motor control at all, so there is nothing to add a load to. I do not know if the TF4 is designed to sync current through one of its function outputs upon a CV-read request, but if not then there is no way to read any of the CVs (in other words, even if you add a load, the TF4 has to be designed to activate that load upon a CV-read request -- I don't know enough about the TF4 to know if it does). Also, the TF4 is a transponder and can communicate with digitrax systems that can read digitrax transponders. This is beyond NMRA DCC standards and DCC++ does not have the ability (currently) to read transponders. Should still be able to operate the decoder though. Is the cab address you are using 128 or less? -Gregg
I have two boxcars with solenoids in them. One was working but I tried to reprogram it with a new address and now I can not get the solenoid to open the coupler. The other boxcar I can't remember the address so have been trying to reprogram that as well. I may have to take it to the club and put it on the Digitrak programming track. I know that the decoder is not readable but I should be able to write to it. I may need to program each CV but I don't know if the company that produced the DCC Uncouple Cars changed the CVs specific for their application. I am thinking that while attempting to program them I may have changed something. As I said one of the boxcars was working before I tried changing the address.
Rob, Are you using the Program Track or are you trying to Program On the Main? If you haven't tried POM it might be worth a try.
I have been using the programing track. Won't hurt to try on the main. I will try anything at this point. I found this mention of the TF4 and have attempted to contact Rob. http://www.robsrailwaymodelling.co.uk/rrm/dcc-decoder-test-rig/
I reviewed the specs for the TF4 and think I understand the issue. First, the TF4 does not support programming on the main, so you have to use the programming track. Second, it does not provide any feedback. This means that any programming that attempts to verify whether a "write" is successful will always show a fail, even if the write was indeed successful. If you try to program a 4-digit address using DCC++ Controller, the system will detect a fail after writing the first address byte, at which point it stops, reports the failure, and does not proceed to write the second byte. But there is a good chance the first byte was successfully written meaning the address on the decoder has been partly changed, which is probably not what you want. We could modify DCC++ Controller to ignore the fail message. But to test the theory I recommend you first try to write a 2-digit address on the programming track using DCC++ Controller. It will report a fail for sure, but probably did succeed. Also, you will need to tell the decoder it should recognize 2-digit (short) addresses instead of 4-digits (long). There is a specific button on the DCC++ Controller programming window that allows you to select short addresses. When you press this button it will report a fail, but again, we can't rely on that. -Gregg
An easy way around this problem is to put another loco on the programming track together with the TF4. After the address is programmed, just reprogram the loco with the old address. That said, a better solution would be to for the controller program to carry out the entire write operation, and then report that it couldn't confirm the write. I think that's how Digitrax does it - I remember programming Acela dummy locos that way with no issues.
