More Suggestions

[westdetroit]

A few more items that might be helpful. A couple minor and one major.

1) Not sure if this can be accomplished but it would be nice if trains can simply clear up in a block, as well as exits, to simulate trains leaving the main line at "hand operated" switches. It would make a dispatcher's screen a little "cleaner". I'm not sure what logistics would be involved to accomplish this feat??? Of course hand operated switches at passing sidings would still have to be "displayed" to keep individuals from "cheating" by putting a 5800 feet train in a 5600 feet passing siding.

2) Being able to apply blocking devices where trains are working on mainlines, as per the rules, to "protect" cars left unattended on the main. The color would be magenta. This ones minor of course but realistic.

3) Crossovers (A combination of two switches connecting two adjacent tracks. When lined, this switch combination allows movements to cross from one track to the other): Maybe we can have both switches of a crossover line together, in unison? of course the maintenance would remain separate. Just a minor thing but it is per operating rules.  

Thanks.

[westdetroit]

Addition to item #1. A train would clear the specified block only after the rear reaches the end and somehow include a built in "delay" to simulate the time to line up the switch and to line it back normal. And, just as it can be done for work locations within a block in CTC, maybe specify where in the block the hand operated switch is located...

[DPump]

(1) Well - there is an idea that I had a few days ago ...

Since in a different line of conversation you talked about manual operated switches (throwing directly by clicking on the icon) in context of automatic signaling - I thought it would be nice to have switches that only a crew on the ground can control, but still show them and their status on the grid. Everything would be the same except you can't throw or lock them, because they are not remotely controlled. There needs to be something that would instigate the virtual ground crew to throw them. This is also for cases when switches fail to throw (like TD3's switch failure).

(2) If cars are unattended but still present (via split and later merge), the block is occupied. If cars are assumed to be left on the main while the train works somewhere else and you don't want to use the rather cumbersome split/merge (it is schedule based and thus not very flexible to address daily variations), the block can be set to "maintenance blocked". Are you talking about something similar to maintenance on blocks, lets say "protect blocked", with just a different color?

(3) There is something in the works to have "protecting" switches, which are those not traveled by the train for which a route is set, as to prevent loose cars from adjacent tracks to roll into that train.

This is more powerful than just having two switches linked together as TD3 does. As per rules (in some jurisdictions) switches need to be aligned for protection only for regular routes, but not for switching routes. Furthermore, you can set protections if the route you're protecting does not have switches, but there is a crossing with a minor line that has protecting switches - sometimes with the purpose just to derail a conflicting movement instead of running into the main line. Moreover, besides of regular switches, we have also slip switches, single and double, in our inventory, which can make it very complicated. Finally, there may be some requirements to have switches aligned beyond the signal at the route destination - just in case the rails are so slippery that the train runs through the stop signal (won't happen under normal situations and we don't have impacts of the weather included in our simulations - yet).

All of this can be addressed. However, at least for the time being, those protections need to be set case-by-case by the route author to be included in the scene definition file.

[westdetroit]

Hi Detlef. I think we're somewhat on the same page but I took some comparison pics to help clarify some things.

With regards to 1) The switches labeled "Electric Lock" on my Chicago West territory would be "unlocked" by the dispatcher for the crew on the ground to throw, which would be a nice feature as several of my routes have them, but I mean some switches are not needed on the dispatchers display because they are operated by the crew on the ground so I was thinking that the train would just leave the territory within a block (say B332 for example), like Pine Yard, instead of an exit (where the arrows are).

2) Yes, I can put a "block" for a train working if there are more than one blocks available between interlockings but I can't if there's only one block between interlockings and there is a train "working". I should be able to and the standard color for this is magenta as illustrated in the attached pic. That is a screen shot using my ATCS display of an actual dispatcher's display, created using TD though. The magenta indicates there's a blocking device applied and the track is occupied.

3) As in the example of CP-501, if switch 5A is thrown so would switch 5B, as labeled by an actual interlocking chart. They are labeled A and B to indicate they work together. Of course, maintenance issues would occur separately.

Hopefully the attached pics helps. Thanks.

[westdetroit]

P.S. In regards to 3) I believe you are referring to derails and those would be cool to have as well.

1) Of course the switches for the siding would still remain so the siding could be used. So, in the above example the exit block would be the siding (B332) because that's where the switches for Pine Yard are located.

[westdetroit]

And one last example pic from my ATCS program of a blocking device applied and a block occupied (the magenta colored block).

[westdetroit]

Ugh. Sorry for another reply but I just thought about this too. And, of course have the trains ask for permission to occupy the block, when entering, just as they are required to do so according to the rules, for obvious reasons.

P.S. I attached a pic as an example. Trains that exit/enter Pine Yard or Burns Harbor would simply leave/enter the designated blocks (ie B332 for Pine Yard trains).

[DPump]

The protecting scheme as mentioned for (3) is now functional starting with CTC 3.21. As already stated there, this is dependent on the routes in the scene definition data, which are currently specified in the full (premium) version of our territories, which will be updated over the next few days. Free or standard versions don't have the routes defined in the scene data - they are automatically generated upon start of a territory - and therefore will not have the protection scheme.

[westdetroit]

I am just wondering if in the future when "acknowledging without a time" can be increased to 5 minutes before a caller tries to call back as it typically takes a train ahead roughly 5 minutes to clear a block from start to finish. Maybe even wait 6 minutes to allow for a route to clear as well. I know a limit has to be drawn somewhere but at least it would give a chance for a situation to clear on its own first.

[DPump]

This sounds like a good candidate for configuration option...

[westdetroit]

I agree as I am sure there are different preferences. Thank you kind sir.

[tve]

In Finland we have normal/uncontrolled position indications on the panels for hand-throw switches. In some countries it depends on the location if the indication is provided or not.

Another thing with the hand-throw switches is that in some countries the rail traffic controller must electrically release the hand-throw switch or keys for the switch. Once released, no routes over the switch can be cleared until the switch is restored and keys returned.

But another hand-throw condition worth cosidering is simulating unsignalled track warrant controlled line. In TD3 this was typically just a mock-up, since you had to line all the switches yourself. Perhaps something similar could be made with CTC: the dispatcher would set the route (to simulate the limits of a given track warrant) but the crew must line and restore the (main line) switches manually. Naturally, this would also involve that with cabooseless trains the conductor would have to walk back up to the locomotive after the train has passed over the switch before it can proceed.

Also there somehow should be an option to tell the crew that they may leave the switches as last used, and that the next train to come along must restore them. And naturally, if another crew is already waiting at the switch for the other train to arrive, they might - in silence - at least offer to restore the switch in order to save the colleage from a bit of walking.

[westdetroit]

In Finland we have normal/uncontrolled position indications on the panels for hand-throw switches. In some countries it depends on the location if the indication is provided or not.

Another thing with the hand-throw switches is that in some countries the rail traffic controller must electrically release the hand-throw switch or keys for the switch. Once released, no routes over the switch can be cleared until the switch is restored and keys returned.

But another hand-throw condition worth cosidering is simulating unsignalled track warrant controlled line. In TD3 this was typically just a mock-up, since you had to line all the switches yourself. Perhaps something similar could be made with CTC: the dispatcher would set the route (to simulate the limits of a given track warrant) but the crew must line and restore the (main line) switches manually. Naturally, this would also involve that with cabooseless trains the conductor would have to walk back up to the locomotive after the train has passed over the switch before it can proceed.

Also there somehow should be an option to tell the crew that they may leave the switches as last used, and that the next train to come along must restore them. And naturally, if another crew is already waiting at the switch for the other train to arrive, they might - in silence - at least offer to restore the switch in order to save the colleage from a bit of walking.

I love everything you just said! For now all my "hand-throws" are set to 5mph to simulate the crew throwing the switch and either walking or "cabbing" back to the head-end. In the current version a user can "lock" a switch which is what I do at any "electric locked" switches until I need them then I "unlock" it until the train clears the switch and then I put the user lock back on.

[DPump]

I am just wondering if in the future when "acknowledging without a time" can be increased to 5 minutes before a caller tries to call back as it typically takes a train ahead roughly 5 minutes to clear a block from start to finish. Maybe even wait 6 minutes to allow for a route to clear as well. I know a limit has to be drawn somewhere but at least it would give a chance for a situation to clear on its own first.

With CTC 3.22 an option was added to Operation Mode, "Default Ackn Pause n min". to allow values between 1 and 10. It can be saved in the scene configuration file.

[westdetroit]

I am just wondering if in the future when "acknowledging without a time" can be increased to 5 minutes before a caller tries to call back as it typically takes a train ahead roughly 5 minutes to clear a block from start to finish. Maybe even wait 6 minutes to allow for a route to clear as well. I know a limit has to be drawn somewhere but at least it would give a chance for a situation to clear on its own first.

With CTC 3.22 an option was added to Operation Mode, "Default Ackn Pause n min". to allow values between 1 and 10. It can be saved in the scene configuration file.

Thank you!