simonjackson1964

The longest single span of an individual catenary length on the model is set at 39.73m. Die längste Einzel spannweite einer einzelnen Oberleitungslänge des Modells ist auf 39,73 m festgelegt. Add just 5mm to that length and the centre of the catenary "pops up", requiring an additional support. Fügen Sie dieser Länge nur 5 mm hinzu und die Mitte der Oberleitung "springt auf", was eine zusätzliche Unterstützung erfordert. Is there a reason for this, like a physical limit in the program? Because in real life, a single span can be up to 65m, possibly longer. Gibt es dafür einen Grund, wie zum Beispiel eine physikalische Grenze im Programm? Denn im wirklichen Leben kann eine einzelne Spannweite bis zu 65 m betragen, möglicherweise länger. Google Earth Satellite view, line drawn between two catenary pylons. Google Earth Satellitenansicht, Linie gezogen zwischen zwei Oberleitungsmasten. Is there a way to turn off this "pop-up", because it is impossible for me to put the correct number of pylons on the model to make it as accurate as possible? Gibt es eine Möglichkeit, dieses "Pop-up" auszuschalten, weil es mir unmöglich ist, die richtige Anzahl von Pylonen auf das Modell zu setzen, um es so genau wie möglich zu machen?

Deleted

Trying to find a model to build that is less complicated and can be a bit mire realistic, I settled on Fürstenberg. The station building in reality looks nothing like the model... I'm guessing that the original station building was demolished at some point, and the one there now is a replacement? But after the successful scratch-build below, I might just rebuild the station building myself! There's a building on the island platform at Fürstenberg station, that is not represented in the models. I think I did a pretty good job?

Correction: Evergreen is scaled to 1.2, not 2.0. After all, she has to fit through the Suez canal somehow, ha ha! Korrektur: Evergreen ist auf 1,2 skaliert, nicht auf 2,0. Schließlich muss sie doch irgendwie durch den Suezkanal passen, haha!

Hi folks // Hallo Leute I've often admired the suspension bridge models that @FeuerFighter made, but I can't help but notice that they are a bit twisted. I can't really do much about that, and to be perfectly honest I would never be able to make something even half as good. But what I have done is created a scaled up version of the large suspension bridge. Now just under 0.5km from end to end, and 100m high, it is still on the small side compared to such bridges as the old Severn bridge (1.6km x 136m) or the Golden Gate (2.7km x 227m) it now beats others like the Menai bridge (417m x 47m). Ich habe die Hängebrückenmodelle von @FeuerFighter oft bewundert, aber ich kann nicht anders, als zu bemerken, dass sie ein bisschen verdreht sind. Daran kann ich nicht wirklich viel ändern, und um ganz ehrlich zu sein, ich könnte niemals etwas halb so Gutes machen. Aber ich habe eine vergrößerte Version der großen Hängebrücke erstellt. Jetzt knapp 0,5 km von Ende zu Ende und 100 m hoch, ist sie im Vergleich zu Brücken wie der alten Severn-Brücke (1,6 km x 136 m) oder der Golden Gate (2,7 km x 227 m) immer noch eher klein und schlägt jetzt andere wie die Menai-Brücke (417 x 47 m). It now carries 4 lanes of traffic, complete with crash barriers. Es trägt jetzt 4 Fahrspuren, komplett mit Leitplanken. The two end road sections are level and aligned to 0° relative to the bridge, and I have left the ends of the steel crash barriers open on purpose. Die beiden Endabschnitte der Straße sind eben und im 0°-Winkel zur Brücke ausgerichtet, die Enden der Stahlleitplanken habe ich bewusst offen gelassen. In addition, the centre span is now high enough to allow the Albatross ( @ 1 scale), the Evergreen ( @ 2 scale), and the three schooners (Borgfeld, Arona, and Christina) (@ 1.25 scale) to pass under it, as long as the ships are lowered to bring their plimsoll lines to the same level as the bridge - technically they should be lower as the bridge piers should be above sea level and the ships hulls should be below sea level. Außerdem ist die mittlere Spannweite jetzt hoch genug, um die Albatross (Maßstab @ 1), die Evergreen (Maßstab @ 2) und die drei Schoner (Borgfeld, Arona und Christina) (Maßstab 1,25) darunter passieren zu lassen, solange die Schiffe abgesenkt werden, um ihre Plimsoll-Linien auf das gleiche Niveau wie die Brücke zu bringen - technisch gesehen sollten sie niedriger sein, da die Brückenpfeiler über dem Meeresspiegel und die Schiffsrümpfe unter dem Meeresspiegel liegen sollten. (In case you're wondering at the scaling of the ships, those are the scales at which the ship captain can fit through the doors without ducking!) (Falls Sie sich über die Skalierung der Schiffe wundern, das sind die Maßstäbe, bei denen der Schiffskapitän durch die Türen passen kann, ohne sich zu ducken!) If anyone wants a copy, to save having to put it together yourself, send me a PM. Falls jemand ein Exemplar haben möchte, um sich das Zusammenbauen zu ersparen, schickt mir eine PN. Cheers Simon

88 is my best score so far...

The solution is simple: Edit the diamond crossing to add switch positions to the two track routes. Then the Routes (capital R to distinguish them from the routes contained within the track section) will select the correct route through the crossing, disabling the other one. At present,the default for a diamond crossing is that both routes through it are always active, meaning that bot can be selected at the same time. Adding switch positions prevents this.

Yep, I was being obtuse, because you seemed to have missed my point. I know that junctions are always signal protected. The question was rhetorical, or rather, a self-ask in response to this: In other words it doesn't work with junctions, so how do we make it work with junctions? Your comment was missing the point. I never said they were. I said that I am considering self block from a modern perspective and central block from an older perspective. That neither excludes nor includes Old Self block, nor modern Centre block. The system I have devised will work just fine with KS, 69 and semaphore signals. It will need tweaking to work with KS multiblock, but it will need tweaking to include advance signals on either of the other systems. I haven't got as far as them yet. You are answering a question I have not asked. Allow me to ask you one: When is a train allowed to request a route at a junction? 10m away? 100m? 1km? 10 km? What, to you is a reasonable distance between the train and the junction at which the junction should be set for that train's approach? The point is that at some point in time the signalman, and/or the Automatic Train Protection System is/are going to notice that a train is approaching a junction. And either the computer system will flip some relays, or a human in a signal box or control centre will flip switches, press buttons and/or pull levers, thus changing the points and the signals. Where this happens in real life is down to the allowed track speed, the positioning of the track contacts and the alertness of the person pulling the levers. As I already said, back in the days of levers, wires, bell-codes, metal tokens and semaphore signals, it took time to get everything ready (I did a spell working a signal box on a preserved line!), so if there is an express coming through you would want to get those points changed, level crossing barriers down and signals set as quickly a possible. Of course for a stopping service that wasn't strictly necessary. But the think is, on a model, it is up to you, the modeller, where to put your track contact. First of all, how do you know that I was using it in inappropriate places? Second of all, this is why I looked for and found what I consider to be a better and easier method. In that case, I respectfully request that all the diamond crossings in the catalogue have switches added to them, in order to avoid this highly unrealistic situation: However, if you look at what I actually said rather than what you think I said, and put it back in the original context: Does the block start at the signal in front of the junction? Or at the signal after the junction? Does the signal after the junction even exist? The signal in front of the junction protects the junction. It goes green when requested by an approaching train at a distance determined by the location of the track contact. Provided the diamond crossing has switch positions added, then selecting the route from bottom left to top right will block that route, the route left to right along the bottom and the route right to left along the bottom. It will set the junction signal bottom left to green set the lower point to curved, the diamond crossing to "angled" and that's it. What I'm saying is that the same route might as well include the block starter signal on the upper right exit track as well, because you are never going to set the one without the other. If a train cannot enter that block, it should not be allowed to enter the junction.

Except when a train is approaching the junction...! "Always" implies that the signal will never be set to green, which of course would not work! I'm talking about the self-block, from a modern layout perspective, but also "Central bock" from the perspective of hand pulled semaphore signals when every block section had it's own signal box, and bell codes were used to pass messages from one signal box to the next. If box A sends "Express entering block" to box B, Box B will want to send "Clear for Express" to box C, and as soon as he gets the acknowledgement, will clear the signal, and get the token ready for the fireman on the express to grab in passing, thus blocking the line. I tried doing it the opposite way to the above and having the route reselect itself as soon as it was released. It doesn't work anything like as well as the simple cascade system. The track contact to set the route at the facing junction can be as close to that junction as you want, or it can set multiple junctions, but I can't guarantee that won't cause conflicts if there are trailing junctions in between. True. However, for the route system on V7 to work, the route must start on the other side of the junction to the block it equates to. Otherwise the route will not set the junction, nor the signal protecting the junction. Whether the sections of track between the signals are separate routes or not, the route must start at the signal before the junction in order to correctly protect the junction where the actual block starts is not really relevant to a virtual model railway. On the trailing junction (right to left) each route will select the next one and cascade through, unless the junction is already blocked for that route (and using a diamond crossing with track switches added ensures this works). On the facing junction, a track contact in the preceding block will attempt to activate the route the train requests.. If activated, that route will then cascade to the next facing junction, or next blocked section. Whether the block entry signals after the junction are the starts of their own Routes or included in the routes that lead to them is not important from the perspective of the model as it will work either way However, you would never stop a train on the junction, you would hold it at the junction signal, so those block starter signals should be included in the route that starts at the junction signal. Cheers Simon

Apologies to anyone who has already figured this out on their own, or has actually got a better way of doing it. Something I have noticed while travelling by train is that on modern railway networks it is normal for the signals on the main line to default to "Clear", green, "drive" or off (all meaning the same), unless there is a train in the block they are protecting. This is to avoid unnecessarily slowing an express train. I can't say this for certain but I can imagine that in the days of hand pulled signals, the signalmen would want to clear the express through as far as possible too. One way to try and simulate this on MBS v7 would be to have a single route containing all the block sections you wish to clear at once. The problem with this is that the route will not fully release and thus will not allow another train into the first block, until the last block is empty. Obviously this kind-of defeats the object. The ideal way to set routes is a one-to-one correlation between block sections and routes. A better way to simulate the route of the train being cleared as far as possible is to "cascade" or "domino" the individual routes. Each route will have a variable on it, naming the next route in sequence. There can also be a keyword if you wish but it's not strictly necessary. An event "When any route is activated/deactivated", holds the condition: "If Trigger Route is Active", and the action: "Activate Route (Trigger-Route.Next-Route)". Defer Request is important, as at some point you will have a route that cannot be activated immediately due to a train being on it. I have tested this and it works perfectly on a straight track between two depots and on a continuous circuit. Set one route to clear and the rest cascade all the way around. On a continuous loop with a single train it will clear the entire loop except the one with the train on, but that will be deferred until the train leaves, allowing the train to run indefinitely on the loop with no intervention. But what about junctions? What if there is more than one possible route for my train to take? For this we require a slight modification: On any route where there is more than one possible next route, do not add the "Next Route" variable to it. Instead, place a track contact at the earliest place a train will encounter it - this will usually be immediately after any preceding junction, inside the first block after that junction. This track contact should have a keyword "Junction" (or similar), and a list variable holding the routes available for that junction. While this would normally be two, a multiple junction for sidings would be treated as a single junction. NB: This solution does not cater for choosing the First Free Siding. I leave that for people to figure out on their own! But if each train always goes into the same station platform, for example this works just fine. So: Track contact in place. Now each locomotive that will pass through the junction will need a list of routes it will take at each facing junction it comes to. If the train will only go through one facing junction, still use a list, as this cuts down on coding. A list of one element is still a list. Now we need an event, activated when a track contact with Keyword "Junction" is triggered upon entering The keyword is important and can be added to any track contact including a signal, as long as it is in the right place and has the list of available routes on. Within this event we have two nested iterations, one for the triggering contact and the other for the triggering vehicle. It doesn't matter which order they are in, but I usually put the track contact one outside because usually (not always) it will have the fewer iterations. Within the inner iteration, the condition "If Iter1 = Iter2" will say "This train is taking this route", and if the condition is met, set the route active-deferred. Important: This is not necessary on trailing junctions, only facing. The route immediately before the junction is the one that does not have the "Next Route" variable and is the last possible place that the "Junction" track contact can be. The routes that start at the junction should each have their own "Next Route", so that when the junction is set, the cascade/domino will continue Terminus routes, including those ending at a virtual depot or fiddler yard, will not have a "Next Route". This should work, in theory, if routes for more than one junction are placed within the same available list on a single track contact, thus cascading past multiple junctions. However I've not tested this on an actual layout, only on a test-bed. I hope someone finds this useful. Cheers. Simon

Hi Henry. Thanks, but I already did exactly that and saved the results in my own catalogue, for all the crossings in the "Model Oriented, Standard Gauge" set. It's also possible (but a little bit more complex) to turn a double or single slip into a crossing, by removing route 2 (and 3 if it's a double), and removing the corresponding switch positions. The complicated bit was figuring out how to save them! I have tested how they behave and they work exactly as they should: routes remain blocked until the last wagon is clear, then they select. This is why I think this should be done to all the crossings in the catalogue, because it is how the trains are supposed to behave prototypically.

Fair enough. It was just a thought that it would be a permanent solution, rather than having to re-solve it whenever it crops up... What I might do is see if I can save the edited crossings in "My Models", so I've got them when I want them.

So... that worked and was a lot easier that what had done. Which begs the question: Rather than only using slips, and removing the slip routes, could we not have switch positions 0 and 1 on the crossings? Is this something that would be easy to implement and not require any change to the way the route system works? I mean yes it requires someone to go through all the crossings in the catalogue and add the switches to them, but at the end of the day it could easily justify the time spent in the simple fact that you no longer have to protect crossings from two trains being on them together!

In fact, I'm going to replace all the crossings with single slips, edited to remove the slip route. So much simpler!

Got it, and fixed with a couple of events that work for all crossings in both directions. Of course the other option is to replace all crossings with double slips, because being points, they have the interlocking in their crossing routes!

I did this originally, and had a different issue: The single route exiting the junction leads to an 8 track fiddle-yard. (The layout pre-dates virtual depots). When two trains arrived at the junction heading the same way ut from different directions, the one that went first correctly selected a route, the one follow did not. I finally fixed this, but one of the things I tried, before realising what was actually causing it, was to split the routes after the junction. Re-combining them would totally destroy the system I put in that works... But really, that isn't the point. It shouldn't matter how long the route is nor how long the train is. As I "colourfully" pointed out already, if this were the prototype, there would be hundreds dead and a massive lawsuit pending! I think the fault does in fact lie within the system, because the light on route 6 should never go green while there is even one wagon still on that crossing from route 4 and vice versa. I am going to put a "manual" check in place to prevent this, but I think the team should consider a fix for this.

No worries. It's cosmetic anyway. I tried your example, and the trains are shorter than the gap between the crossing and the end of the block. I shortened one of the blocks and the trains both hit the crossing at the same time almost ignoring the signals! Have you tried my example yet? it shows clearly what the issue is.

The ground signal, the one that shows which way the point is ... pointing. In that last picture, it's still showing the curve where the point is set straight... Okay... 3B7194FC-3D4A-4B2F-910C-0508F4FB9078 My simple example. Select route 4, which will select/lock, then select route 6. Route 6 will show blocked. Start train 2 moving and it will stop at the signal. Start train 1 moving and it will go through the junction, and stop at the end signal. When it does it releases route 4. Route 6 then selects/locks and allows train 2 to pass through the cars still sitting on the junction... I'm not trying to be difficult, I just want to make sure I haven't done something stupid first.

Not the track... The ground signal is still linked to the Arnold point so hasn't changed. I'm going to see if I can reproduce this on a test bed, and if I can, I'll upload it for you.

Sorry, I was having a bit of fun with it. I have tried replacing the Arnold Spur N 1854 with a 1853 to the same effect. Now trying it with "|1435| K138/10 Kreuzung 10°" from the model oriented set, which also meant replacing the points so it fits together... sort-of. I'm not sure what I'm hoping to prove, because if I still get a collision then it is something else weird, but if I don't then I am going to have tp re-lay all the track which defeats the object of upgrading the layout..... Anyway I will let you know what the outcome is.

Restarted from the save point and managed to capture the whole event this time... Hopper train is held at the light, and the point is showing to go the other way Tank train comes around the corner. (By the way in case you're wondering, this part of the layout is supposed to be hidden from view, but while upgrading I wanted to see it.) With the tanks still on the crossing, the signalman has a brainfart and changes the point and the signal. The driver of the hopper train is either blind or insane, because he starts moving forward! KABOOM!

I just checked and it does it at other places where that crossing is used. I think it's a problem with the track itself. Unfortunately I was too slow on the pause button, but there's no way the hopper train could have got that far without hitting the last few tanks. Not on any railway I've ever heard about! The whole point of signals is to prevent trains hitting each other, not cause them to...!

Hi Goetz But they do. I even deleted the original crossing from V5 and put it back in at V7 to see if that might make a difference. It could be something wrong with that particular track object, but I've used the same object in all the other places where two tracks cross each other and I've not seen it do the same thing, but that could be because I'm not watching for it. As I said, the one track blocks while the the other is "locked", but as soon as it "unlocks" - when the train reaches the contact for the next block - the crossing route clears, while the train is still on the crossover.

I think I may have found a bug? This is an old V5 layout that I thought might work better at V7. It does, and so far I've managed to solve every conundrum it as thrown at me, except this one... The layout is paused for clarity, but I can record video of this happening if you wish. As ypu can see there is a train on the junction. it has passed the signal to the next route and so the route it is leaving is now no longer selected, but is still blocked. Trying to select that route gives a "blocked" message, as it should. The yellow route is the anti-clockwise route crossing the track with the train on, highlighted blue with a pencil in the route sidebar. Logically if I select that route it should go "Blocked", right? Except it doesn't. The route selects (and due to a deliberate event, also selects the next route down, as it's clear). Clearly this should not happen! As I said, I can easily provide video of this "signalling failure" that has caused hundreds of pretend little model people to be killed, when the trains hit each other and (fortunately) pass through. It looks to me like the system is not recognising the coaches on the back of the loco. Except it is or the route it's on would be selectable...? Help, please? Thanks Simon

I also noticed a typo: The event to release a car to leave is triggered by the expiry of "Abfahrttimer" with two "t"s, but the variable holding the timer name holds "Abfahrtimer" with only one "t". I was wondering why there were two timers both set to zero and not doing anything, and why the cars never seemed to leave. Played with both and figured out what was going on. Easy enough fix to add a t into the name in the variable. Cheers Simon.