Warning: "continue" targeting switch is equivalent to "break". Did you mean to use "continue 2"? in /homepages/45/d549400858/htdocs/nicklebyhousewebsite/templates/sdr_template_nov17/functions.php on line 199
Not much had happened since last October. We had partly completed the "steam excursion" schedule, but a watcher had to call all the block signals where the train was required to stop. For it to work properly, we needed all the rest of the signals to be added to the railway and for Traincontroller block signals, when red, to force a SIGM20 signal to red. That pretty much took two days to resolve - adding in the end 13 new signals.
There are still a few more needed:
At the top of the hill, on approach to Portsmouth;
The four fiddle yard roads that take two smaller trains each need "intermediate" signals;
The long block behind Portsmouth and running up to Petersfield needs to be split into two. That will mean a visible signal, and a hidden one. The catch is we have a spare sensor to add a stop marker for one track, but not the other (power zone G has 15 of 16 sensors used, but zone C has all 12 of 12 sensors used). I do have a BD4, so I could in principle add one more set of sensors to zone C.
Railway weekend October 2018 - so I had to do something!
I want to get to the point where you can run a "manually driven" train around the railway on a Traincontroller schedule. That meant being able to see where the trains are on underground sections, and see the signals. The simple answer: CCTV.
I was able to get on ebay a pair of 7" monitors, each of which could take feeds from two cameras. I also got three miniature cameras. o provide light, I got LED tape lights. The cameras are mounted to the baseboard and look along the track pretty much head-on.
My initial assumption was that I should have lights above the track I wanted to see, but not elsewhere. That resulted in very poor image quality. We added diffusers; it just kept getting worse. Eventually we found the solution was to have light everywhere, with no "blacked out" zones. The image quality was much better. We added two aspect signals, with the direction reversed so they face the cameras.
So, a simple solution, that works well!
There is a new version of Traincontroller: version 9, requiring an upgrade.
The new TC9 converted the old TC8 files uneventfully. Its appearance is quite different, but we seem to have got used to it quite quickly.
A significant new feature that should have been useful is the crossing gates symbol on the switchboard. We have logic to operate the level crossing in each of 16 routes; having all that logic in one place would be much better. Unfortunately we haven't been able to make it work here. The operation we want is:
- Lights start flashing
- wait 4 seconds
- barrier comes down
- wait 4 seconds
- train can now cross the crossing
We can't find a way to do that. You can't have an operation on the crossing - you can only set at DCC accessory address. You can add the logic into a flagman, but you can't stop a train driving onto a crossing until the flagman operation is complete. Yuo can set a "switch time" on the crossing, but that time adds to the time before the barriers come down.
Tony and I have had another busy operating and development weekend 30 Sept - 2 October 2016. Here's what we got through.
Some topics we've looked at are:
- We added the interlocks to the control panels at Portsmouth and Clanfield, so the manual operators there have the ability to reserve track and request schedules. The one in Clanfield is done using routes, rather that reserving blocks.
- We looked into why we'd created "cycle" schedules last time. More here!
- We've develop more schedule sequences so trains can go for a run. There's more detail in a separate article about that.
- We've added trees to the backscene on the run up to Portsmouth. Previously there was an abrupt change in brightness of the backscenes where a rural one joined an industrial one. More to do, but it's a start.
- We've added voice announcements to the end of some schedules, where manual intervention needed. It is done as a scheule operation, so it can't be specific about the train type (ideally you'd say "driver required" only for a passenger or goods train requiring a shunting operation). We haven't yet looked at using a different voice: essentially can the Windows script specify the voice to be used.
- I'd wired up a batch of signals near Petersfield in the last few weeks. We programmed them up using Locoanalyse, and spent quite a while getting the logic right. It does appear that board 4 had the most recent SIGM20 software, but board 5 had older software: it did not properly set when "next signal is red" was programmed. With a chip change it was fine.
- We've found a way to delay a train leaving Petersfield to the left, so that the level crossing barrier has time to come down. It needed operations on each route through the crossing with the required time delays; having the delays in a flagman triggered by the route didn't make the route wait until the operation was completed. Read more.
- We found that trains were still sometimes getting shown a red signal while running through Portsmouth reversing loop. The problem is because the point into the diamond crossing needs to be set back straight, and that should be done by an operation on the release of a route through the crossing. It was on some routes but not others.
- I've added more photos (particularly of Portsmouth) for the website front page. Also Tony has taken a video using a 360 degree video camera: so there could be more views to come.
- I modified a wagon in the small goods train to have a magnetic coupling. That should now be fully usable.
- Petersfield platform 5 had trains stopping instantly when the hit the start sensor. It was as if the stop sensor wasn't there. We deleted the sensors and markers and re-created them - which solved the problem.
We were starting to get some regular activity on the railway in early Summer 2016, with several operating sessions. Then came the new kitchen, and the shed was filled with non railway "stuff" for a couple of months. That's now mostly gone, and we can start to look at the railway again.
I spent this weekend sorting out wiring and block detection in the approach to Portsmouth station. There were two separate issues to address:
- Trains had been exiting Portsmouth driving on the right hand track. I added a unidirectional critical block at the bottom of the hill up to Portsmouth on the approach side, so trans can't depart on that track. This needed one new sensor, and there were two sensors available on a BDL168 that were connected to the same power zone. However, it also turns out that the schedules had allowed that route - I've removed some blocks and routes to make sure there is only one "exit" track.
- Shunting operations in the station throat: the two blocks at the entrance to the station area didn't exactly match how the electrical detection was implemented. The detection made sense from the perspective of setting signals according to train movements; but they didn't match well to permit tracking of trains. A "proper" solution would have needed 3 new detectors. I've reached a workable solution with no new ones, just by reconfiguring. Now the final curved point onwards on the exit road belongs to the beginning of the block running down the hill to Eastleigh junction, rather than belonging to the end of the block in the throat. All the expected shunting operations result in correctly tracked movements. There is still one inconsistency - the point into the container yard is incorrectly placed on the block diagram, but train tracking follows all train movements correctly.
Earlier in the week I made some improvements by editing a couple of schedules, where the full set of required routes weren't included. This was probably the consequence of "copy a working route then edit it" with over-enthusiastic editing. Te result was a schedule sequence where trains got most of the way through a sequence then stopped in the fiddle yard; the reason was because there was a planned exit from one track in the fiddle yard but not the others. The sequence would have worked correctly on that one track.
Schedule sequences, now we've got to the bottom of that problem, do appear to be the way to go. We can create simple "base" schedules for the main components of a train journey, then create specific journeys by chaining them together. We've been able to create longer journeys involving several laps of the railway, for example.