Hi Scott, I'm not sure about the specific convention you are referencing above (<f locos lightson 1>). Perhaps this was something added in another branch of DCC++ to be compatible with JMRI? In any case, I think I get the gist of your question. In the main branch of DCC++, the command for setting functions F0-F4 is: <f CAB BYTE>, where BYTE = 128 + F1*1 + F2*2 + F3*4 + F4*8 + F0*16. Let's assume for a locomotive with address 4567, F0 is the light control, and F1 is the bell control. The following commands control the lights and bell: <f 4567 128>: bell and light are both off <f 4567 144>: light is on, but bell is off <f 4567 129>: bell is on, but light is off <f 4567 145>: bell and light are both on As you can see, the <f> command allows you to jointly control all of the functions and set any given one on or off, but you need to let the decoder know the status of F0, F1, F2, F3, and F4 all at the same time. Extending the above example, now let's assume a horn is attached to F2. There are now 8 combinations needed to control these as follows: LIGHT BELL HORN <f 4567 128>: OFF OFF OFF <f 4567 129>: OFF ON OFF <f 4567 130>: OFF OFF ON <f 4567 131>: OFF ON ON <f 4567 144>: ON OFF OFF <f 4567 145>: ON ON OFF <f 4567 146>: ON OFF ON <f 4567 147> : ON ON ON The more functions used, the more combinations. Fortunately, the DCC spec separates function groups and does not combine all 28 functions into a single command. To control functions F5-F8, the same logic is applied as above, but the "seed" byte is 176 instead of 128 (i.e. 176 turns off F5, F6, F7, and F8; 177 turns on F5 but keeps F6, F7, and F8 off...). Keeping track of all of these combinations when you only want to change one function is a bit of a pain, which is why the DCC++ Controller GUI separately keeps tabs of the status of each function for each cab in an internal array. Then, when the user hits the horn button, or the light button, it dynamically constructs the correct byte value using the formula above, and sends that to the DCC++ Base Station in the form of a single <f> command. Hope this helps. -Gregg
That is Exactly what I am referring too...the Controller GUI keeps track of the commands issued or not and the combinations....now I am able to complete this function in my GUI....just needed to know how the functions were stored...thanks and Merry Christmas!
All, I have been talking to Gregg about producing a DCC++ specific shield. Right now, I have the basic motor driver added. Gregg also mentioned to me about adding general control I/O to the board, which I have started, but is not seen in this picture of the first draft board design. I would like to look at the idea of even adding the ethernet capability right on this board. I want to make it as drop-in and run as possible. One of Gregg's other requests was adding configuration headers for the UNO vs. MEGA. I'm open to suggestions. I've been in the electronics design business for over 15 years. If this turns out to be something people want, I'll produce and sell them through my company RPC Electronics, LLC.
Thats a very good idea....remember to add the Pololu motor shield which I use to power HO Scale as the original Arduino and Adafruit motor shield is unable to handle the higher voltage.....and the pin mappings are a bit different. Your shield would have to compensate for that. Other than that I cannot think of anything off hand to add.
I think the idea is that this would be an actual motor shield so you would not need the Pololu (or the Arduino version). It therefore may make sense to use the h-bridge chips found on the Pololu to ensure users can operate with the greater voltages and current needed for HO.
Yes if that is included then that would be great.....one thing to make sure is being able to select the power used in order to power, Z scale, N scale, HO scale and G scale....as that is what is on the selector switch on my Digitrax Power Supply
Regarding keeping track of function states, I don't know if JMRI itself does it, but Digitrax command stations do keep track of F0 through F8, and JMRI queries function states and presents them to throttles. The states are preserved when the station is powered off. They are stored in slots, which are Digitrax's equivalents of packet registers, along with direction, speed, DCC address, consist info, etc. The limitation with this approach is that there can only be as many loco settings as there are slots. I am unlikely to run out any time soon with only four locos and as many as 120 slots, but I don't see too many complaints from people that have 50 or 100 locos and use the Zephyr with only 24 slots. The command station does seem to be the logical place to keep track of this kind of data. I don't know how other manufacturers handle this, but DCC++ could implement this quite easily.
You would still need to use an external power supply (which would have the appropriate voltage switch). The shield Jason showed above would replace just the Pololu or Arduino Motor Shield.
I agree --- the question is whether to create a new function for this, which would allow for backwards compatibility, or replace the existing <t REGISTER> command, which is cab-agnostic, with a two-step approach. Something where you would "register" a cab, at which point the Base Station would take care of finding and managing the actual slot, and then you would issue <t CAB> commands to control the throttle. A single structure would maintain each Cab's slot, function settings, and speed. Part of this structure can be stored in EEPROM so it is saved between power-cycles. I could create a second branch in GitHub for this type of "version 2" system.
If there is a issue with EEPROM space these 256k I2C modules are cheep and and could be added to the UNO or MEGA or integrated into a DCC++ shield easily enough. http://www.ebay.com/itm/AT24C256-Se...567458?hash=item4aea205562:g:w9MAAOSwBLlVVb2Z I would think the 2 step process would be better if it could be set for 40 or so individual cabs and maybe 10 consists, that would roll over when you went over the 40/10 limits. (I have never had a consists setup with multiple live engines so I am not sure how it works.) Then use the same struct to keep track of accessory decoders (f0-f15) as well. Set the MEGA base station extra outputs in groups of 16 with a hard coded dcc address. Witch would allow all dcc throtles to access the I/O pins on the mega as another acc. decoder.
I have a quick question about recommended voltage for HO track using the Pololu shield. I have a 20 volt, 3 amp supply that I was planning to use, but then thought this maybe too high. Doing a little research, I find that most of the commercial command stations supply about 14 to 15 volts for HO. Scott, what AC voltage do you measure on your rails? I'm measuring 20.1 V. David
Gregg, the way Digitrax does it is as follows: - throttle device requests loco with address e.g. 1234 - command station searches the slots for this address - if the address 1234 is found in one of the slots, whether active or inactive, the loco was previously used, and the slot number, e.g. 11, and all state information is sent back to the throttle - if not found, a new slot is allocated with default speed (0), direction (F), functions (off) and that is sent to the throttle - if no inactive slots are available, the request fails, and the user can choose to reset slots (that's what we do in our club before operating sessions) - the throttle device then uses the slot number for all subsequent commands - it is expected that users release locos after use (but not all do, hence the need to reset the slots) If we were to use a scheme like this, it would requires significant changes both in the base station and in the GUI and JMRI interface. As a matter of fact, from our club's experience, I'd rather have Digitrax modify theirs. What I would suggest instead is the following: - leave the <t ...> commands as is, or drop register number - implement packet registers as an associative array (dictionary/map) indexed by loco address - keep track of function states and send them back in the acknowledgement message - implement some least recently used scheme to reassign unused packet registers (locos that are not moving) when we run low on memory
Thanks! This is really helpful. Since I'm already dynamically allocating memory for sensors, turnouts, and outputs (where the ID of the sensor, for example, can be any integer, and it is stored sequentially in a linked-list), I can use a lot of what I've already written to implement a "registration" of cabs (including the removal of a node in the linked-list). I can also check the memory and if a new request would cause an overflow, can release an unused train.
Friends, I need a help. All devices are 100%: Arduino Uno (Genuino) ;,DF Robot 2A Motor Driver Shield (tested with two motors) ; LaptopUniversal Adaptor Input 110V-240V output 12-24V. But, until now, no locomotive movement. Scott write on previews post: "You have to issue the locoid command in order to get the loco to move <t 1 locoid speedstep 1> in other words <t 1 03 20 1> this would make loco address #3 move forward." Sorry, I can not understand this. Is it possible to clarify this? I make a lot of trial on controller-master program, following the four videos , but unfortunately no movement. Is it possible any help? Regards.
Using the Arduino IDE version 1.6.6 or higher and upload the code. Open the serial monitor in the ide (click tools then click serial monitor) and type the command <t 1 03 20 1> including the greater than and less than signs. If your engine is 1991 then change 03 to 1991 <t 1 1991 20 1> if you want 1/2 of full speed you change the 20 to 63 so <t 1 1991 63 1>. If you want to go in reverse on 1991 at quarter speed it would be <t 1 1991 32 0>. The throttle formula is <t REGISTER CAB SPEED DIRECTION>. Breakdown for this example <t 1 03 20 1> is : "<" = listen to me i'm and DCC++ command. "t" = (lower case) this command is for a Decoder installed in a engine or simply a "cab". "1" = REGISTER: an internal register number, from 1 through MAX_MAIN_REGISTERS (inclusive), to store the DCC packet used to control this throttle setting "03" = CAB: the short (1-127) or long (128-10293) address of the engine decoder (this has to be already programmed in the decoder) "20" = SPEED: throttle speed from 0-126, or -1 for emergency stop (resets SPEED to 0) "1" = DIRECTION: 1=forward, 0=reverse. Setting direction when speed=0 or speed=-1 only effects directionality of cab lighting for a stopped train ">" = I'm done sending this command If the command is successful the serial monitor should reply with : <T 1 20 1> meaning : register 1 is set to speed 20 forward direction. I hope this helps, willy
ISCOLD, if I am reading your posting correctly then the root of the problem is in your motor shield. You say you have the DF Robot 2A Motor Shield --- can you confirm this is the model: http://www.dfrobot.com/index.php?route=product/product&product_id=69#.VnzTBDYoX-Z. If so, though this motor shield is compatible with the Arduino Uno, it is not the same as an actual Arduino Motor Shield. The DF Robot shield has about the same functionality but the signals are on different pins. It is still possible to use this shield, though the jumper wires would need to be moved to different pins and you'd need to make a small modification to the DCC++ Base Station code so that the system knows which pins are used on the DF Robot shield. One other thing to note: the DF Robot shield does not seem to have implemented the current sensing circuits. Without that, DCC++ won't be able to monitor track current or check for short circuits. More so, it will not be able to read CVs or cab addresses from your train decoders. If you can, I'd recommend trying to purchase an actual Arduino-brand Motor Shield, or alternatively the Pololu brand that others have used successfully (see prior postings). However, if you'd like to try out the DF Robot shield, let me know and I can help you with the changes needed in the software as well as the placement of the jumper wires. -Gregg
I use the Digitrax Power Supply which can do N Scale, HO Scale, and G Scale....it has a selector switch whioch automatically sends the correct voltage to the rails: http://www.digitrax.com/products/power-supplies/ps2012/ if you are measuring 20.1v there is an issue...mine doesn't get that high
Now I've used Digitrax for the last number of years and there is an issue with Digitrax's system of getting the dreaded "slot max"> This occurs when a user forgets to "dispatch" the locomotive from the Base Station's internal memory. As long as the DCC++ Base station drops the slot when the locomotive is dispatched then no issues...if I understand correctly the DCC++ base station does not save any information and thats good then no slot max will occur.
Gregg, Yes, you are right at point. My motor shield is exactly this model that you said. As it have the limitations as you said I will change this motor shield. Please, let me know the right model that I must purchase. Regards
