Click Here to go to Home

Computer Controlled Railroad 

::Philosophy:: ::Journal:: ::Progress:: ::Resume::

::Journal::

02/03/09--Trying to figure out how to work the pipes in C#.  Deciphering Kratz's code, thank God he did a decent job documenting...I can follow most that he wrote, have a little trouble following some of his "Objects" throughout, but after further review, I can trace his header files back to the actual .cpp.  The more and more I look, I realize that there is alot of encapsulation, but alot of interprogram communication as well (that will probably take the most time) and I still have to learn where the comport to the DCC is in any of this scheme...

02/10/09--Finally got all the .exes running on my laptop and got c# to grab the available serial ports from the PC and pass to what I plan on making the UI. Found that dialog .cpp holds al lthe controls of the UI from Kratz so now I can begin to start modeling my UI to some of his similarities. Finally learned that VS2008 contains a class/namespace for the use of Pipes in c#, thank God because now I can begin to talk to the other programs, but still not exactly sure how to use the other functions of the other source files that are in c++.

02/18/09--GOT THE PIPES WORKING!! Finally can talk to the other processes, and they recognize it too, which is even better.  C# has its own protocol for handling pipes and it was included in the new .Net framework.  Now I need to start giving the processes actual functions they can handle.

02/21/09--Still having some trouble getting the processes to complete the functions...I know there is something I am missing, but I can't find it.  I think I have to add a 'train' to the resources before I can actually tell the train to start running.  This could be why when I tell the train to move, it says train 16 does not exist.  Hopefully I can find what I am missing before I decide to just use the previous code for nothing more than just a reference.....

02/24/09--Finally got all the DLL's working, yes all three of them but still having trouble actually getting the train to actually move. I found another SetTrainSpeed function that uses the DCC directly rather than trying to send it to TrainMan first, but it says something about failure to set speed from the DCCMan, curious if it has something to do with my message length....

02/26/09--ITS ALIVE!!!!! We got the train moving from my prototype interface... there is video on the progress page if your interested. Now we have the most basic functions of the actual train down, forward and backward only using the DCC to do the controlling. It all had to do with the size of the parameter I was sending into the DLLImport Function. Now it works!!!

03/2/09--We have turn out functions too! Still trying to track down all the addresses of the turnouts, well I know them all, but some aren't exactly working with my interface yet. They seem like they could be a bit or so off.....I will have to do some digging, but if you want, feel free to check out the progress page, there is a video on there with the turnouts.

03/4/09--Having been trying to get all the addresses on the track to work with my interface.... and have had luck to about 75%ish, for some reason, a few of the turnouts are not fully functional from my UI but only from the handheld...I need to iron this out...

03/6/09--Not a whole lot of advancement since the last entry, I removed the bottom of the track to see if their is a way to determine the addresses (or change) of the physical accessory, and found some neat things with the AIU dipswitches and such....Will need to follow up and research, but this is getting increasingly frustrating....

03/10/09--Ok seriously getting frustrated, I have officially wasted too much time on this turnout problem, starting to think it is the implementation of the DCC commands written by previous students...So I need to take a break and play with something else, tried to get the track update (returns status of track and train location) working, but having some implementation issues, will refer to Professionals--(professors!).....

03/12/09--Ok got some resolution (thanks Blahnik) on my implementation problems with GetMessageFromPeer even though its not 100% functional yet (or even close)....And talked to Pankratz and started to come to the conclusion that there is some programming errors in the DCCman implementation from Kratz, it has to do with the layout of the packet for the Accessory Decoder...flipping a bit where it is not supposed to be and not changing one where it is suppose to be??? (the whole state of accessory and accessory a and b deal..)

03/19/09--Its break, I am not working on my project...

03/22/09--Have been trying a sub program to send direct messages to the powerhouse DCC rather than use any of the threads from Kratz just to take out any error so that I can try to debug some things and I haven't had much luck yet....hhhhh.

03/26/09--Still fussing with the turnout issues, but decided to stray a little bit and installed some physical LED's to illustrate which way the turnout is turned.... just need to do something different than trying to figure out the turnouts right now before I smash something....

03/30/09--Hold on a minute...starting to understand the bit patterns of the addresses, come back soon for details....I may have something good.....

04/02/09--GOT IT!! Finally got all turnouts to work without any problems.... this is how the turnout bits work:

bit1: Command Bit tells DCC what is going to be controlled

bit2: Address, 10aaaaaa 11111aas eeeeeeee (a for address, s for state).

04/06/09--Time to work on the Realtime Track Updating: allowing the user to know where the train is anywhere on the track in relatively real time. This is achieved using an AIU and the hall effect sensors that are activated via magnets on the track. Having some problems with stack overflow or something... it keeps crashing when I run it for a little bit, need to iron it out.

04/09/09--Made some adjustments, increased the size of the array that holds the track status (doubled it) and now it catches everything, well almost, if the train is moving too fast, the sensors do not actually capture the train passing, trying to figure what I can do, tried putting more magnets on but ended having the magnet shorting out the decoder!!! (oops....) Also picked up a wireless remote to control the train with, gonna give it a whirl

04/12/09--Played around with the controller a little bit over the weekend and found a library that could potentially be used in c# (SDL library....) But may be way more than I need for this project..... More to come.....

04/14/09--Scrapped my initial plan of the SDL library from online (it is more for if I wanted to make my own controller controlled game...) I did find that the .Net framework has some Microsoft DirectX Controls in it and a very nice simple implementation can be achieved for joysticks and other gaming devices...

04/15/09--Ok created a very nice simple program that runs a 'poll' on the joystick state to find what buttons are being pushed. Very nice simple program using the DirectX controls... Now to integrate this into my CCR... hmm...

04/16/09--SIMPLE! I took the form from the little app I created for the joystick and just plopped it into my CCR, and accessed the form from a button. I then used the states of the joystick to determine how to manipulate the train and track...still working on that

04/19/09--OK I got the train moving back and forth under the control of the wireless controller.... But in doing this I realize there is a little problem (and I am not sure how much can be done about it....) When the Speed of the train is changed, I receive junk in my AIU's for a reading or two, and I think this has to be a collision problem because I broke it down all the way to the worker thread to see where I was receiving poor readings and they were already tainted at the DCCMan, so its either at the Decoder, Powerhouse, or the Cable itself... not sure

04/21/09--Ok I am trying now to have the train turn (basically have the controller control the turnouts in some way) and well having my problems with the AIU's I just decided that its not too hard to just have every turnout turn the same direction, this will achieve the same thing for turning the train down a different strectch of track.... Maybe in the future the AIU's could be ironed out and then it could be made more efficient. I could see the implementation of an Event Handler to handle when there is a change in the state of the track could be helpful maybe but I'm not sure about the collisions problem

04/24/09--Track Prep! Fixing all turnouts, attaching LED's, making sure that all turnouts are set to the same direction upon reset and all the correct LED's light up.... Also toss together a few trains for the presentation so I have a few spares just in case....

04/26/09--BIG SCARE!!!! Accident with the power supply (destroyed) had to drop 55 bucks and get a new one so at least I have a power supply for the presentation. This one is nice and the old one served its purpose. And well it works pretty slick as well so, no complaints.

04/27/09--Hoping Dr. Pankratz likes what I did to the track, FULL FACELIFT!.... (check out progress page)