DCC Loco Functions

This project will use the NCE DCC Twin shown. It has provision for controlling two locos at address 3 and 4. It can also program the functions 1 through 8 for both locos - see buttons. However that is all it can do. It cannot control accessories such as points. This project will capture the function information and in a later project Function_Control_Points this function information will be used to control points.

The information on the tracks is captured via the opto coupler (The white chip) and the Nano interrupt pin (D2). A previous project DCC_Probe has decoded all the DCC messages - this project will extract the Loco Function information. These can be used to control accessories.

The board on the top right is not part of this project but is used in a later project to drive servos that control points.

Source code for program DCC_Loco_Fn_code

Summary of program DCC_Loco_Fn

This program will use the information captured by the class/library DCC_Probe and pull out the status of the function buttons 1 through 8 for a specified locomotive.

Include file: DCC_Loco_Fn.h
Constructor: DCC_Loco_Fn no parameters
Public Methods: void Begin( )
int Fn_State(LOCO); where Loco is loc of interest
Method returns state 8..1 of functions

Possible Audience: Model train enthusiasts who have a knowledge of C++
Required Hardware: Project will use the PCB required for the DCC_Probe project. Basically, an opto coupler wired between the railway tracks an Arduino microprocessor.
Keywords, The project does not demonstrate new key words but is an example of Inheritance in C++.
Required Software: As illustrated the project builds on the DCC_Probe so will require the DCC_Probe library. The project will be developed using the Arduino IDE.

The Starting Client Code.

The project will require 3 files all with the same name but different extensions. In the Arduino IDE create a new file DCC_Loco_Fn. The editor will give it the extension *.ino. Also in the same window use the upside down triangle near the top right to create two new files DCC_Loco.cpp the implementation file and DCC_Loco_Fn.h the header file.

For starters populate the client or application file as shown. The client code almost gives the starting point in the propject design. That is a function/method of the form Fn_State(LOCO) that returns the current state of the function settings for a specified LOCO is required. Fn_State(LOCO) will be a member of a new class DCC_Loco_Fn to be developed. Possible starting code will be:

/DCC_Loco_Fn.ino Application or client code#include "DCC_Loco_Fn.h"
#define LOCO 3
DCC_Loco_Fn Fn;
void setup() { Serial.begin(112500); Fn.begin( );}
void loop() { int active = Fn.Fn_State(LOCO); Serial.println (active, HEX);}
As shown one instance Fn of the new class DCC_Loco_Fn is created and this class has a method Fn_State (LOCO) that will reurn the state of the functions for a specified LOCO. Associated with the class will be a begin( ) method
----------------------------------------

The Starting Header File

The end application has defined a starting point for what is required of class DCC_Loco_Fn. The class will read the results found in the class DCC_Probe and provide a public method Fn_State that returns selected results to the application or client code. In C++ terms the new class will inherit the DCC_Probe class. This will be part of the definition:

//DCC_Loco_fn.h Header File#ifndef DCC_LOCO_FN_H#define DCC_LOCO_FN_H
#include <DCC_Probe.h>
class DCC_Loco_Fn : public DCC_Probe { public : DCC_Loco_Fn( ); void begin( ); int Fn_State(int loco ); }; //don't forget - error message gives no clue where problem lies#endif
The class definition has defined the two methods begin( ) that is anticipated will be required and Fn_State( ) that is known to be required----------------------------------------------

The Starting Implementation File.

At this point the implementation file will be a shell of the final code consisting of the class constructor and the begin() and FnState() methods. That is

//DCC_Loco_Fn.cpp Implementation File#include "DCC_Loco_Fn.h"
DCC_Loco_Fn::DCC_Loco_Fn ( ) { };
void DCC_Loco_Fn::begin ( ){ }int DCC_Loco_Fn::Fn_State(int loco ){ return 0;} ---------------------------------------------------

Adding the detail to the application file.

Since the new class uses the DCC_Probe class any initialisation requires the DCC_Probe::begin( ) method.

void DCC_Loco_Fn::begin ( ){ DCC_Probe::begin( ); }

At this point the new class does not require any additional initializations.

The next stage requires some knowledge of the methods available with the DCC_Probe class (begin() has already been used).

The DCC_Probe class has collected the data from the railway tracks and placed these in an array. To read the array the method get_result( ) is provided. When there is new data this will be flagged with the method message_done( ) and when this data has been used the status may be cleared with the method clear_message_done( );

The code becomes:

int DCC_Loco_Fn::Fn_State(int loco ){ if (!message_done()) return 256; //flags no new data static int pat; //pattern of functions to return byte command1 = get_result(1); byte command2 = get_result(2); clear_message_done( ); //information used// manipulate the data return (pat);}

At this point if there was no new data it was decided to return an invalid number. ie 256. This will require up grading the application code. that is

void loop() { int active = Fn.Fn_State(LOCO); if (active < 256) { //valid reading Serial.println (active, HEX); } // valid reading}

The implementation code then makes copies of the two elements of the data array and clears the message done.

The next part of the code requires combining the two bytes to obain the loco functions

-------------------------------------------------------------------------------------

Extracting the function data

This step requires a knowledge of the DCC track protocols. See DCC_Protocol. Any pattern that does not satisfy the requirent for the loco function an invalid value (256) is returned.
With the first byte of data command1 the following are not valid for this project
if (command1 == 255) return 256; //ignore idle if (command1 >=128 ) return 256; //not a short loco if ((command1 & 0x7F) != loco) return 256; //not loco of interest

With command2 the results must be in the range 128 (0x7F) through 191 (0xBF). That is

if (command2 < 128) return 256; //not fn commands if (command2 >= 192) return 256; //not a function command

The final step is to manipulate command2 to generate the required patterns. That is Function 1 in bit 0 of the result, Function 2 in bit 1 through Function 8 in bit 7. Note the status of the light function is not returned.

command2 &= 0x2F; //mask light
if (command2 < 32) pat = (pat&0xF0) | command2&0xF; else pat = ((command2&0xF)*16)|(pat&0xF); //patterns in higher bits return (pat);
--------------------------------------------------------------------------

Refining the client code

At this point the code will continuously output the status even if it does not change. To only output new data the application or client cod may be modified by including a variable saveActive which contains the last reading.

void loop() { static byte saveActive; int active = Fn.Fn_State(LOCO); if (active < 256) { //valid reading if (active != saveActive){ //new reading Serial.println (active, HEX); saveActive = active; } //new reading } // valid reading}
----------------------------------

Conclusion

The project was tested using an NCE DCC Twin that has a throttle and 8 function switches for locos 3 and 4. Note function 2 is a momently on switch so pressing will give 3 outputs xxxx,xx0x the original reading, xxxx,xx1x momently on and back to the original reading xxxx,xx0x.
One problem while developing the program is that if the NCE DCC Twin is not reset each time new code is transferred the Function switches will be in an unknown state which may create uncertainties in the testing.

Page updated

Google Sites

Report abuse