Bug when pulling EMU and braking with dynamic / independent brake

[DB-47]

Hello there,

I discovered minor bug when doing some atypical trainsets. I created trainset ET42 + 2xEN57 to try whether you can pull "dead" EMUs or for instance simulate their transport to overhaul repairs or scrapyard. However during tests I discovered, when you brake only locomotive by using locomotive brake or electrodynamic brake and you exceed 100 kN of braking force. Trainset suddenly halts to complete stop as if there was derail. I recorded short private video clip showing also some debug information.

Repro steps:

I. Accelerate to at least 20 km/h
II. Apply at least 100 kN braking force by using locomotive brake or dynamic brake (for instance on ET42 or Traxx)
III. Observe trainset stopping instantly

Trainset used: See attached screenshot

[youBy]

Does it also happen when all vehicles are not reversed?

[DB-47]

Yes, I unreversed all vehicles and changed ET42 for Traxx, but the problem was identical. I also changed ET42 for Traxx and threshold was now at about 60 - 70 kN of dynamic braking until it suddenly stopped.

[Farmadupe]

This bug has been present for a while. It seems to trigger when there is a force imbalance in the coupler of the locomotive, because if you slowly reduce pressure in the brake pipe, all vehicles apply their own brake and no such stop occurs.

I assume that this bug may be caused by interaction between the drawhook coupler on the locomotive and scharfenburg coupler on the EMU. Perhaps spring/damper constants for Scharfenburg are set to very-high or very-low which might cause problems in the physics engine (overflow/underflow/implausible forces). I have not looked at source code but I guess that some author decided the best thing to do in this situation was to stop the train.

A useful experiment may to be copy/paste drawbar spring/damping values into EN57 .fiz file. If the bug goes away, it may also be an acceptable workaround for this problem.

[Farmadupe]

Yes, the problem seems to be eliminated by copy/pasting BuffCoupl. values from ET42 .fiz into EN57 .fiz

I have attached modified .fiz files (EN57AKŁ)

[Farmadupe]

I spent some time reading the source code. It looks like when a coupling is compressed by the sum of .fiz parameter fiz parameter BuffCoupl.::DMaxB of the couplings of the wagons, then the source code  forces the wagons to collide.

Maximum compression is set to 5 cm (0.05) on all couplings of EN57AKL, This value is clearly too low for the existing spring/damping constants. Unless Scharfenberg is known to be extremely weak in reality, I think a reasonable fix is to increase kB (coupler compression spring constant) and DmaxB (maximum allowed coupler compression). This is what I did in the .fiz files in my previous post, so I will not post another attachment here.

Note1: I am not sure why the source code causes a collision in this case but I guess that maybe it is to prevent wagons getting too compressed or streched (which would be a graphical glitch).

note2: If I read the code correctly, a slack of 1cm is applied on line 5290. This means that in combination with the small 5cm operating range for compression, a significant proportion of the restorative force is deleted (minimum delection: 20%  @ 5cm compression; maximum deletion: 100% @ 1cm or less). Assuming the unit of force in the source code is kilonewton, then two en57 wagons will 'collide' when compression forces reach kb*(DMaxB-0.01) = 4200 *0.04= 168 kN. This value is probably easy to reach when including slack/jerk.

note3: Perhaps maszyna should perform some other behaviour when the maximum values are exceeded. Perhaps this collision behaviour could be replaced with exponentially increasing buffer force and damping to prevent wagons from visually merging with each other

note4: I am worried about line of code 5275, because it will hard clamp the maximum coupler forces to some value depending on DmaxB. This risks causing infinite stretch/compression if such force is exceeded. If the collision logic was inserted to prevent infinite stretch, then a better fix would be to delete the collision logic and delete line 5275. I think clamping effect line 5275 also prevents the coupler break logic from ever executing in some .fiz files (in the case of EN57AKŁ, line 5275 means that CF will never exceed 168kN in compression, meaning that breaking force FmaxB (1.74 MN) can never be reached).

[jakubg1]

Unfortunately at the moment the executable file team is very small, it's only two people of which only one person does something from time to time, the other person rarely does anything, so they won't really help you much.
If you are able to, you can try compiling the source code and fiddling with it. Let us know when you come into interesting observations.

[robert357]

This is big issue because this can easily happen with heavy trains. For example I had that bug in L053_noc with ET42, L053_cargo_part1 with ET41 and in Calkowo_V2_eszelona with two ST44. With diesel locomotives it is especially easy if we set full throttle.

[Farmadupe]

I made a graph of the forces in couplers to investigate this issue. It is in the debug menu.

With this graph you can see the coupler forces become chaotic when there is > 450 kN.

I attached the executable.

[Farmadupe]

Just for fun, I also make a brake visualization (I wanted to do this for a long time)

If it is useful, I will try and make a pull request on github.