Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 37

Thread: Reusing OpenRails physics code for model railways use

  1. #21
    Join Date
    May 2010
    Location
    Metairie, Louisiana
    Posts
    642

    Default

    You're welcome, and yes, I do understand you're a happy man.

    I think I'll need to buy a DCC system soon. One change at a time.

    Just kinda feeling odd here that some train simulator code can make model railroading feel more realistic. And thanks for reminding me about CVs. I should've known better because I was looking at decoders recently. And I'm only 22!
    Last edited by SD40-2; 01-11-2019 at 01:08 AM.
    Parker B. - A Misplaced Midwesterner.

  2. #22

    Default

    Hi Parker, I’m three times your age. Older, slower bummer, uglier, what else, blinder.

    But I guess we are both addicted to fun

  3. #23
    Join Date
    Jan 2007
    Location
    Just south of NYC
    Posts
    1,505

    Default

    In thinking about how OR simulator code could add some realism to model railroading use:

    1. creation of engine specific behaviors - i.e. throttle lag, traction motor loading, and triggering of other decoder SFX, etc.
    2. better simulation of train load - train would behave as if the train cars had realistic mass and resistance relative to the engine power. Slower acceleration and tougher grade climbing
    3. better simulation of braking - since model cars have no brakes, this could be simulated by slowing the train more realistically via the engine

    Here's the drawback:
    A model railway route only represents a tiny fraction of the size of a simulator route. For example David Park's famous Cumberland route ( http://dpcw.borail.net/ ) has about 1200 feet of HO track, and only 243 feet of mainline run - which translates into 2,117 feet in the 1:1 world or less than 1/2 mile. It is supposed to represent the B&O from Cumberland to Terra Alta, a distance of about 70 miles in 1:1 scale. In my B&O West End simulator route, it's the same as in 1:1 - 70 miles of track!

    So having a heavy train take almost 1 mile to reach 30 mph from a stop is no big deal, but would require more than the entire length of Dave Park's model railway.

    Compromises will be required between realistic and model behaviors
    Chris
    "True rail fans have two favorite railroads. The B&O and one other."

  4. #24

    Default

    Quote Originally Posted by Markstaffrld View Post
    Re being as realistic as possible. We already have “smiles”. I don’t know if this is right but I call them “small miles” smiles. And fast clocks are very common. Personally I have no particular need of either as I have a small switching layout with only a short piece of main line that immediately goes into a storage staging area. I’d be quite happy for the train to barely get up to any speed at all before disappearing off stage.

    So dispose my particular use maybe distorting physics could be good thing for most if not all.
    I think "distorted physics" would be best.

    The simulation would not know where your loco was on the layout, so would ignore gradient and track curvature. Also it would not be able to respect signals.

    It's possible for a C# program to call functions in a DLL written in C, so a special version of Open Rails could be created which would include your code.

    Do you see this as a program which runs standalone inside your ProtoThrottle or as two separate programs which communicate - one in your ProtoThrottle and the other running on a PC?
    Chris Jakeman


  5. #25

    Default

    Two Chris’s
    It could get confusing. Mister B&O and other. You made me laugh out loud at that one. So it must be B&O and Victorian Railway’s Narrow Gauge then.

    I figure your right about needing distorted physics. The issue may finish up being a bung fight about “how” distorted is the right amount of distortion. If possible maybe a distortion multiplier might be one way to satisfy all comers. I was thinking of asking how many people use fast clocks etc in some sort of pole and I figure I already know the answer, anything from 0 thru to say a maximum of around 8:1 with a lot sitting at 6:1.
    But this is one of those you never please everyone all the time sort of discussions.

    I’d like to talk about train Tonnage and track gradients for a bit. In both areas model railways are sadly deficient. There is no way to automatically “know” how much my train weighs because not only it is just a model but I am wanting different performance from my train based on knowing my train has loaded or empties and in what ratios in the consist or not. It is me and me alone that knows these facts so l think the only viable input device to load that information into the sytem is my big fat finger.

    ProtoThrottle has a config (pending) that allows for end uses to set “Tonnage” to light, medium, heavy, or very heavy. I believe there is a possibility that these setting could be made to change the “momentum “ settings we current have in our decoders. If we get physics into our Protothrottles the that momentum type of control could become obsolete. Momentum could be set to zero and physics applies the precise motor request directly to the train motor.

    At this time slope is not catered for at all. Personally I believe there is a need to have a similar end user control where the setting of slope could be set “on the fly” and then is mixed with all the other inputs in order to set “Tonnage” style momentum settings or alternatively if physics gets up to be part of the algorithm that sets motor speed. Just think, accidentally knock the brake off and your train could start rolling away. I have a little gleam in my eye just thinking about it. How cool would that be.

    As to B&O Chris’s creating specific engine behaviours. I look briefly at your engine configuration file and my word, no wonder people want to sell them. My idea of a config was something like a comma delimited txt file that had those basic performance and capacity details that are required to differentiate between one engine class and another. No need of any artwork rendering or such. Basic details that allow physics to be applied to that locomotive that we are controlling at the time. Diesel, electric or steam.

    My preference would be to have physics code embedded in the ProtoThrottle itself. But, and it’s a reasonably big but. The boys at ISE who designed and built this throttle built it with overall weight, battery life, small size, and overall costs as significant constraints on this project. So I am assuming that if the code gets embedded in the throttle then it has to be very lean&mean as I don’t think there are bucket loads of computing resources available on board.

    That being said there are always more way to skin a cat as they say. Putting physics on a pc may provide plenty of computing power but may prove to have other “difficulties” translations etc.

    True rail fans have two favourite railways The Victorian railways narrow gauge and the B&O. Hahaha. I crack myself up at times.
    Have a great day men
    Mark

  6. #26

    Default

    Quote Originally Posted by cjakeman View Post
    I think "distorted physics" would be best.

    It's possible for a C# program to call functions in a DLL written in C, so a special version of Open Rails could be created which would include your code.

    Do you see this as a program which runs standalone inside your ProtoThrottle or as two separate programs which communicate - one in your ProtoThrottle and the other running on a PC?
    Hi Chris,

    I spend a good portion of yesterday reading through train.cs and only got partway through before my eyes gave out. But I found it most instructive even if I only got to brake retarding at around 3767.

    19693 lines, so I only have 15000 odd to go, hahaha.

    Even in that truncated read I already know there is large amounts of that code that we modelrailroaders will never ever use. I’m guessing you already knew that when you put together the words that I quoted above. Can you please excuse my playing catch up but I’m a bit slow on the uptake.

    I see now the sense in you guys creating a special version. I would think even you doing the job is not an insignificant task. A lot of work indead.

    But I’m thinking that without that we in model railroad land are dead in the water so to speak. On the other and having just the physics and only the physics in one place could prove to be a usefull excersise in the long run for everyone. Though Chris I can’t for the life of me come up with something tangible to justify that statement it just sort of “feels” right some how.

    Even with that effort I got it that that is only the start of the journey to get those features into model railways (see I slipped back into being Australian there). Did you notice?

    On another subject, have any of you looked on github at the Iowa Scaled Engineering’s section on ProtoThrottle yet. I’d love to see you fellas getting into that. I could see those consoles picking up the pleasure index for V-Scale end uses quite a lot.

    I think I’m going to go back into train.cs. Cause I have a bit of a masochistic streak in me.

    Mark
    Last edited by Markstaffrld; 01-12-2019 at 07:43 PM.

  7. #27

    Default

    Quote Originally Posted by Markstaffrld View Post
    At this time slope is not catered for at all. Personally I believe there is a need to have a similar end user control where the setting of slope could be set “on the fly” and then is mixed with all the other inputs in order to set “Tonnage” style momentum settings or alternatively if physics gets up to be part of the algorithm that sets motor speed. Just think, accidentally knock the brake off and your train could start rolling away. I have a little gleam in my eye just thinking about it. How cool would that be.
    In Open Rails, your train does indeed roll away if you mess with the brakes.

    Imagine an arrangement where you have a PC running Open Rails linked to your ProtoThrottle. As well as selecting the consist (loco and train) on Open Rails to give the right mass, power, braking etc., Open Rails could perhaps contain a model of the layout complete with gradients. After all, this is what it's designed for.

    Then, as you drive your model along your layout, the speed of the model is automatically controlled to match the simulation on Open Rails. We would need a way to keep the location along the track fully in sync, perhaps with a few track sensors at strategic points.

    Also Open Rails provides an animated map view, so you can see where all your trains are.

    Anyone could make this vision a reality, but there's a lot of work involved.
    Chris Jakeman


  8. #28

    Default

    Quote Originally Posted by cjakeman View Post
    Imagine an arrangement where you have a PC running Open Rails linked to your ProtoThrottle. As well as selecting the consist (loco and train) on Open Rails to give the right mass, power, braking etc., Open Rails could perhaps contain a model of the layout complete with gradients. After all, this is what it's designed for.

    Then, as you drive your model along your layout, the speed of the model is automatically controlled to match the simulation on Open Rails. We would need a way to keep the location along the track fully in sync, perhaps with a few track sensors at strategic points.

    Also Open Rails provides an animated map view, so you can see where all your trains are.

    Anyone could make this vision a reality, but there's a lot of work involved.
    Yes Chris I can see that as a possibility.

    We do have some software vendors that offer automation and some exciting features. The one I’m most familiar with is a product out of Germany called Traincontroller, he has three versions with differing feature sets.

    From the small amount I’ve looked at in your code I suspect yours is better. I put that down to your being an open source development model. Driven by the users for the users. I’m my opinion the only way to go.

    I’d put as an example of this is a true work of art software that did all anyone could ask for in the operations of simulation of carrying freight an passengers around ones layout. It printed out all switch lists for each train it monitored all loads and the appropriate allocation of car type for a given load. It managed customers and their request for traffic. It did all sort of actions that were done “in the back room” by clerks and station masters etc.
    It was written by one man who had a intimate knowledge of railroad traffic management in North America.

    It was called Protrak and it was written by a fellow by the name of Jim Moir, a Canadian. I purchased a licence to use the software for what I consider a bargain price. Especially when you consider just how much effort and how many years it took the man to write the program. But sadly Jim has left us, and he left us leaderless as well.

    I attempted to convince his estate to donate his legacy to an open source group so that his code could live on. But my proposal was rejected.

    I am saddened that that determination will mean the eventual death of Protrak. I would have loved to have seen your people taking ownership of his work. I think everyone could have become winners. Maybe if we had enough cash we could buy the code? But I’m not hold my breathe to see it it happens.

    Now back to positivity.
    Yes I can see that openrails and modelrailroad could be a marriage made in heaven. For example I have devices called digitrax BXPA1 that can track occupancy detect, seperatly detect locomotive details of railcom (backchannel loco info) enabled decoders. Short circuit detection and protection and each covers eight blocks a piece. Just the thing to link Openrails to a layout.

    But I in my very nerdy way am not what I would call “the norm” in modelrailway circles. Most don’t do this. I think even if we had the Openrails/modelrailroad interface all sorted the railroad modelling community is not quite ready for that degree of sufistication. Don’t get me wrong, just because we are not there yet doesn’t mean that that couldn’t change, and fast. But I think a demonstration of the positive application of openrails code in the form of physics could be what is needed to kick start that growth.

    To date I have had no coders from my side express an interest in helping me out. Chris do you know of any people on your side who may be willing to carve out the essence of physics stuff with me. Getting it in one bundle is the start. What to do with it then is open at this stage.

    Mark

    Ps what is the little blue tag looking thing in the corner where the attachment paper clip symbols are. It driving me nuts trying to work it out. See I told you I’m a nerd.
    Last edited by Markstaffrld; 01-14-2019 at 06:07 PM.

  9. #29

    Default

    Chris maybe I should have a closer look at Openrails intergration directly with a model railway to see what needs to occur. You have manual and automatic running so that might be cool to see if I could get it going. I’d need a dcc interface but we might get that from existing jrmi software (another open source development group)

    Defiantly worth consideration isn’t it! It might be easier as well
    Mark

  10. #30

    Default

    Chris I’ve been told that replicating model railway track is not able to be duplicated exactly and because of the discrepancies it could lead to application crashes.

    Does the two descriptions of both the real and virtual have to be precisely the same? If it is can it be achieved?

    I don’t know enough about the subject to have any sort of an informed view.

    Going the other way and distilling the physics code out of train.cs have you a view on how big that code would most likely be?
    I’m trying to work out if our protothrottles have enough ram to be able to process the physics basic algorithms on board. Ball park?

    Thanks for your input buddy.
    Regards
    Mark

Tags for this Thread

Posting Permissions

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