TrainSimulations CN SD70-2 Coal and Sulphur Trainsets

**R. Steele** · 12-30-2017, 16:07

from this thread in the MSTS section: https://www.trainsim.com/vbts/showth...phur-Trainsets

Originally posted by Curt C

I am planning on picking this set up too today. I have to admit, I've never heard of "Davis values". What exactly is that?

Curt, you gotta read the threads, this information has been posted in the OR section for some time now and see Charles's post #6 for manual references. TS is trying to catch up, many of the payware content providers are starting to educate themselves about OR physics and the best way for them to implement them. Next up after the Davis numbers (resistance) should be the ORTS Diesel Engines block...here's a sample of what I'm currently running (it's the set referred to in this thread).

I'm using:
1. a common folder named Common.Std (just like the MSTS Common.Snd & Common.Cab folders).
[this folder could be named anything...like Common.Fleet; TS_OR_Required; or Curts_OR_Standards..does not matter, as long as it makes organizational sense to you and works for your setup. Whatever the name used, it has to be correctly identified in the path string
"..\\..\\Curts_OR_Standards\\Std_Eng_SD70-2.inc"]

There is talk in the threads of the community trying to adopt a universally recognized folder for ORTS standards...just like MSTS did years ago with the adoption of the Common.Cab and Common.Snd folders. I'm in favor of this, although I've not read much serious discussion about it. The genesis for all this started with Wayne Campbells brilliant idea when he was working out the beginnings of OR, Dave Nelson at ET has designed an brilliant system using a Common.Fleet folder...his system is much more advanced than mine, I'm still lagging way behind most folks in my railroading knowledge.

... and
2. an OpenRails folder (just like a MSTS Sound or Cabview folder which is also found in the parent wagon or locomotive trainset folder. )
Path strings in the include files point to the OR "Common.Std" which contains .inc files, which are simply text files containing parameters specifically adjusted for OR.
Search the threads and read the manual, you will find more about this.

Using this systems allows you to make easy changes for your entire OR trainset, whether it is brakes, couplers, engine files, or whatever.
How simple or complex really depends upon the user.
Here's the files just to give you an idea...
Locomotive

Code:

include ( "..\\CN_SD70M-2_8012.eng" )
Wagon (
	include ( "..\\..\\Common.Std\\Engines\\Std_TypeF_Coupler.inc" )
	include ( "..\\..\\Common.Std\\Engines\\Std_Loco_BrakesTS.inc" )
	ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) )
	ORTSAdhesion ( ORTSSlipWarningThreshold ( 70 ) )
	ORTSBearingType ( Roller )
	ORTSDavis_A ( 2138.03 )
	ORTSDavis_B ( 70.4167 )
	ORTSDavis_C ( 8.337645 )
	Comment( == Assumptions -Locomotive diesel/electric - speed - 65mph (105km/h), Roller Bearing, 6 axles, frontal area - 14.5m2, WagonWeight - 214.0 ton (metric), Drag 1.0 == )
	Sound ( "..\\..\\Common.Snd\\MC.SND\\MC_EMD710\\CNSD70_eng.sms" )
)
Engine (
	Effects
	(
		DieselSpecialEffects
		(
		Exhaust1
			(
				0 4.781 0.912
				0 1 0
				0.14
			)
		)
	)
	include ( "..\\..\\Common.Std\\Engines\\Std_Eng_SD70-2.inc" )
	Sound ( "..\\..\\Common.Snd\\MC.SND\\MC_EMD710\\CNSD70_cab.sms" )
)

Std_Eng_SD70.inc file

Code:

Comment ( Standard ORTS Diesel Engine for EMD SD70-2  )
Comment ( include ( "..\\..\\Common.Std\\Locomotives\\Std_Eng_SD70-2.inc" ) )

ORTSDieselEngines ( 1
		Diesel(
			IdleRPM ( 310 )
			MaxRPM ( 915 )
			StartingRPM ( 215 )
			StartingConfirmRPM ( 360 )
			ChangeUpRPMpS ( 75 )
			ChangeDownRPMpS ( 25 )
			RateOfChangeUpRPMpSS ( 10 )
			RateOfChangeDownRPMpSS ( 5 )
			MaximalPower ( 3206.509kW )
			IdleExhaust ( 0.5 )
			MaxExhaust ( 0.5 )
			ExhaustDynamics ( 0.5 )
			ExhaustDynamicsDown ( 0.5 )
			ExhaustColor ( 206B787D )
			ExhaustTransientColor ( 40212324 )
			DieselPowerTab (
				  0	0
				310	0
				385 400814
				460	801627
				535	1202441
				610	1603255
				685	2004068
				760	2404882
				835	2805695
				915 3206509
			)
			DieselConsumptionTab (
				0      0
				310   3.9
				915   124
			)
			ThrottleRPMTab (
				0   310
				12.5  385
				25  460
				37.5  535
				50  610
				62.5  685
				75  760
				87.5  835
				100 915
			)
			DieselTorqueTab (
				0       0
				310   62831
				915   502649
			)
			MinOilPressure ( 25 )
			MaxOilPressure ( 90 )
			MaxTemperature ( 120 )
			Cooling ( 3 )
			TempTimeConstant ( 720 )
			OptTemperature ( 71 )
			IdleTemperature ( 55 )
		)
	)
	ORTS  (	ORTSWheelslipCausesThrottleDown ( 1 )
			ORTSEmergencyCausesThrottleDown ( 1 )
			ORTSMainResChargingRate ( 0.750 )
			ORTSBrakePipeChargingRate ( 30 )
			ORTSEngineBrakeReleaseRate ( 38 )
			ORTSEngineBrakeApplicationRate ( 34 )
			ORTSBrakePipeTimeFactor ( 0.003 )
			ORTSBrakeEmergencyTimeFactor ( 0.15 )
			ORTSBrakeServiceTimeFactor ( 1.46 )
			ORTSAirBrakeMainresvolume ( 11 )
	)

Std_TypeF_Coupler.inc

Code:

	Comment ( Standard Grade F Couplers for Diesel Locomotives  )
	Comment ( include ( "..\\..\\Common.Std\\Locomotives\\Std_TypeF_Coupler.inc" ) )

	Coupling (
		Type ( Automatic )
		Spring (
			Stiffness ( 4e2N/m 6e6N/m )
			Damping ( 5e6N/m/s 5e6N/m/s )
			Break ( 1850kN 1850kN )
			r0 ( 5cm 7cm )
		)
		CouplingHasRigidConnection ( 1 )
		Velocity ( 0.2m/s )
	)
	Comment ( front coupling )
	Coupling (
		Type ( Automatic )
		Spring (
			Stiffness ( 4e2N/m 6e6N/m )
			Damping ( 5e6N/m/s 5e6N/m/s )
			Break ( 1850kN 1850kN )
			r0 ( 5cm 7cm )
		)
		CouplingHasRigidConnection ( 1 ) 
		Velocity ( -0.2m/s )
	)

Loaded Sulphur Gon wagon (wagon include file in the OpenRails folder)

Code:

include ( "..\\SULX_BATHTUB_GONDOLA_3027_LD.wag" )
Wagon (
	include ( "..\\..\\Common.Std\\Std_Grade-E_Coupler.inc" )
	include ( "..\\..\\Common.Std\\Single_Pipe_AB_BrakesLD.inc" )
	ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) )
	ORTSBearingType ( Roller )
	ORTSDavis_A ( 1289.68 )
	ORTSDavis_B ( 21.6357 )
	ORTSDavis_C ( 1.197900 )
	Comment( == Assumptions -FreightCar Standard - speed - 65mph (105km/h), Roller Bearing, 4 axles, frontal area - 10.0m2, WagonWeight - 131.5 ton (metric) == )
	Sound ( "..\\..\\Common.Snd\\TT_Freight_Sound\\TT_welded3.sms" )
)

Empty Sulphur Gon ( Wagon file found in OpenRails folder)

Code:

include ( "..\\SULX_GONDOLA_2051_MT.wag" )
Wagon (
	include ( "..\\..\\Common.Std\\Std_Grade-E_Coupler.inc" )
	include ( "..\\..\\Common.Std\\Single_Pipe_AB_BrakesMT.inc" )
	ORTSAdhesion ( ORTSCurtius_Kniffler ( 7.5 44 0.161 0.7 ) )
	ORTSBearingType ( Roller )
	ORTSDavis_A ( 535.06 )
	ORTSDavis_B ( 4.7549 )
	ORTSDavis_C ( 3.593800 )
	Comment( == Assumptions -FreightCar EmptyHopper - speed - 65mph (105km/h), Roller Bearing, 4 axles, frontal area - 10.0m2, WagonWeight - 28.9 ton (metric) == )
	Sound ( "..\\..\\Common.Snd\\TT_Freight_Sound\\TT_welded1.sms" )
)

Some screenshots --- how it all is setup
Last screenshot is from the locomotive folder within the Common.Std folder, all the OR diesel engine blocks I currently have made or am testing.
My setup, compared to others I've read about and seen, is pretty rudimentary, some folks are making OR Traction Tables and experimenting with braking parameters. Adding all this to your setup takes time, but the difference is very noticeable when running in the sim.
bandicam 2017-12-30 13-31-19-878.jpg bandicam 2017-12-30 13-27-30-667.jpg bandicam 2017-12-30 13-27-18-713.jpg
bandicam 2017-12-30 13-26-24-876.jpg bandicam 2017-12-30 13-26-11-548.jpg

**dcarleton** · 12-31-2017, 13:40

Originally posted by Darter7

...both the ENG and WAG files are built to ORTS Specs, to include the ORTS Davis values.

Well, yes, BUT - After running these in OR, look at the log. Do anyone else see something like this?

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_SD70M-2\CN_SD70M-2_8910.eng:line 40

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_SD70M-2\CN_SD70M-2_8910.eng:line 41

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_SD70M-2\CN_SD70M-2_8023.eng:line 40

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_SD70M-2\CN_SD70M-2_8023.eng:line 41

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\CN_COAL_GO N_197621_LD.wag:line 41

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\CN_COAL_GO N_197621_LD.wag:line 42

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\CN_COAL_GO N_197111_LD.wag:line 41

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\CN_COAL_GO N_197111_LD.wag:line 42

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\BCNE_COAL_ GON_900135_LD.wag:line 40

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\BCNE_COAL_ GON_900135_LD.wag:line 41

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\BCNE_COAL_ GON_900358_LD.wag:line 41

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\BCNE_COAL_ GON_900358_LD.wag:line 42

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\CN_COAL_GO N_199194_LD.wag:line 41

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_COAL_GONDOLAS\CN_COAL_GO N_199194_LD.wag:line 42

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_SD70M-2\CN_SD70M-2_8859.eng:line 40

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_SD70M-2\CN_SD70M-2_8859.eng:line 41

Warning: Found a suffix 'lb' which could not be parsed as a Resistance unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_SD70M-2\CN_SD70M-2_8012.eng:line 40

Warning: Found a suffix 'lb' which could not be parsed as a ResistanceDavisC unit in C:\MSTS_Routes\Train Sim-CAN\trains\trainset\TS_CN_SD70M-2\CN_SD70M-2_8012.eng:line 41

**crstagg** · 12-31-2017, 14:52

Looks like TS (no it doesn't stand for Tough $hit) placed a space between the numeric value and the unit of measure which is a syntax error in MSTS also.

**R. Steele** · 12-31-2017, 15:02

This is from BCNE_COAL_GON_900135_LD ( this is from the purchased set when first released - TS SD70-2 Coal & Sulphur Trainsets )
ORTSBearingType ( Roller )
ORTSDavis_A ( 287lb ) default is Newtons ( N ) or specify lbf not lb
ORTSDavis_B ( 2.1450lb ) default is Nm/s, or specify lbf/mph
ORTSDavis_C ( 0.005000lb ) default is Nm/s^2, or specify lbf/mph^2

A closer reading of the OR manual shows that using FCalc2 ( set for metric units ) will generate Davis numbers that do not require UoM.
Any other UoM must be written as specified in manual. So why not just use the numbers generated by FCalc2 as they will be accepted without having to add the secondary accepted UoM??? Puzzling, just being contrary I suppose.

Also I take exception to not providing the Comment Assumptions line, shows proof of data used, provide a reasonable way to check for accuracy, and since this is an Open Source free simulator, provides others in the community a means to educate themselves and open data for them to use, what's the big secret?? How did they arrive at those numbers? Puzzling.

BCNE_COAL_GON_900135_LD
ORTSBearingType ( Roller )
ORTSDavis_A ( 1374.27 )
ORTSDavis_B ( 23.5278 )
ORTSDavis_C ( 1.197900 )
Comment( == Assumptions -FreightCar Standard - speed - 65mph (105km/h), Roller Bearing, 4 axles, frontal area - 10.0m2, WagonWeight - 143.0 ton (metric) == )

BCNE_COAL_GON_900135_MT
ORTSBearingType ( Roller )
ORTSDavis_A ( 535.06 )
ORTSDavis_B ( 4.7549 )
ORTSDavis_C ( 1.197900 )
Comment( == Assumptions -FreightCar EmptyHopper - speed - 65mph (105km/h), Roller Bearing, 4 axles, frontal area - 10.0m2, WagonWeight - 28.9 ton (metric) == )

A deserved criticism of my Davis numbers is that the frontal area is always 10.0 ( an exception is modern tankers, I'm using 7.8 m2 and modern autoracks - 14.5 to 16.0m2 - FCalc shows 16.3 in the autorack spreedsheet)
Better accuracy for Davis_C would be to precisely calculate the frontal area, instead of using the average recommended by the FCalc2 instructions -- 10.0m2 for standard freight cars.

One wish I have is for a utility program (maybe an addon for ShapeViewer) that would take the data found in the shape and wagon file and compute the frontal area of the model...that would be wonderful!

**crstagg** · 12-31-2017, 16:07

Originally posted by R. Steele

This is from BCNE_COAL_GON_900135_LD ( this is from the purchased set when first released )
ORTSBearingType ( Roller )
ORTSDavis_A ( 287lb ) default is Newtons ( N ) or specify lbf not lb
ORTSDavis_B ( 2.1450lb ) default is Nm/s, or specify lbf/mph
ORTSDavis_C ( 0.005000lb ) default is Nm/s^2, or specify lbf/mph^2

...........

That's outrageous. Where did these BCNE Gons come from, Gerry?

**R. Steele** · 12-31-2017, 18:32

It's the TS set that is the subject of this thread.
Oh I don't think it's outrageous Charles, you have to expect mistakes when everyone is figuring out how to implement the OR physics...I wouldn't be too hard on them...they are definitely in the learning curve when it comes to OR. Heck, we all are.
If you think about it, this is an interesting time, much like when MSTS was first released and everyone was trying to understand the simulator.

They (TS - and other payware providers) are trying to find a way to go forward with models strictly made for OR.
While the rest of us puzzle out how to make the tons of MSTS legacy models (the ones without square wheels, and having proper couplers and brake hoses) compatible with OR - with regards to the native physics of OR.

Personally I think the idea of using an OpenRails folder and a Common folder for OR include files is a brilliant idea.

**crstagg** · 12-31-2017, 18:52

Originally posted by R. Steele

It's the TS set that is the subject of this thread.
Oh I don't think it's outrageous Charles, you have to expect mistakes when everyone is figuring out how to implement the OR physics...I wouldn't be too hard on them...they are definitely in the learning curve when it comes to OR. Heck, we all are.
If you think about it, this is an interesting time, much like when MSTS was first released and everyone was trying to understand the simulator.

They (TS - and other payware providers) are trying to find a way to go forward with models strictly made for OR.
While the rest of us puzzle out how to make the tons of MSTS legacy models (the ones without square wheels, and having proper couplers and brake hoses) compatible with OR - with regards to the native physics of OR.

Personally I think the idea of using an OpenRails folder and a Common folder for OR include files is a brilliant idea.

Learning is one thing. Attention to detail is another. Especially for Payware. Look at the problem identified by post #3, putting a space between the numeric value and the unit of measure. STRIKE 1. Then the wrong units of measure for the Davis values. STRIKE 2, 3, & 4.

Also take a look at the Wagon filenames in post #3:

CN_COAL_GO N_197621_LD.wag

Why put a space between the "GO" and the "N" for GON?

BCNE_COAL_ GON_900135_LD.wag

Why put a space before "GON" when you already have an underscore to separate it from "Coal"?

**R. Steele** · 01-01-2018, 15:59

Charles --- referring to your post#8 --- the versions I have show no such spaces or any irregularities in the names...I think you've assumed something not in evidence.
Perhaps an artifact from posting them.

However, I am in general agreement concerning the level of craft, care, and precision required of payware providers.
Let's hope they also embrace those standards.

**wwhall** · 01-02-2018, 08:43

One of my big complaints about the payware providers is that they, with only a couple of exceptions, have seemingly embraced the "fire and forget" mentality. In other words, they release a product and, when bugs--often serious bugs--are discovered in the product, they make no effort to post a patch on their website. It's left to the user (buyer) to try to fix all the problems, if they can be fixed by a user. I used to justify this in my mind by saying that the payware providers were in a rush to get products to the market, but with some of them now going weeks or months between releases, that ceases to be much of an excuse in my mind. Simply put, we all make mistakes--it's what we do to correct them that separates the good producers from the not-so-good ones.

**crstagg** · 01-02-2018, 09:44

Originally posted by R. Steele

Charles --- referring to your post#8 --- the versions I have show no such spaces or any irregularities in the names...I think you've assumed something not in evidence.
Perhaps an artifact from posting them.

However, I am in general agreement concerning the level of craft, care, and precision required of payware providers.
Let's hope they also embrace those standards.

Gerry,
I assumed that Post #3 was created by copy from the OR Log file and paste to the forum rather than typing. But since the poster did not include the OR log we do not know. Could be a matter of word wrap.

**crstagg** · 01-02-2018, 10:01

Originally posted by wwhall

One of my big complaints about the payware providers is that they, with only a couple of exceptions, have seemingly embraced the "fire and forget" mentality. In other words, they release a product and, when bugs--often serious bugs--are discovered in the product, they make no effort to post a patch on their website. It's left to the user (buyer) to try to fix all the problems, if they can be fixed by a user. I used to justify this in my mind by saying that the payware providers were in a rush to get products to the market, but with some of them now going weeks or months between releases, that ceases to be much of an excuse in my mind. Simply put, we all make mistakes--it's what we do to correct them that separates the good producers from the not-so-good ones.

So true, Wade.

From the errors reported in post #3 it appears that this Payware provider does not use the OR Log file as a tool in testing their products.
Now how many of these ENG/WAG files with Davis value unit of measure errors will be copied to create ENG/WAG repaints?