Elvas Tower: LOAD_METER, TRACTION_BRAKING, AMMETER issues - Elvas Tower

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

LOAD_METER, TRACTION_BRAKING, AMMETER issues Rate Topic: -----

#1 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 18 May 2017 - 09:26 AM

I was trying to get a solution for this https://bugs.launchp...or/+bug/1691251 , and by doing so I stumbled into a list of issues related to the above cabview displays:
- in fact, as the bug reports, tractive effort gauges when DirIncrease is set at 1 are not shown; committed in x.3856.
But I found a list of other issues that came out by trying to let the complete .cvf file work:
- always when DirIncrease is set at 1 and the gauge is horizontal, the gauge is displaced vertically in a way proportional to its value; committed in x.3855
- for LOAD_METER gauges, the positive and negative colours are exchanged when DirIncrease is set at 1; still to be solved in a neat way;
- for all gauges except LOAD_METER, TRACTION_BRAKING, AMMETER, AMMETER_ABS the value of the physics variable is compared with the ScaleRange values, and so the length of the gauge is determined; incoherently with this, and also with MSTS, for the above four gauges there are cases where the ScaleRange values determine also the maximum value that the physics variable can reach, which does not seem correct; the result is that the lenght of the shown gauge is not the right one. This point is more difficult to be solved; committed for LOAD_METER in x.3857; committed for TRACTION_BRAKING in x.3858
- in the code related to such four gauges there is a clause checking if LocomotiveAxle is defined for such locomotive; from the code I see that LocomotiveAxle is always not null in locomotives; so I wonder whether this is a relict of old times. unused code removed in x.3857


Which units of measure are foreseen for LOAD_METER? Only Amps? and which units of measure are foreseen for TRACTION_BRAKING?
Experiences of people using or developing content with such gauges and ideas on how to proceed by developers which were involved with such code are welcome.

22/5/2017: text changed after first commits

#2 User is offline   superheatedsteam 

  • Conductor
  • Group: Status: Contributing Member
  • Posts: 497
  • Joined: 28-June 08
  • Location:Perth, WA
  • Country:

Posted 19 May 2017 - 06:53 PM

Firstly, thank you for your continuing work on OR. I very much appreciate what the developers are doing with OR.

I modelled the AC6000CW locomotive as once used by BHP Billiton in Australia. These locomotives display the tractive effort in Kilo Newtons (kN) for both motoring and dynamic braking. My reference photos show US locomotives using Kilo Pounds (Klb). It is my understanding that operators can have a degree of customisation of their displays so there may be other units of measurement used.

On the real locomotive I modelled, the drivers video display has a 'digital' gauge as well as a 'solid' (bar) gauge that displays the amount of tractive effort. The 'solid' gauge moves to the right of it's 'central' position to display increasing motoring tractive effort and moves to the left of the 'central' position to display increasing dynamic braking tractive effort.

MSTS would not correctly display the above behaviour using 'normal' gauge values so I created a post at the trainsim forums asking for assistance in this matter:

https://www.trainsim...ight=load_meter

I was not the only one to experience this problem. The above post describes in more detail the issues as well as the suggested work around that resolved this problem in MSTS.

Your post has prompted me to test this locomotive in OR (x3757) and I find that the tractive effort 'solid' gauge does not work the same as in MSTS. In OR, when displaying motoring tractive effort, the 'solid' gauge works correctly. However when in dynamic braking, the 'solid' gauge moves to the right of the centre position instead of the left. In addition to this, with each notch of dynamic braking, the 'solid' gauge displays the correct amount of braking tractive effort up to notch 4. For each notch above 4 the tractive effort, the 'solid' gauge shows progressively decreasing amounts of tractive effort even though the 'digital' gauge show the correct increasing tractive effort.

If you wish to download the model from trainsim.com the file name is bhp_ac60.zip. The direct link below may work.

https://www.trainsim...right&fid=27447

Please note that I am not suggesting in any way that the OR code be changed to support a MSTS kludge solution. The AC6000CW above is designed to work with MSTS and only with MSTS.

In my opinion the OR code should be written with the future in mind so that OR content creators can create cabs with gauge functions that work logically and correctly, unlike MSTS. Content creators and end user community can modify existing MSTS eng/cvf/sms files to suit new and evolving OR code as required.

I hope this helps. Once again thanks for your hard work.

Cheers,

Marek.

#3 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 20 May 2017 - 02:07 AM

Here the problem is not to imitate MSTS, but to do things correctly, which in this case (and not only this, even if not always) corresponds to what MSTS does.
At the moment, inspecting the OR code, if e.g. you change units of measure of TRACTION_BRAKING from KILO_LBS to KILO_NEWTONS you get the same value!
I would like to have some explanation on the meaning of TRACTION_BRAKING and LOAD_METER before considering intervention on the code.
The following is as I assume that things are. If it is not correct, please correct me.
TRACTION_BRAKING: When the engine is in traction, the value of the tractive force should be displayed, while when it is braking, the value of the braking force (air brake force + dynamic brake force) should be displayed; both must be displayed with positive numbers.
LOAD_METER: its unit of measure is always AMPS. It shows the total amount of current absorbed by the motors or generated by them. So air brake force must not be used to compute it. LOAD_METER is represented by a signed number. As OR computes the current deriving it proportionally from the generated force, in case of traction the proportion should take into account MaxCurrent ( 1800A ), while in case of dynamic braking it should take into account DynamicBrakesResistorCurrentLimit.
What should be the difference between LOAD_METER and AMMETER?

P.S. First fixes uploaded in x.3855, x.3856 and x.3857 as described in first post. Now Marek's problem should have been corrected. I hope I haven't introduced new errors...
TRACTION_BRAKING scaling is still to be corrected. I've found in an old bug report a proposed bug patch by J. Realmuto about the problem of the different units of measure of TRACTION_BRAKING, that he already had recognized. I'll use it as a basis for my foreseen patch.

#4 User is offline   superheatedsteam 

  • Conductor
  • Group: Status: Contributing Member
  • Posts: 497
  • Joined: 28-June 08
  • Location:Perth, WA
  • Country:

Posted 20 May 2017 - 10:02 PM

Wow that was quick. I have downloaded x.3857 and can see the changes as you describe. Thanks for that.

As I understand it, TRACTION_BRAKING is the total amount of resistive force that the traction motors provide when they are in dynamic braking mode. I do not think any friction braking should be included in this value.

I am not an electrical engineer so the following are just my amateur observations of MSTS gauges.

The LOAD_METER is used in the Kuju Dash9, GP38 and SD40 to display AMPS in Diesel/Electric locomotives.

The AMMETER is used in the Kuju SERIES 2000 and SERIES 7000 to display AMPS in the Electric locomotives.

I therefore assume that LOAD_METER = AMMETER. Both measure the current draw of the traction motors. I don't know why Kuju differentiated between the two electrical systems.

Cheers,

Marek.

#5 User is offline   hroch 

  • Fireman
  • Group: Status: Active Member
  • Posts: 198
  • Joined: 05-June 14
  • Gender:Male
  • Simulator:MSTS OR
  • Country:

Posted 21 May 2017 - 01:47 AM

Hi,

On diesel-electric locomotives is a difference between the traction generator current and the traction motor current. MSTS/OR has no model of traction generator.

#6 User is offline   RTP 

  • Conductor
  • Group: Status: Active Member
  • Posts: 254
  • Joined: 14-June 09
  • Gender:Male
  • Location:Barcelona
  • Simulator:Open Rails
  • Country:

Posted 21 May 2017 - 03:25 AM

Usually, the ammeter shows the current in ONE motor.

Regards.

#7 User is offline   Csantucci 

  • Member, Board of Directors
  • Group: Status: Elite Member
  • Posts: 6,986
  • Joined: 31-December 11
  • Gender:Male
  • Country:

Posted 22 May 2017 - 02:29 AM

Thanks for useful replies.
TRACTION_BRAKING scaling bug committed in x.3858.

#8 User is offline   darwins 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,222
  • Joined: 25-September 17
  • Gender:Male
  • Simulator:Open Rails
  • Country:

Posted 11 August 2019 - 07:39 AM

Hello,
Can I just clarify from the. above, that at present OR does not show any current on an ammeter or load meter due to dynamic braking.
Having just tried

Gauge (
Type ( AMMETER GAUGE )
Position ( 370 271 11 44 )
Area ( 0 0 10 5 )
Graphic ( ..\\..\\common.cab\\em1-em2\\pointer.ace )
Style ( POINTER )
ScaleRange ( -500 1000 )
ZeroPos ( 0 )
PositiveColour ( 1
ControlColour ( 0 0 0 )
)
NegativeColour ( 0 )
Orientation ( 1 )
DirIncrease ( 1 )
Units ( AMPS )
)
I have noticed that when applying the dynamic brake the reading does not go below zero.


#9 User is offline   steamer_ctn 

  • Open Rails Developer
  • Group: Status: Elite Member
  • Posts: 1,879
  • Joined: 24-June 11
  • Gender:Male
  • Country:

Posted 11 August 2019 - 04:57 PM

View Postdarwins, on 11 August 2019 - 07:39 AM, said:

Can I just clarify from the. above, that at present OR does not show any current on an ammeter or load meter due to dynamic braking.
Having just tried
Is this in the MG or Mainstream version of OR?

Thanks


#10 User is offline   darwins 

  • Superintendant
  • Group: Status: Elite Member
  • Posts: 1,222
  • Joined: 25-September 17
  • Gender:Male
  • Simulator:Open Rails
  • Country:

Posted 15 August 2019 - 09:34 PM

This seems to apply to both MG and X1.3.1

Page 1 of 1
  • 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