This will be my last entry in my blog. It has been roughly two weeks since my presentation, and if I am to be honest, I have not worked on my project since. As my classes wrapped up and finals approach, I decided that the approach I blogged about following my presentation would be how I end the semester.

I have in my mind completed the task I was assigned. I designed an operating system that could support multi-user operations. I designed prototypes of CABs to interface the system, and showed that they indeed can control trains on a track exclusive from other users. Though I do not have complete models of those CABs complete, I know that the principles behind it are sound.

I will be giving my defense of my capstone this Tuesday. Between now and then, I will be prepping this site do be turned over. I will also be printing off all documentation of the program, its proper usage and shortcomings, and everything else that is required.

It's been quite a semester - one that has gone much too fast. I wish I could have focused solely on this project in the 16 weeks I was allowed. Work, other courses, friends, family - everything seems to just pile on and some things inevitably get put on the backburner. I tried my best to make sure that this project was never the one to be put in such a place, but at times it did. I do not regret the choices I made; they were all invaluable to the learning process.

One thing is for certain: this will be a capstone experience I will never forget.

Tonight was the night that everything came together. I presented my project to my professors, peers, and friends. The presentation had one hitch, which was entirely my fault and not the programs. While demonstrating that two trains moving toward each other should stop, I neglected to set a turnout so that the trains actually were facing each other. The one train acted as it should by stopping at the unset turnout, while the other appropriately moved through it. I did not have time to reset the demonstration, so I moved along.

Overall though, I am extremely with what I presented. I did not complete the User CABs using PHP, and I did not fix the bug during disconnect. I do not know if I will be able to address those at all, as I have other class work I have been putting off for far too long to focus on this. However, I will try my best to document everything that is done as well as everything that is not. I feel at this point that approach may be the best course of action.

It has been awhile since I have updated my blog. Since last Sunday, I have accomplished quite a lot:

• Trains have an occupied status that allows or disallows users to try and control them when they are already occupied. My server displays correctly show which trains are currently in use and which are not.
• I have tweaked a lot of the Master CAB to accurately display what the server has written to the files. The CAB will now display and remove trains when the server adds and removes them, as well as reset its status so that it is always ready for the server to add a train. In other words, the Master CAB does not need to be restarted when a new server instance boots.
• I began creating the User CABs via HTML and PHP. They can accurately display the file contents and controls.

There are two major issues that remain before I present:

• I need to find out how to reprogram a locomotive's short address with the DCC handheld unit. I do not have my server set up to accept user input of long addresses, as the address is saved as a single integer. Unless I can find out how to reprogram locomotive short addresses, I will only have two locomotives that will work for the presentation.
• I have run into some restrictions with PHP and the User CABs. I need to have button clicks call PHP so that the new information can be written to the files. I am not familiar with this, so hopefully Dr. McVey will have some resources for me to work with before I present. Otherwise my presentation will be limited to a single train via the Master CAB.

I really hope I can resolve these issues before I present. However, I also need to start preparing my presentation, so at this point I don't know what will happen. However, as I look back on the semester, I am happy with the work I have done. Hopefully I can wrap things up nicely in the next two weeks before graduation.

And no, not with my PC (*knock on wood*). The physical railroad components - such as the sensors and rails - are proving to be quite a bit of a challenge. I tweaked a lot of my code today, and I believe that most of what I intend with the logic for trains is done. Trains are stopping at dead ends, turned-away turnouts, and sections that another train occupied. I am able to change their direction and appropriate reallocate its track ownership as well.

However, I am having a lot of derailments and sensor misses along the way. I am worried that I am going to be unable to demonstrate and present my server, as the trains quite frequently derail or get lost when a sensor is missed. I'll have to talk to Dr. Pankratz and see what we will be able to do in the next week to alleviate some of these issues, but I doubt we will be able to do much. It seems like the derailments have to do with the tight corners and unlevel table, while the sensor misses seem to be random. Sometimes they recognize the magnet, and sometimes they do not. I'll have to play around with the magnet placement some more, but I am heavily restricted to where they can fit underneath the model trains.

On a different topic, I planned to meet with Dr. McVey about WAMP tomorrow, but a snowstorm this weekend shut the campus down, so I'll have to wait until Tuesday - which will be tough because it is advisement. I believe my logic is ready for the multi-user CABs, but it will be hard to test with the finicky railroad. Hopefully things come together, as I am now 11 days away from my presentation.

One thing I had neglected most of this project was aesthetics and displays for the server. I initially wanted to reuse Brice Hilgemann's display, as he had many appealing graphics to show a user what the railroad looked like. However, I found his C# form inextricable from the logic he used to manage the railroad resources, and so I simply ignored my lack of displays. However, debugging the code has turned to become too time consuming, and so yesterday and today I spent some time creating one, and this is the rough product:

I still need to adjust some of the sizing for labels and text boxes, but I am proud that I was able to create the track elements dynamically, and so it is able to be used with a different model railroad if one is ever built again. It shows where a train is AT, and what section a train OWNS toward which it is moving.

I want to add functionality for this form to add the trains to the server instead of having to add trains directly to the file. However, now that I have a display, fixing some of the issues with my logic should be a bit easier.

I just finished up writing a few chunks of code to have a train stop when it tries to request its next section and the section is occupied. I am able to issue a forward command after it stops, which is not good, but I will look at that tomorrow. I also found several bugs-in-waiting along the way which I resolved, most of which were in my writing to the train file after something happens. I am happy with my progress today, but I am tired and I plan to sleep in a bit tomorrows since the class meeting was cancelled. 

After a bit of tinkering around (six hours worth...) I finally have my Master CAB able to wend commands to the server to switch unoccupied turnouts. I also wrote a method that synchronizes the turnouts with their direction in the file upon start up of the server. I learned that communication to the track is REALLY slow, so I placed some port.Read() calls after I write to the port. This allows the command the port to complete before the server continues on.

Let me start by saying, "What a PAIN in the BUTT!"

Now that it's been said, let me explain. From the beginning of making my Server, I had been unsure exactly how AIUs and sensors worked, what the difference was, and how best to represent them. Brice Hilgemann's code did not make this task any easier. There was hardly any documentation on the sensors and AIUs, I basically had to scrub his code line by line to finally understand that the sensors are wired to the AIUs, but not in any sensible order. Additionally, some AIUs have "blank" sensors in their indices, further complicating the matter.

However, I was able to make some files to represent which AIUs hold which sensors, and which sensors are tied to either side of a track section. I added code to my server to read in those files and create data structures that allowed me to write a function to poll the AIUs and read the sensors' values, compare them to their corresponding data structure, and then to move a train if the sensor was adjacent to its location in the direction it was moving!

All in all, it was a successful weekend. It's hard to believe there are only two weeks left, but I think I have most of the heavy work done. The next things I want to do are finalize my response from the server to my master CAB, and then hopefully start designing my WAMP CABs. I am worried that I will not finish the latter part. I am proud of the work I am done, and I will have running trains for my final presentation. With hard work and some luck, the WAMP will come together smoothly. I think it will, given how clean and structured the server I created is.

I hit a milestone today: I have my code sending commands to the track! Although I have been testing railroad communication and protocol with Brice's code, I first implemented those features into my server, and was able to modify a trains speed while it moved on the track!

I am currently working on creating a C# class separate from my Train and Turnout classes to command the railroad so that they are not inseparable, as that is one of my big goals is to keep different components modular in my project.

I am feeling good, though it is now less than three weeks before I will have to present... It's going to be a busy month, but I am confident.

After some miscommunication, the track is now in its new home. Yesterday Dr. Pankratz and I disassembled the track, but due to an April blizzard (yikes!) we chose to wait before moving it. Today was much nicer, and so I rounded up some friends to move the track into GMS. However, I received an email shortly thereafter from Dr. Pankratz to set up the track in the South Teaching Wing in the CS lab! I have no desire to take this thing apart again, so hopefully I can get my testing done before I devote another round of effort to move this beast again.