Csantucci, on 01 July 2019 - 06:08 AM, said:
I haven't worked on such section of code, or, better said, I tried to but I found it quite mysterious.
I agree with that. The reason why the code does certain functions is not very well described.
Thanks for the feedback and finding the code snippet.
Csantucci, on 01 July 2019 - 06:08 AM, said:
so their absolute value is the same if DynamicBrakeForceN is > 0 and if MotiveForceN enters this block of code with value 0. Is this always the case?
I assume that when dynamic braking is applied that the locomotive is not producing any MotiveForce (ie it will be 0), however I think that it is then confusing to be modifying the MotiveForce to insert the DynamicBrakeForce.
This may also introduce some issues in the code, if a test exists to check when MotiveForce is equal to zero, if it is then artificially changed to accommodate DynamicForce.
dajones, on 01 July 2019 - 02:58 PM, said:
It looks like this code could use either DynamicBrakeForceN or MotiveForceN. This code appears to be relative new and was probably added as a bug fix. Before that MotiveForceN was added to TotalForceN without regard to the direction of travel and that probably caused the dynamic brakes to not work when going backwards.
Thanks for the feedback.
It certainly appears to be a convoluted process to modify MotiveForce to accommodate the DynamicBrakeForce. Given that the DynamicBrakeForce is a retarding force similar to normal BrakeForce, any thoughts on why couldn't it have been treated in the same manner, and if necessary an ABS value used to eliminate any directionality issues in DynamicBrakeForce (do you think that this was the issue trying to be fixed)? Having DynamicBrakeForce appear in these formulas would certainly make it easier to understand the code rather then mixing the meaning of parameters.
Would it be as simple as using the DynamicBrakeForce value calculated in the code block posted by Carlo, and removing relevant alterations to MotiveForceN?
dajones, on 01 July 2019 - 02:58 PM, said:
So brake force is used for locomotives but not for cars. I don't remember why. I also don't know why friction forces are not used. If the static force is under estimated here, then the car/train might oscillate between moving and stopped. It the static force is over estimated then the train might not start when it should.
Thanks also for the feedback on this, as it helps to clarify some of the code operation.
The full code block below shows that BrakeForceN is used sometimes in both locomotive and cars, and other times just in the cars.
TrainCar car = Cars[i];
if (car.SpeedMpS != 0 || car.TotalForceN <= (car.FrictionForceN + car.BrakeForceN + car.CurveForceN + car.WindForceN + car.TunnelForceN +
((car is MSTSLocomotive && (car as MSTSLocomotive).DynamicBrakeForceN > 0) ? Math.Abs(car.MotiveForceN) : 0)))
continue;
int j = i;
float f = 0;
float m = 0;
for (;;)
{
if (car is MSTSLocomotive)
{
f += car.TotalForceN - (car.FrictionForceN + car.CurveForceN + car.WindForceN + car.TunnelForceN);
if ((car as MSTSLocomotive).DynamicBrakeForceN > 0)
{
f -= Math.Abs(car.MotiveForceN);
}
}
else
f += car.TotalForceN - (car.FrictionForceN + car.BrakeForceN + car.CurveForceN + car.WindForceN + car.TunnelForceN);
m += car.MassKG;
if (j == Cars.Count - 1 || car.CouplerSlackM < car.GetMaximumCouplerSlack2M())
break;
j++;
car = Cars[j];
}
If there are anymore thoughts/insights, then it would be appreciated.
Thanks