A couple of questions from a newbie

[Domino78]

I have started to play with this simulation this afternoon, and I have a couple of questions...

I started the timetable on Monday, around 5:00 (tried a couple of times).

1.) On track 24 there is the 7204 standing with a shunt driver. Can't change the shunt driver to train driver, why? I have tried to give the orders via yard master and phone too, but the orders disappear.

2.) Can't set train route from N24 in direction 101 - why? According to the blinking pink circles it should work. Do I need to take additional special actions? OHLE...

3.) I tried to set exit for 7204 from N24 towards 041; after clearing the N24 I revoked the route. The status and location of 7204 did not change (Ready for dep., Gleiss 24), but the occupancy (red dashes) disappeared from the panel. As next step I could set a route from ESig G to Gl. 24 and accept 7203 without problems. According to the TC occupancy lights 7203 crossed the "ghost" 7204 and pulled up to the end of the track. According to the Train overview window both trains were standing on Gl.24. This happened once, could not repeat...

4.) I have tested the route settings and releasing from ESig. G to several targets. It seems that there is a mix between shunt and train routes. If I first set a shunt route to the target signal, then I overset it with a train route, I can reset the entire train route by resetting the shunt route with FRT instantly, uncounted, with train approaching(!!!). Is this intentional?

5.) After revoking a route from ESig. G once the base lamp (Festlegemelder - I don't know the English name:) remained on. A route from the signal could be set, but the signal did not clear (although the shunt signals did clear along the route). Finally I could reset the Festlegemelder with SBRT. What does the Festlegemelder without a route mean?

6.) Differing from other shunt signals setting a route from W61 to any targets W61 does not clear (only tested without train) - is it intentional? Are there different kind of shunt signals?

7.) Fleeting can be enabled on several signals (without feedback lamp); this will lead to warning buzzer in case if a train is approaching to the signal. Is this intentional?

8.) Gs III does not close after revoking a route from 22 to W65 - is it intentional?

And finally a general question:

8.) What is the purpose of the black buttons placed on straight tracks (not the switch-buttons).

9.) What is the rationale behind overlap-handling? I mean revoking overlaps always needs the handle of DHT (which is counted therefore needs to be documented), even when the route itself can be reset with FRT.

- If there is train approaching, I anyway need to use (and document) the FHT, this could reset the overlap too (overlaps make no sense without route);

- If there is no train approaching, no documentation needed for resetting the route, it would be logical to be possible to apply DHT to the overlap too.

[Domino78]

...and here we go again!

Andernach has the same bug with the overlap releasing, as Braunschweig. I mentioned this oddity more than a half year ago, but I did not receive reply. Is it a bug or a "feature"? Is there any bug list, where I can check/report things?

It would significantly simplify the communication with the customers, if there were an official forum with

- the actual version;

- maybe a version history;

- a bug list on three languages,

...so everybody could check if he/she has the last version, and if the bug was reported before(regardless of the language). This would preclude the answers like "this was already reported in German"

[signalsoftRC]

I read a mixture of bugs/operating errors and vague things... But also something like "not having the latest version"...

Note that a train route is first set up as a shunt route. after all safety things are ok, it's "upgraded" to a train route. Though you don't see a difference on the panel! (beside the square light at the start signal).

For a train route, FIRST the overlap route must come in. (and that's a train route safety level!)

So you can have the situation, where the overlap route must be revoked with a DHT, and the train route towards it with a FRT as it has not made it up to a train route yet.

In normal cases, an overlap route releases automatically (when last switch was cleared!) the blinking light indicates the timer running. Just wait until the timer is out. In case it does NOT blink, the overlap route can't release (last switch still occupied?). If you MUST release the overlap (rare case!), you need DHT.

In other cases you need DRGT + FRT + ST (last two within 5 secs from DRGT)

Read the Wiki please for more information.

Also: you are sure that you have the latest version if in the start screen doesn't show the "there is an update available for you". If that message is not there, you have the latest version you're eligible to. (if you didn't register, you won't have that message!)

So there is no need for a list of latest version. it's working fully automatic. Just like in Windows.

Writing a full version history/bug list... sorry, simply don't have the time for that! (That's a LOT of work to do that in three languages) Most of the bugs are such minor issues, some are bigger and if we solve them

Did you try Huerth yet? Same issues there? (don't think so)

We're working on an Update of Andernach. but a tiny bug prevents us from releasing it at the moment.

[Domino78]

Hello and thaks for the fast reply.

I read a mixture of bugs/operating errors and vague things... But also something like "not having the latest version"...

Well, let's say, I like to test things, I'm a programmer too. And the aim of an interlocking system is to protect the system from dummy/evil people

Note that a train route is first set up as a shunt route. after all safety things are ok, it's "upgraded" to a train route. Though you don't see a difference on the panel! (beside the square light at the start signal).

For a train route, FIRST the overlap route must come in. (and that's a train route safety level!)

If you revoke one of the shunt route-fragments already upgraded to train route, sometimes it will revoke the entire route, even if it is occupied

When a train is leaving an occupied overlap, sometimes it will release the overlap, but not its own route.

If you think that it would help debugging, I can capture screenshots with moving trains without route, real SPADs, trains leaving route fragments locked, and describe how I generated them.

Anyway, regarding the overlap, thank you for the information, It seems that I forgot the DRGT

Also: you are sure that you have the latest version if in the start screen doesn't show the "there is an update available for you". (...) it's working fully automatic. Just like in Windows.

Regarding the "Just like in Windows" update thing: for Braunschweig it took more than two weeks together with the developer to find the bug in the automatic update part (it was a Microsoft-bug), he wrote a custom-made update program for me. Unfortunately I have no feedback if other sims also have this bug, or if it was corrected since then... For Andernach I have 2.0.2.2 and it says that there is no update.

Did you try Huerth yet? Same issues there? (don't think so)

I quickly installed it and tested (only for the bug#4, which seems to be the most serious), it can be reproduced.

[signalsoftRC]

1. the german system do NOT protect 100% for dummies/evil people. Unfortunately. But it's hard to do it wrong. (and sometimes very hard to do it right!) The dutch/american GRS panels are idiot-proof. You can't do it wrong.

2. screenshots normally not needed. a step by step reproduction suffices. (and the step you would expect to be different)

3. Overlaps "can't be occupied". The route before the target signal would not come in then. Only when the overlap route is available, the route will come in.

4. note that the purple/yellow rings may INDICATE that it may work or not. As many things that are checked AFTER the route is called, we cannot predict if a route is going to be successful or not. (It's a notorious thing of the german system)

5. I found the issue with operating the FRT on a start shunt signal/end signal. It was missing a condition to see if it was a train route or not. (the condition was there, but disabled for testing... forgot to turn that on again :-))

6. The routelock indicator (square light) indicates that the "train safety level" on the route has been achieved and the signal can be cleared. In the Siemens system it does NOT go off, in case the conditions are NOT met AFTER it came on. (it won't go off...)

[Domino78]

1. Ach so! I remember, I heard rumors that back in the '50s when we (Hungary) bought the license for our Domino55 (Integra-based) interlocking system, we had to modify it because it did not fully met the Hungarian safety requirements.

3. Let's say we have three adjacent signals: A(home) - B(starter) - C(first block). And we have two trains: 1234 has just left signal B (route B-C set, locked), 5678 is waiting in front of A. Now I set the route A-B, the system checks it, locks it, the routelock indicator of A goes on (train route), A stays ON. As 1234 is departing, it will free up the overlap of A-B behind B, but it also revokes the overlap (I would expect keeping the overlap locked by A-. As 1234 passes C, it will NOT revoke the remaining part of B-C. As result we will have a train route A-B locked (without overlap), and a B-C partially locked (first half of B-C, the overlap of A-B is released, but the rest of B-C still locked). This seems to be a bug.

=5678=A=1234=B========C========D====== - Route set for 1234; 5678 is waiting for A to clear.
=5678=A------B=1234===C========D====== - 1234 is leaving;
=5678=A======B=1234===C========D====== - I set A-B for the 5678 - route locks, routelock ON
=5678=A======B---1234=C========D====== - A-B set for 5678, 1234 releases the overlap of A-B.
=5678=A======B---=====C===1234=D====== - 1234 passes C, but does not release the rest of B-C
=5678=A======B---=====C--------D=1234=

5. I'm happy that I could help This applies both to Braunschweig, Andernach and Hürth, doesn't?

6. OK., now it's clear. Once I could revoke a route without clearing the routelock indicator, but I can't reproduce it anymore...

[signalsoftRC]

1. wise decision!

3. you may NOT set the route AB before the overlap after B has been cleared! AB will not run in and "hang".

The condition for a route is that the overlap is not occupied!

5. Huerth and Andernach have just been updated. No FRT issue there :-) (And new level crossing functions :-))

[Domino78]

3. OK., this was new information. This means that in this case the routesetting is not inhibited by the interlock system, but it will lead to an "unhandled exception", therefore it is not allowed? So this "feature" is one of the SpDrS60's non-idiot-proof features?

5. It seems that Hürth and Andernach both have the same .NET framework bug, as Braunschweig (the update wont work on my computer). Should I contact Charlie again?

[michaels]

3. Unfortunately true. This only works for exit routes: If no locked switch has to be thrown, an exit route will run in after the exiting train (of course, the exit signal will only show proceed aspect when the route is entirely cleared). For routes leading into the station, you indeed have to wait until the exiting train has cleared at least a part of the overlap. Otherwise you will run into the described situation (route runs in, but without overlap, and has to be revoked and set again).

Anyway, the further parts of B-C as shown in your scheme SHOULD be released (I think), no matter if you set A-B before or after the overlap is cleared...

[signalsoftRC]

3. remember that a routesetting starts with everything set as "shunt" level safety. There are very few checks there (switches correct and directionality). At that moment you CAN press the buttons and "call the train route".... but the route will NOT come in properly and "hang".

The German system does NOT prevent happening this and it is a cause of lot of trouble, misunderstanding and LOTS of regulations around this.

And no you should not see any "unhandled exceptions" that's a programmatic thing. But i'm currently not aware of any exceptions in regards to the interlocking.

[Domino78]

And no you should not see any "unhandled exceptions" that's a programmatic thing. But i'm currently not aware of any exceptions in regards to the interlocking.

Yes, i meant "unhandled exception" in a relay logic style

Anyway, finally I could update the sim (together with Hürth - thanks again, Charlie), and I have to update my original question#8 too

Apparently the small black buttons turned brown after the update. But what are the small brown buttons exactly good for?

Oops, I have just noticed, that there are still a couple of black buttons too. What do they do exactly?

Thanks!

[signalsoftRC]

http://signalwiki.signalsimulation.com

(if you can't find it in the english part, simply go to the german part and use a google translator (and have good laugh as well))

http://www.railsignalling.org/signalwiki/index.php/Achsz%C3%A4hlgrundstellungstaste but it's doing a relatively decent job :-)

[TjoeTjoe]

Or in English (I knew I had done this one ;-)

Wiki - Axle_Counter_Reset_Button

The SignalWiki structure is a bit under (re)construction so the linking is not completely as it should be

There is a new page discussing all the group buttons : Wiki - Group Buttons

It is currently only accessible from the Manual page (English). Will also add a link on the English Sp Dr 60 S page.

Sorry for the inconvenience anyway.

It is just a lot of work (during evenings /weekends) to get it all in the German-style-structure as done per Michael

The brown dotted buttons on the panel are where axle counters are installed, and have to be pressed together with AzGrT button if those fail and need to be resetted, and thus clear the track occupation.

Note that they may also be needed, like the normal black ones, i.e. to revoke a route if some rare events

Erwin

[Domino78]

OK., thanks for the links! German is not a problem, weil ich ein bißchen auch deutsch verstähe

Have the black buttons the same function?

Regarding the update, now the function of the FRT, FHT, DHT is much clearer. It seems that the overlap-problem was also corrected, and the fleeting problem has also gone.

One question regarding the ZNP801: how can I delete a wrong train number offered? The neighbor has accepted the train. ZNL does not work. Even if I offer a new train, the old (wrong) train number remains in the berth and starts blinking, finally the neighbour refuses the new train (but the berth does not clear).

[TjoeTjoe]

OK., thanks for the links! German is not a problem, weil ich ein bißchen auch deutsch verstähe

Have the black buttons the same function?

Regarding the update, now the function of the FRT, FHT, DHT is much clearer. It seems that the overlap-problem was also corrected, and the fleeting problem has also gone.

One question regarding the ZNP801: how can I delete a wrong train number offered? The neighbor has accepted the train. ZNL does not work. Even if I offer a new train, the old (wrong) train number remains in the berth and starts blinking, finally the neighbour refuses the new train (but the berth does not clear).

As you do understand a bit of German, try this:

See topic : Gelsenkirchen - Fragen & Antworten - ZNP801

Anyway, something like this should work ...

12345 AND 038 and then ZNL-key for A038

12345 AND 111 and then ZNL-key for A111

12345 is the example for the train you previously offered and is still in Train Number window (1=Steering number, remaining=2345=train number)

Let me know if it worked. Honestly I never tried it myself for the KAND simulation. It worked for EG and KB.

Edit : Ah, even that is in the Wiki : Wiki - ZNP801 under Cancelling an offered train

Erwin

[Domino78]

Or in English (I knew I had done this one ;-)

Thanks for the link! I really appreciate the huge work you invest into the wiki and the manuals. In the last five years I got used to another great simulation family, which is also quite professional, but has almost zero documentation. Now I have to get used to the existence of the documentation too

[Domino78]

Anyway, something like this should work ...

12345 AND 038 and then ZNL-key for A038

12345 AND 111 and then ZNL-key for A111

Sounds logical. And it really works. Thanks!

[TjoeTjoe]

Thanks for the link! I really appreciate the huge work you invest into the wiki and the manuals. In the last five years I got used to another great simulation family, which is also quite professional, but has almost zero documentation. Now I have to get used to the existence of the documentation too

You're welcome.

For the records #1 : Richard did the ZNP801 story

For the records #2 : it is not just me spending a lot of time on the Wiki, we also have SpDr60 , Michael, Charlie and Richard.

For the records #3 : yes, it is a lot of work, but even I learn from it and hopefully a lot of others do so too.

For the records #4 : documentation is one of the fundemental things needed to understand and be able to work with these advanced simulation series

For the records #5 : it must said as well, that the Signalsoft team do all they can, with the limited they have, to support the Wiki team on improving it

Erwin

[michaels]

*THUMBS UP*

[Domino78]

Just saying: the problem of the non-reversible lines (discussed in topics "Directions of non-reversible lines" and "Erlaubniswechsel mit Rbf Stw7") applies to Andernach and Hürth too. Nasty bug, it ruins the whole simulation, you have to start a new game (or load an earlier saved sim)...

[signalsoftRC]

I always advise to use the automatic saving option. (saves it every 5 mins...)

The wrong line working has two complexities at the moment:

- which type of written order to use (as there are many variants between 1975 and 2011...)

- coupling sims/communication with neighbour stations.

The latter is right in development and hence Andernach and Huerth have problems in going wrong line. You CAN do it, but have to stick to a very particular way of working.

[Domino78]

Oh, I wanted to ask already... Now we have two possibilities to offer trains for the neighbour: on the phone and via ZNP801. Which should be used in which case? It seems that there is a mix-up between the two systems: if I offer a train on the phone, the number of the offered train appears also in the berth of the wrong line (but faulty?): if I offer train 1234, it will appear 1 234 (where 1 is the direction identifier). I'm wondering, how the ZNP801 knows what I am speaking on the phone; is there a bug built in the telephone? >

Regarding the direction of the non-reversible lines, there are still a couple of points which I don't understand.

If I understood well, even the non-reversible lines have directions on the interlock-level, which for me seems to be wrong. I suppose in the "real life" the interlocking system is unable to manage the direction of these lines, this is why they have no dir. buttons, and wrong line working is managed on a higher level, protocol-based (written order, phone, etc.). In the simulations mentioned above the interlocking system has the ability to intercept my telephone calls and change the direction of the line (or the neighbour AI does it?). But I have no device to change back the direction on interlock level (perhaps because there should be no direction-information on interlock level for these lines). Am I right?

There should be two potential solutions (on programming level), which currently seem not to be clear for me:

1.) make it possible for the interlock system to allow train traffic against the direction (as is in the real life?), this means that the flow will be managed entirely on higher level;

2.) or keep the direction information for these tracks but manage it completely automatic (in other words: direction will follow the train, therefore I don't receive messages to change the direction; this adds an extra interlock to avoid head-on collisions).

In both cases the direction must be managed on a higher level too: on phone, ZNP801, written orders, whatever. The problem of Multiplayer vs. AI neighbours applies to this higher level. But before this, first the interlock-level must be clarified.

Of course this is only my private opinion based on my limited knowledge

[TjoeTjoe]

Oh, I wanted to ask already... Now we have two possibilities to offer trains for the neighbour: on the phone and via ZNP801. Which should be used in which case? It seems that there is a mix-up between the two systems: if I offer a train on the phone, the number of the offered train appears also in the berth of the wrong line (but faulty?): if I offer train 1234, it will appear 1 234 (where 1 is the direction identifier). I'm wondering, how the ZNP801 knows what I am speaking on the phone; is there a bug built in the telephone? >

Maybe your neighbour dispatcher listened very careful to you, and as your ZNP801 was not working (why else would you call him ;-) , he entered the number using his ZNP801.

He just forgot to add the correct steering number.

Personally, I do not consider this a real big bug, it's more like a feature, which is not completely correct

Regarding the direction of the non-reversible lines, there are still a couple of points which I don't understand.

If I understood well, even the non-reversible lines have directions on the interlock-level, which for me seems to be wrong.

I think you are mixing up two things. The functionality of the simulation and the interlock-system built in it.

May be your right, that it is somehow connected with each other. But I am pretty sure that the Signalsoft Team has not implemented bi-directional functionality at interlocking-level on a line with non-reviserable directions (on purpose). And if they did for nowm that have it working, then it is probably just to able to track down what the valid direction of travel is. Also take into account what Richard has said above: they are still looking for a good way (written orders system) to get it properly working.

I suppose in the "real life" the interlocking system is unable to manage the direction of these lines, this is why they have no dir. buttons, and wrong line working is managed on a higher level, protocol-based (written order, phone, etc.).

Even with my limited level of knowledge on this matter, I am pretty sure that what you say here is absolutely right

In the simulations mentioned above the interlocking system has the ability to intercept my telephone calls and change the direction of the line (or the neighbour AI does it?). But I have no device to change back the direction on interlock level (perhaps because there should be no direction-information on interlock level for these lines). Am I right?

Which brings me back again to what I said earlier: simulation-wise some things might have been implemented, to get it working 'safely', whether its right or wrong is out the scope of (my) discussion here, until the simulation-logic to apply written orders for such train movements is there. But as Richard says, it is a pretty complicated matter

There should be two potential solutions (on programming level), which currently seem not to be clear for me:

1.) make it possible for the interlock system to allow train traffic against the direction (as is in the real life?), this means that the flow will be managed entirely on higher level;

I believe that will be the solution in the end, once the written-order-logic to achieve this is implemented. Till then we will have to live with how it currently works

Of course this is only my private opinion based on my limited knowledge

And so is mine. That's where the boards are for

Erwin

[michaels]

If you want to now something about different "methods" of using the wrong track (in reality), you should check out http://railsignalling.org/signalwiki/index.php/Grundlagen#Fahren_auf_dem_Gegengleis .

The first variety is already implemented in the simulation (in case the track is equipped with it). The second one is already prepared and will come soon, see also http://railsignalling.org/signalwiki/index.php/Falschfahrgruppentaste . The third one is not so easy to implement, as Richard already mentioned...

[signalsoftRC]

The complexity is hidden in the requirement for the sims to be able to work with and without a neighbouring signal box (simulation). This means that we have prepped the code for BOTH situations. As we are only currently able to actual linking up two sims with each other (with Remagen and Bad Godesberg and now Bonn Hbf) we couldn't test that stuff before. We didn't want to do all the work twice.

The directionality in the block tracks (between stations) have various types of systems.

The ones WITH the directional setting (the two arrows you can see)

Those ones have various subsystems:

- each party (AI or real neighbour) can only turn the arrow towards him, approving the other party to send trains

- "internal" automatic blocks (one dispatcher operates both sides of the automatic block)

- "autoflippers", directionality depends on first-come-first-serve base (very commonly used in non-german systems), there's one in the Wuppertal-Oberbarmen simulation.

- "backflippers", directionality flips back to default, after train cleared automatic block (used in Cologne)

- "one party operator", directionality is set by ONE party only. (very common in the Netherlands)

- token block systems

- tokenless block systems (UK only)

- RETB block (UK only)

- TPBR block (dutch systems only)

The systems above HAVE influence on the interlocking system. (sometimes only in one direction.... sigh)

The ones with the directional setting without indication are *normally* only used in wrong line working and signalled wrong line working systems (latter one in german routes only).

There are various subsystems there to:

- token block systems (with "pilot")

- plain wrong line working (no interlocking influence)

(and some minor systems, not implemented yet. The French and Spanish/Portuguese have some variants here.)

both have NO influence on the interlocking but on the signalling systems... sometimes...

various written order systems are in use there.

the systems has been implemented for the dutch systems (Hengelo, Arnhem). With the german signalling systems, there are some special things that need to be implemented. (in the older sims like Braunschweig, we don't have the ability to reset a block after a wrong line movement. So it is in a "broken state" after a wrong line movement.

This is very problematic if you don't "own" the block, but your neighbour does. We've thought of various implementations. Difficulty is the fact that we do NOT want to interfere with the code part for neighbouring signal boxes at this moment. (as not to break it)

I wish it was easier.. but it pretty complex.