I was involved in investigations to produce computer models of train handling on the then Hamersley Iron and Mt Newman Mining railways, now Rio Tinto and BHP respectively. This was between 1976 and 1978. I believe this work was used in the work leading up to Rio Tinto's present remote controlled trains.
Back then the electronics required were quite big and clumsy. We could only instrument a pair of cars, which we moved to different locations in the train.
Of course these trains of 144 to 200 cars were always either completely empty of fully loaded, and the cars were effectively identical in size and weight.
But the tests were carried out and the models developed. These days much more could be done at a much lower cost. We actually had a black and white video camera and a reel to reel video recorder which may have been powered by car batteries, just to give an idea of what was available.
On the Hamersley trains the cars at each end were always the newest cars available, so that the trailing cars were always fitted with the best air brake valves to reduce the chances of dragging brakes on the trailing cars.These cars were all pairs with only a single air brake valve for the two cars, which substantially reduced the propagation time of the air brake signals.
200 cars with individual brake valves would be subject to greater delays in application and release of the brakes.
Of course, all these trains now have ECP brakes, whether the trains are remotely controlled or conventionally driven. The significant reduction in in train forces allowed by ECP brakes is regarded as a neccesity for remotely operated trains.
Peter
oltmannd Euclid BaltACD Euclid ... I doubt the railroads would program simulators that show that derailments can be caused by excess buff forces in their ultra-long trains. But I suspect that if they had real world data, it would show that in-train forces associated with these trains will derail them under certain conditions. Indeed, that is the conclusion of the FRA and unions. And there is mounting empirical evidence of the correlation. ... Your lack of knowledge of railroad operations and supervision is SHOUTING. Well if you have the knowledge; show me the use of computers to model the in-train forces in a 250-car train with suitable distributed power and best train handling practice in moderately hilly terrain, at typical road speeds. Also, if the industry has this capability, why aren’t they using it to predict derailments caused by in-train forces? If they are doing that, why are these derailments occurring? They do have modeling tools. They do use them to set rules for train make-up and territory. They are often used retrospectively to analyze derailments. They are generally difficult to use and tough to deploy as tools for train consist management. Car geometry plays a big role as does ROW geometry and in-train forces.
Euclid BaltACD Euclid ... I doubt the railroads would program simulators that show that derailments can be caused by excess buff forces in their ultra-long trains. But I suspect that if they had real world data, it would show that in-train forces associated with these trains will derail them under certain conditions. Indeed, that is the conclusion of the FRA and unions. And there is mounting empirical evidence of the correlation. ... Your lack of knowledge of railroad operations and supervision is SHOUTING. Well if you have the knowledge; show me the use of computers to model the in-train forces in a 250-car train with suitable distributed power and best train handling practice in moderately hilly terrain, at typical road speeds. Also, if the industry has this capability, why aren’t they using it to predict derailments caused by in-train forces? If they are doing that, why are these derailments occurring?
BaltACD Euclid ... I doubt the railroads would program simulators that show that derailments can be caused by excess buff forces in their ultra-long trains. But I suspect that if they had real world data, it would show that in-train forces associated with these trains will derail them under certain conditions. Indeed, that is the conclusion of the FRA and unions. And there is mounting empirical evidence of the correlation. ... Your lack of knowledge of railroad operations and supervision is SHOUTING.
Euclid ... I doubt the railroads would program simulators that show that derailments can be caused by excess buff forces in their ultra-long trains. But I suspect that if they had real world data, it would show that in-train forces associated with these trains will derail them under certain conditions. Indeed, that is the conclusion of the FRA and unions. And there is mounting empirical evidence of the correlation. ...
Your lack of knowledge of railroad operations and supervision is SHOUTING.
They do have modeling tools. They do use them to set rules for train make-up and territory.
They are often used retrospectively to analyze derailments.
They are generally difficult to use and tough to deploy as tools for train consist management. Car geometry plays a big role as does ROW geometry and in-train forces.
EuclidThis issue is not just a matter of having computers and doing modeling. Everybody is doing that every day. The point is that the computer modeling needed for solving the problem of excess in-train forces has got to be directed at that problem. So the first step is to find examples of that problem by measuring in-train forces. Then use the most applicable computer analysis to see if it verifies that same problem. If it does not verify the problem, then try to figure out why a real problem is not detected by the computer program. In other words, you need to test real trains to learn how to build the program that can flag that problem before it causes a derailment.
Validation work had long been done. Models work very well.
You can't practically model every train for every operational scenario before you dispatch. Train forces are the results of train handling which depend largely on what's happening where on the railroad plus unintended stuff.
You gonna model the train going into emergency every 50 feet? For a separated air hose at every one of 200 locations on the train? Or even every combination of DB and service brake application for every spot the train might have to slow down?
Not happening. Can't happen.
-Don (Random stuff, mostly about trains - what else? http://blerfblog.blogspot.com/)
oltmannd Euclid This issue is not just a matter of having computers and doing modeling. Everybody is doing that every day. The point is that the computer modeling needed for solving the problem of excess in-train forces has got to be directed at that problem. So the first step is to find examples of that problem by measuring in-train forces. Then use the most applicable computer analysis to see if it verifies that same problem. If it does not verify the problem, then try to figure out why a real problem is not detected by the computer program. In other words, you need to test real trains to learn how to build the program that can flag that problem before it causes a derailment. Validation work had long been done. Models work very well. You can't practically model every train for every operational scenario before you dispatch. Train forces are the results of train handling which depend largely on what's happening where on the railroad plus unintended stuff. You gonna model the train going into emergency every 50 feet? For a separated air hose at every one of 200 locations on the train? Or even every combination of DB and service brake application for every spot the train might have to slow down? Not happening. Can't happen.
Euclid This issue is not just a matter of having computers and doing modeling. Everybody is doing that every day. The point is that the computer modeling needed for solving the problem of excess in-train forces has got to be directed at that problem. So the first step is to find examples of that problem by measuring in-train forces. Then use the most applicable computer analysis to see if it verifies that same problem. If it does not verify the problem, then try to figure out why a real problem is not detected by the computer program. In other words, you need to test real trains to learn how to build the program that can flag that problem before it causes a derailment.
Euc wants all that modeling done for each train that departs its originating terminal - for each and every train, every trip. Probably ending in discipline for somebody if the train derails for any reason anywhere.
Never too old to have a happy childhood!
BaltACD oltmannd Euclid This issue is not just a matter of having computers and doing modeling. Everybody is doing that every day. The point is that the computer modeling needed for solving the problem of excess in-train forces has got to be directed at that problem. So the first step is to find examples of that problem by measuring in-train forces. Then use the most applicable computer analysis to see if it verifies that same problem. If it does not verify the problem, then try to figure out why a real problem is not detected by the computer program. In other words, you need to test real trains to learn how to build the program that can flag that problem before it causes a derailment. Validation work had long been done. Models work very well. You can't practically model every train for every operational scenario before you dispatch. Train forces are the results of train handling which depend largely on what's happening where on the railroad plus unintended stuff. You gonna model the train going into emergency every 50 feet? For a separated air hose at every one of 200 locations on the train? Or even every combination of DB and service brake application for every spot the train might have to slow down? Not happening. Can't happen. Euc wants all that modeling done for each train that departs its originating terminal - for each and every train, every trip. Probably ending in discipline for somebody if the train derails for any reason anywhere.
Yup. And what are you going to use for train handling inputs? You put that exact train out on the road for 10,000 days in a row and you'll have 10,000 unique sets of train handling data (brake, throttle, DB, etc.)
It's those darned shades of gray, again...
Larry Resident Microferroequinologist (at least at my house) Everyone goes home; Safety begins with you My Opinion. Standard Disclaimers Apply. No Expiration Date Come ride the rails with me! There's one thing about humility - the moment you think you've got it, you've lost it...
oltmannd BaltACD oltmannd Euclid This issue is not just a matter of having computers and doing modeling. Everybody is doing that every day. The point is that the computer modeling needed for solving the problem of excess in-train forces has got to be directed at that problem. So the first step is to find examples of that problem by measuring in-train forces. Then use the most applicable computer analysis to see if it verifies that same problem. If it does not verify the problem, then try to figure out why a real problem is not detected by the computer program. In other words, you need to test real trains to learn how to build the program that can flag that problem before it causes a derailment. Validation work had long been done. Models work very well. You can't practically model every train for every operational scenario before you dispatch. Train forces are the results of train handling which depend largely on what's happening where on the railroad plus unintended stuff. You gonna model the train going into emergency every 50 feet? For a separated air hose at every one of 200 locations on the train? Or even every combination of DB and service brake application for every spot the train might have to slow down? Not happening. Can't happen. Euc wants all that modeling done for each train that departs its originating terminal - for each and every train, every trip. Probably ending in discipline for somebody if the train derails for any reason anywhere. Yup. And what are you going to use for train handling inputs? You put that exact train out on the road for 10,000 days in a row and you'll have 10,000 unique sets of train handling data (brake, throttle, DB, etc.)
Which is a concept Euc can't or won't comprehend.
My favorite interest is automobile racing - virtually all forms from F1 through IndyCar, NASCAR and on down to Club racing and the local bull ring dirt tracks. In many cases there are 'spec classes' where the intent of the specifications are to make the cars as identical as humanly possible to that the driver is the variable to the success or failure in any competition. The drivers is the 'master sensor' and is the one that inputs throttle, brake and steering inputs to make the car go - good drivers are faster than less than good driver. I won't hazard any guess to what a 'computer' driver's performance would be.
I have not been on any trains that are being operated with the various locomotive operation computer application, as such I am not in any position to comment on how well those programs peform, what their sensory inputs are and how they react to those sensory inputs. Jeff Hergert would be a much better source on their operation and quirks.
BaltACD oltmannd BaltACD oltmannd Euclid This issue is not just a matter of having computers and doing modeling. Everybody is doing that every day. The point is that the computer modeling needed for solving the problem of excess in-train forces has got to be directed at that problem. So the first step is to find examples of that problem by measuring in-train forces. Then use the most applicable computer analysis to see if it verifies that same problem. If it does not verify the problem, then try to figure out why a real problem is not detected by the computer program. In other words, you need to test real trains to learn how to build the program that can flag that problem before it causes a derailment. Validation work had long been done. Models work very well. You can't practically model every train for every operational scenario before you dispatch. Train forces are the results of train handling which depend largely on what's happening where on the railroad plus unintended stuff. You gonna model the train going into emergency every 50 feet? For a separated air hose at every one of 200 locations on the train? Or even every combination of DB and service brake application for every spot the train might have to slow down? Not happening. Can't happen. Euc wants all that modeling done for each train that departs its originating terminal - for each and every train, every trip. Probably ending in discipline for somebody if the train derails for any reason anywhere. Yup. And what are you going to use for train handling inputs? You put that exact train out on the road for 10,000 days in a row and you'll have 10,000 unique sets of train handling data (brake, throttle, DB, etc.) Which is a concept Euc can't or won't comprehend. My favorite interest is automobile racing - virtually all forms from F1 through IndyCar, NASCAR and on down to Club racing and the local bull ring dirt tracks. In many cases there are 'spec classes' where the intent of the specifications are to make the cars as identical as humanly possible to that the driver is the variable to the success or failure in any competition. The drivers is the 'master sensor' and is the one that inputs throttle, brake and steering inputs to make the car go - good drivers are faster than less than good driver. I won't hazard any guess to what a 'computer' driver's performance would be. I have not been on any trains that are being operated with the various locomotive operation computer application, as such I am not in any position to comment on how well those programs peform, what their sensory inputs are and how they react to those sensory inputs. Jeff Hergert would be a much better source on their operation and quirks.
Euclid BaltACD oltmannd BaltACD oltmannd Euclid This issue is not just a matter of having computers and doing modeling. Everybody is doing that every day. The point is that the computer modeling needed for solving the problem of excess in-train forces has got to be directed at that problem. So the first step is to find examples of that problem by measuring in-train forces. Then use the most applicable computer analysis to see if it verifies that same problem. If it does not verify the problem, then try to figure out why a real problem is not detected by the computer program. In other words, you need to test real trains to learn how to build the program that can flag that problem before it causes a derailment. Validation work had long been done. Models work very well. You can't practically model every train for every operational scenario before you dispatch. Train forces are the results of train handling which depend largely on what's happening where on the railroad plus unintended stuff. You gonna model the train going into emergency every 50 feet? For a separated air hose at every one of 200 locations on the train? Or even every combination of DB and service brake application for every spot the train might have to slow down? Not happening. Can't happen. Euc wants all that modeling done for each train that departs its originating terminal - for each and every train, every trip. Probably ending in discipline for somebody if the train derails for any reason anywhere. Yup. And what are you going to use for train handling inputs? You put that exact train out on the road for 10,000 days in a row and you'll have 10,000 unique sets of train handling data (brake, throttle, DB, etc.) Which is a concept Euc can't or won't comprehend. My favorite interest is automobile racing - virtually all forms from F1 through IndyCar, NASCAR and on down to Club racing and the local bull ring dirt tracks. In many cases there are 'spec classes' where the intent of the specifications are to make the cars as identical as humanly possible to that the driver is the variable to the success or failure in any competition. The drivers is the 'master sensor' and is the one that inputs throttle, brake and steering inputs to make the car go - good drivers are faster than less than good driver. I won't hazard any guess to what a 'computer' driver's performance would be. I have not been on any trains that are being operated with the various locomotive operation computer application, as such I am not in any position to comment on how well those programs peform, what their sensory inputs are and how they react to those sensory inputs. Jeff Hergert would be a much better source on their operation and quirks. I do not understand why you and Don assume that the “modeling” I refer to will be done for every train before it is allowed to depart from its terminal. My reference to “modeling” refers only to the second stage of a 3-stage process as follows: STAGE ONE: Perform testing to gather data of in-train forces. STAGE TWO: Build a model of those forces showing every detail of their potential. STAGE THREE: Write a program to evaluate train make-up and all of the in-train forces that it can produce. After the data is gathered by testing to learn the entire scope of those forces, computer models of those forces are built. The final model will show every detail of the buildup and dissipation of those forces as they move through the train car by car. This would be a big task costing many millions of dollars. It has not been done yet. It would take considerable time. It will be revised occasionally to account for new types of rolling stock. The testing to gather data alone will also be a lot of work, yet I expect the data might show things that have not been known. It might show force multiplication that is sometimes greater than has been determined by practice. And I don't think that everything developed for the model will have to come from actual measuring of the in-train forces. There can be a mix of approaches with the model making. For one thing, they could model a 250-car train to learn about the in-train foreces. I think this is what the FRA has in mind. I understand that the only similar project that has been done is extensive modeling of tank cars following the Lac Megantic wreck. The purpose was to study how tank cars collide in high speed derailments in order to build them with more crashworthiness. In any case, the modeling for in-train forces would be an enormous task. The cost will certainly be objectionable, as will the prospect of the resulting knowledge that might lead to mandates limiting train length. HOWEVER-- Once the modeling has been done, the occurrences of all in-train forces will be understood. At present, they are not fully understood. But when they are understood, a program will be written. It is the program that will be used to evaluate every train to determine whether it is safe to run. So the “modeling” will be done for the purpose of writing the program. Then the program will evaluate each train to show all of the potential in-train forces and warn against operation of some the force potential is high enough to show a derailment hazard. So you put the train car-list into the program, and it gives you the answer. I don’t know how long that would take, but maybe only seconds. So the data gathering, modeling, and developing a program is a massive effort needed to build the system, but it certainly does NOT have to be done for each train. All three stages of development will have been completed before the working system will be used in actual service of evaluateing trains for excess force potential.
You continually demonstrate you have no idea how trains come into being or why they end up in the form they do.
Railroads service customers - customers get and release cars - cars that customers get or release can be in one's and two's or twenty's and thirty's or even more. Some trains are fully built at origin, many more are not. Those that aren't fully built will be involved in pick ups and/or set offs as the train moves from its origin to its destination. Such a train might depart origin with light power and end up with 200 or more cars when it gets to its destination - or it may arrive destination with light power after being 200 or more cars for periods during its trek.
A function of PSR among most of the carriers is a reduction in the number of yards and expanding Yardmaster responsibilities to cover multiple yards. Another function of PSR is the act of 'block swapping' between trains that have diffeent origins and different destinations at some point where both trains share their routes. The block can be 1 car or 150 cars and it will change on a daily basis.
One thing modeling has done from my experience up until the time I retired was to create Train Handling Rules and Timetable Special Instructions concerning permissible train make up. Some of the simple rulings are 1. blocks of 30 more more empties can have no more that 10 loads in whatever cars follow the empty block. 2. long (longer than 60 foot) empty cars are restricted to how much tonnage can trail behind them. 3. placement restrictions between various types of HAZMAT. 4. Placement restrictions between shiftable loads and HAZMAT. There are probably a dozen or more other placement restrictions that will crop up from time to time - like clearance implicated cars being handled within five cars of the locomotives.
EuclidSTAGE ONE: Perform testing to gather data of in-train forces. STAGE TWO: Build a model of those forces showing every detail of their potential. STAGE THREE: Write a program to evaluate train make-up and all of the in-train forces that it can produce.
STAGE TWO: Build a model of those forces showing every detail of their potential.
STAGE THREE: Write a program to evaluate train make-up and all of the in-train forces that it can produce.
As Balt points out, and to my knowledge - this has already been done. Hence the existing rules for train make-up.
The prime reason for block-swapping is to prevent handling a given car at every single terminal. This is why humps are disappearing. Not to mention that terminal dwell is a major productivity killer.
Keeping entire 200 car trains in the "proper order" would bring the railroad to a halt.
Keep in mind, too, that a 50' boxcar loaded with balsa may well weigh less than an empty LP gas car (partly conjecture on my part, but...).
And even if you do get the train in the "proper order," a dragging brake changes the whole dynamic...
EuclidThe system I refer to will warn of dangerous train consist/make-up, not only prior to departure, but also with every change in consist along the route.
There's a lot of these models already out there. They will continue to be be refined, and use expanded, I'm sure - but to imply they currently do not exist is disingenious at best.
It's been fun. But it isn't much fun anymore. Signing off for now.
The opinions expressed here represent my own and not those of my employer, any other railroad, company, or person.t fun any
EuclidYes I understand that trains change their consists by making setouts and pickups along the way. Why is that a problem? The system I refer to will warn of dangerous train consist/make-up, not only prior to departure, but also with every change in consist along the route. A key point here is that the physical train does not have to even exist to be inspected by this system program. All it needs to “inspect” the train is a list of its cars. This is basically what the FRA intends to do in order to solve a problem of dangerously high in-train forces that they believe exists with this new generation of ultra-long trains. The solution is essentially the same as the train marshalling programs that have been developed and sometimes used over the last 15 years. But the FRA finds evidence that the risk of this problem of excess in-train forces has grown larger precisely because of the massive increase in train length in recent years. So they are calling for new research to find and predict these higher in-train forces. Why would anybody besides railroad management oppose that?
Your protestations remind me of when a change was made to the National T&E contract that permitted cars for a 'block' to be in other locations in trains and that crews could be required to switch out those 'outliers' with no penalty payments being owed to the crew.
Some 'Terminal Management' thought buckshotting cars in the trains was the way to minimize the terminals crew time in building trains. All was well and good until senior division management started asking why it was take three, four or more hours for a train to make a 25 cars set off ON LINE OF ROAD.
When it comes to block swapping - a block that is made correctly for Train 1 can be a issue for Train 2, especially when HAZMAT is part of any of the trains.
zugmann Euclid The system I refer to will warn of dangerous train consist/make-up, not only prior to departure, but also with every change in consist along the route. There's a lot of these models already out there. They will continue to be be refined, and use expanded, I'm sure - but to imply they currently do not exist is disingenious at best.
Euclid The system I refer to will warn of dangerous train consist/make-up, not only prior to departure, but also with every change in consist along the route.
We now have a thing now called UP Vision. One of the features is that it lists places of risk areas for draft/buff force. It gives the mile post and even gives the car number where it's calculated the forces will be the most extreme for that location.
I checked a manifest scheduled with 196 loads, 34 empties 25700 tons and 13900 feet in length. There are 25 locations of medium or high (mostly medium, only about 4 high locations) of buff/draft force risks on four different subdivision.
The programs are out there. If they are actually used to rearrange a consist at an originating terminal, I wouldn't know. I think most of the yard masters just use the regular computer programs to "train set" a consist. If the computer doesn't spit out a warning and sets the consist, it's good to go.
Jeff
BaltACD Euclid Yes I understand that trains change their consists by making setouts and pickups along the way. Why is that a problem? The system I refer to will warn of dangerous train consist/make-up, not only prior to departure, but also with every change in consist along the route. A key point here is that the physical train does not have to even exist to be inspected by this system program. All it needs to “inspect” the train is a list of its cars. This is basically what the FRA intends to do in order to solve a problem of dangerously high in-train forces that they believe exists with this new generation of ultra-long trains. The solution is essentially the same as the train marshalling programs that have been developed and sometimes used over the last 15 years. But the FRA finds evidence that the risk of this problem of excess in-train forces has grown larger precisely because of the massive increase in train length in recent years. So they are calling for new research to find and predict these higher in-train forces. Why would anybody besides railroad management oppose that? Your protestations remind me of when a change was made to the National T&E contract that permitted cars for a 'block' to be in other locations in trains and that crews could be required to switch out those 'outliers' with no penalty payments being owed to the crew. Some 'Terminal Management' thought buckshotting cars in the trains was the way to minimize the terminals crew time in building trains. All was well and good until senior division management started asking why it was take three, four or more hours for a train to make a 25 cars set off ON LINE OF ROAD. When it comes to block swapping - a block that is made correctly for Train 1 can be a issue for Train 2, especially when HAZMAT is part of any of the trains.
Euclid Yes I understand that trains change their consists by making setouts and pickups along the way. Why is that a problem? The system I refer to will warn of dangerous train consist/make-up, not only prior to departure, but also with every change in consist along the route. A key point here is that the physical train does not have to even exist to be inspected by this system program. All it needs to “inspect” the train is a list of its cars. This is basically what the FRA intends to do in order to solve a problem of dangerously high in-train forces that they believe exists with this new generation of ultra-long trains. The solution is essentially the same as the train marshalling programs that have been developed and sometimes used over the last 15 years. But the FRA finds evidence that the risk of this problem of excess in-train forces has grown larger precisely because of the massive increase in train length in recent years. So they are calling for new research to find and predict these higher in-train forces. Why would anybody besides railroad management oppose that?
Euclid BaltACD Euclid Yes I understand that trains change their consists by making setouts and pickups along the way. Why is that a problem? The system I refer to will warn of dangerous train consist/make-up, not only prior to departure, but also with every change in consist along the route. A key point here is that the physical train does not have to even exist to be inspected by this system program. All it needs to “inspect” the train is a list of its cars. This is basically what the FRA intends to do in order to solve a problem of dangerously high in-train forces that they believe exists with this new generation of ultra-long trains. The solution is essentially the same as the train marshalling programs that have been developed and sometimes used over the last 15 years. But the FRA finds evidence that the risk of this problem of excess in-train forces has grown larger precisely because of the massive increase in train length in recent years. So they are calling for new research to find and predict these higher in-train forces. Why would anybody besides railroad management oppose that? Your protestations remind me of when a change was made to the National T&E contract that permitted cars for a 'block' to be in other locations in trains and that crews could be required to switch out those 'outliers' with no penalty payments being owed to the crew. Some 'Terminal Management' thought buckshotting cars in the trains was the way to minimize the terminals crew time in building trains. All was well and good until senior division management started asking why it was take three, four or more hours for a train to make a 25 cars set off ON LINE OF ROAD. When it comes to block swapping - a block that is made correctly for Train 1 can be a issue for Train 2, especially when HAZMAT is part of any of the trains. You and Don say the in-train force detection system I propose has already been done. And you also seem to be saying it won’t work because of the block problem you are describing. Can you explain this? If the system cannot work, why was it built?
BaltACD Euclid BaltACD Euclid Yes I understand that trains change their consists by making setouts and pickups along the way. Why is that a problem? The system I refer to will warn of dangerous train consist/make-up, not only prior to departure, but also with every change in consist along the route. A key point here is that the physical train does not have to even exist to be inspected by this system program. All it needs to “inspect” the train is a list of its cars. This is basically what the FRA intends to do in order to solve a problem of dangerously high in-train forces that they believe exists with this new generation of ultra-long trains. The solution is essentially the same as the train marshalling programs that have been developed and sometimes used over the last 15 years. But the FRA finds evidence that the risk of this problem of excess in-train forces has grown larger precisely because of the massive increase in train length in recent years. So they are calling for new research to find and predict these higher in-train forces. Why would anybody besides railroad management oppose that? Your protestations remind me of when a change was made to the National T&E contract that permitted cars for a 'block' to be in other locations in trains and that crews could be required to switch out those 'outliers' with no penalty payments being owed to the crew. Some 'Terminal Management' thought buckshotting cars in the trains was the way to minimize the terminals crew time in building trains. All was well and good until senior division management started asking why it was take three, four or more hours for a train to make a 25 cars set off ON LINE OF ROAD. When it comes to block swapping - a block that is made correctly for Train 1 can be a issue for Train 2, especially when HAZMAT is part of any of the trains. You and Don say the in-train force detection system I propose has already been done. And you also seem to be saying it won’t work because of the block problem you are describing. Can you explain this? If the system cannot work, why was it built? P S R
Why didn't you put 5 and 6 in red, too? The latter is just what you were calling for in the last few weeks.
Here is the relevant reference in the eCFR:
https://www.ecfr.gov/current/title-49/subtitle-B/chapter-II/part-217/subpart-A/section-217.9
Note subpart (c)(1).
I know it can be irritating to wade through the Federal verbiage and cross-reference their priorities with actual railroad reality, but this actually calls for operations testing and not 'more detailed inspections'.
Euclid4. Identify changes to crew training, train handling procedures, train makeup, DPU requirements, limitations to length or tonnage, speed restrictions, track, mechanical, and brake inspection and maintenance requirements necessary to ensure safe operations of longer trains.
.
Overmod Why didn't you put 5 and 6 in red, too? The latter is just what you were calling for in the last few weeks. Here is the relevant reference in the eCFR: https://www.ecfr.gov/current/title-49/subtitle-B/chapter-II/part-217/subpart-A/section-217.9 Note subpart (c)(1). I know it can be irritating to wade through the Federal verbiage and cross-reference their priorities with actual railroad reality, but this actually calls for operations testing and not 'more detailed inspections'.
Euclid Overmod Why didn't you put 5 and 6 in red, too? The latter is just what you were calling for in the last few weeks. Here is the relevant reference in the eCFR: https://www.ecfr.gov/current/title-49/subtitle-B/chapter-II/part-217/subpart-A/section-217.9 Note subpart (c)(1). I know it can be irritating to wade through the Federal verbiage and cross-reference their priorities with actual railroad reality, but this actually calls for operations testing and not 'more detailed inspections'. I don’t mean to diminish the role of testing. I think all of the points on the FRA list are relevant. It is just that #4 interests me most because it is wrapped around the factors that lead to excess in-train forces. Until that issue is fully understood, it will not be solvable. And to be fully understood, it needs to be tested-sensed on monster trains. Of course sensing the drawbar loading on various mixes of trains that are over 200 cars long will be an awful chore. But if it is done, I suspect it will disclose some surprising slack behavior. Maybe in lieu of measuring forces with sensors to start, they could develop a program that could analyze a hypothetical long train just according to its makeup and location on the line. Then use that program to predict whether the NS train that derailed in Springfield, OH would derail as it did. But I would not stop there, especially if the program says the Springfield derailment would not have happened.
Improper, ham fisted, locomotive operation can cause a derailment of virtually any size train - big or small.
Cause of the Springfield, OH derailment has not been published - officially or unoffically. Without access to the full investigation of the incident we don't know anything factual. Without factual knowledge we are just making WAGs.
Tetra Tech’s RailAI system offers the most technologically advanced in revenue service, at track speed, fully autonomous track inspection assessment system available.
https://railai.tetratech.com/
rdamonTetra Tech’s RailAI system offers the most technologically advanced in revenue service, at track speed, fully autonomous track inspection assessment system available. https://railai.tetratech.com/
CSX has a group of 'box cars' that have been outfitted with geometry measurement equipment that they operate on various regularly scheduled trains operating over the network. The also have specific locomotives that have been outfitted for track geometry measurements. I know the locomotives wirelessly transmit the exceptions they find to the MofW Desk in Jacksonville who in turn notify the Roadmaster of the affected territory for them to inspect and recitfy. I don't know of the box cars are wirelessly reporting the results of the data they develop.
I know the locomotives were reporting data before I retired in 2016. I would imagine improvements have been made in the past seven years.
BaltACDCSX has a group of 'box cars' that have been outfitted with geometry measurement equipment that they operate on various regularly scheduled trains operating over the network.
Generally easily spotted by the huge billboard lettering "DO NOT HUMP" on both sides...
At night you can sometimes spot the lasers under the cars.
BaltACD Euclid Overmod Why didn't you put 5 and 6 in red, too? The latter is just what you were calling for in the last few weeks. Here is the relevant reference in the eCFR: https://www.ecfr.gov/current/title-49/subtitle-B/chapter-II/part-217/subpart-A/section-217.9 Note subpart (c)(1). I know it can be irritating to wade through the Federal verbiage and cross-reference their priorities with actual railroad reality, but this actually calls for operations testing and not 'more detailed inspections'. I don’t mean to diminish the role of testing. I think all of the points on the FRA list are relevant. It is just that #4 interests me most because it is wrapped around the factors that lead to excess in-train forces. Until that issue is fully understood, it will not be solvable. And to be fully understood, it needs to be tested-sensed on monster trains. Of course sensing the drawbar loading on various mixes of trains that are over 200 cars long will be an awful chore. But if it is done, I suspect it will disclose some surprising slack behavior. Maybe in lieu of measuring forces with sensors to start, they could develop a program that could analyze a hypothetical long train just according to its makeup and location on the line. Then use that program to predict whether the NS train that derailed in Springfield, OH would derail as it did. But I would not stop there, especially if the program says the Springfield derailment would not have happened. Improper, ham fisted, locomotive operation can cause a derailment of virtually any size train - big or small. Cause of the Springfield, OH derailment has not been published - officially or unoffically. Without access to the full investigation of the incident we don't know anything factual. Without factual knowledge we are just making WAGs.
EuclidIt is true that any engineer can derail their train with bad train handling. But I don’t think this fact can rule out the possibility that the longer trains have higher in-train forces that can make it easier for a careless engineer to cause a derailment due in part to poor train handling. It has not even been established that what is considered proper train handling for moderate train lengths may be inadequate for the ultra-long trains.
Kind of forgetting trip optimizer is a thing.
zugmann Euclid It is true that any engineer can derail their train with bad train handling. But I don’t think this fact can rule out the possibility that the longer trains have higher in-train forces that can make it easier for a careless engineer to cause a derailment due in part to poor train handling. It has not even been established that what is considered proper train handling for moderate train lengths may be inadequate for the ultra-long trains. Kind of forgetting trip optimizer is a thing.
Euclid It is true that any engineer can derail their train with bad train handling. But I don’t think this fact can rule out the possibility that the longer trains have higher in-train forces that can make it easier for a careless engineer to cause a derailment due in part to poor train handling. It has not even been established that what is considered proper train handling for moderate train lengths may be inadequate for the ultra-long trains.
And in 'Company Eyes' Trip Optimizer is infailible. Even when Trip Optimizer makes train handling actions that cause derailments. Only human engineers make train handling mistakes in the eyes of the company.
EuclidAt the time of the derailment, the entire 210-car train was being slowed with dynamic braking provided by only by the two units on the head end.
Our community is FREE to join. To participate you must either login or register for an account.