Non DCC Point Direction Indication on Railmaster Track Plan

[Greynut]

I have my layout track plan on Railmaster and the DCC controlled points all work very nicely when clicked and all the points set properly on start up. I have also included the other non DCC controlled points on the plan which I actually work by switches powered through a CDU on a totally different circuit to the DCC bus. On the plan, these have got the point firing icon buttons next to them and all show as '00'. The idea being to throw the point using a switch but to change the grey point direction indicator on screen by also using the control icon button - to have a visual indication of the directions of all the points on screen.

 

I get three problems doing this. Firstly, the point direction of the switched non DCC point often just changes back to where it was after a while - I think this happens when a DCC point is thrown after setting the non DCC one. Secondly, on some occasions, when I click a non DCC point button, Railmaster freezes for a minute or two and no points will fire and no locos will move. Then the plan sort of jumps on the screen a little bit and everything works normally again. Thirdly, whenever I click a non DCC point, the screen gives a little jump even if Railmaster doesn't freeze. (It sometimes does the little jump when setting DCC controlled points too.)

 

My thinking is that when firing a non DCC point, Railmaster goes off to ponder the request or it tries to fire the point through DCC, finds it can't and then decides to have a think about it. This produces the little jump ... and causes the freezing when it happens. The annoying thing is that, on most occasions, Railmaster happily switches the point direction indicator without any problem - although it might take a second or so longer to move than with a DCC controlled point.

 

I suppose I could make these points DCC operated but they are all in sidings and give me something extra to fiddle with. Plus it saves parting with cash on extra accessory decoders.

 

I don't know if anyone else gets this but it does go a way to answer some previous concerns that I posted about a month or so ago, when it appeared that the elink seemed to cut out for a time. My thinking now is that it is more likely to be Railmaster 'freezing' for this short period. Generally though, is this something I've missed - is there a 'how to' on handling non DCC points on the Railmaster track plan that I should have read? I've looked but I couldn't find anything. I thought about giving these points a number/setting each but as I they are not DCC controlled, I think that this would confuse Railmaster just as much (if that is what is happening). Does anyone else do this successfully or have any ideas please.

 

Ray

[Nick_]

Instead of leaving them all with address 00 try assigning them individual addresses numbers larger than any you are currently using For real. RailMaster will then think they are real. It wont know and won't care that there is actually nothing on that address

[96RAF]

There was a post a while back about uncommanded points switching when another point was selected. This always seemed to boil down to the errant point buttons having been placed under/over another point or had been erroniously been given a duplicate address.

The suggestion to give them a ficticious address out of your normal points range seems a good idea. Besides if you leave them all at 00 then each time you select one all the others will change to match that first selection.

RM is essentially dumb and just does exactly as it is told. It doesn't look back to see if any of that stuff actually happened.

[Greynut]

Many thanks Nick and RAF for your replies.

 

I'll give it a whirl and give each non DCC point a unique number. I was being much too complicated in my thinking in that there might be a further problem in setting a fictitious point as DCC. Of course, all RM actually must do is give a pulse to a programmed number and it's the decoder that catches it and fires the point. In this case, if there's no decoder RM doesn't know and isn't bothered. The freeze etc. must be coming from the duplication of point icon button numbers. I'll report back later when I've changed things.

 

Although, to be fair to RM, when I change a non DCC point direction indicator, even with the duplicate '00' numbers, it's only the clicked point direction indicator that changes, not all of 'em, and not any of the others. But, as I said in my original posting, they often do not hold the changed direction, something resets them later.

 

It's just a thought but perhaps it might be something that could be added to RM. Another set of 'non firing' point icons and maybe a different colour direction indicator that can be used simply to give a visual indication, on screen, of non DCC point direction.  It might be useful enough to think about.

[96RAF]

[Me]... if you leave them all at 00 then each time you select one all the others will change to match...

[You]... even with the duplicate '00' numbers, it's only the clicked point direction indicator that changes, not all of 'em...

 

Thinking about it again Greynut this is a bit like the problem we have seen with passing loop points given the same address. We want to select one and have both change but they don't, so maybe I am wrong in my thinking.

[Greynut]

Each non DCC point now has a unique number and it works a treat (well it has so far). No jumping screen and no freezing.

 

I think it was the screen jumps and freezing that made me think that it was more complicated than simply giving unique numbers. It made me think that there was more interaction between the accessory decoders and RM than there actually is.

 

What I'm thinking now is that if there is duplication of point numbers - or certain point arrangements, RM goes into a loop which either lasts a second or freezes everything for a bit longer. The screen jump is RM coming out of the loop and unfreezing.

 

RAF, I have included a non DCC cross over and given both points the same number and this works. Click one button and both of the point indicators change.

 

Again though, referring back to the RM going into a loop idea, when I change a DCC controlled cross over (and the non DCC one) the clicked grey point indicator line changes immediately but its partner takes a second or so longer to change. I wonder if that's significant regarding passing loop point problems ... does any unclicked duplicate confuse RM a bit when its partner is clicked and do other settings add to the confusion? Although, on one of my DCC controlled crossovers, I have a different combination to the norm in that one point sets left as the other sets right. (Just like a passing loop.) In my case, it's because it's not a direct, straight across type crossover between 'same handed' points. It's one where the spur of left hand point connects to the straight of a right hand point via a curve. And this works OK. Both indicators follow the correct point directions - there is still the same second or so delay before the unclicked indicator changes. It is odd how the same combination works in one configuration but in the passing loop layout, not in another.

[96RAF]

RM sends each point command twice Greynunt - that may be why you are seeing a delay. First (any - slackest) one fires then the other one fires with the second tap.

[Greynut]

It certainly could be that. I have heard the multi click on DCC operated points so even firing a single point has the potential for a built in delay. I have noticed though that there often is still a small delay, with DCC fired crossovers, between the last firing click and the non clicked point indicator moving.

[Fishmanoz]

Won't the delay be the delay set in the Railmaster.ini file?

[96RAF]

So you are saying the points change fairly promptly but the screen indication is lagging behind.

[RDS]

My screen indications lag slightly behind

[Chrissaf]

As do mine.

[Greynut]

Hi Fishy, Chris and RDS.

 

Fishy, the delay in the .ini file shows as '1' which I took to be the delay before any clicked indicator changed and this seems about right on screen when a point is fired. I suppose though it could also affect the timing of the second indicator moving on cross overs - i.e. 1 second after the first but it is more like a 3 second delay. Since allocating unique numbers to non DCC points I'm not getting freezes or screen jumps ... so that has been cured. I'm not really too troubled about the second indicator delay and it's reaasuring to see you get this as well - but I wondered if it was significant in giving a clue to some problems that have been added to the forum regarding multi point firing.

 

Chris - with the DCC cross overs, both points seem to fire together and it's the screen indication that lags - or at least there is that lag with the non clicked indicator moving. And the same lag with indication on the non clicked indicator on non DCC cross overs.

[Chrissaf]

Chris - with the DCC cross overs, both points seem to fire together and it's the screen indication that lags - or at least there is that lag with the non clicked indicator moving.

.

Exactly the same as I get too Ray. I think the screen indication delays are as normal for the way RM software is written.

[St1ngr4y]

When you click a point icon on your layout diagram, RM will fire two commands to its address a second or two apart. If you have two points with the same address, e.g. in  crossover, RM will fire two commands for each point i.e. four altogether. However, I find that in this situation you only hear three clicks from the points. My theory is that the first command for the second point is almost instantaneous with the second for the first point. I would guess that the more points you have with the same address, then this 1 or 2 second delay will mount up and RM will appear to freeze while it fires each configured point in succession. I would also summise that the point indicator on the screen will not change until that point is fired in its turn. Hence the lag for the non-fired point of a pair.

Speaking as an ex-computer programmer, I have been trying to work out how RM responds to the click of a button on the screen. My conclusions are as follows....

RM will read the layout file at startup and store all of the points records in a table in memory.

When a points button is clicked, it will use the screen co-ordinates of that button to locate the record. When it finds that record, this will tell RM the address of the point and whether it is being switched left or right. 

RM will then issue a fire DCC command for that point address.

RM must then search the rest of the table of points for other records which have that address and each time it finds one it will fire off another DCC command to that address. By the way, did you know that the Layout file contains two records per point icon - one for the green button and one for the red button.

If anyone can think of any other way RM might operate points please feel free to speculate !!

Ray

[Fishmanoz]

Ray, you have me somewhat confused.  While RM may be able to tell how many points are on a single port/address,cthe points themselves can't so both will try to change on the first pulse.  Clearly any subsequent pulses may then help if one or both don't change first up, but always both points will get those pulses.

 

Greynut, the value in the ini file is the minimum delay between point firings, has nothing to do with delays in anything appearing in the schematic.  It is there to allow a CDU to recharge before attempting to fire off another pulse to any point.

[St1ngr4y]

Ray, you have me somewhat confused.  While RM may be able to tell how many points are on a single port/address,cthe points themselves can't so both will try to change on the first pulse.  Clearly any subsequent pulses may then help if one or both don't change first up, but always both points will get those pulses.

 

 

You are quite correct Fishy, real points with the same address will always react to the first DCC command sent to its decoder port. I am simply summising that RM may be searching the rest of the points table for other points with the same address, in order to fire an extra pulse e.g. in the case of a crossover. However, if you have 10 "non-DCC" points with the same address, it will go through the same process trying to fire them one by one with "delay" seconds between each one, and it is this which would give the impression of RM freezing.

Ray

 

 

[Greynut]

Fishy, in my .ini file I have 'Points timer=0.75' (not '1' as I said before) so, as you say, I think the built in delays on my setup amount to 0.75 seconds between pulses - then once all the pulses are done, the direction arrow changes. On cross overs with 3-4 pulses, this would account for the slight delay with the clicked point indicator changing but the non clicked indicator can take a couple of seconds longer to change.

 

Ray, I certainly go along with your thinking of how it works but a couple more thoughts.

 

When I first posted I was thinking that RM simply gave a numbered pulse when that point number icon was clicked and treated the direction of throw according to which icon (red or green) was used. In other words, for the actual firing, RM wasn't bothered where the point was on the plan as it left the accessory decoders to sort that out when they 'caught' the pulse. (Techno speak or what.) It was only after RM threw the pulse did it look at the schematic side of things relating to which point was fired so it could set the indicator(s). But what you say shows that before the first pulse is thrown, RM does a look up on that number and acts on that. Makes more sense than my thinking and it does seem more involved than it first appears.

 

It also makes more sense in that the crossover that I have, where when one point throws one way and the other throws the opposite way, works OK. If my way of thinking was right then on that crossover, if I clicked the icon to throw to the right, both would throw to the right - they don't. So RM must be looking up the current point settings for direction of throw required as both points change correctly and also both of the indicators change correctly ... after a lag, of course ;-)