Elvas Tower: Improved Anti-Slip Technology - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Improved Anti-Slip Technology Real-Time Tractive Effort Modulation Rate Topic: -----

#1 User is offline   PerryPlatypus 

  • Fireman
  • PipPipPip
  • Group: Access 1 Open Rails Forums
  • Posts: 192
  • Joined: 13-January 10
  • Gender:Male
  • Location:Post Falls, ID
  • Simulator:Open Rails
  • Country:

Posted 05 April 2021 - 04:27 PM

Currently in OR, the only remotely close thing to "anti-slip" technology is the variable that completely zeroes the throttle when wheelslip occurs.

In order to simulate the type of anti-slip tech on modern locomotives, I would like to proposed a true anti-slip system that does not completely zero the throttle, but instead adjusts down the tractive effort (without physically moving the throttle control) when the system detects the wheelslip threshold has exceeded a certain value. These systems can detect BEFORE full wheelslip has begun. (In OR's code, true wheelslip corresponds to a wheelslip value of greater than 100%)

I would proposed the following variables:
ORTSAntiSlipSystem ( 1 ) - indicates this locomotive will use the antislip system
ORTSAntiSlipThresholdHigh ( 75 ) - if slip threshold is above this value (in percent, so this would indicate 75%) then the system will "ramp down" the amount of tractive force being put out at the wheels until slip falls below the Low threshold. This value could be set to 100 if it is desired to not have the system kick in until full wheelslip has begun.
ORTSAntiSlipThresholdLow ( 50 ) - if slip threshold falls below this value, then the system will "ramp up" the amount of tractive force being put out at the wheels until either A. tractive effort has returned to coincide with the current throttle position, or B. the current wheelslip exceeds the High threshold again. I think having these values are important to model locomotives that have hyperactive antislip systems, for example.

Would recommend that the "rate" at which the traction force is adjusted is proportional to the difference between the current slip threshold and the High threshold. In other words, with the value of 75 for the high threshold above, when the current slip threshold is measured at 95%, then the system will reduce power at a rate twice as high as if the current threshold is 85%, because (95-75) is double of (85-75). This will help ensure that, when the system does not respond quickly enough and true wheelslip begins, that the system will ramp down power faster and faster, in an effort to overcome the wheelslip and return to a no-slip condition more quickly.

Could potentially introduce ORTSAntiSlipChangeRate or ORTSAntiSlipAveragingTime as variables as well, but potentially not necessary.

Thoughts?

#2 User is offline   pschlik 

  • Conductor
  • Group: Status: Active Member
  • Posts: 311
  • Joined: 04-March 15
  • Gender:Male
  • Simulator:OpenRails - Unstable
  • Country:

Posted 05 April 2021 - 06:33 PM

I did a bit of my own thinking on Anti-Slip implementation and found it to be a bit of a rabbit hole if it's to be done well. And if anyone is going to do it, they might as well do it properly.

One of the first problems encountered with trying to implement realistic anti-slip is that Open Rails has no way to force an individual locomotive to set its power output independently of other locomotives. This is why AntiSlip ( 1 ) has to move the throttle handle; there simply isn't any facility in the game to change power other than just moving the throttle handle. Adding something to bypass this would likely be complicated and require a significant rethinking of some of the (incorrect) assumptions the current system makes. And when you change something that core in the physics, it has a tendency to make a lot of people upset. Whoever works on this would need to ensure compatibility with prior content (perhaps by turning this feature off unless it is explicitly turned on by the person making the engine file) or face a lot of grumpy people.


My thought was to start the process toward improved anti-slip by introducing the (HEAVILY SIMPLIFIED) idea of the load regulator and accompanying rate control system ("rate control" is the terminology EMD used to describe how quickly the load regulator was allowed to change, I don't know if this term is used elsewhere but it's the best I got).
The idea is that a "load regulator" variable would define the actual power setting of the locomotive, which would change at a rate specified by the rate control (rather than using the engine RPM), while the throttle would merely set the target value for the load regulator. Other parts of code would be allowed to override this response, forcing a single locomotive to reduce its "load regulator" (eg: during wheel slip) with no effect on the throttle setting or engine RPM. The only rate control quantities required in an engine file would be the power up speed, power down speed (think of the "ChangeUpRPMps" and "RateOfChangeUpRPMpSS" in diesel engines), and maybe even additional parameters for how quickly dynamic brakes apply/release. All the other work could be done in code by the sim.

Comment ( Example implementation of load regulator/rate control. )

ORTSRateControl (
	Comment ( Rate at which power is increased in % per second. )
	ChangeUpPowerpS ( 10 )
	RateOfChangeUpPowerpSS ( 5 )


	Comment ( Rate at which power is decreased in % per second. )
	ChangeDownPowerpS ( 20 )
	RateOfChangeDownPowerpSS ( 10 )
	
	Comment ( Maybe even repeat for dynamic brakes so they dont apply and release instantaneously. )
	ChangeUpDynamicpS ( 25 )
	RateOfChangeUpDynamicpSS ( 2 )
	
	ChangeDownDynamicpS ( 30 )
	RateOfChangeDownDynamicpSS ( 5 )
)


This basic simulation of the load regulator/rate control pairing would allow for a lot more than just wheel slip control, which is why I propose the idea. It also has potential uses for modeling nominal locomotive performance more realistically.
In a lot of locomotives, the engine RPM and the generator power output are not directly related, as the rate control system forces the power to ramp up slower than the engine itself. The most infamous example would be something like a P42DC locomotive in HEP mode, which likes to remain at a constant 900 RPM but powers up really slowly; currently, there is no way to correctly simulate this in Open Rails, as setting a constant 900 RPM will result in an instantaneous change in the tractive effort...which is disappointing when the intention is a slow P42DC. Instead, you just have to fake it by using completely wrong RPM values and making the engine take unrealistically long to rev up.
There's also the possibility of simulating the dip in power that occurs during transition which is a feature entirely missing from Open Rails, but that would require more than just defining a few variables.


Once there is a way to override the throttle setting at an individual locomotive level, all that's left is to integrate it into some sort of wheel slip system, and there are a lot of potential ways to do this. I agree with the thought of using the wheel slip % to activate and deactivate the WSP response (however, I should note that there are still some serious bugs in the adhesion model which allow nonsense such as wheels slipping at ludicrous speed, yet the wheel slip % will drop below 100%...even though the wheels are very very obviously slipping), the ability to define custom activation thresholds is certainly a must-have in order to represent some of the different types of wheel slip protection. And once the system activates on a particular locomotive, it merely needs to interface with that one locomotive and tell it to reduce its load regulator variable. This won't change the power output of other locomotives, this won't move the throttle handle, and engine RPM will stay where it is. Problem solved...at least, that's one solution.

Now, maybe I'm losing the plot here and expecting too much from stuff typed into a .eng file, but I felt like there is more that could be done. Rather than trying to automatically calculate the speed of power reduction, one of my thoughts was the ability to custom define a speed of power reduction, but then to define multiple "levels" of wheel slip control inside the same engine file in order to achieve faster power reduction at higher slip. This would be more complicated but would allow for deeper simulation of the intricacies of real wheel slip protection systems, which often act in multiple distinct stages (rather than working continuously or gradually). This is especially true of wheel creep systems, and I don't think it would be feasible to fully represent a wheel creep system with just one set of activation and deactivation thresholds, nor with automatic calculation of power reduction.

Comment ( Example implementation of multi-stage anti-slip systems. )

ORTSAntiSlipSystem (
	Comment ( Stage 1 of anti-slip: Activates at high slip and slowly reduces power to correct for minor slipping. )
	AntiSlip (
		Comment ( Wheel slip percentages at which slip is detected and when the control response is reset. )
		SlipDetectionThreshold ( 90 )
		SlipResetThreshold ( 80 )
		
		Comment ( RateControl section inside anti-slip defines how fast power should decrease, overriding the basic RateControl defined earlier. )
		RateControl (
			Comment ( Speed of load regulator power reduction during this phase. )
			ChangeDownPowerpS ( 5 )
			RateOfChangeDownPowerpSS ( 1 )
		)
	)


	Comment ( Stage 2 of anti-slip: Activates at full slip and very quickly reduces power to correct for major slipping. )
	AntiSlip (
		SlipDetectionThreshold ( 100 )
		SlipResetThreshold ( 70 )
		
		RateControl (
			ChangeDownPowerpS ( 50 )
			RateOfChangeDownPowerpSS ( 25 )
		)
	)
)


Not that the automatic power reduction rate is a bad idea, I think that would be a good choice to have, but using that exclusively is problematic. Perhaps if someone were to not define a custom power reduction speed then the automatic calculation could be the default. But again, maybe this is me dreaming unrealistically big. Ideally, I want a system that is simple to implement, but with potential for complex behavior as a result of many simple interactions combined. That's hard to do but is very important for Open Rails, where there's a whole planet's worth of trains that we want to model with one generalized system. That system will need to be flexible to make anyone happy.



Oh, and another thought, there should also be the provision for automatic sanding (if desired by the engine file creator) as this is yet another feature commonly incorporated into some (but not all) anti-slip systems. A good setup should also allow for defining the duration of time for which the sanding should occur after slip has stopped. In my multi-stage example, stage 1 could have no automatic sanding while stage 2 could have 10 seconds of automatic sanding, for example.

And I know Erick also proposed the idea of a wheel slip detection delay. I liked that as it could add some spice to anti-slip systems and make them behave a bit more erratically.

#3 User is offline   ErickC 

  • Foreman Of Engines
  • Group: Status: Contributing Member
  • Posts: 997
  • Joined: 18-July 17
  • Gender:Male
  • Location:Hastings, MN, US
  • Simulator:ORTS
  • Country:

Posted 05 April 2021 - 08:05 PM

Yeah, the main difference in what I proposed was that I think any anti-slip system will also need two variables: detection speed and reaction speed. The major difference between, say, WS10 and Super Series is that WS10 has a slow detection method (resistance) paired with a slow reaction speed (analog controller), while Super Series (in theory) has a fast detection method (radar) and a fast reaction speed (digital controller)*. This is why a locomotive using WS10 or IDAC would apply heavy-handed correction with large swings in load while modern radar-controlled systems have such fast detection and such fine control that they can maintain the conditions necessary for wheel creep (no, it is not now and never has been a function of AC motors, it's a function of ground radar and digital control modules).

There are also retrofit wheelslip control modules for older locomotives that will provide a sort of in-between - detection is still done with resistance, but the microprocessor control unit can react more quickly and accurately. This would provide a good simulation of, say, an SD40-3.

I've been meaning to write a super long technical post called "how diesel-electric locomotives actually work," but most of my writing these days concerns the minutiae of tying social work literature to practice. And discussion posts. How I hate discussion posts.

*In reality, as I understand it, Super Series was basically garbage and never really worked as advertised, hence why the 60 series quickly moved to Mod3.

#4 User is offline   joe_star 

  • Fireman
  • Group: Status: Active Member
  • Posts: 191
  • Joined: 16-January 13
  • Gender:Male
  • Simulator:MSTS
  • Country:

Posted 10 April 2021 - 12:10 AM

Just a small comment here

The current parameter ORTSCausesthrottledown does not zero the throttle from what I have seen, rather reduces it automatically to a level where slip stops. But it is a physical adjustment of the throttle, rather than what is proposed here which I tend to like as well

#5 User is offline   pschlik 

  • Conductor
  • Group: Status: Active Member
  • Posts: 311
  • Joined: 04-March 15
  • Gender:Male
  • Simulator:OpenRails - Unstable
  • Country:

Posted 10 April 2021 - 08:08 AM

View Postjoe_star, on 10 April 2021 - 12:10 AM, said:

Just a small comment here

The current parameter ORTSCausesthrottledown does not zero the throttle from what I have seen, rather reduces it automatically to a level where slip stops. But it is a physical adjustment of the throttle, rather than what is proposed here which I tend to like as well


I believe it's AntiSlip that reduces throttle only as much as is needed to bring slip under the slip warning threshold, while ORTSWheelSlipCausesThrottleDown is the one that completely shuts power. Might have been changed though, I usually use AntiSlip as it was rather less annoying than the ORTS option.

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users