Frequent Broken Coupler!

[geepster775]

Thanks for constructive comment! NOT!

My thoughts, exactly, concerning the value of this entire thread.

[PeterB]

Thanks to meeshu and R. Steele for this thread!

This is an interesting situation!

As I understand it, resuming a saved activity where a heavy train was going uphill, there is a possibility of (excessive) broken couplers occurring on resumption of that activity. Yet prior to saving that activity there was no issue with broken couplers!

This situation appears more likely to occur when there is more head end power with respect to other power placement within a consist.

I haven't come across the broken coupler situation, yet, on resumption of saved activities, but I will attempt to create some activities that might lead to broken couplers occurring on resumption of saved activities.

As for some that like to denigrate this thread, I don't really understand why. Maybe they don't have anything better to do?

This seems like a genuine and constructive thread to me.

[derekmorton]

>This seems like a genuine and constructive thread to me

The only thing it misses is that is not a consist that would be used in the real world.

I try and run realistic consists.

[R. Steele]

>This seems like a genuine and constructive thread to me

The only thing it misses is that is not a consist that would be used in the real world.

I try and run realistic consists.

Yes, Derek --- normally I do to. I doubt that any train like this went over the Cajon...(I'd be genuinely surprised if evidence proved me wrong ).

However, this is a simulation and this experiment brings out an interesting problem in pushing the physics envelope and train handling. I have not broken a coupler, but I did lose the train due to inattention to wheelslip. I was creeping up the hill at about 7mph, could add throttle every few minutes or so to keep the speed steady at 7-8mph, but if I notched up the throttle for too long I encountered wheelslip, had to immediately back off the throttle. You were on the money about too much head end power.

[meeshu]

This thread is basically about Open Rails not resuming saved activities precisely to the state of the activity immediately prior to saving the activity.

This has nothing to do with whether the trains are typical or not.

Again. Despite there being no issues with broken couplers immediately prior to saving the activity, Open Rails decides that there are now broken couplers on resuming that same activity! So Open Rails does not appear to properly restore the activity to the state that the train was in immediately prior to saving that activity.

[R. Steele]

This thread is basically about Open Rails not resuming saved activities precisely to the state of the activity immediately prior to saving the activity.

This has nothing to do with whether the trains are typical or not.

Again. Despite there being no issues with broken couplers immediately prior to saving the activity, Open Rails decides that there are now broken couplers on resuming that same activity! So Open Rails does not appear to properly restore the activity to the state that the train was in immediately prior to saving that activity.

Did you read the "static breaks" thread at ET...here's a quote from OR developer dajones:

I suspect that this might be related to the performance problem that was found to be due to extra couplers being added to cars by the save/restore process. But I thought that was fixed.

In any case the logic that is used the check for excessive coupler force looks wrong. It is looping over all couplers defined for the cars and comparing the calculated coupler force with the limits defined for each. But the coupler force is calculated using only one of the defined couplers. That is the one returned by the coupler getter which returns either couplers[0] or couplers[1] depending on the car orientation.

Doug

...I don't know if the above code was ever looked at or worked on.

If this is the same problem, it should be duplicated with test stock as Peter Newell suggested, but which I was unable to do, then a developer would have to look at the appropriate code section. You could file a bug report.

[meeshu]

Yes, I did read that topic at Elvas, thanks.

I didn't get broken coupler issues when running my train with 4-4-4 locomotive configuration and after resuming the saved activities.

I'll try again with the original locomotive configuration of 5-3-4, and see if the broken couplers issue occurs again after resuming a saved activity.

[derekmorton]

>see if the broken couplers issue occurs again after resuming a saved activity.

If you do report broken couplers on resume, make sure you specify that it is on resume.
The code that needs looking at is different for the 2 cases.

[geepster775]

This thread is basically about Open Rails not resuming saved activities precisely to the state of the activity immediately prior to saving the activity.

This has nothing to do with whether the trains are typical or not.

“What are you, twelfth man on the deal team – last to know?” — Gordon Gekko

Rewind the calendar by 2 years and this thread would constitute a front page story. As of today, its a thread about a fantasy consist with unreal coupler break physics being forensically tested by folks who insist old news is breaking news. Now, is there anybody else who is slow on the uptake who cares to chime in?

I will say, over the past 2 years, there have been attempts to address it, as the recent "throttle down upon restore" topic shows us.

As for the wheelslip, note that the very design of AC traction locomotives makes it impossible to experience "runaway" traction motors. Its how real world engineers with AC engines get down to 1 mph when lugging uphill.

http://www.republiclocomotive.com/ac-traction-vs-dc-traction.html

"First, in a standard DC drive, if wheel slip occurs, there is a tendency for the traction motor to speed up and run away, even to the point of mechanical failure if the load is not quickly reduced."

"The AC system, however, operates in a very different fashion. The variable frequency drive creates a rotating magnetic field which spins about 1% faster than the motor is turning. Since the rotor cannot exceed the field speed, any wheel slip is minimal (less than 1%) and is quickly detected by the drive which instantly reduces load to the axle."

If, inside the sim, we are seeing uncontrolled spinning of wheels on AC traction SD80MACs, then either our engine physics are incomplete or the code itself cannot process the wheel slip distinction between AC and DC traction systems.

If we don't have this distinction coded right, then the rest of this exercise becomes moot.