**ALPHA** OS_ATS in C#

Version 0.216
Changes:

• Added error.log file- This stores any errors encountered on an attempted configuration upgrade.
  
• Added version number to automatically upgraded files- Please delete this if you manually modify the file. (Future use)
  
• Handle existing OS_ATS configuration files with a malformed gearchangesound parameter.
  
• New paramaters as follows:
  

1. wiperswitchindex Sets the panel index for the three position wiper rotary switch. (Use a standard digitalnumber in the panel2.cfg)
   
2. wiperswitchsound Sets the sound to be played once when the windscreen wiper switch is moved.
   

Cheers

Chris Lees

http://www.bvecornwall.co.uk

EDIT: Confirmed, working like a charm. 

I quite like driving Dexter's electrics now that I've got a working config, so I might as well also test the night cab. I'll be at this computer until Friday, after which I'll go away for a couple of weeks.

A quick update on some tested trains and known bugs:
Working:

• Czech 163 (by Dexter)- Upgrades and work largely as designed.
  
• Czech 754 (by Dexter)- Upgrades and work largely as designed.
  

• Class 104 (by BVETMD)- Upgrades and I *believe* works 100%
  
• 81xx (BVE Cornwall)- Supported, and I believe works 100% (Newer version at some stage soon, with a few tweaks)
  

Broken:

• German F92 (by Rudiger Hulsmann)- Not supported, custom OS_ATS version.
  
• Czech 452 (by Vince Black)- Broken, requires fixing (Negative values used for it's ammeter notches)
  

Further Notes:
The upgrade process will not attempt to add new paramaters or 'improve' an existing train.
Trains which use a custom OS_ATS (The F92 & anything using OS_SZ_ATS1.dll) version are at present added to a blacklist, and will require a custom configuration file building.
If you are on Linux, then the case of OS_ATS1.dll and OS_ATS1.cfg must match exactly at present, or the upgrade will fail.

Current Known Bugs:

• Unexpected negative values in any parameter are highly likely to cause crashes or unexpected behavior.
  
• Panel/ sound indices above 255 or below -1 (disabled) will crash the plugin.
  
• Ammeter not implemented for diesel traction.
  
• viglianceinactivespeed not currently implemented.
  
• Key configurations not upgraded.
  
• overheatalarm sound index triggering inappropriately.
  

I'll stick up another version at some stage over the next couple of days which fixes most of these, other than the key configurations & the first two.

I'm also in the process of improving the failed load/ upgrade error log to be more descriptive.
Finally, if you're interested in the source code, I'm also trying to add summary descriptors to most parameters (See the last couple of commits tonight), which whilst not doing anything for the end user will make the task of anyone trying to modify the plugin much easier.
[At some stage I need to redo a lot of the configuration to eliminate unneeded casts between number types, but that's not affecting things at the moment]

Cheers

Chris Lees

http://www.bvecornwall.co.uk

Sir chris leezer
Your work here in language C# is good, though I am very weak programming.
I would like to learn.  Can you make a gracious step to step tutorial how to write C# and how is it said "compile" convert to dll?

Good day and night for you
HK

HijauKuda wrote:Sir chris leezer
Your work here in language C# is good, though I am very weak programming.
I would like to learn.  Can you make a gracious step to step tutorial how to write C# and how is it said "compile" convert to dll?

Good day and night for you
HK

Short answer is that it's not simple

Get yourself a copy of Visual Studio (Not free unless you are a student), or Sharp Develop.
Then get a copy of the source code from GitHub, and load it, adding a reference to OpenBveApi.dll (Found in the route of the OpenBVE folder).
Hitting the build button will then produce a copy of the DLL.

Further than that, I can't really teach you very much. I'm mostly self-taught, and you need to understand the basics of how code works before you can even begin to try playing with plugins really.
If you look at the source code, I've attempted to comment things, explaining what it's doing wherever I can, but you basically need to understand things like the basics of integer versus double arithmetic and passing values around between functions before you'll get anywhere really useful


The attached is a very slightly experimental version 0.218.
Changes:

• Error validation for parameters in the electric section of the configuration file. This only performs a cursory check, and does not check that any input is valid for a given parameter. Errors will be logged to error.log
  
• Eliminated various unnecessary casts between number types in the electric section. This should be a wholly internal change, but again it requires a quick test.
  
• Adds handling negative values in ammeter notches on upgrade. (Simply assumes these should be positive)
  
• overheatalarm fixed.
  
• vigilanceinactivespeed implemented.
  

(Error validation for all further sections and eliminating other unnecessary casts will be done once someone else has verified that things still work.....)

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I have some additional test results concerning both the plugin, and Dexter's new beta 163, so I'm posting here.

I was running the beta 163 (out of the box, no modifications) on the Network West Midland route Maybank - Hobbs Cross (2C89, 23:10 departure), which has the 323 as a default stock. The section gap between Kings Road and Clifton Greenbridge did not open the main breaker as it does on the 323. The blue line voltage light stayed on, and the kV meter still indicated close to 3 kV (although this is a 25 kV AC line...) The 323 uses UkTrainSys.dll, if it makes a difference; however, most of the default stock of NWM uses OS_ATS1.dll, so I'd imagine the track would have been coded in a compatible way.

This is 50% a not implemented feature and 50% a bug in the current train configuration.

To explain:
The main breaker switch & the voltmeters are both keyed off the panel index for the main breaker. What this means is that whenever the main breaker is on, they are lit.

The ACB/VCB doesn't trip on OS_ATS standard neutral sections [It was never a part of OS_ATS], and as both the volts indicator and the breaker switch are keyed to it's panel index in the train settings, the power cutoff is never shown.
UKTrainSys has some additional ACB/ VCB handling code for these; I'll look into adding this.

The attached zip file contains a patched configuration for the beta 363.


Cheers

Chris Lees

http://www.bvecornwall.co.uk

Version 0.219
Changes:

• Parameter validation added to diesel traction
  
• Various unnecessary casts between number types eliminated in diesel traction
  
• If an ACB/VCB is defined, it will now trip/ reset automatically at the beginning and end of an OS_ATS standard neutral section.
  

Cheers

Chris Lees

http://www.bvecornwall.co.uk

leezer3 wrote:The attached zip file contains a patched configuration for the beta 363.

Erm, what exactly has been patched in there?

Specifically:

1. powerindicator & breakerindicator values swapped in BVEC_ATS.cfg (That was an accidental byproduct of my testing whilst I figured out what was going on, but to retain the original BVEC_ATS.cfg you would need to change the subject for ;VOLTMETR & ;AMPÉRMETR HLAVNÍ to Ats54....)
   
2. Main breaker switch (cabview\HV_d.png && night\HV_d.png) ATS subject changed to Ats54 as opposed to Ats53
   

For neutral sections to work correctly, the main breaker and line volts indicators need to be different. You also get a false line volts reading if the breaker is turned on with the pantographs down, which now won't let you move

Cheers

Chris Lees

http://www.bvecornwall.co.uk

OK, I did not spot that, it is a small change.   So, the change you have made makes it work correctly now, or there are some more changes needed? I know about the thing with false volts, but I don't seem to be able to fix that at this point

That should fix both your false volts reading and the neutral sections

If you combine with 0.219, the main breaker will even trip on and off at the start and end of neutral sections.

As a FWIW, this is a rather handy little tool for showing changes between two files:
http://winmerge.org/

Cheers

Chris Lees

http://www.bvecornwall.co.uk

LOL I just hope the gauntlet tool won't mess up any transparent colors.  
But we are straying off topic here.

Yes, now the neutral section works right. The main breaker opens (you can hear it) and the kV needle drops. The blue light ("pantograph is up"?) remains lit.

Also, now you can close the main breaker with the pan down, but the train won't move, and the kV needle remains at zero. Any attempt to raise a pan with the main breaker closed just open the breaker. You have to operate the pan switch a second time to actually raise the pan, which I think is sensible. You can actually lower the pan with the main breaker closed, but I'm under the impression that some (older?) locomotives actually allow that, even though it's not usually a smart thing to do.

jsiren wrote:Yes, now the neutral section works right. The main breaker opens (you can hear it) and the kV needle drops. The blue light ("pantograph is up"?) remains lit.

Also, now you can close the main breaker with the pan down, but the train won't move, and the kV needle remains at zero. Any attempt to raise a pan with the main breaker closed just open the breaker. You have to operate the pan switch a second time to actually raise the pan, which I think is sensible. You can actually lower the pan with the main breaker closed, but I'm under the impression that some (older?) locomotives actually allow that, even though it's not usually a smart thing to do.

If I'm looking at the same blue light, this just shows that the pantograph is raised, which is what I'd expect

The parameter pantographalarmbehaviour governs what happens when a pantograph is lowered with the main breaker closed at speed:
https://bveworldwide.forumotion.com/t1022p30-alpha-os_ats-in-c#11523
The default behaviour is that it simply lowers the pantograph, which is what's happening here.

Thinking about it, it probably needs an option to *deny* the attempt to lower the pantograph, and I've added that to my list.

Cheers

Chris Lees

http://www.bvecornwall.co.uk

I don't think there should be any deny option - though some countries do have strange things... You don't lower the pan at speed and with breakers on for fun - you do it to try and avoid extensive damage if you spot something in the overhead wire. I guess that would be the same in any country with electrified railways...

And here's how they move from a DC to AC wire in India. There are several videos like this.

You don't need to go to India, just look at most of the european borders ;-)

At some system changes you even aren't required by the infrastructure to lower the pantograph - if, of course, you have a pantograph for both the system before and after. See also the system change of the tramtrain in Karlsruhe (that's where tram-trains were invented! Even if the French sometimes like to claim otherwise ) between tram voltage 750V DC and railway voltage 15kV 16.7Hz AC

Version 0.220
Changes:

• Fixed: AWS/ TPWS interventions could trigger on trains they were not fitted to in some cases.
  
• More parameter validation changes.
  

Cheers

Chris Lees

http://www.bvecornwall.co.uk

It's not totally unheard of in the UK to lower pans at speed. I was involved in a trial last year on Greater Anglia where because two of the 4 lines were closed for work, the adjacent line had to have the power isolated.

When leaving Romford the driver would take power like normal, when he/she reached a "PAN DOWN 500M" board shut off power and then by the "PAN DOWN" board the train should be coasting. The train would then coast until Ilford where the train would stop and the pan raised to continue like normal.

A lot of staff were skeptical of this plan, but a lot of work was put in to making sure it was a success - ensuring the train wouldn't be held at signals, train modifications to make the lights stay on under battery power for long enough, and we were confident that if a train came to a halt the power could be switched back on within 20 minutes. A lot of staff expressed their surprise at how smoothly it went afterwards

I haven't forgotten this project. Today, I've been doing a little preparatory work for trying to improve the firing/ driving model a little.
One of the biggest problems with doing this is OpenBVE's inability to display text without resorting to nasty digitalnumber based hacks.

The result looks like this:


It doesn't look like much, but I can pass text messages etc. through to the Advanced Driving window, and for that matter I can make calls back in the other direction
At the moment, all it's doing is displaying the current debug message, but it's easily extended.

(I'm not playing with overlays....)

Cheers

Chris Lees

http://www.bvecornwall.co.uk