[Serana]

Hi,

During the creation of my TCS script, I was thinking about how to model the high voltage circuit breaker, or the traction relay on diesel-electric locomotives. Why ? Because signalling systems do not order the pantograph to go down, but instead open the circuit breaker or the traction relay in order to cut the power (and I mean all of the high voltage part of the train : traction, compressor, air conditioning, etc.).

I saw in the code, that the "electric" part of the circuit breaker (or traction relay) has already been implemented : it is called "PowerOn" !

But currently, PowerOn's value becomes True when at least one pantograph is up, or when the diesel engine is turning and the fuel tank isn't empty.

I would like to add the possibility for the player or the TCS script to cut the power without bringing the pantograph down or stopping the engine.

So first, I would like to know if there is a key that is available for this.

Also, I would like to simulate the multiple possibilities to command the circuit breaker (CB) like in the reality.
There are several way to command the CB :
1) A switch that allows the CB to close automatically. (Most of the locomotives use this)
2) A switch that gives the authorization to close the CB, and a push button to command the closing of the CB. The CB opens if the switch is switched off. (SNCF and Alstom system)
3) Two push buttons : one to close, the other to open the CB. (RATP (Paris) system)
4) On diesel-electric locomotives only, one push button to close the traction relay... which stays always closed.
Of course, the TCS can force the opening of the CB or traction relay.

How to model this in OR ? For each system :
1) Push [Key] to switch on or off the CB.
2) Push [Key] to switch on or off the authorization. Push Shift+[Key] to close the CB.
3) Push [Key] to open the CB. Push Shift+[Key] to close the CB.
4) Push Shift+[Key] to close the traction relay.

Of course, if you know other possible commands, please tell me what they are.

The behaviour chosen by the creator will be selected in the ENG file with a new parameter (maybe ORTSCircuitBreakerType).

I will also add an option in the Menu in order to disable this new behaviour... :mshk:

Bye !

[PA1930]

This would be very nice if one could make "neutral zones" in the routes themselves to work for real. I've seen routes using the signals and objects related to those, and on MSTS you end up just lowering and raising the pantograph when in real life, many of the cases you just need to switch off the "main switch" while passing through those neutral sections. :mshk:

[Serana]

Oh, and I forgot : the TCS can also open and close the circuit breaker (and make the pantograph go down).

Sometimes, it's just a security system : if the driver forgets to open the CB or lower the pantograph, it does the needed action and sets a penalty timer. It's the case for KVB, TVM300, TVM430 (pantograph only).

It can also be an automatic system for the CB only : the CB closes when the neutral sections has been passed. It's the case for TVM430.

Finally, it can be a totally automatic system : the pantograph can be raised by the TCS. It's the case for SILEC and KVB in Ile-de-France (Paris), and ETCS (depending on the rolling stock ability, it can fallback to the previous cases).

In all of these systems, the information come from balises on the track. We'll have to wait until they are available in OR.

[RTP]

In some neutral zones, like the ones between the 25KvAC and 3KvDC in high speed lines you must put both the pantos down in order to avoid short circuits.

Also, both line breakers must be opened.

Cheers.

RTP

[Serana]

Sometimes you don't have to lower the pantograph when changing the voltage.

Two examples :
French line Nantes - Chateaubriant : when you exit Nantes station, you get a cut power announce, a cut power execution, a voltage change to 750V DC (from 25000V AC) and an end of power cut.
At Modane : you get the same sequence from 1500V DC and 3000V DC (Frejus tunnel to Italy).

Let's look at the pantograph used in both cases.

All the trains that go from Nantes to Chateaubriant are tram-trains. They have a common pantograph for 750V DC and 25000V AC.

At Modane, there's two cases : common pantograph for 1500V and 3000V (Italian trains and TGV) or separate pantographes (French international locomotives).
The speed there is low so there is no need to make a difference between the two cases.

On high speed lines, the pantograph is lowered at most separation sections (voltage changes)
Well, Germany doesn't do the same as the other European countries... :whistling:
On TGV, on the 25kV pantograph, a mechanical stop is added on HSL. You needed to lower the pantograph in order to put the stop.
On more modern TGV, it changes the control loop of the pantograph pressure. So in order to avoid any weird behaviour when entering a line with constant height overhead wire, the pantograph is lowered.

What's the conclusion ? It depends on what the trains are supposed to do at these neutral sections.

And it's obvious that you have to open the circuit breaker before lowering the pantograph. A pantograph has a limited breaking capacity, whereas the circuit breaker... has obviously a high breaking capacity. But if the circuit breaker has melted, the pantograph can still be lowered in emergency.

Long explanation finished ! :rolleyes:

[Matej Pacha]

Hi fellows,
first of all, I think it's a really good and easy to do feature that should be implemented in future versions of ORTS.
Just to be clear about agreements and follow the project leaders decissions:
- are we allowed to add these ORTSNewParameters into ENG files?
- are we allowed to add a new key command to control the traction? For most of the rolling stock, users will not be affected until they add this new ORTS parameter into their ENG file.

Now back to the circuit breaker feature:
1) I agree that the circuit breaker has a different function from pantographs, but I believe the "P" key has a circuit breaker function built-in.
2) If we implement this feature, how will it affect the control routines of the locomotive? What about multiple-unit locomotives with no circuit breaker parameter? In real world, there is usually a mode switch with selection of single/multiple unit operation. Or, you can control the breakers independently.
3) I'm familiar with most of diesels produced in Middle Europe, which are based on Russian diesels, which are based on US diesels (believe or not). There is something like a circuit breaker, but it is controlled by the throttle controller in most of cases. Very simple - if you set the first notch, the traction circuit would be "built" by switching on all the contactors. Setting the throttle controller to zero leads to the contactors switched off (with some time period to let the diesel engine to cut off the fuel). In emergency cases - if the contactors are disconnected at full throttle, with no time period, the diesel engine load will drop to zero, what leads to the RPM overrun and to the engine to stop completely (engine overspeed protection). In ORTS, we should simply set the throttle to zero for now.
4) If we are talking about modern diesels with AC/AC power transmittion, there is usually no circuit breaker. The function is emulated by the control system.
5) The electric loco's circuit breaker operation procedures are different around the world. In Czech rep. or in Slovakia, the circuit breaker is the main protection of the locomotive and it should be ready to breake the circuit (switched on) when the pantogtaph goes up. If passing a neutral section or a splitter, pantographs are lowered to avoid arcs.
6) The circuit breaker's main purpose is the overcurrent protection. Other protection functions are connected with other protection systems of the locomotive, such as overvoltage, undervoltage, traction inverter failure, fan failure, emergency brake, train control system, etc.

Anyway, Serana, if you have your scriptable train control system workin, have you considered to make a scriptable physics? Well, if you are interrested, there is a document of future ORTS physics structure - the blocks could be well scripted, I guess.

Best regards,

Matej

[gpz]

Serana, on 23 March 2014 - 01:42 PM, said:

So first, I would like to know if there is a key that is available for this.

Also, I would like to simulate the multiple possibilities to command the circuit breaker (CB) like in the reality.
There are several way to command the CB :
1) A switch that allows the CB to close automatically. (Most of the locomotives use this)
2) A switch that gives the authorization to close the CB, and a push button to command the closing of the CB. The CB opens if the switch is switched off. (SNCF and Alstom system)
3) Two push buttons : one to close, the other to open the CB. (RATP (Paris) system)
4) On diesel-electric locomotives only, one push button to close the traction relay... which stays always closed.
Of course, the TCS can force the opening of the CB or traction relay.

How to model this in OR ? For each system :
1) Push [Key] to switch on or off the CB.
2) Push [Key] to switch on or off the authorization. Push Shift+[Key] to close the CB.
3) Push [Key] to open the CB. Push Shift+[Key] to close the CB.
4) Push Shift+[Key] to close the traction relay.

Of course, if you know other possible commands, please tell me what they are.

There is one more command that should be added: switch ventillation/cooling on-off. This feature can be switched separately on older locomotives.

There is no dedicated key for these features in OpenRails/MSTS. But I think a key already used for some steam operations can be overloaded, if there would be an agreement on this by the team.

[gpz]

Matej Pacha, on 23 March 2014 - 11:14 PM, said:

have you considered to make a scriptable physics? Well, if you are interrested, there is a document of future ORTS physics structure - the blocks could be well scripted, I guess.

For implementing scripting for physics, first of all the problem must be defined the script should solve, and considering if the problem to be solved is really so widespread among the different locomotives of the world, that it is not worth including into the main program code. If it is such a problem that from the solution most world locomotives can benefit, than it must be kept in the main code, and shouldn't be moved into a script.

Afterwards an API must be defined for the problem: what input parameters it needs and how the result should be communicated back to the main code. If you have a specific problem or type of equipment that you think should not be kept in the main program code, I can assist you technically to implement a scripting possibility for that. The current scripting framework in OpenRails can theoretically drive any area of the program, including physics.

[James Ross]

Matej Pacha, on 23 March 2014 - 11:14 PM, said:

Just to be clear about agreements and follow the project leaders decissions:
- are we allowed to add these ORTSNewParameters into ENG files?
- are we allowed to add a new key command to control the traction? For most of the rolling stock, users will not be affected until they add this new ORTS parameter into their ENG file.

AFAIK, the current rules are:

• Additional data may be added to MSTS content files provided it is prefixed with "ORTS" and it does not impact the content working in MSTS.
  
• Behaviour without additional data defaults to the closest MSTS approximation that in sensible to use.

So I think you're okay to add some ORTS-parameters that enhanced the rolling stock in some way.

[Serana]

Hi,

To answer to the message of Matej :

1) It's maybe the PowerOn function you're talking about. As I said in my first message, PowerOn's value becomes True when at least one pantograph is up, or when the diesel engine is turning and the fuel tank isn't empty. It's probably this function that I will modify (in MSTSElectricLocomotive and MSTSDieselLocomotive).

2) Well, you're not supposed to mix different types of locomotives. In the reality, if you do that, the locomotives of the same type as the leading one are working while others are wagons because the multiplexing or communication system is often incompatible between those different types.

3) I think these traction contactors only affect the traction, not the auxiliaries. So it's a bit like the traction relay I talked about, but with a different type of command.

4) That's a bit weird because I think there's a standard (EN or something like that) that says that contactors are mandatory (circuit breaker or relay) for security reasons.

5) That's also weird because the system must detect the presence of a correct voltage before closing the circuit breaker. Alstom, Siemens and Bombardier apply this rule (or EN standard).

6) Even if the overcurrent protection is integrated into the circuit breaker, its electrical or pneumatic command is always linked to the over or under-voltage protection and TCS emergency braking. If at least one of the conditions is not true, the circuit breaker isn't allowed to close.
Fan failure is either answered by an emergency braking of the driver (on older locomotives) or a current limitation by the control units.

For the scriptable physics, indeed, most of the time the laws are the same. I would like to see a case where an extension is needed before beginning the implementation of the API.

I am working also on the BrakeController. The interfaces were not really used.
Abstract classes would have been more appropriate here, but anyway... maybe I'll send you an UML model about what I'm thinking about.
For now, I'm modifying IController and IBrakeController so as to include all of the functions that are used in MSTSLocomotive, Message, etc.
In MSTSLocomotive, the brake controllers will be using the IBrakeController type instead of MSTSBrakeController.
Secondly, I'm developing a pulse brake controller.
I'll talk about it in another topic I'll write this evening.