Author Topic: Possible cause for Springfield OH derailment  (Read 2662 times)

0 Members and 2 Guests are viewing this topic.

Hawghead

  • Crew
  • *
  • Posts: 791
  • Gender: Male
  • Respect: +325
Re: Possible cause for Springfield OH derailment
« Reply #45 on: April 28, 2023, 11:20:47 AM »
0
Forgot to add that the AEI readers will update your consist and that update gets “pushed” to PTC and the electronic copy of the work order on the iPad.

I'm pretty sure the new AEI data won't update PTC until the next crew logs into the system.

Scott
There's a prototype for everything.
If you can't make it perfect, make it adjustable.
DCC is not plug-n-play.

pedro

  • Crew
  • *
  • Posts: 550
  • Gender: Male
  • Respect: +341
Re: Possible cause for Springfield OH derailment
« Reply #46 on: May 01, 2023, 09:26:40 PM »
+1
I'm pretty sure the new AEI data won't update PTC until the next crew logs into the system.

Scott

Ours (BNSF) updates within seconds of passing a reader if there are any changes. We then hit “refresh” on the ipad work order and it updates. Same thing happens if any work is done en route. As soon as the work is reported on the ipad, the PTC chirps with the consist update. In either either example the Trip Optimizer data updates at the same time if it is active linked to the PTC computer. (Older versions of T.O. were not linked and wouldn’t update.)

John

  • Administrator
  • Crew
  • *****
  • Posts: 13393
  • Respect: +3255
Re: Possible cause for Springfield OH derailment
« Reply #47 on: May 02, 2023, 06:24:57 AM »
+1
Ours (BNSF) updates within seconds of passing a reader if there are any changes. We then hit “refresh” on the ipad work order and it updates. Same thing happens if any work is done en route. As soon as the work is reported on the ipad, the PTC chirps with the consist update. In either either example the Trip Optimizer data updates at the same time if it is active linked to the PTC computer. (Older versions of T.O. were not linked and wouldn’t update.)

Sounds like you guys are using a fancy version of JMRI Operations Pro :)

Hawghead

  • Crew
  • *
  • Posts: 791
  • Gender: Male
  • Respect: +325
Re: Possible cause for Springfield OH derailment
« Reply #48 on: May 02, 2023, 10:17:33 AM »
0
Ours (BNSF) updates within seconds of passing a reader if there are any changes. We then hit “refresh” on the ipad work order and it updates. Same thing happens if any work is done en route. As soon as the work is reported on the ipad, the PTC chirps with the consist update. In either either example the Trip Optimizer data updates at the same time if it is active linked to the PTC computer. (Older versions of T.O. were not linked and wouldn’t update.)

You guys must be using the Gold version of PTC where the UP is using the free beta version.

Scott
There's a prototype for everything.
If you can't make it perfect, make it adjustable.
DCC is not plug-n-play.

Ed Kapuscinski

  • Global Moderator
  • Crew
  • *
  • Posts: 24744
  • Head Kino
  • Respect: +9271
    • Conrail 1285
Re: Possible cause for Springfield OH derailment
« Reply #49 on: May 02, 2023, 10:54:07 AM »
0
You guys must be using the Gold version of PTC where the UP is using the free beta version.

Scott

PTC Plaid

signalmaintainer

  • Crew
  • *
  • Posts: 421
  • Respect: +234
Re: Possible cause for Springfield OH derailment
« Reply #50 on: May 02, 2023, 07:52:34 PM »
+1
You guys must be using the Gold version of PTC where the UP is using the free beta version.

Scott

Well, not to brag, but I would say BNSF's version of PTC leads all Class 1s. Word is UP's is just enough to get by.
NSMR #1975, RMR #4

Hawghead

  • Crew
  • *
  • Posts: 791
  • Gender: Male
  • Respect: +325
Re: Possible cause for Springfield OH derailment
« Reply #51 on: May 03, 2023, 11:16:33 AM »
0
Well, not to brag, but I would say BNSF's version of PTC leads all Class 1s. Word is UP's is just enough to get by.

It is.  We still have to have the dispatcher call us and have us verify that new bulletins have been added/deleted/updated, where as on the BN, as you know, the system beeps at you when a new bulletin has been received and you just have to hit an acknowledge button.

Scott
There's a prototype for everything.
If you can't make it perfect, make it adjustable.
DCC is not plug-n-play.

John

  • Administrator
  • Crew
  • *****
  • Posts: 13393
  • Respect: +3255
Re: Possible cause for Springfield OH derailment
« Reply #52 on: May 03, 2023, 11:41:11 AM »
0
It is.  We still have to have the dispatcher call us and have us verify that new bulletins have been added/deleted/updated, where as on the BN, as you know, the system beeps at you when a new bulletin has been received and you just have to hit an acknowledge button.

Scott

This feature does sound like a good thing - at least to me .. How do you pro's feel about it?   

signalmaintainer

  • Crew
  • *
  • Posts: 421
  • Respect: +234
Re: Possible cause for Springfield OH derailment
« Reply #53 on: May 03, 2023, 02:39:00 PM »
+1
This feature does sound like a good thing - at least to me .. How do you pro's feel about it?
I won't answer for the TY&E guys. But I will say that BNSF's PTC backbone is beginning to replace the ARES and ATCS CTC radio systems, and soon some of non-vital dispatcher to field (office) CTC fiber network. So the data messaging capabilities are pretty darned good. Of course, it's not as if gigabytes of data per second are passing over the network, either. Still, it's impressive to have gone from almost nothing in the field 13 years ago to where we are now.
NSMR #1975, RMR #4

Hawghead

  • Crew
  • *
  • Posts: 791
  • Gender: Male
  • Respect: +325
Re: Possible cause for Springfield OH derailment
« Reply #54 on: May 03, 2023, 05:28:42 PM »
0
This feature does sound like a good thing - at least to me .. How do you pro's feel about it?

Contrary to what people might think, I love PTC.  From a safety stand point I think it's worth it's weight in gold, especially with the current lack of proper training new engineers are getting.  The only problem I have with it, is there is so much more it could do with little added expense.  In the UP example the auto updating of track bulletins is one of the things I'd would implement if it were up to me.  Right now we are stuck between using PTC to convey bulletins (track condition summaries/TCS) and still having to comply with the paper copies we carry.  These two are often in conflict which requires the crew contacting the dispatcher and resolving the discrepancy.  For example I might have a slow order of 25 mph from m.p. 40 to m.p. 41.  Then lets say a new slow order is issued raising the speed to 40 mph.  That will show up as a new bulletin in PTC and the original will be removed from PTC, however I still have the original in my TCS.  I'm required to comply with the original until the dispatcher voids that 25mph slow order.  On the BNSF you would receive an alert on the PTC screen, deleting the old slow order and initiating the new one and all the crew has to do is acknowledge the change on the PTC screen.

Another example is lets say I'm operating on 50 mph track and 1 mile ahead track speed changes to 40 mph.  The PTC screen would show NEXT TARGET: SPEED 40 MPH, but lets say 1/10 of a mile past the permanent speed change there is a slow order for 25mph.  That slow order won't show under the NEXT TARGET line until you've entered the permanent speed restriction at which point you'd only have 1/10 of a mile to slow to 25 mph.  I'd like to see a change where the NEXT TARGET line shows any and all changes listed sequentially for the next 6 miles.
NEXT TARGET: SPEED 40 MPH 1 mile
                                  25 mph 1.1 mile
               AUTHORITY   0 mph 2 mile

These are just a couple examples of things that could be done to make PTC even more useful, but at least on the UP, haven't been implemented.  PTC is a great tool, but don't get me started on EMS (Energy Management System/cruise control)!

Scott
There's a prototype for everything.
If you can't make it perfect, make it adjustable.
DCC is not plug-n-play.