Page 1 of 5 1 2 3 ... LastLast
Results 1 to 10 of 48

Thread: CSX Ethanol train physics

  1. #1
    Join Date
    Sep 2006
    Location
    .
    Posts
    1,794

    Default CSX Ethanol train physics

    I've encountered an interesting situation. The "out of the box" physics settings for SLI's ethanol train release for Open Rails still seem a little off. If I place that trainset, using the provided consist, and use it on the Sherman Hill route, I seem to be unable to ever get that train moving on the upgrade when starting the train anywhere on the 0.8% uphill grade of Track 3, the low grade line via Harriman.

    Of course trains that size should be able to start from a dead stop on a 0.8% grade without any rear-end shove - that happens all the time. In real life, coupler breaks would only happen from sloppy train handling or engineer-induced slack yanks and jerks.

    In explorer mode, starting at Harriman, and heading towards Dale Jct, it requires the 5th notch just to keep the train from rolling away backwards. But even if I stay in the 5th notch, doing this no-win battle against gravity, after about a minute, the coupler knuckles between 2 cars somewhere in the train will break. If I go to the 6th notch earlier, knuckles will break immediately.

    While I applaud the effort to bring this kind of train handling physics to Open Rails content, something seems a little brittle in the chosen values. Either that, or the rolling friction is too heavy.

    The only changes I made to any files were to correct the MaxPower value which was incorrect (it was too low) on the GE's. I never touched the car physics settings in any way.

    The reason I chose Sherman Hill was because not all routes are laid with consistent gradient, especially when trying to replicate modern construction of lines built in the mid 20th century as opposed to late-19th century, but this route was built right.

  2. #2
    Join Date
    Feb 2013
    Location
    known universe
    Posts
    1,156

    Default

    Good comments about the content from TS. I don't think payware providers have an understanding of OR yet. Most of them have not used the sim enough.

    I would say, that testing is much more reliable when using the test route.
    Here >>> http://www.coalstonewcastle.com.au/physics/route/
    For testing purposes I switched over a few months ago, you'll probably appreciate this route's advantages more than I.

    I just took a look at the wag files...(engine files are way outta my knowledge base, wags much simplier)
    Here's what makes them OR ready
    1. DDS only no ACE files
    2. Mass UoM is US tons?? - why? - locos are still metric tons.
    3. Coupler Break set at 1067kN, using UoM "kN" in preference to msts style (1.067e6N) - which is within a good range, probably will not break (gone as low as 400kN with some trains/loads. I think a reasonable range is from 950kN to 1550kN, lower if you want more breakage action than prototypical).
    4. Faster brake settings..maybe a nod to OR??? why that fast?

    On the minus side...
    1. Still using the old Adheasion (sic )
    2. Still using the mysterious msts Friction statement - anyone can derive the numbers using the proper utility. A few on the forums can actually understand and explain the concept of Friction and how it works in real world physics (definitely NOT one).
    Did anyone ever understand how all the Friction parameters were actually used in the msts calculations, how they interacted?

    Most definitely not OR ready until they start putting in the correct Davis Numbers and using Curtius Kniffler.

    Using the test track I cannot pull the consist without breaking couplers - 1% grade, I set the couplers ridiculously high, and still could not move consist. It will start on a level grade, without breaking couplers...but power is mismatched to load.

    Here's include files I used for the whole shebang. Engine include files are basic stuff.
    TS_EthanolTrain.zip
    Last edited by R. Steele; 06-30-2017 at 02:57 AM.
    Cheers, R. Steele [Gerry] It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.


  3. #3
    Join Date
    Nov 1999
    Location
    Chippenham, Wiltshire, UK.
    Posts
    6,549

    Default

    If no bearing type is specified the default is "friction". Try adding ORTSBearingType ( Roller ) or even ORTSBearingType ( Low ) to the wags for a lower starting friction.
    Beer is not a matter of life or death, it is much more serious than that.

  4. #4
    Join Date
    Feb 2013
    Location
    known universe
    Posts
    1,156

    Default

    Quote Originally Posted by baldwin View Post
    If no bearing type is specified the default is "friction". Try adding ORTSBearingType ( Roller ) or even ORTSBearingType ( Low ) to the wags for a lower starting friction.
    Correct, but if you examine files contained in "TS_EthanolTrain.Zip (post #2) you will find:
    Code:
    include ( "..\\DBUX_302740_26K_TANK_LD.wag" ) 
    Wagon ( 
    	 Coupling (
    		Type ( Automatic )
    		Spring (
    			Stiffness ( 1e6N/m 5e6N/m )
    			Damping ( 1e6N/m/s 1e6N/m/s )
    			Break ( 1067kN 1067kN )
    			r0 ( 15cm 25cm )
    		)
    		Comment ( CouplingHasRigidConnection ( 1 ) )
    		Velocity ( 0.12m/s )
    	)
    	Coupling (
    		Type ( Automatic )
    		Spring (
    			Stiffness ( 1e6N/m 5e6N/m )
    			Damping ( 1e6N/m/s 1e6N/m/s )
    			Break ( 1067kN 1067kN )
    			r0 ( 15cm 25cm )
    		)
    		Comment ( 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 )
    	)
    	ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) ) 
    	ORTSBearingType ( Roller )  <<< (my emphasis)
    	ORTSDavis_A ( 1196.27 )
    	ORTSDavis_B ( 19.5462 )
    	ORTSDavis_C ( 1.197900 )
    	Comment( == Assumptions -FreightCar Standard - speed - 65mph (105km/h), Roller Bearing, 4 axles, frontal area - 10.0m2, WagonWeight - 118.8 ton (metric) == )
    
    	Comment ( orts performance brakes )
    	BrakeEquipmentType( "Handbrake, Triple_valve, Auxilary_reservoir, Emergency_brake_reservoir" )
    	BrakeSystemType( "Air_single_pipe" )
    	MaxBrakeForce( 35.0kN )
            MaxHandbrakeForce( 57.2kN )
    	NumberOfHandbrakeLeverSteps( 100 )
            EmergencyBrakeResMaxPressure( 90 )
    	TripleValveRatio( 2.5 )
    	MaxReleaseRate( 3.50 )
    	MaxApplicationRate( 3.50 )
    	MaxAuxilaryChargingRate( 3.684 )
    	EmergencyResCapacity( 8.604 )
    	EmergencyResVolumeMultiplier ( 1.461 )
    	EmergencyResChargingRate( 3.684 )
    	BrakeCylinderPressureForMaxBrakeBrakeForce ( 77 ) 
    )
    Cheers, R. Steele [Gerry] It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.


  5. #5
    Join Date
    Sep 2006
    Location
    .
    Posts
    1,794

    Default

    I am beginning to think there is a bug in the code. Here is how I came to this conclusion.

    Just for grins and giggles, I took the SLI wag file, deleted the Friction line, and inserted the roller bearing line in its place. There were no other ORTSDavis or ORTSAdhesion entries. No other ORTS physics entries at all. I did it for every wag in the consist. I am still testing on the Sherman Hill route with only a 0.8% grade.

    Under these conditions, the train ran away backwards quicker upon entering the sim, and it took almost 2 minutes to arrest the backwards slide with a notch 5 (63%) power setting. After arresting the slide, it did start creeping forward. It made no difference in how long I waited for the speed to build up. Whether it got to 2 mph forward (after about 4 minutes), or over 10 mph forward (after about 9 minutes), it DID NOT MATTER what the speed was, the moment I advance the throttle to notch 6, the train separated and went into emergency.

    If I happened to save the run just before advancing the throttle, and if I restored from that save, I could lean on the throttle all the way up to 100% notch 8 and have no trouble with separation. Even if I put the throttle in idle, waited until gravity stopped the train, and started out again from 0 mph, I could slam that throttle all the way to number 8 and never break the train.

    Something is happening when you start the explore session that is NOT happening when you restore from a save. I find it very difficult to believe once the train gets over 10 mph that the next notch up on the throttle will break it so easily. There already is enough forward momentum underway by that time. Something is very sloppy in the code there. And if you restore from a save you can abuse the train handling all you want and you will never break it.

  6. #6
    Join Date
    Feb 2013
    Location
    known universe
    Posts
    1,156

    Default

    Quote Originally Posted by geepster775 View Post
    I am beginning to think there is a bug in the code. Here is how I came to this conclusion...
    Running on the 1% grade on the test track, using all the include files in post #3, the train will slide back, but slower then the content as delivered and your description using the Roller Bearing parameter...mild application of brakes (brakes settings in include file) will halt backward slide easily. The power as provided will not move the default consist, couplers breaks occur.

    By not using the Davis Numbers, Curtius Kniffler and the other components of the include file you are depriving yourself of using native OR physics, these eng and wag files as provided by TS are frankenwagons and frankenlocos. [spirit of transparency...long time and loyal customer of SLI-TS]. I think your testing is flawed at this point. More accurate results would be obtained using the include files.

    Really, just plug in the include files (these are very basic)...see for yourself. You should try this before deciding if there is a bug. Could be, not convinced here.
    If you are unconvinced about the test track...where on Sherman are you testing - still at "starting at Harriman, and heading towards Dale Jct"?
    Last edited by R. Steele; 06-30-2017 at 11:22 PM.
    Cheers, R. Steele [Gerry] It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.


  7. #7
    Join Date
    Feb 2013
    Location
    known universe
    Posts
    1,156

    Default

    No backward creep on Sherman Hill 0.8% - slight after 2+ mins running time, -0.1mph, easily compensated for.
    Using include files & provided 103 consist.
    bandicam 2017-06-30 19-50-01-024.jpg
    Last edited by R. Steele; 07-01-2017 at 12:03 AM.
    Cheers, R. Steele [Gerry] It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.


  8. #8
    Join Date
    Sep 2006
    Location
    .
    Posts
    1,794

    Default

    I am seeing different behavior before and after a save. That alone is a bug, and is irrelevant of backwards creep or ORTS physics included or not or what route I am using to test. The question is, is it contained there around the save function, or part of a bigger problem. I do find the coupler sensitivity very harsh, almost unrealistically so, on the front side of the save, and non-existent when restoring on the back side of a save.
    Last edited by geepster775; 07-01-2017 at 12:42 AM.

  9. #9
    Join Date
    Feb 2013
    Location
    known universe
    Posts
    1,156

    Default

    Quote Originally Posted by geepster775 View Post
    I am seeing different behavior before and after a save. That alone is a bug, and is irrelevant of backwards creep or ORTS physics included or not or what route I am using to test...
    Maybe a bug, maybe not - Now a new element has been added, never mentioned in first post, about behavior before and after saves, and now backward creep and OR physics is irrelevent...but you introduced the physics problem in your first post.

    The only buggy behavior I'm seeing is your aversion to using even the most basic proper OR physics found in the include files.
    Just give the include files an honest try and report the findings...what it so confounded difficult about that, geepster?
    Quit using the frankenfiles provided by TS for testing purposes.


    Quote Originally Posted by geepster
    In explorer mode, starting at Harriman, and heading towards Dale Jct, it requires the 5th notch just to keep the train from rolling away backwards. But even if I stay in the 5th notch, doing this no-win battle against gravity, after about a minute, the coupler knuckles between 2 cars somewhere in the train will break. If I go to the 6th notch earlier, knuckles will break immediately
    As shown in screenshot (post #7) the behavior you describe is not observed on the Sherman Hill route when using the include files.
    Of course, you could try the include files and add to the knowledge base by finding out if your observations hold true when using basic OR adhesion and friction parameters. Perhaps, I've made an error, would be delightful, although embarrassing, if you found it.
    I'm just looking for the best and most accurate results.

    ...And yes, I will agree that a behavior change before and after save, if documented and repeatable, could be a bug...but you seem to be zigging&zagging across different subjects.
    Last edited by R. Steele; 07-01-2017 at 01:58 AM.
    Cheers, R. Steele [Gerry] It's my railroad and I'll do what I want! Historically accurate attitude of US Railroad Barons.


  10. #10
    Join Date
    Sep 2006
    Location
    .
    Posts
    1,794

    Default

    Quote Originally Posted by R. Steele View Post
    Now a new element has been added, never mentioned in first post,

    ...but you introduced the physics problem in your first post.

    ...but you seem to be zigging&zagging across different subjects.

    Why, yes, the process of deduction through public input can feature many twists, turns, wide swings and zig-zags. Yes, the flashlight of suspicion can swing around dramatically, from vendor-supplied files, to what the code is doing when it processes vendor-supplied files. And I admit this process is not for everybody. Some people just may throw up at the sight of the sausage being made.




    Quote Originally Posted by R. Steele View Post
    Just give the include files an honest try and report the findings...what it so confounded difficult about that, geepster?
    I will. Just for you.

    But you do me a favor, too. Go back to this from post #2

    "Using the test track (and ORTS physics) I cannot pull the consist without breaking couplers - 1% grade, I set the couplers ridiculously high, and still could not move consist."

    Do this again, but just before you notch out the final step to the point of breaking the couplers, do a save, and then bail and restore. Tell me if notching up fully after the restore still breaks the couplers then.

    Heaven forbid we see the same result (now, suddenly success!) Why, that just might prove the choice of test track, and whether or not OTRS physics are involved are irrelevant (you have them, I don't, and yet we both are seeing the same sudden success result, post-save). That will point to a code problem that might need fixing before the remainder of the deductive process can resume without results being tainted.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •