[R H Steele]

jared2982, on 31 December 2018 - 01:09 PM, said:

I have used the raildriver with several different train simulators. I must say that Run8 has the best implementation. You calibrate it in the game and the controls work much better than they do in any other train simulator. Including the auto brake. I think the control issue that is experienced in OR is related to controls setup in the eng files in combination with the sscript and coding built into OR.

my emphasis

RE: Run8 implementation of Raildriver, in agreement. I was impressed, same analog controls, absolutely fine control in the simulator, so it's not all Raildriver, although BillCs idea of digital encoders is intriguing, they would probably make a difference.

[perpetualKid]

great input in this thread, appreciate :)

So while the 32/64bit is a done thing (and I can't see a need for user to select which version to install, as long we can support both in parallel), I'm tempted to implement customizable key mapping, similar as we do for keyboard commands. Maybe I even get the calibration included, so we would no longer need separate setup from PI and have to copy the calibration files....

This way there could be different mappings for steam engines vs others etc.

[dforrest]

perpetualKid, on 31 December 2018 - 10:37 PM, said:

great input in this thread, appreciate :)

So while the 32/64bit is a done thing (and I can't see a need for user to select which version to install, as long we can support both in parallel), I'm tempted to implement customizable key mapping, similar as we do for keyboard commands. Maybe I even get the calibration included, so we would no longer need separate setup from PI and have to copy the calibration files....

This way there could be different mappings for steam engines vs others etc.

I am all for this for steam locos and would move to using RailDriver immediately if it was done.

[EricF]

I agree that the current Open Rails implementation leaves something to be desired in the control response. There's a "rubber-band" effect, where you move the control, and there's a definite lag before response in the sim catches up. That could have something to do with how frequently OR scans the Rail Driver for input changes, or just a low priority for processing its inputs compared to the keyboard. (For comparison, MSTS tended to have input lag even from the keyboard -- press a key... wait a noticeable interval... then the control input would take effect. The Rail Driver was no better or worse, really, since MSTS' controls were always a bit slow.)

[perpetualKid]

making good progress - rewritten the way Raildriver input is received, basically now working the same way and same frequency as the keyboard input (polling in sync instead of callbacks at a different rate), which should lead to better accuracy. Can't judge unbiasedly but feels more snappy. Also "fixed" the the Bail-Off issue which has been reported multiple times in the past - I don't know what the correct handling would be, only guessing that Bail-Off is only enabled as long the lever is pressed to the right, and disabled again once the lever is released - works along the full range of the Independent Brake handle.

Looking into button customization and handle calibration now, seems doable at reasonable effort. But may take longer to also implement an editor (as part of Menu-->Options), so first stage may require some manual tweaking of config params.

Also wondering what's the purpose/correct handling of the E-Stop buttons in the left hand button field - while it's a two position rockers, either position only triggers emergency brake. Can't imagine this being correct in real world scenarios?

[R H Steele]

http://www.elvastower.com/forums/public/style_emoticons/default/sign_thank_you.gifhttp://www.elvastower.com/forums/public/style_emoticons/default/hi.gif much appreciated.

[jared2982]

In real world scenarios the emergency brake switch is used to put the train in emergency using the EOT. The real life switch is a toggle switch with a red safety cover and only throws one direction. For use with raildriver I think it is acceptable to allow that switch but the train in emergency flipping it both ways. It may also be a benefit to some to allow the various raildriver controls to be re assigned by the user.

[EricF]

If I recall braking systems correctly (and have enough caffeine this morning... http://www.elvastower.com/forums/public/style_emoticons/default/lol.gif ), bail-off should rapidly release the locomotive brake and keep it released while holding the independent lever in bail-off. Upon letting the lever return to rest in any position (applied or released), the air pressure should build and cause it to re-apply at whatever pressure is set by the main (automatic) brake handle. Re-application shouldn't be instant, as the air pressure needs to build again in the locomotive brake circuit. (The sim should handle that according to braking and physics... if not, there's a bigger problem.)

Some notes on using the bail-off function...

The locomotive brake should only stay cut-out (disabled) when the dynamic brake is activated. Here's where it gets complicated. Early systems require the engineer to bail-off once when applying the dynamics to trigger the hold-off. On modern dynamic brakes, the locomotive brake should bail-off and stay held off automatically when the dynamics are activated. (Or activated beyond the minimum setting, depending on locomotive manufacturer. Also, some systems may have a feature which cuts the locomotive brake back in when dynamic braking falls below a useful level at low speeds. This would be have to be handled in .eng and .include files in the sim.). Bailing-off periodically while in dynamics is done to ensure that the locomotive brake isn't applying because of a leak or malfunction in the automatic brake system. It shouldn't be necessary, and may be prohibited by some railroads. (Why? Because hitting bail-off still dumps the locomotive brake air, which takes time to recharge. That means there might not have enough pressure in the system when it's needed, so it's a safety issue.) But if the locomotive brake is applying under dynamic braking when it shouldn't this will keep it from applying too much additional braking force at the locomotive's wheels. (In the sim, leakage should be defined in .eng and .include files.)

On steam locomotives or anything without dynamics, the only way to keep the independent bailed-off is to hold the lever in the bail-off position. This means that to control slack in the train (or stretch the train) by bailing off the locomotive brakes while applying throttle while the automatic brake is applied at the same time, you'll have to hold the locomotive brakes in bail-off with one hand while operating the throttle with the other. Since you don't have a third hand, you have to plan what you're doing so you can let go of the throttle to operate any other controls while staying bailed off. Which can be more of a problem than at first thought. (And this is why it's important to know how much "set" to apply to the automatic brake so you don't have to fiddle with it...) You might hear talk of putting a "wedge" in the independent to keep it bailed-off -- this is what it sounds like -- jamming an object into the independent brake handle's area to keep it pushed into the bail-off position, freeing your other hand. It's also prohibited to do so by any railroad's rules. Coordinating throttle, automatic brake and locomotive brake bail-off to control slack (and perform stretch-braking in passenger service, particularly with heavyweight cars) isn't easy! Having the necessary functions working correctly on the RailDriver would be great for steam operations!


We appreciate the work! http://www.elvastower.com/forums/public/style_emoticons/default/sign_thank_you.gif

[jared2982]

Your close with your bail off description. The bail off function is used to release the locomotive brakes after an application of the train brakes as described above. However, if the independent brake is applied already during the train brake application then bailing off will only reduce the pressure in the locomotive brake cylinders to the pressure that the independent brake is applied. Example: I have 15lbs off brake cylinder pressure. I make a 10lbs reduction with the automatic brake and brake and bail off the independent brake. My brake cylinder pressure will remain at 15psi or if I don’t bail off soon enough it will start to raise but will come back to 15 once I bail off.

Also on modern US locomotives (all diesels) dynamic brakes do NOT cut out the independent brake. There are some locomotives that will cut out or reduce the dynamic braking effort with the application of the independent brake. This is mainly to reduce the possibility of sliding wheels and creating flat spots.

[thegrindre]

dforrest, on 30 December 2018 - 12:46 PM, said:

I have had a RailDriver for many years but find that its support for steam locomotives, the only thing I seriously drive, is very limited.

I must agree. I would like to see more if any, steam supported buttons or whatever. It would be nice to have the controls more adaptable to steam if at all possible.

[perpetualKid]

If someone wants to test current state of the changes as mentioned above, attached is a binary package.


This is based on ORMG 3.7, so make sure the prerequisites as mentioned here are installed. Should work both for 64 and 32 bit, default to the OS architecture.


Known issues:
- expects the RD calibration file (ModernCalibration.rdm) in the exe-folder. This is a temporary issue and change to the original version, but since I expect to remove these external calibration and move into settings/options anyway, didn't want to spent time fixing Path-settings


Currently working on button customization, and I'll backport the code changes to ORTS (other than the changes for 64bit which there is not possible in original ORTS currently) only once done, or if someone else wants to take on such job.

Let me know any feedback or bug reports.

//edit on Feb 3rd - removed the binary package as a newer version is available further down the thread.

[perpetualKid]

dforrest, on 30 December 2018 - 12:46 PM, said:

I have had a RailDriver for many years but find that its support for steam locomotives, the only thing I seriously drive, is very limited.

since I'm not driving steam engines, I don't really know what's missing. Imagine we get customizable blue buttons (and maybe the left hand side buttons as well), would the levers need to be mapped/used differently also?

[James Ross]

perpetualKid, on 25 December 2018 - 11:11 AM, said:

Unfortunately didn't got it working in the first trial, but I discovered the Raildriver support in ORTS is bound to an older 32bit driver implementation from PI Engineering. Good news though, PI is supporting 64bit in newer versions of their API. However there are some changes in the PI API which require couple updates to the OR code for Raildriver to get the new version to work. Furthermore, they way it's implemented, may cause some challenges supporting both a 32bit and 64bit at the same time. I'm looking to implement this in a 64bit version of OR MG at least, but potentially backport to the official (32bit) version as well - if there is interest at all...

If there are changes we can safely make to the official version that will enable 64bit to work in the future, I'd be happy to take them ahead of enabling 64bit support. I suspect we'll keep things 32bit with MonoGame initially, just to reduce the number of large changes at once, but it does depend on how things are affected by 64bit.

perpetualKid, on 25 December 2018 - 11:11 AM, said:

So while getting into the code, wondering how many folks are using Raildriver with ORTS, if there's larger interest in other changes.
I searched the forums and there seem few sporadic messages on Raildriver only, and indicating missing features like programmable key mappings or different keys mappings for OR camera views.


What's on folks mind, do we need any updates for RailDriver in OR? No commitment or timelines yet ;)

Being able to customise the buttons on the RailDriver, at least, would be fantastic; the other inputs I'm less sure need it, but if there's a calibration step needed for proper functioning I'm okay with us including that too.

[perpetualKid]

finally got some time to complete work on the RailDriver implementation I started few weeks ago.

this includes:
- a new tab page on Options Dialog in Menu to customize Raildriver. The tab page will only show if an RD is connected
- on the page, RD buttons can be customized in a similar way as keyboard settings. Known limitation - each functionality can only have one unique button assigned. This means the horn and e-stop dual way switches can be assigned to different settings only, but not the same on either direction. In default config however, both switches still can be used in both ways for the same functionality.
- RailDriver calibration is now part of the options dialog. Calibration is fully integrated in ORTS, so there is no need for separate calibration program and calibration files. Therefore an initial calibration needs to be run in ORTS. While Calibration runs, a guidance dialog will be shown as in the screenshot, showing which lever to move in position to get a measurement, before moving to next.
- I found some Trello card voting for options to reverse lever handling, and use full throttle range for trains not using dynamic brake. This can be configured separately now.

- both 32 and 64bit versions working
- fixed the BailOff issue
- more precise input reading
This is currently based on Monogame implementation, and as before, requires .NET 4.7.1, DirectX runtime, and OAL installed as mentioned here


//removed attachment for newer version further down the thread

[R H Steele]

http://www.elvastower.com/forums/public/style_emoticons/default/sign_thank_you.gifhttp://www.elvastower.com/forums/public/style_emoticons/default/sign_rockon.gif Your time and effort are very much appreciated. http://www.elvastower.com/forums/public/style_emoticons/default/cool3.gif http://www.elvastower.com/forums/public/style_emoticons/default/hi.gif