Steam Model - Work in Progress
#21
Posted 15 October 2013 - 04:24 AM
We know what the OR code developer does, but to clarify - the OR model developer may - do the relevant research to setup the physics input data, build the 3d model, do the conversion, and do the artwork and conversion, associated with the model. (It may be done in a different order, depending how individual modelers conduct a modeling project.)
Personally, I do my research and try and find relevant data pertaining to the locomotive class and type, but where data is missing I use extrepolated data that achieves a satisfactory result, ie, running and load characteristics. Thus any engineering script should have a good layout to which known, or extrepolated, data is entered. The preference, I am sure, is a similar plain language type script such as that used for the MSTS ENG file. Text is entered using a unicode text editor, which are easily available, ie, ConTXT Editor.
There should be a single numeric system, ie, imperial, or, metric formats. Conversion utilities are readily available, including from the ET library, so there is no real problem converting from imperial to metric formats. OR code developers might find metric data input is easier to work with?
Cheers Bazza
#22
Posted 15 October 2013 - 05:14 AM
It is now quite clear to me that MSTS will in fact ignore anything it is not set up to read in an eng file so long as that OR data line follows the same convention as MSTS, Parameter ( data ). The problem with the diesels was caused by a parameter having no associated data. As soon as I commented the offending lines out, all the rest were accepted by MSTS with no error messages.
Therefore as I see it, OR can extend the MSTS eng file without upsetting MSTS as long as the rule Parameter ( data ) is observed. I would however recommend that each such new addition to an eng file is tested in MSTS before being committed.
#23
Posted 15 October 2013 - 05:18 AM
copperpen, on 15 October 2013 - 05:14 AM, said:
Fascinating! We'll probably want to understand this in as much detail as possible (e.g. does "Parameter ( data1 data2 data3 )" work?) but thanks a lot for figuring this out!
#24
Posted 15 October 2013 - 07:31 AM
James Ross, on 15 October 2013 - 05:18 AM, said:
MSTS already accepts lines like that. Take the following for example, a standard MSTS eng file entry
comment( min steam pressure, min water proportion, max water proportion )
InjectorLimits1 ( 50psi 0.4 1 )
InjectorLimits2 ( 60psi 0.4 1 )
#25
Posted 15 October 2013 - 07:42 AM
copperpen, on 15 October 2013 - 07:31 AM, said:
comment( min steam pressure, min water proportion, max water proportion )
InjectorLimits1 ( 50psi 0.4 1 )
InjectorLimits2 ( 60psi 0.4 1 )
But are those unknown parameters to MSTS? It's entirely possible for MSTS to accept "UnknownParameter ( data )" but blow a gasket on "UnknownParameter ( data1 data2 data3 )". If it doesn't, great, but I'd like everything known and tested. :)
#26
Posted 15 October 2013 - 11:36 AM
James Ross, on 15 October 2013 - 07:42 AM, said:
The example shown is working MSTS code. I do not think that MSTS will toss the toys out of the pram as long as the additional parameters are set out in a way familiar to the MSTS code engine. What it does not recognize or cannot use will simply be discarded. It is merely the syntax that has to match. I agree with the testing bit anyway. That is my role with the steam code, along with research.
#27
Posted 15 October 2013 - 11:36 AM
The compatibilty issue may in the end not be a serious problem, my impression from looking around the net for MSTS info most people are now using OR except for the editor and tools. Even then at least three people developing routes are now doing so that they will only run on OR. Even OR's relatively recent abilty to see longer distances being catered for.
Lindsay
#28
Posted 17 October 2013 - 02:57 PM
The calculated heating surface was high by around 25%, slightly over 5000 square ft, where as the heating surface appears to be around the 3900 sq ft marker, I say appears as different sources give differing values, 3900 would be correct for this loco.
Calculated grate area was 102 sq ft, this is way to high the actual grate area being 68sq ft.
Power output was around what the real loco generated (3600bhp at the wheel rims), very good.
Water consumption was between 13 and 15 lbs/bhp/hour which is in the correct area.
Only two complaints, the steam generation NEVER decreased, even when one stopped the machine.The second point from information published in Chapelons book the chest pressure indicated in the hud is to high by a good bit. Chapelon states that almost all locos lost around at least 25 to 33% of the boiler pressure in the steam piping at full steam flow.
Lindsay
#29
Posted 17 October 2013 - 05:51 PM
Quote
I believe your impression is symbolic of the forum niches you frequent. I suspect you would find that a survey of the general MSTS populace will indicate this to not be the case by a long stretch.
#30
Posted 17 October 2013 - 10:42 PM
#31
Posted 18 October 2013 - 02:48 AM
Running a steam engine in MSTS/OR is not like a diesel at all. That is, as with a prototype steam engine, you'll need to conserve steam pressure and find "sweet spots" (by using the reverser in concert with the throttle) for long pulls that yields maximum steam generation vs steam consumption. Wide open with the reverser in full forward will consume a LOT of steam on the prototype as well as the model.
IF you have my ancient "North Arkansas" route, there is a lengthy tutorial on running steam engines within the "Documents" folder that resides in the route folder. Perhaps a quick reading of it will help.
#32
Posted 18 October 2013 - 03:14 AM
With those kind of loads you can start your train using just over 40% cutoff and 10% or higher throttle, W for increase and S for decrease of cutoff. Once you are running keep an eye on the two steam figures in the HUD. Left side is generation, right side is usage. If right is higher than left reduce cutoff until you get down to 30% or even lower to 20%. If the usage still runs higher than generation reduce the throttle a bit. You should be able to run up that 1% grade if it is accurate with the 20th Century consist. I will test that today and let you know.
#33
Posted 18 October 2013 - 11:42 AM
James Ross, on 15 October 2013 - 07:42 AM, said:
I've taken a section of parameters (a cuckoo :-) and inserted it into several files in the default MSTS installation. The cuckoo looks like this
ORTS ( 1 2 )
ORTS ( 1 2 3 )
ORTS ( 1.2mph )
ORTS ( 1.2 2.3mph )
ORTS ( 1.2 2.3 3.4mph )
ORTS ( "text with spaces" )
ORTS ( text )
ORTS ( text text )
ORTS ( text text text )
and the error messages suggest that MSTS does not care what goes inside the ORTS ( . . . ) brackets, only where the cuckoo is inserted.
So far I've inserted it into scotsman.eng and scottender.wag and scotsman.con and shrtpass.act.
scotsman.eng and scottender.wag were tolerant, provided the cuckoo was inside the Wagon ( Scotsman or Engine ( Scotsman and therefore not at the highest level. Any deeper level was also accepted.
scotsman.con was tolerant provided the cuckoo was inside Train ( TrainCfg ( Scotsman and therefore not at the highest 2 levels. Again deeper levels were also accepted.
shrtpass.act was more picky. It rejected the cuckoo inside Tr_Activity_Header and Player_Service_Definition but accepted it inside Player_Traffic_Definition.
This isn't quite as clearcut as I hoped but it's still promising. My question now is, are there any other test cases that should be explored?
#34
Posted 18 October 2013 - 12:34 PM
Walter Conklin, on 17 October 2013 - 07:43 PM, said:
As a member of the Open Rails team, I probably should already know the answer to the following question, but I don't: http://www.elvastower.com/forums/public/style_emoticons/default/sweatingbullets.gif
Can Open Rails users adjust the cutoff of steam locomotives in the sim?
Just an observation, not a complaint, most of the time my steam driven trains stall going up the virtual Shawangunk on the unreleased Tristate route while using Open Rails. Tristate utilizes DEMs. In reality, the grade on the former Erie Mainline going from Port Jervis, NY to Graham, NY is approximately 1%. Using OR v1818 and previous versions of the sim, I often run a consist no pun intended consisting of the 21st Century Limited Hudson and a string of about fifteen passenger cars. The consist came with the Train Artisan American Classics add-on. During other occasions, I run Allen Norton's Erie Berkshire with about four to five of the pseudo Erie Railroad passenger cars, the latter available from the Train-Sim file library. Irregardless the type of steam locomotive used, I am running the steam locomotives with full throttle, reverser at full, and brakes released. I am not very knowledgeable about steam locomotive operations. Perhaps the reason why the trains are stalling on the ridge is because of my bad driving. http://www.elvastower.com/forums/public/style_emoticons/default/rotfl.gif
I understand that the steam locomotive features are a work-in-progress in OR. Thank you for developing the steam locomotive features in the sim.
Piston steam engines as used in locos vary in effeicency with the length of travel of the valve. The machines tractive effort also varies getting higher as the valve travel lengthens. OR has these abilities for sometime now.
In most valve gears (some rotary cam valve gears excepted) as the valve travel gets shorter the port opening and closing times start to negatively effect the loco. These poor timing events reducing the effiecency as the valve travel shortens. So most steamers have particular valve travel they perform best at. Most old drivers of steamers say it was pointless going below 20 to 25% valve travel as the loco did not improve below that travel.
In Walschearts valve gear the lap and lead lever holds the input port opening time relativly constant greatly improving the abilty of the cylinder to fill at all valve travels, Unfortunately as the valve travel shortens the exhaust port times get earlier. This allows the release (opening of the exhaust port) to occur earlier thus reducing the effiecency slightly, The closing of the exhaust port also occurs earlier, this results it what is called the compresion part of the cycle as the cylinder pressure rises because of the early closing of the exhaust port as the piston approaches the end of its stroke prior to the opening of the inlet port. This is a significant cause of the reduction in effiecency at short valve travels.
In normal two cylinder valve gear one usually needs a starting valve travel of greater than 50 percent other wise there would be a danger the the loco would come to rest at a point in the valves timing cycle in which no cylinder had a steam port open and therefore would not start.
Note, some locos designed from scratch to have a short maximum valve travel had small auxilary ports to allow a loco to start at valve travels shorter than 50%. I Believe New York Central RR had some examples of this. A major advantage of a short maximimum valve travel was that it allowed the valve ports to be open wider at short cuttoffs greatly improving the locomotives TE and therefore power at high speeds.
Steam loco design was ___NOT___ static over time there is clear evidence particularly in Europe and the USA of attempts to improve cylinder filling specially at short valve travels. I have not left Britain out here they were widely acknowledge as building the most effiecent and finely built steam loco's in the world.
I believe OR has yet to handle most of the above. Although using the interpolator data type from the eng file (if it worked) one could certainly have a good try.
Lindsay
#35
Posted 18 October 2013 - 12:48 PM
Coonskin, on 17 October 2013 - 05:51 PM, said:
I had a good think about this before I answered.......
In my opinion from my own experience most rail and steam loco fans neither know nor care about the loco's "Physics" , power and TE both being seriously miss understood. Little point in mentioning the effect of grate area they would have no idea of what one is talking about.
To a great extent accurate "phsyics" in a train sim will almost certainly only be apreciated by a very small percentage of the users.
Lindsay