Update of January 27, 2002

As of right now, I have 2 major sources for information on this project.  One is the National Model Railroad Association web page.  This is where some of the standards in the model railroad community come from.  These will be important, as I have inherited this project from other students.  Hopefully they followed these same standards.

The other source I have found is a manual for System One.  This is where information can be found on codes and standards for the remote control can be found.  This is important because a large part of this project is mimicking the remote using a computer. 

At the moment, there is some thought to changing my project.  This would evolve something with trains rather than engines.  Engines are of course just that.  They are the single cars that traditionally pull the train.  The train would be a collection of cars behind the engine.  The intent of using trains is to represent processes of different lengths of time.  This whole model train is meant to represent an operating system.  The trains are the processes and the track segments are the resources to be allocated.  When introducing the element of multiple cars on each train, more problems arise.  With our system, there are light sensors to tell the operating system that a train is moving off one track segment and onto another.  With trains of length, this would be increasingly harder since there is no real way of knowing what train the sensor is “seeing”.  Plus there is the issue of each car setting off the sensor.  This would indicate to the OS that each car is a process that is finished with that track and in need of the next one.  Obviously this would not be the case.

Another approach to this problem is to deal with the coupling and decoupling of the cars.  This could lead to problems of changing the cars order and all sorts of switching trains around.  Possible issues to keep track of what train is where and how many cars each train has.  These are tough problems to solve given the current setup.

Update of February 03, 2002

So far, I have put together an extra car that the engine could pull.  I did this rather quickly and need to go back and put the details on the car.  I also changed one of the couplers on the engin # 32 I think.  The intent here was to determine how the photo sensors picked up the multiple cars.  As it turns out, because the level of sensitivity can be adjusted the cells can pick blink when the train goes over of they can stay on.  This depends on how I choose to have to cells set.  I am guessing that I will want the cells to be triggered by each car.  This will allow me to count how many cars have gone over the cell.  Right now I am thinking that in a data structure for the train the number of cars will be stored.  This will allow me to see if any cars have decoupled. 

Right now I really need to sit down with the OS which already exists and figure it out; find what I think would be useful and what wouldn't.  I also need to formalize my ideas on how the OS will deal with the train.  These are things I hope to have finished this week.  From there it is a matter of implementation I hope. 

Update of February 10, 2002

I have figured out a bit about the couplers for the train.  From what I have read at the National Model Railroad Association as well as a few other sites on the web, it seems as if the Kadee #5 is the coupler to use.  Kadee's site is here www.kadee.com.  I think that this coupler and some decoupler is what I want to go with.  Either the delayed decoupler of a normal magnetic one.  The delayed one sounds like it allows a bit more time to maneuver the car where you want it after it separates from the train.

I am still playing with the physical train to get it to move via the computer.  I think I have isolated the functions in the dcc.dll but I have a few questions about them I need to figure out.  I plan to have a train moving, stopping and reversing by Wed of this week.  If I can do that, then I can start to figure out the algorithms to make the train behave in a manor consistent with the requirements of this project. 

I have some idea as to how I am going to use the photocells to detect both the speed and the number of cars on the train.  By looking at 2 sensors I will obviously be able to calculate the speed between these two points.  By counting the cars at the first sensor, knowing how many cars are on the train and by using the second sensor I can figure out if there are uncoupled cars. 

Other issues that have been addressed are stopping the train if another engine being controlled by another source is in the way or using resources that I am requesting.  Some guidelines as to the manor in which other trains on the track will behave have also been set forth.  For example, a train cannot interrupt my train in the middle of a turn out.  That is to say a manual user cannot switch the track if my train is over it.  Dr Pankratz and myself have also determined that a test needs to be available to see if the OS has control of the switches.  There is the possibility that the program will not be able to throw these in which case my train will be blocked.

I have also been looking into the scale conversions for HO and the real thing.  This would hopefully enable me to determine its relative scaled speed.  That is to say, if my train goes 5 feet per min what would the real train be going?  Right now I think it would be a bit less than 5 mph as the scale is 1:87.1.

That's it for now.

Update of May 5, 2002

Major problems I have had have been with the photocell sensors.  I think something else should be used as a sensor for these trains.  They caused many problems with development from the simple stand point of needing to be recalibrated every time the light in the room changed.  This included when the sun moved from morning to afternoon to night.  Some type of sensor that would produce consistent results would be most helpful in developing a project like this one.  This really became a problem when I had to present what I had worked on.  The room where this was all developed had vastly different lighting than was available for the demonstration.  So, as a result, my project's demo failed.  This is just something for people working on the train project in the future to keep in mind.

I must say, that perhaps the most useful thing for this project was to have meetings with both Dr. Pankratz and Dr. McVey.  Being able to bounce ideas off of them and just hear my own ideas out loud was useful.

I had some bizarre problems with this project that I haven't really run into while working on a project, or at least have not noticed before.  When I was working on making the train obey a batch file to go forward around the track, I never really thought about how I was going to make it go backwards.  This ran me into some difficulty when I finally tried to implement that part of the train's motion.  I kept my scope of the problem too small.  

The couplers also gave me some problems with working consistently.  After a while of playing with them, lubricating them and making them open and close a lot by hand, they eventually got worked loose.  These just took playing around with to find the right hight for them to work.  Too high and they wouldn't get tripped by the magnet, and if they were too low, they would get caught on the track in the turnouts.  Also weight in the cars is important. Extra weight needs to be added and it needs to be evenly spread over the car so one end is not heavier than another.  I cover all this in the web page, but I thought it was important enough to mention again.

Well, it's now May 6th and I think I'm going to end this web page's development process here.  If there are questions about the project, they can be emailed to me at riggep@snc.edu