What are the rules for entering the values for dynamic braking current meters?

[sidp]

I have been corresponding with an Open Rails programmer working on making the control displays in OR match their operations in MSTS. For most cases, it seems straightforward. However, in the case of some two needle displays where there is one needle for driving current (positive) and another for dynamic braking current (negative), some of the values found in the .cvf file appear puzzling.
I am looking at the file "EMD-GP38-BNSF-H1-AS.cvf" for Charlie Sibaja's GP38 cabview. The entries for the red (dynamic brake) needle and white (driving current) appear as follows:
Dial (
Type ( LOAD_METER DIAL )
Position ( 423 159 5 31 )
Graphic ( "..//..//SHR.CABS//EMD-STD-1-CAB//needleloadred.ACE" )
Style ( POINTER )
ScaleRange ( -900 0)
ScalePos ( 319 250)
Units ( AMPS )
Pivot ( 27 )
DirIncrease ( 1 )
)
Dial (
Type ( LOAD_METER DIAL )
Position ( 423 159 5 31 )
Graphic ( "..//..//SHR.CABS//EMD-STD-1-CAB//needleloadwhite.ACE" )
Style ( NEEDLE )
ScaleRange ( 0 1600 )
ScalePos ( 319 47 )
Units ( AMPS )
Pivot ( 27 )
DirIncrease ( 0 )
)
The display is a single dial, with both needles starting at the left end; they move clockwise on the dial as the magnitude of their value increases (more motor current for the white, more dynamic braking current for the red).
These angle values are exactly what you see if you open the cab editor and look at the entry template for each of these display items.
The angle values for the white needle look straightforward - the needle moves from 319 degrees to 47 degrees as the current increases from 0 to 1600 amperes.
When dynamic braking is active, the red needle in the display moves from 319 degrees, in the the positive direction (because the DirIncrease value is 1) towards the vertical, i.e. the angle is moving towards 360 and perhaps may move past it. But in the cvf file, the entry is 250 degrees. What is the rule that MSTS uses to interpret this value?

I'm sure that the answer is staring at me, but I can't see it. Any help would be appreciated so that OR can interpret the numbers the same way.

[rdamurphy]

Are you sure it's in degrees?

If the scale range is 0 to 1600, I would assume it's in mils.

Robert

[baldwin]

Would the ScaleRange in fact be AMPS because they are the units in use. I think that the pointer for the dynamic load should be moving in the opposite direction to the running load, because 319 250 is opposite to 319 47. Those figures would equate to degrees in a circle.

Thing is, I have only seen the two needle approach in Charlie's cabs. Every other one I have looked at uses a single bi direction needle. Therefore it is likely that two routines would have to be written with access through an IF-Then type of argument.

[sidp]

Would the ScaleRange in fact be AMPS because they are the units in use. I think that the pointer for the dynamic load should be moving in the opposite direction to the running load, because 319 250 is opposite to 319 47. Those figures would equate to degrees in a circle.

Thing is, I have only seen the two needle approach in Charlie's cabs. Every other one I have looked at uses a single bi direction needle. Therefore it is likely that two routines would have to be written with access through an IF-Then type of argument.

But the dynamic load pointer actually moves in the same direction as the load pointer! It starts at the left end and rotates clockwise like the motor current. And after looking at other samples in the Cab Editor, I am sure that the values are degrees. (See attachment

There is another dual pointer display in the Generic GP38 cab created by Dwight Mitchell (gp38comb.zip) - this one works fine in both Open Rails and MSTS! It is an inverted dial - both pointers start at the left and move counterclockwise with increasing magnitude of load current or braking current.
I agree that there must be an extra step in the processing of the data when there is a negative sign on the data value, but I wonder what it is - Dwight Mitchell's cvf is different (I have attached a text file with the two needle definitions). And it works in both simulators.

[baldwin]

Comparing the two sets, Dwight has the DirIncrease set opposite to that used by Charlie for each needle. The other thing that is different is the way ScalePos data is set out.

Having taken a bit more time to study the Front ace of Charlie's cab, I am not sure what he intended both needles to do, because the actual meter is set up in the standard format with traction load needle moves right and dynamic load needle moves left. It may be that he decided to set it up with different coloured needles for each load type. If that is so, then the red one should move left and the white one should move right. Therefore I would be inclined to swap the DirIncrease for each entry and change the ScalePos of the dynamic ( red ) needle to read as 250 319.

[sidp]

Swapping the angles for the red needle to ( 250 319 ) and changing the direction to (0) makes the red needle start at the left edge and rotate to the left (off the dial) when braking. I tried it.
To make it start at the right, the right hand angle has to be a small positive value to park at the end of the scale.

Looking at the dial, it is difficult to read the values from the screen, so changing the arrangement looks acceptable, if not authentic.

By trial and error (!) I found that setting the red needle angle ScalePos to ( 300 28 ) with the DirIncrease ( 0 ) gives a reasonable performance in MSTS, and it also works the same in Open Rails!
In this case, I understand the settings: the ScalePos numbers define the angular position for the two values of the ScaleRange - 300 degrees at -900 AMP and 28 degrees at 0 AMP in the picture, and the needle turns clockwise for positive increase ( = counterclockwise for negative values).

I wonder what Charlie's opinion is ? It will certainly solve the problem in Open Rails for a lot of popular cabviews if only one of the dual needle setups was changed.
The new settings for the red needle:
Dial (
Type ( LOAD_METER DIAL )
Position ( 423 159 5 31 )
Graphic ( "..//..//SHR.CABS//EMD-STD-1-CAB//needleloadred.ACE" )
Style ( POINTER )
ScaleRange ( -900 0 )
ScalePos ( 300 28 )
Units ( AMPS )
Pivot ( 27 )
DirIncrease ( 0 )
)

[baldwin]

The ScaleRange of -900 0 equals a vertical position when dynamics are off, with a full deflection left at 900 amps when full dynamics are in effect.

So ScaleRange ( -900 0) should equal ScalePos ( 250 319) with a left handed rotation because it is starting at 319 degrees at 0 and moving back to 250 degrees for -900.

300 28 is normally a right handed rotation from 300 through 360 to 28.

Consider for a moment the default GP38 dial. It has ScaleRange ( -800 1600 ) and ScalePos ( 270 180 ) both of which are the extremities of movement -800 = 270 and 1600 = 180. For a two needle system to work properly one has to rotate clockwise and the other counter clockwise. I will set up one of Charlie's cabs when I get a chance tomorrow and experiment with the settings.

EDIT: April 3rd.
I now realise that I have been looking at the wrong CVF. Charlie has modelled both early and later standard cabs with different load gauges. Back later.

[baldwin]

ORTS is handling the cvf Load meter data and the associated in cab graphics for these cabs in a completely different way than MSTS. To get both needles moving in the same direction the values for ScaleRange and Scalepos have to be reversed for use in ORTS. I am currently using ScaleRange ( 0 -1500 ) and ScalePos ( 35 319 ) with DirIncrease ( 0 ) for the red needle ( Dynamics ). This if used in MSTS results in the needle being on the right side of the dial and not moving when dynamics are applied.

There is another thing that is affecting the movement of this needle when dynamics are applied in ORTS and I am not sure what that is yet. On going onto dynamic braking mode with the above settings the needle moves very slightly on setup, but when the first notch of dynamics is applied, it swings across to the right side of the dial and remains there instead of moving in increments as dynamics are increased, or load increases/decreases. It may be that I am using the modified dynamic brake physics from Plainsman, and these are affecting how ORTS is dealing with the application of the data, going back to investigate further.

After changing the eng file to use default physics, that is not the answer. The red needle shows the same actions. Therefore one has to think that ORTS is using the cvf data in a different manner than MSTS. However, if one then considers the default GP38 which is using the single needle for both modes, that works the same in both MSTS and ORTS so quite clearly ORTS is interpreting the standard MSTS instruction set in the correct manner. The confusion sets in when ORTS has to deal with a non-standard dial setup in the CVF.

I have also tried an unmodified Dwight Mitchell cab from his GP38 cab upgrade. In ORTS, the load needle runs in reverse, and the dynamic needle does not move. Clearly, ORTS does not like non-standard cvf data.

[sidp]

In my original post (04-01-2013), I should have made it clear that I was doing my recent MSTS vs. ORTS tests with an unreleased modified version of ORTS, and the handling of cvf needles has been changed in it - Dwight's cabview now works, and Charlie's works by setting the red needle to start at the right hand edge. I had not noticed the slight movements you describe.

If you are using the current experimental version of OR (X1502) or earlier, you should wait for the next release with the bugfix to "Bug #1154002 DirIncrease ( ) ignored in cvf file" before trying any further tests. Go to https://bugs.launchpad.net/bugs/1154002 to see the discussions.

I was puzzled by how MSTS interprets the settings for Charlie's cabviews - especially the red needle Scalepos values, since they will not work in the modified ORTS.

Thanks for the comments.

[baldwin]

I have looked through that thread and collected the updated exe. Like you I am puzzled by Charlie's phase 1 cabs. I will continue to work on the problem. I have come close, but not close enough.