Resuming Activity From Save, Locomotive Wheelslip and Power Reduction Occurs!

[meeshu]

On resuming a saved activity, particularly for saves while train is crawling up hill and locomotives are at maximum throttle, often get warning for wheelslip and locomotive power being reduced! The train usually stalls at that point despite deploying sand to aid traction.

Now, prior to the saved activities, the train was managing to move along (often without sand being deployed) with no issues.

It appears that the slight delay on resuming the activity from a save causes Open Rails to decide that wheelslip must now occur and power must be reduced!?

So, not sure if this a "bug", or what? But it is annoying to have this wheelslip/power reduction/train stall occur on many occasions after resuming an otherwise perfecting running activity!?

Ideas?

[meeshu]

An update.

There is also the occasional over speed and wheel slip warning message appearing while actually running some activities where the train is not necessarily running at full throttle, and might only be running on relatively flat terrain! But in these cases, the warnings seem to appear after data is being transferred from my HDD. There is usually a noticeable slight stuttering to the video display while data is being transferred.

Maybe because of the relatively slow transfer of data from my HDD is triggering these warning messages, as Open Rails seems to think there is now some "problem" with the train(?)

A note that MSTS has been installed on a separate HDD to that of my OS HDD. But Open Rails is installed on my OS HDD. Maybe that is why there is a slight delay to transfer of data?

Using SSD's instead of HDD's should improve data transfer rate, but I'm not in a position to upgrade just yet.

[Vince]

External HDD's on a USB interface transfer data 100 times slower than a typical spinning internal HD.
The USB transfer rate may be closer to 1000 times slower than an internal SSHD.
SSHD's are reasonably priced these days.
You will experience a performance boost if the SSHD is internally. Nada if on a USB connection.

regards,

[R. Steele]

Using SSD's instead of HDD's should improve data transfer rate, but I'm not in a position to upgrade just yet.

Two things...
Running OR with routes, trainsets, etc. on the same SSD will improve performance.
The latest Unstable and MG versions of OR start in Pause mode, giving the sim time to "catch-up" to the physics from the save ( don't know enough about coding to explain it more elegantly ). Earlier versions and the last stable version ( 1.3.31 or something? ) opened from a save on-the-fly...lots of wheelslip.

[meeshu]

I'll probably get internal SSD's eventually, thanks Vince.

Thanks Gerry.

That is very useful information!

So it seems that there is some sort of wheelslip "bug" with earlier versions of Open Rails when trying to resume activities.

I think I'll have a look at these later and alternative versions of Open Rails and see how things go!

[meeshu]

Tried the "unstable" version of Open Rails, and also tried the "MG" version, but neither recognizes the activity saves from Open Rails 1.3.1! So this means for any activities that on resuming results in wheelslips, and tractive effort reductions with trains (eventually) stalling, these activities will now have to be re-run from the start!

[R. Steele]

Tried the "unstable" version of Open Rails, and also tried the "MG" version, but neither recognizes the activity saves from Open Rails 1.3.1! So this means for any activities that on resuming results in wheelslips, and tractive effort reductions with trains (eventually) stalling, these activities will now have to be re-run from the start!

Yep, too many changes in the code to accommodate saves from earlier versions, sometimes if the versions are close enough you can resume from an earlier save, there is a warning to not report errors...just ignore it -- the activity will either resume or not.

[meeshu]

Thanks.

Running the "unstable" version of Open Rails, it crashed sometime after resuming a previously saved activity by this unstable version. Guess that's why it is called the "unstable" version!?

[R. Steele]

Thanks.

Running the "unstable" version of Open Rails, it crashed sometime after resuming a previously saved activity by this unstable version. Guess that's why it is called the "unstable" version!?

Well, lots of the members run the "unstable" version and never have a crash...personally I am always running the unstable or MG version, except when I want to test something...I first test in the last stable version, then also test in the latest unstable. Running activities I always use the MG version with reshade and crashes are infrequent...can't really remember the last one.

Do you have a log from the crash?? Looking in the log may provide a cause for the crash.

Although, you know, I really don't know the technical reason it is called the "unstable" version... I always thought it was because there could still be unresolved bugs to be found in the code...but since OR is in a constant state of development there are always going to be unresolved issues, excepting for the stable version.

[meeshu]

I don't have the log for the first unstable version (23rd April) crash, but I've just had another crash running the latest unstable version (26th April)!

In both cases, the crash occurred while in trackside view ("4" key). The activities were different for each crash, and involved fairly long consists (between roughly 140 to 170 cars with around half a dozen or so locomotives).

Possibly a video issue, as the crashes seem to occur only while in trackside view, where there are more objects to be drawn and textured(?)

Screenshot of error message and log of second unstable version crash enclosed.

OR_unstable_26_crash.jpg

OpenRailsLog.txt

[meeshu]

Another crash, this time for same activity as last time running under OR "MG" this time!!?? And again while in trackside view.

I'll try running this activity under "stable" Open Rails version 1.3.1 and see what happens!

Screenshot and Open Rails log attached.

OR_MG_crash2.jpg

OpenRailsLog.txt

[Vince]

Quick question: Your disk drive H; What kind of drive is it and how is it attached to the system?

regards,

[meeshu]

Drive H: is a standard SATA connected HDD.

Being a Hard Disk Drive, it's data transfer rate is not really ideal. Solid State Drives are being considered as replacements in the future to improve data transfer rates.

Ran the same (last) activity under stable Open Rails 1.3.1, and the activity completed without issues.

Just recalled that a contributing factor for the unstable versions crashes might have been partly due to me downloading files in the background at the same time the activity was being run. The downloading would use some CPU resources, but I would have thought not to the extent to interfere with Open Rails which is not as CPU intensive as MSTS(?)

I might re-run the activity for the unstable versions of Open Rails, but this time ensure no other processes are running in the background, including downloading.

[crstagg]

Drive H: is a standard SATA connected HDD.

. .

Are you sure? Maybe a 16GB partition of a SATA HDD? Or is is an 16GB PATA or IDE HDD?

[meeshu]

Yes. Actually drive H: is a partition of a SATA drive.

That drive also has data partitions and also some other operating systems, but not the main operating system (Windows 7 64 bit) which is on another physical SATA HDD.

While downloading files to the data partition of the same physical SATA HDD as drive H:, this might introduce a slight delay in drive access and consequent slight delay in data transfer while running Open Rails? This might explain why Open Rails could crash as requested data is not being supplied fast enough?

Or is it something else?