Linking points on track plan

[Britannia Builder]

I've been setting up the points in my track plan in RM in preparation for installing point motors and R8247 controllers. If I give two points the same port number they switch together when either is clicked in the track plan, which is fine for two right hand or two left hand points when crossing between my inner and outer loops. However I also have an inner branch for the station with a right hand point at one end and a left hand at the other, which I also want to switch together and connect to the same controller port. If I give them the same port number in RM they switch simultaneously but with the wrong sense, so that one is on the mainline and the other on the station. I guess I can wire them to the same controller port so that they behave correctly, but how do I get them to appear correctly on the track plan?

I've tried setting up two groups for 'station' and 'mainline', but this only works if I give the points different port numbers, otherwise the left and right commands sent by clicking the group each operate both points and so give the wrong settings. I don't really want to waste a port on the R8247, and I would prefer to click on the point symbols as with all the other points rather than clicking on a group name at the top right of the plan.

I suppose I could simply remove the point definition from one of the points and always click on the other point to switch them both, relying on the wiring to the common port?

I did at one stage get a message on the screen to the effect that 'you seem to be making good use of the RM features - would you like to upgrade to the Pro pack?' which was quite flattering but I'm not sure how this would solve my problem.

 

Regards, John

[96RAF]

Just select reverse logic on one of those points in setup to get them to switch as required.

 

the pro offer from memory allows you to fire one point/signal upon instruction of another point selection.

[Chrissaf]

But how do I get them to appear correctly on the track plan?

.

What you describe is called a 'passing loop'. This track plan display limitation has been discussed before. The requirement to support 'passing loop' configurations in the track plan display has been added to the 'RM Desirable Features' list as a result of the previous thread linked below. No guarantee that HRMS will do anything about it though, particularly as the linked post is more than a year old. 

.

User 'St1ngr4y' (Ray) came up with a workable solution on page 2 of this following linked thread (see second post up from the bottom + 6th post down from the top). It is elegant in its simplicity. But it can only be implemented if you have the RM ProPack upgrade installed. Prior to Ray's posted solution was a slightly less elegant solution that will work on Standard RM posted by OssieB on the same page (3rd post up from the bottom).

.

https://www.hornby.com/uk-en/forum/post/view/topic_id/6332/?p=2

[Britannia Builder]

Thanks Chris - if I'd known it was called a 'passing loop' I would have found the earlier very comprehensive thread when searching for posts on the subject!

 

Regards, John

[Chrissaf]

Postscript:

.

On page 3 of my linked thread, HRMS have made a statement that effectively adopts Ray's workaround as the official solution. Thus this infers that they have no plans to introduce anything different either now or in the future. They also give reasons for why they can't do something similar in RM Standard edition.

.

I only remembered the existence of the previous thread because I found the topic under discussion interesting, thus it lodged in my memory. Therefore, I only found the link to the post through forum searching perseverance because I knew it existed somewhere on the forum.

[Britannia Builder]

I bypassed the problem described in my original post above by simply omitting the point definition from one end of the passing loop, so it is shown as a point graphic without the red and green buttons and the grey direction arrow. I then wire both points to the same decoder output and they switch together when the point symbol at the other end of the loop is clicked.

 

I now have a related issue - I have a reverse loop within my main inner loop and so the points at either end can be linked together with the same port number and the symbols appear in the correct sense, as for a crossover pair. The two points are wired together onto the same port of my decoder (I've just today installed a DCC Concepts ADS8FX, since my supplier was out of stock of the Hornby decoder). Although I've only actually wired in one of the points so far, eLink seems to send two pulses at an interval of about one second, and there's a corresponding delay between clicking the point symbol on the track layout and the grey arrow changing. I don't understand why it's doing this - is there any way of preventing the double action and the delay when two points have the same port number on the layout (short of deleting one of the point definitions, as for my passing loop)

 

Regards, John

[Fishmanoz]

Ini file setting on page 33 of the manual Bb - Double pulse=0

 

PS.  Chris is still typing his reply.  It will be 3 paras long but say the same I suspect.

 

PS2.  I also suspect you'll be staying with the ADS8s after you've compared.

[Chrissaf]

is there any way of preventing the double action

.

BB,

See page 33 of the version 1.64 RM manual regarding railmaster.ini file. The 'Double Pulse' entry needs to be set to =0.

.

EDIT: Ditto with Fishy's post just ahead in the final furlong......yet another psychically joining of minds.

[Britannia Builder]

Thanks both, but I'm not sure that the 'double pulse' feature was the problem. It wasn't in my ini file, and I don't know what the default is, but I've now set it to 0 with no change in the behaviour. Basically if a point on the layout has a unique port number, clicking it sends a single pulse and the arrow graphic changes direction instantly; if two points have the same port number and are wired to the same port on the ADS8FX, they both get two pulses at an interval of 1 second, and the arrow graphic doesn't change until after the second pulse. As an added quirk, and this must be a bug, if I delete one of the two point controls and use the other one to fire both points, there's only one immediate pulse, but the arrow graphic still takes a second to change! By deleting the control and setting it up again, it changes instantly.

 

Regards, John

[Chrissaf]

That was the reason why in my reply I highlighted (yellow text box) the part of your query I was responding to i.e the double pulse bit (I believe RM treats the absence of the line in the .INI file as being equal to it being there with a default setting =1). With regard to the graphic delay of the second point symbol moving, this appears to be its normal behaviour for everyone and can't be modified.

.

With two points given the same point number and .INI set to =1 you get a total of 4 pulses. With .INI set =0 you still get two pulses with a slight delay. I am fairly sure there is nothing you can do about that, baring giving one of the points a dummy number and using ProPack.

[Britannia Builder]

Thanks Chris

 

I can't find any description of what the 'double pulse' does - does it send a double pulse to all points, or just those that share a port number? Is it intended to make point switching more reliable, or what?

 

I added 'Double pulse=0' (without the quotes) as the last line in my .ini file - I trust that this is correct?

 

Edit: I replied prior to your edit adding your second para, which clarifies the pulsing sequence thanks.

 

Regards, John

[Chrissaf]

Anything in the .INI file is 'Global', affecting everything. So, for example 'Double Pulse' or 'No Double Pulse' will affect ALL points, both singles and dual.

.

Early releases of RM didn't give the option to disable the 'Double Pulse', it was only added as a result of being requested in the 'RM Desirable Features' thread. Yes, HRMS included the 'Double Pulse' to make point switching more reliable. The delay is included to give Accessory Decoders with integral CDUs time to recharge.

.

I added 'Double pulse=0' (without the quotes) as the last line in my .ini file - I trust that this is correct?

.

Yes, that is correct. It doesn't matter where in the .INI file it appears as long as it is present.

[Fishmanoz]

Interesting exchange.  We must remember at least one pulse per point, even if they have the same number.

 

As Chris said, the default double pulse is just RM belt and braces.

 

And we must acknowledge Bb's Phantom Point solution for passing and reversing loops.  Leave out the point buttons at one end, use the direction arrow at the other end to imply the route, wire both points to the same port, and, even though you can see the point on your schematic, RM doesn't know it is there.  Just as RM doesn't know the connecting track pieces are there.

[St1ngr4y]

As an aside, when points are changed under the control of a program, they are only sent ONE pulse by RM, irrespective of how many points are given the same port number, and irrespective of the INI file setting for Double Pulse. Also, the ProPack feature of points linked to other points or signals doesn't work from within a program.

Ray

[Fishmanoz]

Can't remember Ray, have you put linked points running in programs in desirable features?

[St1ngr4y]

I don't think I did, because a while back I questioned HRMS about this during an email conversation regarding another problem, and they said it was intended to be this way because if you wanted the action of a point or signal to be linked to another, you could simply have the two commands next to each other in a program.

At the time I thought this to be a fairly weak comment but I didn't pursue it.

Ray

[Fishmanoz]

Agree it's a little weak.  If you've set it up that way outside a program, you would expect it to work that way inside wouldn't you.

 

Raises something for the future too - if you run a program that somewhere results in an LD detection, does it then implement the LD setup command routine, which may initiate other programs as well.  Timing issues may well get out of hand in such cases.

[St1ngr4y]

Agree it's a little weak.  If you've set it up that way outside a program, you would expect it to work that way inside wouldn't you.

 

Raises something for the future too - if you run a program that somewhere results in an LD detection, does it then implement the LD setup command routine, which may initiate other programs as well.  Timing issues may well get out of hand in such cases.

I think I raised that very point in the LD discussion a while back. A multiprogramming solution may be needed 😮

Ray