If this is the first time you visited this blog, you might want to read these posts first:
I am now writing my fourth generation of software for the ALLY.
VERSION 1
Version 1 was written over 10 years ago. It did a fair job of automating a couple trains while other trains were controlled by users. It was mostly hard coded to one track plan and used Transponding as its only requirement.
VERSION 2
Version 2 was a complete rewrite using the same programming language. It incorporated the ability to "learn" the track plan. I also had a pretty good idea of the types of automation and animation I wanted at it's onset so it had quite a few cool features. Its biggest fault was that it was started using speed rather than velocity as the method of tracking train positions. It had to rely on kluges in the code to determine direction of travel when a loco's orientation on the rails was swapped, as a result, it was unable to handle reversing loops. My solution was simple. I removed the reversing loop from the ALLY.
VERSION 3
Version 3 was a total departure from previous versions. It used the Java scripts and JMRI for the operational part of the program and used my favorite Windows programming environment to configure the scripts. Version three used zone influence for a lot of it's capabilities instead of tracking individual loco positions in each zone. This was easier to program in JMRI but required more zones for some features. Where versions 1 and 2 could automate the whole ALLY with just 4 zones, Zone influence required 12 to 16 zones. A new concept incorporated in version 3 was the idea that each decoder acted like a robot. Robots could have pre-programmed behaviors. They learned how to apply some behaviors by watching the human operators. Robots could also perform "scenes" in a "play". Scenes can be triggered by "event messages". Event massages can be sent from; The fast clock, a loco, a decoder equipped car, entering or exiting a zone, or a function key or a change in speed. Version 3 also incorporated the ability to build a list of decoder equipped cars behind a loco. This was very slick. Couple a loco to a string of passenger cars. Pull out of the siding or through any gap between zones and the loco would have a list of the cars in the order they were connected. Each car also knew which loco was pulling it, it's location on the railroad and it's velocity. This opened up all sorts of cools animation features for the lights and even sound cards in the cars.
The multitasking nature of JMRI was a plus in some respects but eventually I decided that multitasking was also going to make it impossible to control more than just a few decoders at one time. Commands sometimes arrived at the decoder out of sequence. Opening and closing multiple throttles for every decoder equipped car and loco on the ALLY often got out of sequence due to the length of time it took to get slot information from the command station. This isn't a fault of JMRI, so much as the natural result of multitasking when there is not an acknowledgement for every command issued. With only a dozen decoders being tracked, I found that the slot table was often getting corrupted and I had to reset the command station several times a day.
VERSION 4
Version 4 is another complete rewrite. I'm incorporating the better features from versions 1 and 2, translating all of the features in version 3 from JAVA to a windows based development platform. I'll incorporate an IP based interface to JMRI so that some of the features of JMRI (running on a separate computer) can be accessed.
New to this version will be the "Zero User Interface" concept.
That is to say that, the system can installed on a single card PC. Then it can be connected to, learn, and run, a unknown layout without the need for a keyboard, mouse or monitor.
Of course Version 4 will have a user interface, but the interface is more like a user instruction manual, robot teaching guide and system monitor.
It will also provide extra utility throttles, and a drag and drop robot behavior editor for those interested in customizing how the animation effects work.
The next post will cover some terms I have adopted. If my use of words like "Zone, Segment, Degree, Tick, etc that confuse you, then read the next post.
5 comments:
Bob,
Good post. I didn't realize you were up to 12-16 zones now on the Ally. Do you have a diagram of where the zones are on the Ally? That would be interesting to see and perhaps why so many are needed.
Thanks Steve.
With version three I switched to JAVA under JMRI. Since this was a new programming language to me, I was not comfortable tackling a full positional tracking system. So, rather than trigger events based on the exact position of a train, I simply used zones as triggers.
In a zone influence system, each zone is assigned certain "tags" or "Sign posts". Each zone can have several tags. For example, a zone in a passing siding, and a passenger station, could have the following signs:
(Zone 1)
SIDING
YARD
RESTRICTED SPEED 15
STATION
A robot entering this zone could warn the operator if they were exceeding the speed limit. OR, it might slow to 15.
A robot seeing the Yard sign might be programmed to turn on the bell while in a yard.
Another robot pulling passenger cars may slow to 15 and then stop when it sees the STATION sign.
A robot assigned to a function decoder controlling the lights in a passenger car may turn on and off lights just like a real crew would at a station stop.
Now lets make another zone that starts a few feet before the siding and extends a few feet after the siding.
(Zone 2)
YARD
SLOW
STATION APPROACH
Here again, a loco robot might sound it's bell when it enters a a zone with the "YARD" sign. Or if it is a through passenger express it may just blow a warning whistle and ignore the slow.
A passenger train robot that is set to stop at the station would see the STATION APPROACH sign and Slow to 35 prior to entering the siding. A robot in a coach might light the vestibule lights in anticipation of stopping at the station.
One more Zone we can add:
(Zone 3)
CROSSING
RESTRICTED SPEED 45
This zone would start prior to a highway grade crossing and cause locos to sound the grade crossing warning whistle or perhaps flash the ditch lights. It would also limit the speed.
Now, we can see that zone influence programming is simple, but it requires the operator to configure all these signs.
For what I just described, it does not take very many zones. If you have six different grade crossings, they can all be wired to the same Transponding Zone, (Zone 3).
If you have three passing sidings with passenger stations, they too can all be wired to the same Transponding receivers, (Zones 1 and 2).
From this we can see that quite a large railroad can be automated with just three zones using zone influence.
However, we are somewhat limited.
What if one of our passing sidings does NOT have a passenger station? We can't remove the "STATION" sign from zone 1 without removing it from all three passing sidings.
What if one of the grade crossings is also in a YARD? We can't add the YARD sign to Zone 3 without adding it to all crossings.
What if we want to add station names to each station like
STATION RUBY SPRINGS
STATION MILL CREEK.
We would need a separate Transponding zone for each passing siding with a station if we want some trains to stop only at specific stations.
What if we want passenger train robots to stop at passenger stations and then hold there until the next station down the line is empty? If they are all wired to the same zone, we can't do that.
When I started with JMRI I only had 4 zones, that is all that was needed with the previous software that was position tracking. While Version three (JMRI) did a lot of cool stuff with just four zones, I wanted to play with automating three passenger trains all running autonomously at the same time. I ended up using 12 of the 16 Transponder receivers I had, borrowing some from the HO and N scale switching layouts.
With Version 4, I will be going back to positional tracking. Signs will still be used, but we can put as many as we want in any locations without worrying which zone they are in. I expect that I will only need four zones for the entire garden railroad, but I will likely leave 8 receivers in place, even if they aren't wired, just in case I want too add another loop in the future.
(I'm working on some drawings, just be patient.)
Hi Bob,
I'm pleased to find your new blog and look forward to learning from your experiences.
Do you care to tell us what environmant/language you are using to develop version4?
Also, as you say, much of what you are doing has not been done before. Much of it is very complicated. I understand you don't want to scare folks away from DCC, but please don't leave out all the nerdy stuff.
Have you considered tagging your posts (begginer/interrmediate/adanced) to help folks read only those at their level?
I just hope you don't leave out all the details as in a lowest common reader type of way. Some readers like me may actually try some of your achievements.
Keep up the great work.
Josh
Thanks Josh for the kind remarks.
You wanted to know about the Development Language, Nerdy Detail, and TAGS.
Development Language.
I'm using an old package called Toolbook II Publisher. Originally written by Asymetrix.
I started using it back when Windows 3.11 came out. It uses a language called OpenScript that looks a whole lot like Visual Basic. In fact, one could write code using Visual Basic syntax. However, it also allows you to include Java, Active X and C++ or call DLLs. It is easy to embed JMRI like scripts into the application and then use visual basic like code for the drag and drop user interface. It has much better editing and debugging tools than Visual Basic, in my opinion, but maybe that's because I am comfortable with it. The nice thing I like about it, is that it runs flawlessly on every version of windows right up through Vista. On Vista, I can even run multiple copies of the same program as different users without any problems.
Since I have used this at work for years, I have a large library of routines that allow setting up chat and web servers from within my applications and all sorts of drivers for serial hardware like the PR3. Of course I already have a parser written for LocoNet and the MS100, so that gives me a head start in version 4.
I don't mind sharing scripts for specific tasks and would be happy to see any examples that have been converted to Visual Basic or some other language.
TAGs
I sort of warn people at the beginning of each post, but, Yes, I will try to tag each one as you suggest. I, haven't figured out how to use tags to display only posts with certain tags, but, I'm sure a lot of people have.
The Nerdy Details
The little pole at the bottom of each post heps me measure what people find helpful. Also, comments like yours.
I have 6 more posts saved a drafts. Some are waiting for the weather to bet better so I can take some pictures to go with them. Some just cover difficult topics that are hard to explain clearly. When the topics get to technical, I've decided to move them into Google Docs and publish them as HTML pages. I'll provide a not technical post in the blog with a link to the nerdy details. I think that will help people who would get bored real quick with 100 lines of JMRI scripts, an explanation of Slots, or a detailed installation guide for Transponding.
Thanks again for your comments.
Bob
Hi Bob,
Thanks for taking time to reply. In your software post, didn't you say you'd be moving away from your Asymetrix environ for v4 so you may be able to colaborate with other hobbiests? VB.net Express is free! I know how comfortable we can get with our tools and old habits are hard to kick, but the ability to share and work together may outweigh the pain of switching.
Keep up the good work.
Thanks,
Josh
Post a Comment