April 9
I was at the DMJU (Danish Model Railway Union) exibition in Køge. Many interesting things. But to be honest, I was somewhat disappointed by the quality and level of detail in the club layouts that exibited. But in hinsight, it is only people making it for fun and not to impress others. If that is what one wants, then go to Hamburg and see Miniatür Wunderland.
At the exibition, I noted these things:
Mck exibited red Bn cars, that I got the impression are on their way from the factory in China. In addition, they had a raw and unpainted Bns (i.e. cab car), where one could see a bit about how the light functions are going to work. He told that Mck is going to put a light-kit including a 3rd-rail shoe on the market – maybe this autumn, and that the same thing will be built into the Bns from the beginning.
In addition, they had an early version of the Q-steam-locomotive running. Many people were taking photographs of the nice little thing, even though he underlined that it was indeed a very early prototype – possible with a lot of faults.
Finally, he had an MR/MRD train-set. It was in a wrong color and with wrong LEDs. But no matter that, it absolutely outshined the Lima model that I re-built a few months ago.
Märklin C-track does not have to be noisy. There were plenty of C-track layouts – including one at Märklin’s own exibition, that did not emit much noise. And they were just loose track on top of an MDF board. Maybe because it was in a big room with a lot of noise around? Or maybe because they were using different locomotives? Or maybe I just need to determine what is wrong on my layout?
http://www.mollehem.se/ has some nice Dansih and Swedish signals. He has been smart enough to produce the entire signal – head, mast (which is very thin as it should be) and foot as one PCB. The head is equipped with a pice of plastik at the front that looks like a correct signal to me and another piece of plastik at the rear, that is better described as just a piece of plastik with much resemblence with reality. The mast does not look much like the real mast either, but all in all, it is a nice signal.
For 50 kroner, he also sells servos with a little piece of plastic, that makes them ideal to use with any turnout brand. Finally he sells servo decoders and other kinds of electronics.
Togdillen Was also present with – among other items – IC3 train-sets built from spareparts from Heljan. I asked if they could run and told him about my IC3 train, that I bought from him. He said that I should come to them if it falls apart again, and they will fix it so that it lasts. They want satisfied customers.
Just before bedtime, I managed to edit the XML file into which I some time ago has been defining my new layout. The editing was about replacing the syntax of sensor names from Loconet simulator syntax to ECOS syntax.
April 10
I expected some trouble in getting the layout XML file including its built-in signal logic etc. to work.
But no – no problems at all. It worked right away.
I did however have a few problems in getting Warrants and my Jython scripts to work:
1. One problem was in SCWarrants, that was a bit too eager deallocating blocks to avoid one warrant from prohibit another to run. So eager that the block that was just entered sometimes was deallocated, with the result that the train could stop in the middle of its route.
2. I had to set debounce timers for all ECOS sensors. I have chosen 25 ms delay when a sensor becomes active and 100 ms when it deactivates. There has to be some difference, to avoid problems with a sensor for the block that is left becomes inactive before the sensor for the block that is entered becomes active, thus leading to the detection of a lost train.
3. The function that I made in JMRI for letting a Jython script wait for a warrant to enter a new block did not work correctly every time when a warrant terminated funktion.
I have fixed these minor issues and re-implemented my Jython script for one of my trains, defined buttons to start and stop my trains as well as information fields for the running trains, created SCWarrants for the one train – and spent all day doing so.
And the JMRI fixes are naturally pushed to Github so that they will be part of the next JMRI release.
And now the first train is running pretty stable. The train consists of an old Märklin Santa Fe (3060 for conisseurs) locomotive with the engine rebuilt as a 5-pole DC engine and equipped with an ESU decoder, as well as 3 well-used Lime B-cars. I have uploaded a video here.
A few accidents are happening every now and then, such as a railway car derailing or just decoupling. Or on rare occasions, a sensor is not detected correctly. And then “funny” things obviously happens. But I think the software is as stable as it is ever going to be. Probably, only some kind of duplicated sensor system can really make things more stable.
I can foresee one thing, I need to do pretty soon, if I want to run more trains simultaneously, which I do: I need to make sure that the rear of a train is detectable, i.e. Is equipped with a 3rd-rail shoe so that it draws current. As it is now, JMRI cannot detect the rear of my rather long train, and thereby deallocates a block too soon, making it available for another train to enter. I will probably be saved by the signalling system, since the next train entering the freed block will be given a stop aspect, which JMRI will react upon, but it is not safe.
April 11
One of my turnouts needed adjustment, since the servo was “singing” in one of the positions. This was easy enough, since it was just a matter of changing the CV value in the decoder that controls that particular servo in that particular position.
Another turnout was a bit more challenging. It was one of my 3-way turnouts:
It operates as two independent turnouts. But mechanically, they are not independent, since one of the moving parts is pushing on the other moving part as can be seen on the picture. Again referring to the picture, the outer turnout is closed and the inner is thrown. That is OK. But if I now also throws the outer turnout, the inner turnout is pushing enough on the outer that it does not shift properly, so that trains will de-rail. I tried adjusting CV value the best I could. But it was not enough. I also tried bending the outer turnout slightly, but that was not enough either.
I assume that if one uses Märklins own special decoder (74465), it will not be possible to have both turnouts trown simultaneusly. I have made the same thing using Logix in JMRI. The logix I have made reacts upon the outer turnout being thrown. And the action it takes is to close the inner turnout. Simple and effective. While I was at it, I made the same logix for my other 3-way turnout.
A bit of research shows that it is not the Märklin 74465 decoder, that makes the 3-way turnout function as one turnout. That is a function in the ECOS, which is able to utilize two consequtive turnout adresses combined, if one uses the 3-way turnout icon.
But I cannot use that function in the ECOS, since JMRI does not know anything about 3-way turnouts. In JMRI, one needs to draw and control the two integrated turnouts individually. I.e. My solution with logix seems to be the right one for me.
April 15
I defined warrants for a couple of trains more. But that lead to the greatest of disasters with all cars derailing and crashing deep into a ravine. I have to make my whole train detectable, which means equipping the rear bogie with a 3rd-rail shoe and some current consumption.
Until further, I will just run locomotives without cars. But that is going to become a bit dull.
April 17
It has become spring-time. The driveway is high-pressure cleaned. But I have also been driving trains via SCWarrants.
It was an occasion for a few improvements to SCWarrants (that are not yet pushed to JMRI):
1. I have removed the function that was meant to de-allocate blocks further along the route, if they are occupied by another train. First, it should not be necessary. And second, it has happened on more than one occasion that the function was executed at the same moment as the train was entering the next block, which meant that the block was being de-allocated and occupied by the train at the same time. And thereby the train stopped.
2. Until now, the first allocation of blocks was done in the normal Warrant code, which meant that all blocks were allocated no matter if they are occupied or not. That did not work – especially not now that occupied blocks are no longer de-allocated. The problem is that if one warrant has allocated the block, an other warrant that is supposed to move the train away from that block cannot do so, since it cannot allocate the block that is already allocated to the first warrant. So I have now implemented a very simplified version of this initial allocation: it only allocates the start block.
In addition, I have been fiddling a bit more with debounce timers, because my sensor 17 seems a bit unstable – probably due to dirty track. I have in general increased the timers from 25 / 100 ms to 50 / 200 ms. And for sensor 17, I have set them to 100 / 500 ms.
In addition, I have defined (virtual) signal masts at the entrance to all side-tracks.
April 18
More high pressure cleaning – this time the terrasse.
But I have also made a couple of software improvements:
1. My script to run trains by warrants had the flaw that it re-used the throttle from the warrant itself. This meant that when the last warrant had finished and thereby the throttle had gone, the script failed to turn of lights etc. On the locomotive.
2. SCWarrants will now slow down in the block before the destination block.
3. It can happen that two events are received to tell that the destination block is becoming free. And in that case, a race condition leading to a null pointer exception could occur. That made a thread in the program die. Such behaviour is seldom healthy for a program.
4. If the train doesn’t move (speed == 0), the warrant no longer reacts if the block ahead becomes occupied. It might have been in combination with one of the things, I have corrected, but I had an incident, where my old Santa Fe was yelding nicely to wait for another train that should pass in the crossing in the middle of my layout. But as soon as the other train had finished occupying the crossing, i.e. when the locomotive but not all wagons had passed the crossing, Sant Fe speeded ahead with the result that the two trains crashed and the offended train was damaged. Not good! It must be beacuse the Santa Fe warrant thought that since the crossing was it’s next block, it must have been Santa Fe that entered it. I just don’t understand why I have been unable to provoke the same error again.
5. I have increased the time configured in ECOS to set a turnout. Until now, all turnouts have only had 250 ms to move. I have increased that to 2500 ms or 2,5 seconds. It fits pretty well to the time it actually takes for a servo to move a turnout. And it is the maximum in ECOS.
Besides, I have at long last found out how to disassemble a Lima B wagon. I have “asked” Google numerous times without success. But by squeezing my ugliest Lima wagon carefully, I found out: Roof and windows are casted into one piece. And the sides and bottom in an other piece. So by gently pressing the winws inward, wriggle a bit and so on, it is possible to pull the two parts apart. Use only your fingers. No tools:
This finding could enable me to add interior lights and collector shoe.
April 19
More JMRI improvements:
1. Messages are shown in the window containing the list of warrants when the train runs. I have made these messages specific and relevant for SCWarrants.
2. Editing TimeToPlatform now actually works.
I Have pushed these and previous improvements to Github so that they will become part of the next JMRI release.
April 22
I tried with 3 trains in automatic mode. And it failed miserably. This time because block 11 went UNOCCUPIED even though there was a train in the block. 375 ms later, it went OCCUPIED again. And since the debounce timers in JMRI are set to 50 / 200 ms, it must have been “out” for more than half a second.
I think I will try out 25 / 1200 ms debounce timers. There has to be a resonably prompt reaction when a train enters a new block, but there is no hurry to free a block as the train leaves it. Well maybe when the second last block in a route is left and it has to be determined that the train is into the destination block. But I will have to do some testing about that.