[pschlik]

Ah that's good to hear, at least I'm not barking up the wrong tree. When I get back to my computer I'll have another attempt at using the option.

[pschlik]

Retried what I was doing on Thursday in Unstable 2023.05.12 and it works just as I expected now! Applying the train brakes manually doesn't interfere with the cruise control using dynamic braking when TrainBrakeCommandHasPriorityOverCruiseControl is false. I'm glad my bit of detective work turned out to be correct, maybe I should set up an environment for Open Rails after all so I can stop bugging you all about this kind of thing.

Anyway, I used this to have go at simulating an energy management system for freight trains, like GE's trip optimizer or EMD's LEADER. These aren't strictly cruise control systems, as the speed is decided automatically, but they have the interesting quirk of only using throttle and dynamic brakes, requiring the operator to manually add in train braking at certain points (however, it knows when it will need train brakes and will inform the operator of this-I think in the future even the automatic brake part will become automated). With this fix, it is possible to set a speed, let the system use dynamic brakes, then add a minimum reduction when dynamic brakes aren't enough and the system will then balance speed using the dynamics. It's quite effective and interesting to watch, I'm tempted to record a video to demonstrate considering it flawlessly took a bulky 145 TOB train down a 2% grade with a minimum set. Now I just want to check how it interacts with distributed power. If anyone would like to experiment with this, here's the list of parameters I settled on:

	ORTSCruiseControl (
		MaxForceSteps ( 8 ) 	Comment ( Throttle controls cruise control force, and the throttle has 8 notches. )
		SpeedIsMPH ( True )
		MinimumSpeedForCCEffect ( 10mph )	Comment ( System does not work unless train is already moving. )
		NominalSpeedStep ( 1 )
		SpeedSelectorStepTimeSeconds ( 0.1 )
		UseThrottleAsForceSelector ( True )	Comment ( The throttle sets the maximum power the cruise control will use. )
		UseThrottleInCombinedControl ( True )	Comment ( Required for locomotives which have a combined throttle and dynamic brake. )
		ModeSwitchAllowedWithThrottleNotAtZero ( True )	Comment ( This system allows throttle to be applied while changing mdoes. )
		StartReducingSpeedDelta ( 0.01 )	Comment ( Set very low to make acceleration more conservative. Should avoid overshoots. )
		StartReducingSpeedDeltaDownwards ( 0.05 )
		Options ( "RegulatorManual, RegulatorAuto, EngageForceOnNonZeroSpeed" )
		ThrottleFullRangeIncreaseTimeSeconds ( 30 )
		ThrottleFullRangeDecreaseTimeSeconds ( 30 )
		DynamicBrakeFullRangeIncreaseTimeSeconds ( 30 )
		DynamicBrakeFullRangeDecreaseTimeSeconds ( 30 ) 
		TrainBrakeCommandHasPriorityOverCruiseControl ( False )	Comment ( Applying the train brake manually won't disable cruise control. )
		DynamicBrakeCommandHasPriorityOverCruiseControl ( False )	Comment ( Applying dynamic brake manually won't interfere with automatic braking. )
		KeepSelectedSpeedWhenManualModeSet ( True )	Comment ( Set speed is 'remembered' even when cruise has been turned off. )
		DoComputeNumberOfAxles ( True ) 	Comment ( No manual entering of axle information. )
	)

I noticed one thing it will not do is stretch brake (apply forward traction while the train brakes are applied). I would assume most cruise control systems do not try to stretch brake, but there's probably a system out there that does.

Also, the "SkipThrottleDisplay" is something I didn't see on the Genesis that manifested itself when I moved over to a locomotive with split throttle/dynamic brake. It seems unintentional that the throttle display wasn't skipped when a combined throttle/dynamic brake was used. Also this is yet another thing I'd like to control, as the throttle display should not be skipped on the systems I'm making because the throttle is used as the force selector.

[Csantucci]

pschlik,
your suggested fix for TrainBrakeCommandHasPriorityOverCruiseControl is present also in ORNYMG 142.1. I have now created a quick patch for the same release, that allows to disable the use of the dynamic brake for the CC, as you asked for the Genesis.
Attached you have the patch, to be uncompressed in ORNYMG 142.1.
To disable the use of the dyn brake, you have to add following line to the CruiseControl() block in the .eng file

		UseDynBrake ( False )

Default for such new parameter is True.
A feedback from your side about the effectiveness of the patch is welcome.
 Orts.Simulation.zip (1MB)
Number of downloads: 99

[Laci1959]

Weter, on 24 May 2023 - 02:13 AM, said:

Hello, Carlo.
In MSTS *.eng-files tradition, (0) or (1) were used instead of False/True flags.
Just for reminder.

Hi Weter.

For those who do not know MSTS, it is more natural to use False, True.

Laci 1959

[pschlik]

I haven't actually tested this but I would assume, based on the way C# works, that entering "0" would automatically be interpreted the same as "False" and anything other than 0 would be the same as "True".

I'll have a look at the dynamic brake patch when I'm back home, if there's a way to break it I'll probably find it, but I can't imagine it's that risky.

[pschlik]

Completed a run after disabling dynamic braking, and it seemed to work just as intended. If the set speed was exceeded, cruise just didn't do anything at all this time. No more need for that crazy workaround.

[ATW]

In today's world of trip opptimizers for GE and EMD they both do differ in opperations and EMD one seams to have some faults when judging speed acceleration and deceleration as the leader version thinks the locomotive is solo so it will not judge how many true powered axles you have and will annoy the operator to set air and how much if it can't balance out whether in power or dynamic. GE seams to be smoother and balance things out better because it knows available powered axles but rare occasions depending on route train tonnage they like an alerter will give a prompt of 20 seconds to the operator how much BP reduction to set for it to balance and when to release. Other GE benifit it tells you the target speed in quarter mile increments on monitor.

Little off topic but now these days trip optimizers have been integrated into the PTC systems for controlling and judging upcoming speed limits, acceleration, deceleration, downhill speed calculations to reduce brake fading etc. PTC is just example of the track monitor but horizontal judging by the projected speed distance. By rule PTC knows auto trip optimizing is disabled when passing a approach signal as it doesn't want to get blamed if passing a stop indication or restricted limits so operator takes full control and if not PTC will calculate all available brakes distance to penalty or emergency to stop on a dime from passing stop indication

[Csantucci]

Blueprint https://blueprints.l...trol-parameters has been created. At the moment following parameters have been added in ORNYMG 142.2, and will be added to the Unstable release:

                UseDynBrake ( True )

default: true; when false the CC doesn't use Dynamic Brake (CC may only generate tractive force)

TrainBrakeCommandHasPriorityOverAcceleratingCruiseControl ( True )

: default: true.
This parameter is needed when

TrainBrakeCommandHasPriorityOverCruiseControl (False)

, and allows to have a train brake action by the driver disabling CC generating tractive force, but not CC generating dynamic brake force.

[Csantucci]

Features now available also in Unstable release U2023.05.31-1007 .

[pschlik]

I attempted setting up a cruise control system with TrainBrakeCommandHasPriorityOverCruiseControl (False) and TrainBrakeCommandHasPriorityOverAcceleratingCruiseControl ( False ), but I didn't notice any behavior different from settingTrainBrakeCommandHasPriorityOverAcceleratingCruiseControl to True. I was expecting power to continue to be applied even when train brakes were applied if the accelerating priority was false, but regardless of the setting, applying the train brakes would prevent traction but not prevent braking. I looked around but couldn't find any clear reason why having both tokens set to false would still prevent tractive effort with any train brake application.