Weird issues with SD70M consist leaving Atlanta (maybe Bin Coupler related?)

[tpilot]

Decided to start a new thread for this rather than pollute the one I originally hi-jacked on the main forum.

And my results are slightly different from what I said yesterday. This is really weird though.

I have a consist with the following cars:

Train (
TrainCfg ( NS_SD70M_WF_15_mixed
Name ( "SD70M NS 2584 WF and 15 mixed freight" )
Serial ( 1 )
MaxVelocity ( 40.00000 1.00000 )
NextWagonUID ( 16 )
Durability ( 1.00000 )
Engine (
UiD ( 15 )
EngineData ( 2NS2584 2NS2584 )
)
Wagon (
WagonData ( us2fcarre2timberload US2FCARRE2 )
UiD ( 0 )
)
Wagon (
WagonData ( us2freightcar1 US2FREIGHTCAR1 )
UiD ( 1 )
)
Wagon (
WagonData ( us2fcarye2timberload US2FCARYE2 )
UiD ( 2 )
)
Wagon (
WagonData ( us2caboose US2CABOOSE )
UiD ( 3 )
)
Wagon (
WagonData ( emrr_coal_fl "n11 coal1" )
UiD ( 4 )
)
Wagon (
WagonData ( us2chemicar US2CHEMICAR )
UiD ( 5 )
)
Wagon (
WagonData ( csx_autorack csxauto )
UiD ( 6 )
)
Wagon (
WagonData ( us2freightcement US2FREIGHTCEMENT )
UiD ( 7 )
)
Wagon (
WagonData ( us2bnsfcar US2BNSFCAR )
UiD ( 8 )
)
Wagon (
WagonData ( emetro_coal_fl "n11 coal1" )
UiD ( 9 )
)
Wagon (
WagonData ( us2fullloggercar US2FULLLOGGERCAR )
UiD ( 10 )
)
Wagon (
WagonData ( us2woodchipper US2WOODCHIPPER )
UiD ( 11 )
)
Wagon (
WagonData ( logcarwl "n11 logcar with load" )
UiD ( 12 )
)
Wagon (
WagonData ( ta_nkp_50t_hop_loaded ta_NKP_AlcoRS11 )
UiD ( 13 )
)
Wagon (
WagonData ( us2hoppercar US2HOPPERCAR )
UiD ( 14 )
)
)
)

Conbuilder randomly picked the cars which is why the caboose is in the middle . . . (1560 tons)

Anyway, if I start with this consist on Marias Pass, it works fine.
If I start on Macon Atlanta at Macon, it works fine.
If I start on Macon Atlanta at Reynolds Recycling, it works fine.
If I start at Ford Plant Auto it works fine.
If I start at Atlanta with the KHP2Demo Westbound (which is a 91 car loaded grain train pulled by two AC4400CW’s (11036tons)), that works fine.
If I start with the SD70M consist at Altanta:

The train is initially rolling backward at 0.1 to 0.2 mph, even though the brakes are still set.
When I release the brakes, the train rolls backward - reaching 3.6-4.2 Mph, then comes back to rest in approximately 15 seconds.
After the train comes to rest, I set the reverser to forward and move the CPH to 25%.
The train starts forward, reaching a speed of about 6MPH, however, it then starts losing speed quickly coming back to rest.
I can raise CPH to 100% at this point, the engine spools up, the ammeter goes to 1700 amps, but the train remains stationary. I also don’t get any wheelslip indications.
I can then press F9, all the handbrakes are off, decouple the 0-14 car, no effect, 0-13 car, no effect, 0-12, no effect, etc. until I decouple the 0-6 car. At this point the train shoots forward, rapidly picking up speed to 30 or 40 mph or more.

What could be special about Atlanta on the NS Atlanta-Macon route that could only allow my train to pull 6 cars here and 15 cars anywhere else?

What could be special about the coupling between the US2Chemicar and the CSX AutoRack?

BTW, I am using TurboBill’s (Version 1, not the latest V1.1 posted today) coupler values as follows:

WagonData ( us2fcarre2timberload US2FCARRE2 ) - Cushioned Couplers
WagonData ( us2freightcar1 US2FREIGHTCAR1 ) - Cushioned Couplers
WagonData ( us2fcarye2timberload US2FCARYE2 ) - Cushioned Couplers
WagonData ( us2caboose US2CABOOSE )- Cushioned Couplers
WagonData ( emrr_coal_fl "n11 coal1" ) - Rigid Couplers
WagonData ( us2chemicar US2CHEMICAR ) - Rigid Couplers
WagonData ( csx_autorack csxauto ) - Cushioned Couplers
WagonData ( us2freightcement US2FREIGHTCEMENT ) - Rigid Couplers
WagonData ( us2bnsfcar US2BNSFCAR ) - Rigid Couplers
WagonData ( emetro_coal_fl "n11 coal1" ) - Rigid Couplers
WagonData ( us2fullloggercar US2FULLLOGGERCAR ) - Rigid Couplers
WagonData ( us2woodchipper US2WOODCHIPPER ) - Rigid Couplers
WagonData ( logcarwl "n11 logcar with load" ) - Rigid Couplers
WagonData ( ta_nkp_50t_hop_loaded ta_NKP_AlcoRS11 ) - Rigid Couplers
WagonData ( us2hoppercar US2HOPPERCAR ) - Rigid Couplers

So I don’t see anything terribly out of the ordinary there - and if the coupler values were causing the problem, why would it only happen in Atlanta? Then again, if Atlanta is the problem, why are my other trains able to start fine from here.

Okay, this just gets weirder and weirder . . .

I started off with a different consist with another SD70M (with Bob Boudoin Physics, I hadn’t upgraded the first one, not that it should matter), and I thought there was a slight uphill leaving the intermodal yard. So I tried the following:

I went back to my problem consist and saw I had a lot of siding behind the train. I backed it up to about 15 mph, (it worked fine in reverse), backed down the siding a fair amount, gave it about 25% throttle, and the train started got to about 15 mph and ran fine until it hit the turn out of the intermodal yard, where it slowed to 0.

It gets worse! I backed the train a little bit farther back into the yard, started it up and gave it 100% throttle. It got up to 30 mph, reached the turn out of the yard and slowed down to 0.1 mph, then sped up to about 6 mph, before stopping at the junction of the mainline!!!

I decided to really see what would happen so I backed the train all the way through the intermodal yard and back to the entrance to the Inman yard. Then I gave it full power from here. One thing that seemed odd is that through the curves leading up to the intermodal yard, the engine was not accelerating, but was losing speed (odd for a lightly loaded train with a strong engine). However, on the straight track through the yard, I got up to 42MPH, then the train slowed to 17 MPH through the turn out of the yard and came to a stop at the entrance to the main line. All at 100% power!!!

More testing - I said earlier the train ran okay from Macon, and I guess it does. It will top out at about 35Mph with full throttle, and the projected speed will fluctuate between 15 and 40. It tops out at about 40-45 on Marias, though so I guess that’s pretty consistent. Tops out at 40 on KHP2 Demo, so it seems to work on other routes.

[GaryG]

Hi

That's an autorack. By any chance is that car at a switch? If so, try adding "CouplingHasRigidConnection ( )" in front of the Velocity line in the Coupling section for that car. Having the option blank or '0' or '1' all seem to have the same effect in tests I've done.

It's also possibly if at a switch, the switch might be flipped for the wrong path causing the train to jam. I suspect this isn't the cause though because removing the one car seems to solve the problem; unless with that car, the rear car is at a switch.

The rollback could be caused by having the train start point on a grade and the locos train brake setting (in the .eng file) not at a high enough value to hold the train.

Your final two paragraphs both indicate my first suggestion will solve your problem. I add this parameter to all locos and long cars here; binding and bouncing through switches is no longer a problem. I can take a train of autoracks and dash9's through my sharpest switches with no more power needed than if it was on track without switches.

GaryG

[tpilot]

Hi Gary,

>That's an autorack.

Correct.

>By any chance is that car at a switch?

Quite possibly - the route seems to stack the train up from the tail with the tail on a siding, so there is a right-hand switch in front of the siding and then a left-hand switch onto the main line. (I thought the 91-car train was starting in the wrong place because it extended all the way to the main line before it started.)

>If so, try adding "CouplingHasRigidConnection ( )" in front of
>the Velocity line in the Coupling section for that car. Having
>the option blank or '0' or '1' all seem to have the same
>effect in tests I've done.

Doggonnit, all my wagons had CouplingHasRigidConnection(1) before that line, and Turbo Bill took it out for all except Passenger cars and RoadRailers, and it's still missing on his latest version. Someone needs to let him know.

You are saying it doesn't matter if it is blank, 0, or 1, but the line needs to be there, right? (I would think a blank line would be interpreted as zero).

Looks like the donation-ware version of Route-Riter is going to get another workout!!!!

How come only autoracks have the problem - All my MLT tank cars and the other cars in the same consist don't have that line either. Of course it's also possible it's not the autorack, but just where that car ends up positioned, so swapping a different car, the new car would have the problem.

>It's also possibly if at a switch, the switch might be flipped
>for the wrong path causing the train to jam. I suspect this
>isn't the cause though because removing the one car seems to
>solve the problem; unless with that car, the rear car is at a
>switch.

Well, the locomotive goes through the switch correctly, but the train always binds up at that point in the route. Again, however, the heavier MLT train would be dragging cars thru that same switch with a heavier train and less relative horsepower.

>The rollback could be caused by having the train start point
>on a grade and the locos train brake setting (in the .eng
>file) not at a high enough value to hold the train.

It's not much of a grade and I think the train brake is set full. But it's not the rollback that bothers me it's that sudden stop when I try to get the train out of the yard. (It's not the fall off the scaffolding that's the problem, it's that sudden stop at the bottom.)

>I add this parameter to all locos and
>long cars here

My loco's have the RididConnection (1) line (although the latest Turbo Bill updates would delete it).

Thanks for the advice, although I still don't know why it would be required.

[drjoe]

I don't like the "blank" version of the "rigid" line, but all three "versions" seem to have the same effect. I just prefer the ( 1 ) in place so it is obvious what one is trying to do. And yes, those long autoracks will improve in the turns when you put that value in. Larger r0 values might also work, but the "rigid" line seems to work best.
Almost all my Seaview stock has had the "rigid" line added because of the tight turns on that route.

[GaryG]

Hi,

"You are saying it doesn't matter if it is blank, 0, or 1, but the line needs to be there, right? (I would think a blank line would be interpreted as zero)."

It does appear just defining the parameter does the trick in tests I've done, blank 0 or 1 all seemed to work the same.



"How come only autoracks have the problem - All my MLT tank cars and the other cars in the same consist don't have that line either. Of course it's also possible it's not the autorack, but just where that car ends up positioned, so swapping a different car, the new car would have the problem."

Actually, you'd probably find passenger cars and the 80' intermodals also behave in a similar manner with binding and rubberbanding when going through switches. It's almost as if MSTS doesn't allow for couplers enough range in their side-to-side swings. I think it affects any equipment longer than 40' or so and the longer it is, the worse the problem.

There is one other benefit to adding this parameter, no more broken couplers at track nodes. One disadvantage - no more slack action which is why I'm only using it on longer cars (and all locos).



"Well, the locomotive goes through the switch correctly, but the train always binds up at that point in the route. Again, however, the heavier MLT train would be dragging cars thru that same switch with a heavier train and less relative horsepower."

Probably the long car in the lighter and shorter train is causing the problem.



It's not much of a grade and I think the train brake is set full. But it's not the rollback that bothers me it's that sudden stop when I try to get the train out of the yard. (It's not the fall off the scaffolding that's the problem, it's that sudden stop at the bottom.)

To confirm, look at the .eng file and find the parameter "Brake_Train", example "Brake_Train ( 0 1 0.0125 0.44". In this case, the 0.44 is the train brake initial setting if the consist is set to start at 0MPH. If anything but 0MPH starting speed, the Train Brakes will be released at start.



"Thanks for the advice, although I still don't know why it would be required."

Thank the Kuju/Microsoft designers for that ;-)


GaryG

[Turbo Bill]

I am looking into this problem. I will report back when I have some more answers. I appreciate all the testing help and feedback.

Bill

[tpilot]

Thanks Bill and Gary,

Well, that was NOT the problem. I added the coupling has rigid connection and still can’t move. I think you are onto something, but I’m not sure what.

I did look at the external views, the locomotive is behind the second switch before the mainline. There is no switch between it and the CSX Autrorack. There is a switch at the rear of the next car, the US2 Cement car.

I think brakes are set at 75% initially, but not sure.

Took the caboose out of the consist - Same problems, train again started moving when I decoupled the autorack, even though the autorack's position did not change (the locomotive would be one car further back) - possible switch problem.

Shifted the Chemicar, the CSX Autorack, and the Cement Car to the rear of the consist (still in that order). The train pulled forward until the rear bogie of the cement car was even with the lever to change the switch position (which is the same position it was in when the problem occurred before) (the train was further forward now though). Started dumping cars and still had to dump both the cement car and the CSX auto-rack, but the train ran fine after that.

Now this is weird . . . Deleted the Cement car from the consist. Train started and moved forward, but again stalled. Stopped at the same place as before, except the Cement car was no longer on the switch. The rear bogies of the Autorack were just past (FORWARD) of the frogs (points) of the switch. They had cleared the switch, although the bounding box probably hadn’t. Could zoom in on the switch and could verify the points were set properly.

Not sure what to try next. Decided to call it a night. . .

[tpilot]

BTW, these are the coupler values I am using now:

Autorack:
comment ( MSTS Bin Cushioned coupler values contributed by Otto Wipfel, Joe Morris
and Bill Prieger )
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 6e5N/m 2e7N/m )
Damping ( 1e6N/m/s 1e6N/m/s )
Break ( 5.1e7N 5.1e7N )
r0 ( 20cm 30cm )
)
CouplingHasRigidConnection ( 1 )
Velocity ( 0.2m/s )
)
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 6e5N/m 2e7N/m )
Damping ( 1e6N/m/s 1e6N/m/s )
Break ( 5.1e7N 5.1e7N )
r0 ( 30cm 20cm )
)
CouplingHasRigidConnection ( 1 )
Velocity ( -0.2m/s )
)
Buffers (
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m/s 1e6N/m/s )
r0 ( 0m 1e9 )
)
Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )
)

Chemicar, Cement car:
comment ( MSTS Bin Rigid Coupler values contributed by Otto Wipfel, Joe Morris
and Bill Prieger)
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 0.1e6N/m 20e6N/m )
Damping ( 1e7N/m/s 1e7N/m/s )
Break ( 5.1e7N 5.1e7N )
r0 ( 5cm 7.5cm )
)
Velocity ( 0.2m/s )
)
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 0.1e6N/m 20e6N/m )
Damping ( 1e7N/m/s 1e7N/m/s )
Break ( 5.1e7N 5.1e7N )
r0 ( 7.5cm 5cm )
)
Velocity ( -0.2m/s )
)
Buffers (
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1e6N/m/s 1e6N/m/s )
r0 ( 0m 1e9 )
)
Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )
)

The non-autoracks lack the coupler has rigid connection value, adding it would eliminate ALL slack action, but I don't see how that would help if the train seems to be hanging on the last bogie of the autorack and that DOES have the rigid connection line. (Also don't see how it is hanging up there if NOTHING is coupled to it, which was the case in the last test . . .)

[Turbo Bill]

I have made headway with the coupler gap issue and have all but eliminated the long cushioned cars (ie: centerbeams) binding on double switches (this equates to a very tight S-curve) with no binding on single switches lined for diverging movements. Thanks to Tpilot I have realized that I was incorrectly encoding the second coupler region. So bear with, I should have a new set of couplers up for testing in the next day or so.

[tpilot]

>Thanks to Tpilot I have realized that I
>was incorrectly encoding the second coupler region.

But remember Joe Morris contradicted me, and he should know better than I do.

Did some more testing last night and found the following, but not much:

Well, I couldn’t fix it, but I can tell more about where the problems are and what DOESN’T work. First, I tried to add the MP3Kcons coupler values to the CSX autorack. That would be these values, note there is no second coupler value:

Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1.3e6N/m/s 3.8e6N/m/s )
Break ( 5.4e7N 5.4e7N )
r0 ( 20cm 30cm )
)
CouplingHasRigidConnection (1)
Velocity ( 0.1m/s )
)
Buffers (
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1.3e6N/m/s 3.8e6N/m/s )
r0 ( 20cm 30cm )
)
Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )
)

I had the same problem, but I noticed something I should have caught before. The train would start moving, stop and then roll back a little, but the forward motion carried the end of the train (the CSX Autorack) past the switch, and then it rolled back but it still stopped forward of the switch.

That prompted me to look at the position of the first Autorack, US2freightcar1 from the default set. Sure enough, it was positioned over the forward switch, the one just before the switch onto the main line.

I added the MP3Kcons section above to the first autorack, and saw no change in the results.

I then added a second coupler line to the first autorack, as follows, and tested again:

Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1.3e6N/m/s 3.8e6N/m/s )
Break ( 5.4e7N 5.4e7N )
r0 ( 20cm 30cm )
)
CouplingHasRigidConnection (1)
Velocity ( 0.1m/s )
)
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1.3e6N/m/s 3.8e6N/m/s )
Break ( 5.4e7N 5.4e7N )
r0 ( 20cm 30cm )
)
CouplingHasRigidConnection (1)
Velocity ( -0.1m/s )
)
Buffers (
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1.3e6N/m/s 3.8e6N/m/s )
r0 ( 20cm 30cm )
)
Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )
)

The train stopped at the same place. This time I zoomed in on the first autorack, and you can basically tell the second bogie gets to the frogs of the switch and then the train rolls back and stops.

I decided to try the Route-Riter Bin Long Freight values next:

Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1.3e6N/m/s 3.8e6N/m/s )
Break ( 5.4e7N 5.4e7N )
r0 ( 20cm 30cm )
)
CouplingHasRigidConnection ( 1 )
Velocity ( 0.12m/s )
)
Coupling (
Type ( Automatic )
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1.3e6N/m/s 3.8e6N/m/s )
Break ( 5.4e7N 5.4e7N )
r0 ( 20cm 30cm )
)
CouplingHasRigidConnection ( 1 )
Velocity ( -0.12m/s )
)
Buffers (
Spring (
Stiffness ( 1e6N/m 5e6N/m )
Damping ( 1.3e6N/m/s 3.8e6N/m/s )
r0 ( 20cm 30cm )
)
Centre ( 0.5 )
Radius ( 1 )
Angle ( 0.5deg )
)

No difference. At this point, I didn’t know what to try. All the fixes were for the front coupler, but I was having problems with the rear bogie.

However, as I was writing this up, I thought of something.

Looking at it in hindsight, what I can’t answer now is how come the first autorack on the near to the mainline switch is stopping the train now, but dumping the SECOND autorack allowed the consist to roll out the earlier time I tried this, meaning that the first autorack was clearing the switch then. I did not have CouplerHasRigidConnection on either car the first time and had it on both now, but that shouldn’t be enough to do it.

Out of curiosity, I ran the simulation again, waited until the first autorack appeared to get stuck on the near switch, zoomed the camera in on it, pressed F9, and decoupled the SECOND autorack, sure enough the first autorack rolled right through the switch and the train kept going . . .

This made me edit the second autorack. I had revised it earlier to use the MP3Kcons coupler values, but now I changed it to the double-coupler MP3Kcons, and then to the Route-Riter BIN long freight, and nothing helped, the train got stuck in the same spot.

[drjoe]

I don't think this is a coupler issue, but rather one involving the setting of the switch. It was reported that with Bin 1.6 that switches in activities have a habit of "changing" from their correct setting. One car is following the engines. The other car is trying to go the "other way" through the switch, thus the "bind". The recommended solution is to open the activity and re-save it. The "normal" solution for this at the start of an activity or explore session is to back up until the "lead" of the train has cleared the switch and then "throw" it to the desired direction using the "G" key. Apparently even this was not stable in activities created using 1.4 and then loaded into 1.6, thus the re-save of the activity. I didn't think that this was an activity though. Your post indicated that it was a random consist used in an explore mode session. Try removing enough cars from the consist so that it starts with the lead engine and all cars clear of the switch.

[tpilot]

>I don't think this is a coupler issue, but rather one
>involving the setting of the switch.

The switch is probably involved, but I can't say if this is switch or coupler or wagon related at this point.

This is not an activity, it is in explore mode.

>It was reported that
>with Bin 1.6 that switches in activities have a habit of
>"changing" from their correct setting. One car is following
>the engines. The "normal" solution
>for this at the start of an activity or explore session is to
>back up until the "lead" of the train has cleared the switch
>and then "throw" it to the desired direction using the "G"
>key.

This is an explore mode, not an activity. Also, this might be hard to explain, but these are converging, not diverging switches. In other words, there is not a branch to the left or right ahead and I can throw a switch to select which route the train takes. This is a situation where the yard sidings converge into single track, so a train coming the other direction could choose a path, but leaving the yard there is only one way to go. I thought MSTS set these switches automatically.

>Try removing enough cars from the
>consist so that it starts with the lead engine and all cars
>clear of the switch.

In honesty, I can probably dump the autoracks for something else and the problem will go away, but I would like to know what is causing it. It is not train length related though, b/c I said I could run a 91-car grain train where the train extended through all three switches onto the mainline without problems.

[drjoe]

Which "leg" of the switch are you on at the start? The straight or the turnout? Uncouple your car and after the car clears the switch, see where the points are. I suspect that you are on the "turnout" part of the switch, and that after you uncouple and pass, the points are for the "straight" path. The autoracks "bind" enough ( and depending on their weight, perhaps they are set as empty ) that they may not be able to push through the "extra" curvature of the switch set "against" them, even though you are converging rather than diverging.

[tpilot]

>Which "leg" of the switch are you on at the start? The
>straight or the turnout?

Well, there are two switches, not counting the mainline, and we are not sure which one is having the problem.

At start of Explore, Locomotive is approaching the turnout leg of a converging switch (I will call this "second switch"). Autorack one (US2-SanteFe) is between this switch and the "first switch", further back. CSX autorack (at end of train) is on the straight leg and has not reached the first switch.

When train gets hung up, rear bogie of SF autorack has not cleared second switch. Entire CSX autorack has cleared all of first switch. However, decoupling CSX autorack allows train to proceed, which seems very strange.

I did not decouple first, but i did zoom in and verify that first switch is set for thru-leg and second switch is set for diverging, as desired.

Also, note that when I tried to back up and get a "running start" through the yard, the train slowed down TWICE, but that could either indicate one of the autoracks having problems with both switches, or both autoracks having problems with the same switch.

[drjoe]

If the train has no problems when you remove the autoracks, then please post the .wag file contents of the autoracks. I want to check the physics in those cars ( especially angular friction line and mass ).

[tpilot]

Thanks - I'll post them tomorrow.

The SF autorack started life as an MP3Kcon car, but has since had TS-Fast Fix, Route Riter's rolling stock mods, and too many coupler changes to count.

The CSX autorack was downloaded around 2001-2002 and has had the same updates, but I wouldn't be at all surprised if it needed additional tweaking.

Thanks again.

[Turbo Bill]

I have been working on the cushioned coupler for the Bin pack and found out some things while testing using two switches both lined for diverging movements. This in essence makes a tight "S" curve. If the train will trail or shove thru this it will probably go thru anywhere. What I found is that the new Bin patch makes the switch nodes more sensitive to sprng stiffness levels. I have found that anything above 4e6 on any line in the stiffness value tends to make the car hang on one of the switches if two are imvolved. I have lowered my second expansion value to 4e6 and two engines can pull a rather long train thru the double switch with minimal hang ups. There is still a noticable tug on the cars going thru the deep switch but it is neglegable enough to go with it. This will allow me to still minimize that extension part of the spring and keep the couplers together under hard pulling with high horsepower locomotives. I had been chasing the r0 values thinking this is why my cars would hang up when pulling out but still roll thru on a shove. I then realized that any r0 value could be entered even to the extreme and the cars would still hang on the deep switch. Then something Joe told me clicked in. Some switch nodes do not like high stiffness values and I lowered my second value on both couplers and what do you know the cars now pull thru the double switches and float like butter thru the single diverging ones. so now that this issue is kinda solved I will now work on r0 values to minimize the effects of spring stretch and should have working couplers in the next day or so. BTW I am testing this using centerbeam flatcars and empty ones at that as the empties hang up where the loads will work thru. The new rigid (no slack) couplers seem to be working so far on any length car but the centerbeams didn't like them for some reason. The cushioned drawbars seem to work fine on shorter cars like 50 and 60 foot boxcars. BTW I am using updated newer values then the Bin Coupler pack V1.1 so stay tuned.

[tpilot]

Bill-thanks for the update, I look forward to your new values.

All:

More test results:

I swapped out the CSX Auto-rack on the end of the train for the SF Autorack that was the second or third car, so I had a pair of SF Autoracks. Train stopped at same position. So it likely was not the CSX car.

Removed the SF Autorack from the end of the train and replaced it with the standard boxcar (USFreight6, I think). Train ran fine.

Left the boxcar in, and added the CSX autorack back onto the end of the train. TRAIN RAN FINE. (so it was not the CSX car being at the end of the train.

Removed the boxcar (which put me back to the same consist I had originally). Train stopped at same position.

I don’t think it’s a coupler problem anymore. Either some problem with the autoracks being too close to each other in the trains, or maybe the physics on the autoracks are way out of whack, or just some particular problem with the autorack attached to the car that was originally in front of it.

Anyway, I am posting the files for drjoe to look at.

Still pretty weird.

[tpilot]

I was just browsing the file library and ran across biLev_1.zip, which said this:

MSTS 89' Bi-Level Auto Racks A pack of 37 different Thrall Car bi-level automobile racks. Replaces models originally released during summer 2002. New physics, including loaded and empty versions. New paint schemes included. Model by Bruce Bridges, physics by Bob Boudoin.

I think I probably have the 2002 cars, so replacing them with these should be a good start.

However, I would think the default car that came with MSTS should have worked okay.

[Turbo Bill]

On both the NERR vr and the P&A vr the autowraks even the US 2 ones have always been a thorn in the side. They always hang on switches and I believe one of the members fixed that or at least minimized the problems. I will look at the coupler regions on one of them and post the coupler section. The main number that needs to be changed to make the old couplers work with the Bin patch and flawless coupler action is one: Otto's Default wag file and two: the velocity line needs to be changed to Velocity ( 0.2m/s ) for the first coupler region and Velocity ( -0.2m/s ) for the second coupler region.

A funny thing I noted in researching how various people use the coupler region is that 3DTrainStuff and MLT and I believe Marc Nelson from 3DTrains only use one coupler region and no buffer sections. Has anyone tested to see how this single coupler format is working with the Bin patch? So far I can almost put any erroneous value in the second coupler region either using the same format as Joe for compression/extension or using Route Riters reversed values for the second coupler region and there are no apparant changes in performance. I do think the negative velocity number is the big key to what the second region does for improved performance. One thing I should note is that whatever I have been changing in the first coupler region, I have been mirroring in the second with the value swapping as noted above the only deviation.

[tpilot]

>The main
>number that needs to be changed to make the old couplers work
>with the Bin patch and flawless coupler action is one: Otto's
>Default wag file

Got it . . .

and two: the velocity line needs to be
>changed to Velocity ( 0.2m/s ) for the first coupler region
>and Velocity ( -0.2m/s ) for the second coupler region.

Had that, changed to 0.12 per RR, but didn't seem to work regardless . . .

[Turbo Bill]

Give me a day or two to get you another set of coupler regions to try on your instance. I have made some ground on these and may have a set that should work.

[tpilot]

Turbo Bill - Will do, but I'm wondering now if it's maybe some weird route anomaly - more below. (And yes, I realize I should just add another car to the consist and quit worrying about it - which would fix the problem. It just bothers me when something SHOULD work and I can't figure out why it DOESN'T.)

***

More tests: Okay, this just keeps getting more and more weird!

Swapped out the previous cars for the ones in bilev_1.zip and still get the same errors. Tried with the new CSX autorack empty and full and got the same errors. Tried with and without the Route-Riter Bin coupler values and got the same errors.

Also, I noticed, if you watch the trailing autorack, it will be going fine, then will stop, jerk the whole train back about ten feet, and then rock back and forth on the track (front to rear) like it is being alternately pulled and pushed. The ground around the car seems to have the same motion, and this continues indefinitely until you either decouple or quit MSTS.

???? ????

[Turbo Bill]

It's definetly a node grabbing the car. I had Cascade Crossing do this a couple times and can't remember how I fixed it. I think I removed the route and reinstalled it from scratch, cleaned out any saves and went from there. BTW, clean out your saves folder for this route, that may help, but it's only a guess.

[tpilot]

>It's definetly a node grabbing the car.

Thanks, at least I know what it is! Is that a coupler problem, a physics problem, or something completely different.

>I think I removed the route and reinstalled it from
>scratch, cleaned out any saves and went from there. BTW,
>clean out your saves folder for this route, that may help, but
>it's only a guess.

I think I killed all the saves yesterday. Having another odd problem with this same engine in Train Store. Engine is listed, but won't let me select it in any route. Works okay in MSTS directly though.
(I have an e-mail in to the author, but if anyone else knows why!)

[Turbo Bill]

Joe would know better but I do believe the couplers are a small part of the equation. I think it has to do with how the switch routes the train and it's cars using the nodes but this is only speculation. I do know that Cascade Crossing did this with a big train of Centerbeams I had and I was able to fix it. Let me do some research and see if I can find out how I fixed it. I should have a new coupler pack up soon for you to try but I'm betting it's that switch in the route doing it.

[drjoe]

I need to have the "whole" car. I want to check the bounding boxes, everything. Send both autoracks please.

email address ( note, it is "broken up" so spammers can't read it )

j r m d v m 1 @ a o l . c o m

[Turbo Bill]

New Beta coupler pack released on another thread. This may or may not help. Good luck TPilot.

[tpilot]

Joe - Will send you the files tomorrow. Bounding boxes were supposed to be "fixed" with Route-Riter, but a double-check couldn't hurt.

Bill - Will download the files, but want to give Joe a chance to get back with me before I change anything. (Too much chance of my values not matching his values.)

All - Tony (Train Store author) wrote me back and he feels the engine not launching from TS may be a duplicate name problem. He recommended checking the consists in Conbuilder. I haven't looked into this yet, but there is a possibility that whatever is messing up TS is affecting behaviour in MSTS.