Tunafish13
Active Member
I would be taking bets that Ford is going to announce an opening date for the Crosstown as an election move, or as a reaction to another politician making a statement about it.
This has been floated so many times... considering that the TTC has said Summer is the earliest they could open it, I highly doubt Ford will announce anything.I would be taking bets that Ford is going to announce an opening date for the Crosstown as an election move, or as a reaction to another politician making a statement about it.
I feel like he would try to swing it like "look at this huge project that is opening soon, we finished it"This has been floated so many times... considering that the TTC has said Summer is the earliest they could open it, I highly doubt Ford will announce anything.
Plus, what impact will it have? You think the majority of his base that live in the 905 or rural areas of the province care about the Crosstown?
I mean it’s not like Ford could force the TTC hand and order them to open the line when it’s not ready……..This has been floated so many times... considering that the TTC has said Summer is the earliest they could open it, I highly doubt Ford will announce anything.
Plus, what impact will it have? You think the majority of his base that live in the 905 or rural areas of the province care about the Crosstown?
Okay... whatever you sayI mean it’s not like Ford could force the TTC hand and order them to open the line when it’s not ready……..
Indeed, it won’t make for happy, complacent voters if the Crosstown opens next month and quickly fails, stranding people mid tunnel.It's election time. Gotta keep it quiet until Doug has a fresh 4-year mandate, then they can spill the bad news.
Thanks for the all the detail.The signal system being used on the Crosstown is a Bombardier (now Alstom) product called Cityflo 650 on the tunneled sections, and (IIRC) Cityflo 350 on the surface portion. It's an off-the-shelf product that has been used in many, many different cities on many, many different lines, although the 650 - the fully automated one providing ATC/ATO - frequently on unmanned "people mover" type of systems. But this is by no means it's first transit application, not by a long shot.
As pointed out, Finch West is using a version of Hitachi's (formerly Thales) Seltrac product. It's a totally different system, although it is functionally identical to the Cityflo 350 product - and nothing at all like the version of Seltrac formerly used on the Scarborough RT.
Because the two systems are completely independent from the other, there should be no possibility of any failure in one propagating to the other. I say should, as I don't know how the scheduling functions have been integrated into the two systems. If they are centrally controlled - like the existing subway lines - than there remains a potential common failure mode there.
Except that the migration point between the two systems is not the problem. In fact, it's worked flawlessly since the last upgrade in August/September.
Dan
Nothing is more anxiety inducing in the world of Toronto transit than thinking about the fact that we had started construction on a subway along Eglinton, cancelled it, switched gears, and opted to construct a streetcar instead of restarting subway construction.When all is said and done, I find it hilarious how Sheppard will have a full fledged subway one day from Sheppard West to potentially Morningside, while Toronto's midtown will have a grey streetcar.
Just wanted to be that troll.
Carry on.
My knowledge at this level of detail is limited, but I would assume that the communication would be primarily one-way, and so therefore an API seems unnecessary. It strikes me that the scheduling computer just needs to tell the signal system to "GO", it doesn't need to know what state it is in to send that command. And in fact, watching the signal system at the termini would agree with this - the signal system will hold a train until the scheduling system tells it to. But if there is a condition that is more restrictive - say, another train is crossing over in front of the train scheduled to leave - the signal system will not allow that train to leave until the restriction is removed.Thanks for the all the detail.
Is your understanding that the two software systems are not connecting with each other via an API? I would assume they need to communicate with each other? This sounds equal parts easily solvable and highly complex lol, any software engineers care to chime in?
As I've written earlier, TTC staff have not been given full access to the facilities there. That includes the carhouse, central control, stations, etc. Until that happens, they can not train the operators - and after that, then start running the simulated service.FWIW I've heard Finch is completely finished but Metrolinx/TTC priority is solely on Eglinton and as such no drivers have been trained for Finch...make of that what you will.
What world do you live in that you think anyone actually cares about that?Nothing is more anxiety inducing in the world of Toronto transit than thinking about the fact that we had started construction on a subway along Eglinton, cancelled it, switched gears, and opted to construct a streetcar instead of restarting subway construction.
Thank you for sharing both your expertise and insights gleaned from your "inside" contacts Dan. Are you able to share what the problem is with the signal system if it's not the migration point?...
Except that the migration point between the two systems is not the problem. In fact, it's worked flawlessly since the last upgrade in August/September.
Dan
The system has been built and tested for this, and it is scheduled to be instituted at some nebulous later date once ridership has matured. But it is not planned to happen for day 1.Also, I had understood that every second eastbound train would short turn at Laird using the storage track immediately east of Laird Station. Would this maneuver be completely controlled by ATC? (i.e. the operator wouldn't need to do anything except move from the cab at one end to the cab at the other end of the train).
It’s just Cityflo 650 CBTC throughout the whole line from what I read. The changeover is just selecting which level of control is available to use as the underground section has both ATO and ATP elements available while the surface section only has the ATP equipment.The signal system being used on the Crosstown is a Bombardier (now Alstom) product called Cityflo 650 on the tunneled sections, and (IIRC) Cityflo 350 on the surface portion. It's an off-the-shelf product that has been used in many, many different cities on many, many different lines, although the 650 - the fully automated one providing ATC/ATO - frequently on unmanned "people mover" type of systems. But this is by no means it's first transit application, not by a long shot.
As pointed out, Finch West is using a version of Hitachi's (formerly Thales) Seltrac product. It's a totally different system, although it is functionally identical to the Cityflo 350 product - and nothing at all like the version of Seltrac formerly used on the Scarborough RT.
Because the two systems are completely independent from the other, there should be no possibility of any failure in one propagating to the other. I say should, as I don't know how the scheduling functions have been integrated into the two systems. If they are centrally controlled - like the existing subway lines - than there remains a potential common failure mode there.
Except that the migration point between the two systems is not the problem. In fact, it's worked flawlessly since the last upgrade in August/September.
Dan




