Weekly Vlog

A look at how this project came together.

3 May 2017

Final updates and documentation of code. I've mostly been cleaning up the code, puting repeated lines into functions, and generally making it presentable for the website and defense.

27 April 2017

I presented my project today. Not sure how it went. It felt good to get it finished.

In other news, I've reworked the recovery algrothem so it appears to work. It's rather dependent on random numbers instead of finding the best path but it works. It also has a tendicy to missidentify what type of crash is happening.

26 April 2017

I found a rather interesting problem when making some last minute tests before my presentation. Trains going toward each other at the same speed with an even number of track sections inbetween will skip over each other rather then crash. To alivate this problem I've adjusted the OS so it calculates two track sections in front of each train rather then one. This makes sure no train will have this problem.

Unfortunatally this introduces another set of problems, it breaks my recovery algrothem. For the moment I've commented it out for the sake of my upcoming presentation but I hope to fix it soon.

25 April 2017

I've made a common directory to hold all files. I've simply put a directory called "traincommon" on the C drive that both the OS and Display Program communicate with. I will need to make sure to make a note of this in the ReadMe.

The common directory now hold all files and the track, trains, and turnouts are all passing the corrent information from the Display Program to the OS and I've finally been able to test my recovery algrothem. It appears to be working but I've learned just because something appears to be working dosen't mean it is.

24 April 2017

I was having problems with passing data between the OS and Display Program in reguards to the trains. The turnouts work but the trains didn't. I met with Dr. McVey and Dr. Pankratz again and they determined some locking mechanisms to stop the Display Program and OS from opening files at the same time. They also suggested slowing down the timers on the Display Program's side and only updating files as needed rather then every tick. Another suggestion was placing all files in a common directory so the finished program can be exported to other computers.

As it turns out the problem was I forgot to fill an array filled with classes with empty classes. But slowing down the timers appears to have made the program more stable.

18 April 2017

I've gotten the turnout handler passing information to the OS dynamically. Everytime a turnout is changed it updates the OS and it updates it's internals to account for the changes to the track.

I've also bitten the bullet and hardcoded a track due to the difficulty of working the directional train properties. I still need to work on passing the train data from the Display Program to the OS and then passing adjustments back.

10 April 2017

I met with Dr. Pankratz and discussed the project. In particular we focused on understanding the Display Program. We compared notes and came to similar conclusions. First, there's an internal timer that handles the movement of the trains which will be very useful to determine. Second, there's a handler that activates everytime the user switches a turnout in the Display Program.

I hope to piggyback off these two functions to pass data to the OS.

29 March 2017

Once again I met with Dr. Pankratz. He's not hopeful in my chances of determining how the Display Program works out how the trains progress on the track. He has suggested simply hardcoding a large track into the OS.

I hope to avoid that but in the meantime I've decided to work on the turnouts and trains themselves.

24 March 2017

I've been working in reading in additonal infromation from the Display Program into the OS. The biggest stumbling block has been understanding how the Display Program works. There is a huge array of different classes and files that are interwoven to operate the program. In hindsight, I should have taken notes; I've found myself going over the same code over and over, trying to understand what is really going on.

15 March 2017

I've written part of the back end operating system. Now the back end can read in track layouts made by the display program. This is done using the built in .bmv files. I simply read in all the information stored, though this means I need to have a save file already made rather then being able to create a new track.

A secondary problem is the save file dosen't have a good way to figure out how a train would progress through the track. The save file only really stores the location and type of track. Determining which section of track comes next depending on the train's clockwise/counterclockwise movement is problematic.

Now I will have to figure out how to pass similar data about the trains and turnouts.

16 Febuary 2017

I presented my prototype data structures to the class and was very encouraged. Everything went well and I got some really good feedback. I've come to the realization I need to write my end of the program in C# to help with threading and locking differnet portions of the program out of files that are being adjusted. Unfortunatally it looks like I will have to modify the old program to make it write down to a file the information I need.

9 Febuary 2017

I've been laying out my initial data structures for which data mined from the display program will be placed and adjusted to make sure no trains can crash into each other. Now I need to get started on mining the data out of the display program.

2 Febuary 2017

I've continued to look at the orginal project and I ran into Jack Ward. We had a discussion about the project and he gave me some pointer and things to look out for includling circle eights and other bugs in the orginal program. There seems to be some problem that a train cannot be turned around as the background code cannot accept the left wheel being turned around to the right track.

27 January 2017

After examining the display program I met with Dr. Pankratz again. We discussed the existing program which I will be using as the display portion. I will write my program to take information from the old program, the layout of the tack, turn singles, which sensors are tripped, number and speed of trains, and their starting position. Which will be put into an array that I can access and adjust.

I will have to mimic the existing railroad behind the scenes in the OS and determine if any of the trains are going to hit each other. Then I will adjust the speed of the old program, stopping the train that is going to hit the another train, and creating a blocked train array of trains that are stopped but still storing their usual speed.

For next week I need to study the existing program to learn it's data structure and find the optimum point to transfer information between system. I also need to figure out how and when the old program stores information in text files and when it gets it out of the text file so I know how to affect the display.

25 January 2017

Was assigned my project and met with Doctor Pankratz. We discussed the project and determined that I would need to study the display program made by Jack Ward, a previous student, and use it as the display part of my program in lieu of actual trains. I would have to write an OS, with users being individual trains, and a control program myself.