Wednesday, December 24, 2008

Progress Report 16 - Freight Operation

Although Peckforton station has not yet been completed (see Progress Report 15), I am beginning to think about how the line will operate. With five stations and the copper mine, freight operation will become as important as passenger traffic and so I've decided to create a simple system for generating and managing freight traffic.

My indoor 00 line comprises a terminus to 'Denny' fiddle yard - a four track reversible cassette. I use a card system and dice to decide which wagons should remain and which should go on the daily pick-up goods. For the garden railway, I needed something a little more sophisticated. I have for some years dabbled in an amateur way with a relational database (4th Dimension - now simply 4D) which was given away as a freebie on the cover disc of a computer magazine many moons ago - version 6 which is way out of date but still works! This sophisticated application includes a programming language for handling the data. After a considerable amount of trial and improvement, I came up with a computer-based system for generating and managing my freight traffic.

As with most things I do, the system is simple and straightforward: I want to spend time running trains, not operating a computer!

4D is a relational database - ie sets of data can be related to each other. One dataset holds information about the locations.

As can be seen, The name of the location is entered plus an abbreviated name. In my database, one location is designated the 'Central Location' to which all the stock can be returned, say at at the end of the season (or a session). I have only test-run the system, but it is my intention to store the stock on separate shelves for each location at the end of every running session, so operation can resume 'where I left off'. However, the 'return to base' option will be useful at the end of the season or on occasions when I just want to start-over.

Another data set holds information about each wagon. As with the locations, each wagon is given a unique identification code. In addition, the length of the wagon is indicated to ensure the system does not generate trains which are excessively long. The wagon's location is entered and a percentage likelihood of it travelling from one location to another. For example, in the above example, this tank wagon has a 50% chance of going from BM (Beeston Market) to BK (Bickerton) but will never go to BY (Bulkeley) or the Copper Mine (CM). This screen lies at the heart of the system as it determines which wagons are most likely to be rostered into trains and which locations they will visit.

Finally, this screen is used to generate the freight trains. The potential length of the train is entered and a train is generated based on each wagon's current location and the likelihood of it travelling elsewhere. If I decide the train presented by the computer is acceptable I hit the 'Accept Train' button and the system assumes I will then move the wagons to their new locations. Alternatively, if I'm not keen on the train which is generated I simply keep clicking on the 'generate train' button until it presents me with something more acceptable.

I've not used the system 'for real' yet (I'm still accumulating sufficient stock to make it viable) but I've included an option for generating a series of trains for an operating session and printing out the rosters, so I don't need to keep returning to the computer each time I need a new train.

Once I have a chance to get back out into the garden, I will let you know how the system operates!

Update: June 2013
 I've now been using the freight management program for around five years. Although the program is somewhat idiosyncratic, I am now used to its little foibles. What I like about it is that the semi-randomised way in which the freight traffic is generated means that sometimes I am required to carry out freight movements which I would probably not have thought-up without it (eg see Progress Report 46).

I am now rewriting the program in VBA Basic for MS Access as my original version of 4D does not run on Windows 7.

Until I've got to grips with Access VBA programming, I am forced to use my old desktop computer which runs Windows XP - but I am not certain as to how long that will last as it's already creaking somewhat. I'm finding Access to be a bit clunky but that might be because my programming skills are fairly rudimentary at this stage.

Update - March 2015

 After battling with the complexities of Access VBA for over a year, I had to admit defeat. There were some aspects of the program I just couldn't replicate - the logic of the programming language were beyond me. I then came across Livecode - which is a freebie programming environment which is based on Apple's Hypercard programming language, HyperTalk. Having used this many (many) years ago and marvelled at its high-level conversational approach to programming, I have now started implementing the program in LiveCode. I have found it (as with most Apple derived software) to be a lot more intuitive than VBA and have already made more progress in a few months than I did in over a year previously.

Hopefully, I will be able to complete this re-programming in the next few months. LiveCode will apparently create standalone applications which will run on any platform, including Tablet PCs. Fingers crossed!