03-08-2017, 07:09 PM
(03-08-2017, 06:41 PM)trainspotter139 Wrote:(03-08-2017, 01:40 PM)Canard Wrote: That's not even close to the reason why it's not happening. Your technical explanation of why it's hard doesn't hold water. Just have a trigger point ~30 seconds upstream and program into the Anchor Wall's PLC (yes, there's one at the base) to ramp a PWM profile for the light up, or down, on a timer. It might reach full brightness 3 seconds early - who cares.
As I have said before the reason why it is not happening is not technical in nature.
But it is technical in nature. Trigger points are only accurate enough when a train is expected to travel uninterrupted. Therefore, the trigger points would only be accurate enough on sections of ballasted track. Because the embedded sections have bar tram signals that don't have 100% guaranteed priority, one train could trip a trigger point only to be stopped at the next tram signal and be stopped for a period of time, while another could trip that same trigger point and have vertical aspect signals all the way to the station. For this reason, the solution that is much more suitable for our system is Digital Addressable Lighting Interface, where the lights can be accurately controlled from a central location like the OMSF using accurate train location information. If the system were 100% grade separated then the old school PLC methods would be adequate. Grandlinq already considered their options for this feature and based on the reasoning given, they seem to have settled on the type of system that I myself would use for this purpose. The controllers for such a system are much more expensive than a simple PLC and the programming for such a system is much more complex however the results are much more accurate and much more suitable for a modern transit system in a high-tech area. This feature could have been implemented already but due to vehicle delays testing and implementation of the feature would run past the construction deadline.
Anything related to construction schedule makes no sense as a reason not to do it. The system clearly could open without the pulsating logos and the feature could be added later. One person said something about how long to develop the control software. That doesn’t make sense either. Again, the system could open without the feature and then it could be switched on once the software is ready. Use one or two stops for testing the partially complete software.
But apparently the actual reason is some sort of state secret which however is permitted to be known by certain posters, so who knows what’s really going on.