Well, we're a couple weeks into the semester and it's high time to get moving on some implementation. I believe I have the answer to the overall desing of the system. It's sort of client/server type system, where specific functionality is implemented through client programs that interface to the server via named piped or perhaps socket connections. The central server program would communicate with the clients via a standardized protocal and would server as a hub for passing messages, commands, and information between the clients. The server will also centrally store data related to the system and handle all locking and sharing, sort of like a primitive database system.
Thats the design in a nutshell. Now I need to start implementing class definitions that will serve as the main functionality of the server and provide reusable objects for quickly creating new agent programs.
For now I'll focus on getting that implementation underway. I'm going to hold off on building the physicall layout for a while. That way if I need break in the middle I can switch tasks. Plus if need be its easier to rush building track than to rush writting code.
Christopher Kratz

Alright. The overall operation of the system is set. It basically will look like the design outlined in Concept Drawing 1 in the notebook. I'll move that one into the design section of the website. I have decided that to simplify the desing, the server will only listen to the pipe connections and respond only when given a command. The client is responsible for asking for any messages that may be in its queue and asking for any data it needs. This makes it so each client only needs one pipe that will handle communication in a syncronous manner. The client also will not have to worry about checking the pipe for data, instead the client will issue a command, wait for a response, and then the transaction is over.
I spent a long time today thinking about the internal workings of the server side. The message queues will be easy enough to implement. The data tables may require some more thought, at least so I don't try to implement too complex of a design. I do have a general class/object definition and I'm going to try to implement as much of it as I can this week. My goal is to get the server set up to handle the basic protocal I've defined for communication and get the message queues running. Once I have that I'll set up an example with two client programs sending each other messages.
I'll try to post some more info under the design section this week as well.
-Chrisopher Kratz

Well, another week gone by and time for another jounal update. In the past week I did get a basic server program up and running. I was also able to implement message queues for client programs. I also built two test clients and was able to send a message from one to the other successfuly. I still have much more work to do on implementing that framework. For now I think I will work implementing it in stages, while I design the Train OS that supposed to run on this system.
Other than that, I did spend some time cleaning the room up in PAC. Ideally that will give my a much larger workspace when I start building the second section of track, which will be vital to the demonstration of my software product. I'm close to finishing up the wiring of the hall effect sensors on the first section.
I also used up some time looking at some phototransistors and infra-red LEDs and investigating different kinds of sensors. I was able to make a sensor that detected when an object was over it without interference from the ambient light in the room. My real goal in that experiment was to probe the feasability of an idea i had. I wanted to make a sensor that would read a barcode like marking from the bottom of an engine and load it into a shift register. It seems feasable but I'll save that kind of stuff for after my project makes its base requirements.
-Christopher Kratz

Wow, two days in a row. Well technically its the same day, but I'll consider 1 AM yesterday. Just wanted to make an update that I am progressing with the core of the operating system. I'm using the test I mentioned in the last journal to 'grow' my system. I think I have the particulars of the message passing protocol down and the two dummy agents were a good help for hammering that out. I actually am using the one agent to develope the API funtions for communicating with the server. I should change the file name of test.cpp. Its really a sound enough foundation to create the central server process, and thats most likely what I'll do. I'll see when I can copy down the messaging protocol onto some quad paper so I can scan it. My notebook I orginally wrote it in is too messy, plus I changed it a bit. If you look here Server System Test, you can see what I've been working on.
-Christopher Kratz

Ah, yet another journal entry. On to business. I've cleaned up that test system alot more and I think its going to be a great tool for building the server process and developing the client APIs. I have the 'getting a message' functionality, 'sending a message' functionality, and connecting to the server functionality built into some functions and off in there own .cpp and .h file. I also added functionality to the messaging that lets you know who sent the message. I figured that might come in handy. I also added the idea of a service number that would also be put in the message by the system. That way these service numbers could help communicate what format the data is in when it is sent, seeing as how it is sent as a stream of bytes accross a pipe. I probably should clean up the server code and modularize it some more, but for now it works beautifuly. (Actually I have to add some deconstructors for the message queues, but memory leaks aren't that big of a deal.)

I was also thinking of adding functionality to the messaging to support multi-cast messages. Right now they are only point to point. My thinking there was that maybee a new worker process in the system could send a message to another client and register to recieve particular messages, instead of having to alter the existing client to send those messages to the new client.

For now, I'm going to start working on the desing for the components of the TOS. This is because I'm not sure about how to implement data storage in the server component, and I figure that I'll design the system and then build the server to match my needs. Maybee with the multicast messaging I won't even need data tables. Or the data could be handled by another client. Whatever works best I guess.

On another matter, I'm still working on wiring up the track I need to test the system on. I just finishing up on wiring in all the Hall-Effect sensors, powering them, and getting there signal to the AIU's. Which reminds me I have to ask Dr. Pankratz about the BIOS upgrade chip for the command station, which we need to enable interrupt style input from the AIU's.

-Christopher Kratz

Captain's Log, stardate, 012768XY ..... March 8. A bunch of stuff just fell off the ship, and no one likes me. I love that joke, but seriously, on to business. I think I have a solid design for the train system. I'm envisioning four main processes, the first will be the train manager. The Train Manager will be responsible for the following: deciding to start and stop trains, alter speed and direction of the trains, and obey the judgement of the Resource Manager.

The Resource Manager's job is simple. Own the resources. He will hand out and deny access to sections of track. And he will also control the positions of the turn outs. The Train Manager must ask the Resource Managers permission before any track resouce is granted to a train. Therefore, as long as the Train Manager plays by the rules, there can never be a crash. (With the execption of runaway trains.)

Next up is the DCC Manager. This process will handle all direct communication to the DCC equipment and communication of AIU values back to whoever needs them. Probably the Train Manager and the Resouce Manager. This process will abstract the DCC functionality by implementing common commands through the Multi-Process Server messaging system.

Last would be the user interface module. This, course will display the real-time(ish) state of the track and allow the user to issue commands to the system.

Common data between the processes will include the definition of the track layout, which I actually created a pretty spiffy data model for that, data for the locations of the sensors so you can interpret the meaning when one is signaled, and data on where the trains are. I'll implement some pretty simplistic data storage in the Multi-Process Server to accomadate this data. If someone needs some more advanced models they can write there own client to accomadate. I'll scan some of these sketched and put them in the notebook section on monday night.

Oh and I spent some more time today in the PAC. I have all the sensors wired to the AIU's, all I have to do is wire up the switch machines to the AIU's and tie down some wires and it'll be all set. Soldering is fun. I'll see if I can get some pictures of my latest work.

-Christopher Kratz

Walkthroughs tomorrow. I'll have to spend some time getting some material ready for the presentation. I don't really like powerpoint, but I probably should prepare something. I have lots of stuff written down on quad-ruled notebook paper, but that doesn't work well for presentation. I have some media I can prepare and some example programs to run.
Speaking of example code, I implemented a skeleton of the data table functionality today. I was worried about trying to implement data tables, but it coded a lot faster than I thought it would. The data should be fairly functional and I'll be able to expand it later if need be. I will post that test in the design section as soon as I can. Next I have to start working on implementing DCC functions. Then I can build a simple DCC Client and a test UI client to control it through messages.
Well better start making that presentation.

-Christopher Kratz

Not much of a log entry today. This is my remote spring break segment. Fun. Oh well, as for my project I'm thinking about saying to heck with the data tables. To much work. I have a bunch of completely untested code written, but I don't think the data tables will be necessary for the TOS. Like I need to spend time writing a database. The messaging will work fine for data transfer. I'm also adding an additional client to the system. The TrackManager, (different than the resource manager) will be resposible for loading the track definition from file and communicating that data to whomever requests it.
Thats about it.

-Christopher Kratz

Wow, its been over a month since my last jounal entry. Don't think I've been ignoring my project, in fact I've been focusing on it so much I just forgotten about the web site. I have completed the portable layout. In most respects anyway. I could still use some improvement. The current system for attaching the rails from one section to the next is a little cumbersome but it works. The draw clasps work well for attaching the sections together though. The layout seems to work well and there don't seem to be many sticking points for the trains, although there are some odd spots coming out of the turnouts. It was difficult laying the flex track in such tight curves. On the second section I pinned the track into the position, put super glue on the flex track so it would no longer flex, then I glued it down to the cork. That seemed to work a little better.

As far as software goes, to sum it up I've completed 80% of a system, including 50% of an interface. I've written a basic DCCManager, ResourceManager, TrackManager, UserInterface, and the MessagingServer. I've started but not made an effective TrainManager, which is the key to the whole system. It of course came last in the development order because it was more complex and depended on the other components of the system to functon. The other components could be more easily tested individually. Hopefully in the near future I will be able to write an effective TrainManager. Once that is done I can spend some time developing a better interface. Right now the interface has basic display functionality and needs to be improved. Alot of the system code just needs to be cleaned up and commented. The messaging server still needs to have the Mutex objects associated with the messaging queue to prevent errors since the server is multithreaded. The server also needs to be improved with the ability to load a configuration from a file, right now queues and pipenames are hardcoded. I already have a function built in to run a process, so it would be nice to start the 5 other processes automatically.
For now I have to see what I can get uploaded to the website.

-Christopher Kratz

Well this will be the last journal entry. The projects have drawn to a close and even though the system is not yet complete and whole, I don't have a lot of choice. The semester has come to an end and each semester only has so many late nights of coffee and Mountain Dew in them. Although it is enjoyable to write code, drink some Dew, and saw wood till 2 in the morning 4 nights out of the week for a couple months, I'm relieved that the project is over. Its still sad to have to hand in a system that is mostly complete and not completely complete. I have done some good work however, and I don't think it will go to waste. I believe that the Messaging Server in and of itself is a usefull tool for interprocess communications and hopefully can be applied to other projects outside of the train. Oh well, all things come to an and and it looks like we have reached my end on the Train OS project.
Until we meet again.........

-Christopher Kratz