Elvas Tower: OR Compatibility of Silverliner II - Elvas Tower

Jump to content

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

OR Compatibility of Silverliner II Rate Topic: -----

#11 User is offline   BillC 

  • Conductor
  • Group: Private - Open Rails Developer
  • Posts: 322
  • Joined: 31-May 11
  • Gender:Male
  • Country:

Posted 14 December 2011 - 09:43 PM

View Postmestevet, on 14 December 2011 - 06:08 PM, said:

Chris,

The number of notches in the .ENG and .CVF is the same. The nuance that I think maybe some folks are missing is that the controller in the real Silverliner II EMUs is different than in your typical Freight Diesel (or even some of the well known electric locomotives for that matter). I hope that folks read my description of how the real controller works in my original post, and that I came very close to that same operation in MSTS, with the settings that were released with the cars originally in 2008.

I'm guessing that because the type of controller in the Silverliners wasn't envisioned when the control algorithm was programmed in OR, that the way I set up the controller in the .ENG and .CVF that allowed it to work properly in MSTS (which is NOT conventional), isn't being recognized or handled the same way in OR.

In discussions since finalizing and releasing the Silverliner IIs three years ago, I've become aware of OTHER railroad rolling stock with non-standard type controllers. I'm aware that many trolley cars had a controller which functioned similarly to the type on the Silverliner. Indeed, the PRR's MP54 EMU cars (vintage 1915) had controllers that appear to be the forerunner of the Silverliner's controller (early "steam road" EMU's derived much from trolley experience). Aside from the Silverliner II & III cars, the Silverliner IV and NJT Arrow III cars use this type of controller currently. I was also told about the controllers used in Fairbanks-Morse diesels that also have no reverser and forward and reverse are handled by moving the controller in a sideways "U" shape (one leg of the U for forward, one for reverse) - see this: http://www.trainsim....orse-H12-44-cab

My point is, that what I'm asking isn't normal for late generation diesels, but there was a lot of equipment out there that used "unconventional" controllers that work this way...

...............


Steve


You are correct, the reverser except for steam, now works as a REV-N-FWD control. The previous release worked as a REV-FWD only for all engine types steam, electric, diesel. The reverser for the Silverliner may work in that version, however there have been many improvements in ALL areas of OR, so would not be useful to revert to that version. Once I become familiar with the equipment I'll integrate it into the code.

Will also look into NECv4 control issue's. Very little QA testing outside of MSTS standard routes has been done for electrics.

May I suggest you consider joining OR as a tester. You would have access to the latest builds and fix's, in addition to have a say on features.

Bill

#12 Inactive_mestevet_*

  • Group: Status: Passengers (Obsolete)

Posted 15 December 2011 - 03:00 AM

View PostBillC, on 14 December 2011 - 09:43 PM, said:

You are correct, the reverser except for steam, now works as a REV-N-FWD control. The previous release worked as a REV-FWD only for all engine types steam, electric, diesel. The reverser for the Silverliner may work in that version, however there have been many improvements in ALL areas of OR, so would not be useful to revert to that version. Once I become familiar with the equipment I'll integrate it into the code.

Will also look into NECv4 control issue's. Very little QA testing outside of MSTS standard routes has been done for electrics.

May I suggest you consider joining OR as a tester. You would have access to the latest builds and fix's, in addition to have a say on features.

Bill


Bill,

Thanks for your reply.

What I'm trying to explain is that the Silverliners DON'T HAVE a reverser at all - neither the real cars, nor my model. None. They have a throttle that is moved one direction for "Forward" and the other direction for "Reverse". So that's the way the cars were set up to work in MSTS when I released them in 2008, and they worked fine that way in MSTS. So I'm trying to see if I can now get them to work that way in OR.

And again, the control issues don't seem related to the route on which I'm using the cars, they act the same on all routes I've tried them on. In fact, none of the issues I've brought up appear to be route dependent (Rick Franzosa brought up the route theory with the "black shadow" issue and some of his rolling stock)

I would gladly become a tester, what do I have to do?

----------
Chris,

I'm really not trying to be difficult about the pantos. I'm just making the statement that a Silverliner only has ONE pantograph. So there simply isn't a second one to raise, so I can't test that solution.

My additional comments were simply to point out that, in my experience with electrics, the power operation on an electric locomotive/EMU shouldn't depend on how many pantographs are raised (I'll leave open the possibility that somewhere, that may be the case, but not anything that runs on the NEC or any of the electric commuter lines in the US)

Just out of curiosity, who's providing input about the operation of electric locomotives/EMUs to the OR team?

Would anyone be willing to try running the Silverliners on the NEC in MSTS to see how they were intended to work? I realize that electric multiple unit commuter passenger cars aren't everyone's cup of tea, but I think trying them out may help to clear some of the confusion about the questions I'm asking...

Steve

#13 User is offline   Matej Pacha 

  • Engineer
  • Group: Status: Contributing Member
  • Posts: 571
  • Joined: 08-December 10
  • Gender:Male
  • Location:Slovakia
  • Country:

Posted 15 December 2011 - 03:58 AM

View Postlongiron, on 14 December 2011 - 06:49 PM, said:

View Postmestevet, on 14 December 2011 - 08:41 AM, said:

It also seems to accelerate slowly compared to the MSTS model and real life. Mind you, Joe Realmuto and I ran timed tests over known distances to get the acceleration performance correct in MSTS, since real life TE curves have never been found for these cars, but we did know speeds/distances/times from me actually riding the cars.

I'm asking to see if the OR code is correctly handling electric MU'd cars. If you get much more acceleration with two panto up, then there's some work to be done on the coding side. If not, then we should help you to better understand the OR electric physics engine.

There is no such a dependency on number of pantos up. The only problem is in parameters and parsing. First, you can switch between advanced and simple adhesion model by pressing Ctrl+Alt+X (can be seen in Shift+F5 Froces view).
In simple adhesion mode the tractive force is computed directly from throttle, max power and speed values. If the tractive force "on wheels" is higher than adhesion limit, overall tractive force falls down (it is the same as in MSTS but with different adhesion limits). You can improve the adhesion by sanding. However, I've checked this MU and became surrprised - tractive effort on 100% was 149.85 kN for any speed within 0 - 90 mph, what means that the MU has 6000 kW (8050 hp) when running full throttle on 90 mph (2x410 kW expected)!!! Thus there must be something wrong with throttle controller data parsing.
Running the advanced adhesion model you may experience problems with stability - it is caused by a combination of WheelRadius and MaxPower values. Based on these, the axle inertia is computed but you can still force this value by a hidden parameter:
Wagon(
OR_Adhesion(
Wheelset (
Axle( Inertia ( Value ) ) ) ) )

Valid range is from 10000 to 40000. Higher value means more stability. This parameter (and some others) is hidden because of a new file structure planned. You should see the power on axle floating from 350 to 400 kW on full throttle. If the power is oscilating then it should be tuned by new ORTS parameters.
If you want to help with tunning this MU, you can send me a PM and I can assist you with it next week.

#14 Inactive_mestevet_*

  • Group: Status: Passengers (Obsolete)

Posted 15 December 2011 - 07:40 AM

View PostMatej Pacha, on 15 December 2011 - 03:58 AM, said:

There is no such a dependency on number of pantos up. The only problem is in parameters and parsing. First, you can switch between advanced and simple adhesion model by pressing Ctrl+Alt+X (can be seen in Shift+F5 Froces view).
In simple adhesion mode the tractive force is computed directly from throttle, max power and speed values. If the tractive force "on wheels" is higher than adhesion limit, overall tractive force falls down (it is the same as in MSTS but with different adhesion limits). You can improve the adhesion by sanding. However, I've checked this MU and became surrprised - tractive effort on 100% was 149.85 kN for any speed within 0 - 90 mph, what means that the MU has 6000 kW (8050 hp) when running full throttle on 90 mph (2x410 kW expected)!!! Thus there must be something wrong with throttle controller data parsing.
Running the advanced adhesion model you may experience problems with stability - it is caused by a combination of WheelRadius and MaxPower values. Based on these, the axle inertia is computed but you can still force this value by a hidden parameter:
Wagon(
OR_Adhesion(
Wheelset (
Axle( Inertia ( Value ) ) ) ) )

Valid range is from 10000 to 40000. Higher value means more stability. This parameter (and some others) is hidden because of a new file structure planned. You should see the power on axle floating from 350 to 400 kW on full throttle. If the power is oscilating then it should be tuned by new ORTS parameters.
If you want to help with tunning this MU, you can send me a PM and I can assist you with it next week.


I would love to discuss "tuning" the cars for OR with you.

Certainly the power should drop as the car speed increases (that's the way it is in real life). Two unusual parameters that we employed to get the TE and Power curves correct in MSTS were the "DieselEngineSpeedOfMaxTractiveEffort" (yes, in MSTS, it works for electrics not just diesels) and "MaxInHiAcceleration". Joe Realmuto discovered in MSTS that those parameters could be used to more accurately shape the Tractive Effort and Power curves of electric equipment in MSTS. So I'm wondering, does OR take those parameters into account? If not, THAT may be part of the reason why I'm seeing different performance from the Silverliners in OR than in MSTS.

Also, from what you're saying about "throttle controller data parsing", I'm wondering if the other issue I'm having, with HOW the controller functions, is playing a role in the basic performance of the cars.

Also keep in mind that to set up the proper Tractive Effort curve in MSTS (because of it's limitations), the absolute power and tractive effort numbers that must be used in the .ENG file don't necessarily match the "true", real life numbers, but yet result in accurate performance. Joe Realmuto had a spreadsheet for determining the proper adhesion, force, and power numbers for electric locomotives/EMUs in MSTS to match a TE/Power curve. Since no power curve for the Silverliners could be found, we used time/distance/speed data gathered from riding the actual Silverliners still in service, and then used that to back out a reasonable TE/Power curve.

The real cars, as delivered, were 550hp total (that's 137.5hp per traction motor, 4 traction motors, one per axle). Certainly that is the maximum power, not necessarily what is available at any speed. So that's where the 410 kW comes from. The "Force" and "Max Force" MSTS values in the .ENG were simply chosen to match the available "timed test" data, using Joe Realmuto's MSTS EMU spreadsheet.

So with all of that, thank you for responding and offering to help. I will send you a PM and we'll see where we can go from there!

Steve

#15 User is offline   BillC 

  • Conductor
  • Group: Private - Open Rails Developer
  • Posts: 322
  • Joined: 31-May 11
  • Gender:Male
  • Country:

Posted 15 December 2011 - 11:34 AM

View Postmestevet, on 15 December 2011 - 03:00 AM, said:

Bill,

Thanks for your reply.

What I'm trying to explain is that the Silverliners DON'T HAVE a reverser at all - neither the real cars, nor my model. None. They have a throttle that is moved one direction for "Forward" and the other direction for "Reverse". So that's the way the cars were set up to work in MSTS when I released them in 2008, and they worked fine that way in MSTS. So I'm trying to see if I can now get them to work that way in OR.

After looking at the video I see what you mean. To implement the correct photo-typical feature in OR, code would need to be added, and possible changes to the .eng and .cvf files.

Quote

And again, the control issues don't seem related to the route on which I'm using the cars, they act the same on all routes I've tried them on. In fact, none of the issues I've brought up appear to be route dependent (Rick Franzosa brought up the route theory with the "black shadow" issue and some of his rolling stock)

Agreed as in my previous post that was my take also.

Quote

I would gladly become a tester, what do I have to do?


The traditional way was to go the OR web site and submit a form. However you may want to mail Chris directly. Click on longiron (top left of his post) to view his profile. There is a provision to e-mail him, you should then receive a response.

Bill

#16 Inactive_mestevet_*

  • Group: Status: Passengers (Obsolete)

Posted 15 December 2011 - 01:51 PM

View PostBillC, on 15 December 2011 - 11:34 AM, said:

After looking at the video I see what you mean. To implement the correct photo-typical feature in OR, code would need to be added, and possible changes to the .eng and .cvf files.

Agreed as in my previous post that was my take also.

The traditional way was to go the OR web site and submit a form. However you may want to mail Chris directly. Click on longiron (top left of his post) to view his profile. There is a provision to e-mail him, you should then receive a response.

Bill


Thanks again Bill, I was suspecting as much about the controller. It might be as simple as having some sort of check in the code "is a reverser defined?" or "are all the reverser values equal" (see below) and if not, then the direction of the throttle movement controls the direction of movement? (I won't feel bad if anyone tells me to keep my nose out out of programming, the last time I programmed, in FORTRAN, was for my Master's Thesis, in about 1993.) Like I said, it DOES function fairly accurately in MSTS the way we have it set up, which is defining both positive and negative notch values for the "Throttle" handle (to define forward and reverse), and the direction control definition in the .ENG file is "locked forward ( DirControl ( 1 1 1 1 ) ) So that's how I got MSTS to accept it:

	EngineControllers (
	# ( New Physics Throttle )
		Throttle ( -1 1 0.25 0
			NumNotches ( 11
				Notch ( -1       0 Dummy )
				Notch ( -0.27    0 Dummy )
				Notch ( -0.06    0 Dummy )
				Notch ( -0.021   0 Dummy )
				Notch ( -0.0001  0 Off )
				Notch (  0       0 Off )
				Notch (  0.0001  0 Off )
				Notch (  0.021   0 Dummy )
				Notch (  0.06    0 Dummy )
				Notch (  0.27    0 Dummy )
				Notch (  1       0 Dummy )
				)
			)


As for talking to Chris... he and I go way back :discuss_gathering: I still have an early version of one of his first modeling efforts in TSM in my "HELP" folder! (long before OR was begun)

Steve

{PS, I just learned that Tim Muir has tried loading his MILW Boxcab electrics into ORv0.7, so us "Electric Guys" are coming out of the woodwork!}

#17 User is offline   elkwharton 

  • Apprentice
  • Group: Status: Switchman
  • Posts: 19
  • Joined: 09-July 14
  • Gender:Male
  • Simulator:OPEN RAILS
  • Country:

Posted 11 August 2017 - 06:35 AM

View Postmestevet, on 14 December 2011 - 10:12 AM, said:

Rick,

I don't know, I was seeing this when testing on the NECv4, but in a quick test on my own "test" route, I saw the same effect. I'm positive my test route doesn't have any static track on it (it only has a long straight test track). So far I've seen this behavior in several different locations on the NECv4 (every place I've tried so far), two routes of my own making, and the Tokyo-Hakone default route (I have to test the cars on electrified routes). I've also seen the same effect with my E44 locomotive and my G39a ore jenny model. I DID note, and if you look at my screenshots carefully, that some of the scenery objects in the OR screenshot seem to have the same thing happening (the fence, the trash bin, some of the overpass abutments, and even the billboard above the train). Another thing I'm observing is that if the camera moves closer to the model, the black shadow pushes back away from the camera and you see the normal car texture (like there's a point if you get close enough that it disappears, like there's a radius around the camera location).

I'm wondering if anyone else who has my Silverliners or E44 could check and see if they see the same thing. The other thought I had was that it could be a video card setting or driver issue.

Steve


Hi Guys I too run the silverliner ii in open rails. Yes I have the same problem with the controller. I am trying to do a 3d cab. I have managed to get the controller to work in forward position with all 5 positions properly. How ever I have to use the reverser. I did notice though that even though the controller refuses to go left of the off position the engine file does do the reverse settings. As for your problem with the black patch. I exclusively use the PRR REG EASTERN DIV ROUTE that came out a couple of years back. I just ran a test run from Thorndale to Whitford with no evidence of the black patcth. I have quite often run the entire Paoli route and also the Wilmington, and Reading routes to Norristown and that side of the system and haven't noticed the black patch on my system at all. I am running a run of the mill HP all in one computer with 8 gig of ram and no special video card just the built in one on the board. Hope this helps you. Also if anyone comes up with any solutions to the controller please let me know (elkwharton@gmail.com) as I am really trying to get the 3d cab working with the controls acting properly. Jeff

  • 2 Pages +
  • 1
  • 2
  • You cannot start a new topic
  • You cannot reply to this topic

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users