Hello,
Have some users this issue too: (After NewYear MG Rev. 162)
ORTSBrakeCutsPowerAtBrakePipePressure ( 3.0bar ) -> Not works on AirSingle & AirTwin systems.
ORTSBrakeRestoresPowerAtBrakePipePressure ( 3.5bar ) -> Not works on AirSingle & AirTwin systems.
BrakeCutsPowerAtBrakeCylinderPressure ( 5.5bar ) -> Works, but this is a mess when engine use bailoff and blended function :-(.
I have test this with & without TCS scripts.
A search on the Openrails code, give only result that this tokens:
ORTSBrakeCutsPowerAtBrakePipePressure -> MSTSLocomotive.cs -> case "engine(ortsbrakecutspoweratbrakepipepressure": BrakeCutsPowerAtBrakePipePressurePSI = stf.ReadFloatBlock(STFReader.UNITS.PressureDefaultPSI, null); break;
BrakeCutsPowerAtBrakePipePressurePSI -> Only programmed on VacuumSinglePipe.cs
ORTSBrakeRestoresPowerAtBrakePipePressure -> MSTSLocomotive.cs -> case "engine(ortsbrakerestorespoweratbrakepipepressure": BrakeRestoresPowerAtBrakePipePressurePSI = stf.ReadFloatBlock(STFReader.UNITS.PressureDefaultPSI, null); break;
BrakeRestoresPowerAtBrakePipePressurePSI -> Only programmed on VacuumSinglePipe.cs
@Openrails Developteam -> Is it possible to let works this tokens on Airbrakes too? (AirSinglePipe.cs & AirTwinPipe.cs ...)
So for moment on locomotives that use "blended" system and bailoff, traction "cut" not working.
In advance thanks
Page 1 of 1
Brakepipetokens not working anymore (Twinpipe) ORTSBrakeCutsPowerAtBrakePipePressure/RestoreAt..
#2
Posted 15 April 2025 - 09:12 AM
Hello,
Did they work in previous ORNY versions? AFAIK, ORTSBrakeCutsPowerAtBrakePipePressure and ORTSBrakeRestoresPowerAtBrakePipePressure have never been included in official OR versions nor ORNYMG.
Traction cut-off was implemented in the wrong place (outside the TCS subsystem) for vacuum brakes, but now it must remain in that place forever due to compatibility issues with the AWS system.
The decision at that time was to block the inclusion of said parameters. Thus, traction cut off cannot be further implemented unless we find a way to work around the compatibility issues, which is hard to do.
See also https://www.elvastow...longer-working/ and https://github.com/o...nrails/pull/527
Did they work in previous ORNY versions? AFAIK, ORTSBrakeCutsPowerAtBrakePipePressure and ORTSBrakeRestoresPowerAtBrakePipePressure have never been included in official OR versions nor ORNYMG.
Traction cut-off was implemented in the wrong place (outside the TCS subsystem) for vacuum brakes, but now it must remain in that place forever due to compatibility issues with the AWS system.
The decision at that time was to block the inclusion of said parameters. Thus, traction cut off cannot be further implemented unless we find a way to work around the compatibility issues, which is hard to do.
See also https://www.elvastow...longer-working/ and https://github.com/o...nrails/pull/527
#3
Posted 16 April 2025 - 09:05 AM
Hello,
For test that, i have go back to version of Github (0.0.8953.22386/NewYearNoWD) there it ois no working too.
I think only the lowercasetokens are defined.
When i check this on actual Github version (NewYearNoWD) only lowercasetokens are defined.
And VacuumSinglePipe.cs
float BrakeCutoffPressurePSI = OneAtmospherePSI - lead.BrakeCutsPowerAtBrakePipePressurePSI; Line 451
float BrakeRestorePressurePSI = OneAtmospherePSI - lead.BrakeRestoresPowerAtBrakePipePressurePSI; Line 452
Greetz,
Stijn
For test that, i have go back to version of Github (0.0.8953.22386/NewYearNoWD) there it ois no working too.
I think only the lowercasetokens are defined.
When i check this on actual Github version (NewYearNoWD) only lowercasetokens are defined.
And VacuumSinglePipe.cs
float BrakeCutoffPressurePSI = OneAtmospherePSI - lead.BrakeCutsPowerAtBrakePipePressurePSI; Line 451
float BrakeRestorePressurePSI = OneAtmospherePSI - lead.BrakeRestoresPowerAtBrakePipePressurePSI; Line 452
Greetz,
Stijn
#4
Posted 16 April 2025 - 10:06 AM
cesarbl, on 15 April 2025 - 09:12 AM, said:
Traction cut-off was implemented in the wrong place (outside the TCS subsystem) for vacuum brakes, but now it must remain in that place forever due to compatibility issues with the AWS system.
I think it could easily be solved by a compromise: by defining one more script function that disables the built-in methods, like DisableCompatibilityBrakePowerInterlocking().
#5
Posted 16 April 2025 - 01:23 PM
I'm still not 100% sure about whether it should be implemented using the same functionality as the traction cutoff from the TCS system. The leading locomotive is the only one with an active TCS, but it orders traction cutoff for all locomotives in the consist. If the traction-braking interlocking cuts traction depending on the train brake lever position, then it should also affect the whole train. However, if it is brake-cylinder dependent, the decision may be taken independently and locally for every locomotive, which cannot be handled by the current functions.
#6
Posted 16 April 2025 - 02:50 PM
Hello,
I think that TCS not must handle this commands but the brakesystem "computer" (MPU...)
TCS handles more circuitbreakerevents in my opinian. And is more Alerter, signal related.
Some TCS systems only need some trainbrakecontacts/first brakeleverstep (like Holland ATB overspeedcontrol), for confirm that traindriver is alert
But that have nothing todo how tractioncut works.
A compressor works with a valve of electronic setting for go "off" when pressure of setting of valve/chipplate is reached.
Compressor is not linked too TCS system for this.
So i think this is too with tractioncut in case brakesystem and pressures. I mean with this, that this must be a independent system.
But in my opinan the brakesystem "computer" handle this.
Because if you take TCS system away of a train, the tractioncut and behavior for it, must be still exsist, that stuff is own on locomotive or motor unit.
I think that TCS not must handle this commands but the brakesystem "computer" (MPU...)
TCS handles more circuitbreakerevents in my opinian. And is more Alerter, signal related.
Some TCS systems only need some trainbrakecontacts/first brakeleverstep (like Holland ATB overspeedcontrol), for confirm that traindriver is alert
But that have nothing todo how tractioncut works.
A compressor works with a valve of electronic setting for go "off" when pressure of setting of valve/chipplate is reached.
Compressor is not linked too TCS system for this.
So i think this is too with tractioncut in case brakesystem and pressures. I mean with this, that this must be a independent system.
But in my opinan the brakesystem "computer" handle this.
Because if you take TCS system away of a train, the tractioncut and behavior for it, must be still exsist, that stuff is own on locomotive or motor unit.
#7
Posted Yesterday, 12:57 AM
The TCS must handle the traction cut-off, there is no doubt about that. For example, ETCS cuts traction when you exceed the permitted speed limit. Also there are some other safety systems that cut traction if doors are open. All of those cut traction in all locomotives, and can be handled well by the current TCS functions. The question is whether the traction-braking interlocking cuts traction using the same mechanism, I have to check that against the driving manuals for multiple stock to see how it is handled.
#8
Posted Yesterday, 03:30 AM
cesarbl, on 16 April 2025 - 01:23 PM, said:
I'm still not 100% sure about whether it should be implemented using the same functionality as the traction cutoff from the TCS system. The leading locomotive is the only one with an active TCS, but it orders traction cutoff for all locomotives in the consist. If the traction-braking interlocking cuts traction depending on the train brake lever position, then it should also affect the whole train. However, if it is brake-cylinder dependent, the decision may be taken independently and locally for every locomotive, which cannot be handled by the current functions.
It is a valid point you raised here. I have not checked, but probably the brake controller script also runs on the lead locomotive only, so that would not the best place for this either. Maybe the simplest way would be implementing this as fixed eng-file options, for all possible variations.
Page 1 of 1