St1ngr4y

@BagEndJct Hi John, When you press the Red button, do you have Reverse Polarity checked? Ray

Hi BEJ, Are they 2-aspect signals with a feather? How did you give the signals their addresses in learn mode I.e. what steps did you go through in RM? Ray

How about wrapping tin foil around each leg until they fit snugly. Bit of trial and error needed but once you know how many layers are needed, you can use that as a guide for further signals. I use Peco flexible track and occasionally a signal leg is too loose so I often slightly bend the legs so that they arch upwards. However, from your description the gap in Hornby track might be too much for this to work. Ray

Don’t think it was me, Fishy. Ray

Personally, I do 99% of my operating by running RM programs. A long time ago, I gave up using the signal aspects shown on the display as being a true reflection of what the actual signals were showing. I rarely look at the layout display. Ray

Hi Paul, I've been trying out "routes" for your signals/points and they all work beautifully on the actual layout, but on the layout display, whichever route is executed, the aspects of the signal and feather remain unchanged throughout.... While testing on my layout, of course, I had to use my addresses for the points and signals, but I have added your addresses (9, 10, 61, 67) at appropriate places in the image above. Ray

Hi Paul, I discovered a while back that running a RM program to switch the signals can get them back into sync with the display. Try creating a program like this... 001 Controller A: Port 67 Signal Clear 002 Controller A: Port 61 Signal Stop Then after session start, but before doing anything else, run the program. Nothing will appear to change on either the RM display or the actual signal, but then try using the icon to change 67 to red, and carry on from there. With regard to your second point, there is no logic in RM to stop the action of P10 setting 67 and 61 because of the position of P9. These "other point/signal" commands are carried out regardless of the state of any other point or signal. Ray

Hi Paul, The best I can manage is as follows:- Put the signal and the feather each through learn-mode with Reverse Polarity checked. After learn-mode leave the Reverse Polarity checked. In the centre column of the signal and feather, switch the sequence around so that Seq 1 = green and Seq 2 = Red Try this to see if it fixes part one, then see if part 2 with the extra entries has changed also. BTW why are you switching Point 9 left when you switch Signal 67 green? Edit: ignore question, I was mixing up the 2 points Ray

Hello Paul, I've just powered up my layout, and I'm about to try to simulate your setup. But before I do, a thought just occurred to me, and I've just experimented to find out. My thought was that, if, while the signal is in learn-mode, and you press the RED button, if Reverse Polarity is checked, does it make any difference. The answer is yes it does !!!! With Reverse Polarity checked, the RED button sends a 1 to the signal, instead of a 0. Can you remember when you first put your signals through learn mode, did you have Reverse Polarity set or not? Ray

@pd91223 Hi Paul, The point made by @Fishmanoz is very valid, and was to have been the first thing I mentioned today. However, it does lead me into the reason I asked that last question in my previous post - "when you configured the TT signals addresses in "learn" mode, did you use the RED button in the signal configuration window to set its address?". Unfortunately, the phrase "Reverse Polarity" has been introduced into the configuration of Points and Signals, but this has nothing to do with electrical polarity +/- which analogue users will be familiar with. The DCC message sent from the Controller to a point or signal is very simple. As well as the address of the decoder, the message contains either a 0 or a 1. These values equate to left/right for a point, red/green for a signal, on/off for a feather, etc. Now with, for example, a Hornby point motor or colour light signal, the green wire is the common return, and the red/black wires are used for each switch choice. Having wired up such an accessory, it might be found that the device operates the wrong way around to what RM is displaying on the track diagram, so you can either swap around the red/black wires at the decoder port, or you can use the "Reverse Polarity" field in the point/signal configuration. All this does is to make RM swap around the 0 or 1 it was sending to switch the device. Pause for breath... With TT signals, the wire switching isn't possible because the decoder is built-in to the signal. TrainTech decided to allow the user to choose which value 0 or 1 would cause the signal to change to red or green. The way they did this was to incorporate it into the "learn-mode" process, so when the signal is in learn mode, as well as taking the address from the next accessory message it sees, it also uses the value 0 or 1 contained in the message and it uses this as the value to be used for the GREEN aspect for future operation. The address and this value are remembered by the signal until it is put into learn-mode again. This method then causes problems if the user isn't aware of the significance of the value sent in learn-mode. For example, if the signal has already been defined, and the icon on the main screen is used during learn-mode, then it would depend on what aspect the signal icon was showing as to what value 0 or 1 is sent to the signal. RM would then have no idea which value to send to which signal on the layout - half of them could require a 0 to indicate red, and the others could need 1 to indicate red. For this reason, HRMS decided that the TT signals should be configured in learn-mode using the RED test button in the signal configuration. When this button is pressed, the message sent to the signal contains a value of 0, so TT signals configured this way will always use 0 for green and 1 for red. Now, there are several ways in RM to switch a signal - clicking the icon on the screen, as part of a route, as a command in an RM program, with ProPack by being switched by another point or another signal, and whichever way is used, they should all use 0 for green and 1 for red. However, I suspect that there are some cases where this condition works the wrong way around, but pinpointing which conditions becomes a bit mind blowing. I also suspect that HRMS are not only aware of the problem and how to fix it, but are reluctant to change the code because there are so many users who have already done the best they can to overcome the problems, and any changes to the code in RM could mean many users suddenly have their signals not operate in the way they want them to, and have to reconfigure them all, maybe even put them through the learn-mode process again. End of rant for todaysmiley Ray

@pd91223 Hi Paul, Your setup seems a little more complicated by a second point being involved. Am I right in saying that the signal is physically located where the icon for signal 67 is placed on the track diagram, and the feather icon simply placed in a convenient spot. This would suggest that the green signal aspect and feather-on conditions only apply to trains approaching along the left (red) position of point 9? It looks like you are using the switching of point 9 to right (green) as a means of switching signal 67 to red and feather 61 to off? When point 10 is switched right (green) the feather 61 is switched on and when it is switched left (red) the feather 61 is switched off? However, if signal 67 is showing red when point 10 is operated, the signal will stay at red and the feather will stay at off. To correct this, point 10 should have two extra "other" commands, one for each point position, both to switch signal 67 to green. You are quite right about the use of the signal 67 icon causing problems. I am pretty sure the fault is in RM when the "other" commands in a signal setup, are used to switch another signal. I think within RM, for each signal, there is a variable which holds the status of the signal on the layout e.g. 0 = green 1 = red, but also a separate variable which holds the status of the icon on the diagram, again e.g. 0 = green 1 = red. When the icon is clicked to change the signal, BOTH of these variables are being updated, but when that signal is being switch by another signal by its "other" command, any the status of the icon is updated, so the variable holding the status of the actual signal is now out-of-sync with the colour being displayed on the signal itself. This would account for needing to click the icon twice to get it to change, because if the icon is showing green, but RM thinks the actual signal is red, then clicking the icon changes the signal to green, but the icon remains green. Hope this makes sense !! One more thing, I may be wrong, but I don't think the Reverse Polarity setting has any effect with TT signals. BTW, when you configured the TT signals addresses in "learn" mode, did you use the RED button in the signal configuration window to set its address? Ray

@pd91223 Two Controllers While on the subject of two controllers, can I ask if you have the following observations in common with me? a) In my INI file, I have this line... Reset eLink on start=0 No matter which value, 0 or 1, I set this entry to, AN eLink always resets itself on startup. The reason I highlighted the word "an" is that in my case, it is always Controller B which is reset on startup. b) Although I don't use it, the tiny red reset button only resets Controller A. c) If I hover over the Controllers icon at the top right of the main window, it displays all of the correct information for Controller A, but it always reports Controller B as inactive. These values are repeated at the bottom of the Settings dialogue window. I know these observations don't prevent the system working as it should, but I think they are minor faults which should be addressed by HRMS, that is, if you can see these too, of course. TrainTech Signals with Feathers I think, in the past, I may have posted this in the RM thread "Desirable Features", but I'm not sure whether this thread still exists. Anyway, I would have liked to see in RM, a separate icon for Route Indicators (feathers). There could be two icons, one for left, one for right. They could be separately configurable with a right-click in the layout designer, just as points and signals are. They could be made to "snap" into position against a colour light signal, in the same way that the red/green points buttons "snap" into position on a point icon. In operational mode, the feather would be separately "clickable" to switch the feather on or off, and the main body of the signal would be "clickable" to switch the aspects of the main signal. With a bit of extra code in RM, any attached feather could be switched off if the main signal is switched to red, as in real practice and as the TrainTech electronics of the signal do. Ray

Hi Paul, I've just tried another way of achieving your goal using routes ..... I have assumed the two exits from the points to the right are to station platforms as shown in the bottom diagram. Due to the anomaly with the handling of the aspects, I had to reverse the colours from what you would expect in the route setting entries on both signals and the point, but each route works as required on the real signals and point. Ray

@pd91223 Hi, I, too, have 2 eLinks running a similar setup to yours, including TrainTech signals, two with feathers. However, although I have the ProPack addon to RM, I don't use the Other Points/Signals feature as described by Chris above, as all of my operating is done using RM programs. For the last hour or so, I have been playing around with a configuration of a set of points address 0003, and a TT 2-aspect Home with LH feather. I used address 0110 for the 2-aspect signal and 0111 for the feather. The problem is, even with ordinary addressing of TT signals you can run into problems due to an ongoing bug in RM whereby the icons on the screen become out-of-sync with those shown on the actual signal. This configuration is the best I could come up with ... It does work whether or not the points and the signal are on the same eLink controller or not. Notice that I have used two separate icons for the signal and the feather. If you have any queries, please post a reply. Ray

On some of my pc's in the Windows Update page of settings, Microsoft have provided a link to a webpage which gives the hardware specifications required to upgrade to Windows 11. Wouldn't you think the least they could do is provide a small "App", which would examine your pc hardware and just give a "Yes" or "No" answer to its compatability. Ray

The LDM doesn’t need to be capable of detecting speed or direction because RM already has that information for every loco defined. Ray

There are a few good YouTube videos on the subject ... Ray

As Idlemarvel says, in order to discover the messages passing between RM and a LDM, you need to have a LDM physically connected via USB. Only then would you be able to build, for example, an Arduino running a Python program to simulate the Hornby LDM.

As far as I know, a turntable operational fault is still present in the RM software which causes the actual TT bridge to become out of sync with RM. I reported it years ago but HRMS seem unwilling to accept that there’s a fault even though it can be easily demonstrated. Ray

I forgot to mention that the GIF files must have the prefix "Button_" before their names, otherwise RM won't recognise them as icons for program buttons. Ray

Here's something I tried out today. It's not perfect, but it might do..... First of all I created two GIF files called Button_Horizontal.gif and Button_Vertical.gif, and placed these files in the main Railmaster folder. These files can then be added to the layout diagram as the icons for program buttons, even though they may not be used as such. They are there simply because these program buttons can be placed anywhere on the diagram without them "snapping" to a grid square. HOWEVER, there are a couple of disadvantages to this. First of all, these button GIF files must be 50 x 50 pixels in size. If they aren't, RM will try to squash/stretch them to fit. Secondly, when the layout file is saved by RM, I think the program button records are saved last after all the other track icons, so that when the layout is redrawn, if the buttons are placed on the layout such that they overlap a grid square, then any track icon occupying that square will be masked by the program button. This has actually happened in the diagram above. Also, the DCC address of the TT is displayed over a horizontal button placed at the 3 o'clock position, and the tiny corner piece is missing where the horizontal or vertical buttons meet ordinary track pieces at the corner of their icon square. Ray

I read somewhere recently that you need a pc with quite a recent specification to run W11. Any pc older than about 6 years can’t run W11.

@ColinB Hi Colin, Could you say to which post/person your last post was referring? Ray

@37lover Hi Martin, I am registered on the RMWeb forum with the same user name - st1ngr4y. If you are registered there, we can pm each other and exchange email addresses. The software I created was for my own amusement, just to see if it could be done. Like RM it is capable of using either one or two Hornby controllers (eLink or Elite). If two are used, like RM, A is for locos, B for accessories. It can import a track plan from RM, and it can import RM programs, doing its best to convert them into the program format used by my software. The documentation is all in my head at the moment, but I can send you a summary of its capabilities, with screen shots. Ray

Hi all, The biggest query I have had for the last few years since the proposed Hornby LD was announced, is how would it integrate with the current RM program format. The only answer I can come up with is that it won't. LD implies that the user wants to automate the running of the trains, and currently the RM programming facility provides that automation. Going from the list of commands available when a LD sensor is triggered, the actions can be applied to signals, points and locos, and you can play a sound through the pc speakers or run a program. Now if the train is being run via a RM program, and it triggers a sensor which tells the loco to stop, then how does the program which is running know that this has happened? Also, having stopped the train because of a sensor, how do you get the train going again - "manually" or by running another program? For this, and many other reasons, a couple of years ago I decided to have a try at creating my own RM replacement software, which includes a detection system based on simple micro magnetic reed switch sensors installed at key locations around my layout. Each loco has a small magnet fitted underneath, and each train rake has a magnet fitted under the last vehicle. I have 30 (soon to be 32) sensors installed, and they all connect to the pc via great piece of GB electronics called a BBI-32, manufactured by a company called Leo Bodnar. To keep things simple, my software caters for user written "programs" which can run a single loco to take its train from A to B. The software caters for up to 4 programs to be executed concurrently, and there is a locking system which prevents a program from starting if points and locations on its route have been locked by another program which is already running. For an individual program, the route of the train will take it over several sensors, and the user-written instructions will include commands to "wait" for a named sensor to be triggered, carry out some commands, then "wait" until the next sensor is triggered and so on. In this way, there is no need for the sensor to be "clever" enough to pass back the DCC Id of the loco, because the program running the loco already knows this. By the way, the LD system I have created, which includes the BBI-32, micro magnetic reed switches, magnets, and wire, cost me around £70. Ray