Jump to content

Train-Tech signals out of sync with RailMaster diagram


Recommended Posts

  • Replies 53
  • Created
  • Last Reply

OK Ray. I'll try that.

 

Interestingly, as I was just about to report, though I have completely closed down and opened Railmaster several times and had a couple of power down cycles since, without the anything changing, yesterday when I booted up, the signal was back in sync and I unticked reverse polarity. Let's see what happens next time and I'll do what Ray suggests...........

Link to comment
Share on other sites

Next time one of your Dapols gets out of sync, try closing RM and reloading it, rather than changing the reverse polarity setting. See if that fixes it and let us know.

Ray

 

Ray. It just happened again ie one of my Dapol semaphors is out of sync with its symbol on the track diagram. I tried what you suggested (without reversing polarity) and I'm afraid, no joy. It's still out of sync. I tried closing and reloading RM with and without resetting the ELink as well as de-powering the ELink. So, again, I have had to resort to clicking "reverse polarity" until such time as the semaphor signal gods deem it's time to revert to the orginal setting! How very odd!!

Link to comment
Share on other sites

I often see RM get function buttons out of synch with what the loco is doing so I am not surprised your signals are doing the same.

There is nothing I can click to swap my faulty actions over and they are always OK for logic next time I start up. I think it is a timing thing when I select the function it is not being picked up by RM. If I slowly click and hold a button for a bit it seems to work better.

Rob

Link to comment
Share on other sites

Next time one of your Dapols gets out of sync, try closing RM and reloading it, rather than changing the reverse polarity setting. See if that fixes it and let us know.

Ray

 

Ray. It just happened again ie one of my Dapol semaphors is out of sync with its symbol on the track diagram. I tried what you suggested (without reversing polarity) and I'm afraid, no joy. It's still out of sync. I tried closing and reloading RM with and without resetting the ELink as well as de-powering the ELink. So, again, I have had to resort to clicking "reverse polarity" until such time as the semaphor signal gods deem it's time to revert to the orginal setting! How very odd!!

 

One more thought - do you have your system configured to "Set points on startup" ? I believe this setting covers signals as well.

 

Ray

Link to comment
Share on other sites

@BagEndJct

 

I too have Dapol semaphore signals, some of which are stand alone as you appear to have. With these, as you have configured "Set points on startup", you need to make sure on closing down from a running session that the signals are set to the opposite to the required startup position. This is because RM sends a pulse to the signal on startup,and thus this changes the position of the signal from its last used position.

 

With the signals that are associated with points, with the same decoder port number, then you can alter the signal position by clicking on the point button that will not alter the position of the point.

 

Hope the helps.

 

BarryO

Link to comment
Share on other sites

@BarryO

 

Hi Barry,

I'm not sure what you mean when you say "RM sends a pulse to the signal on startup, and thus this changes the position of the signal from its last used position.". When you configure a signal in the Track Designer, you specify either Clear or Stop as its startup position. How will startup (always) change its position from its last used position?

 

Ray

Link to comment
Share on other sites

@St1ngr4y

 

Ray

 

With Dapol signals, a pulse operates the signal irrespective of the arm position. The next pulse received then operates the signal and moves the arm back to the original position. Therefore, RM does not have any idea of the actual position of the signal - i.e. whether it is on or off. The pulse from RM is given to the signal  via an accessory decoder port , with both left and right terminals on the port connected together, and then through a solenoid relay. Below is a diagram of the circuitry, courtesy of 'idlemarvel'.

/media/tinymce_upload/74fab7dee46ecb56644017979af36d8f.jpg

 

'Chrissaf' has produced a better more refined circuit in a previous topic on Dapol signals, but the above diagram gives the necessary explanation of the method of control and the possible reason for the out of sync operation being experienced by BagEndJct

 

Regards, BarryO

Link to comment
Share on other sites

Another way of explaining the Dapol signals is that there are four wires from the signal, 1 black, 1red and two yellow.

The red and black are the power to the signal. The two yellow wires, when connected together, by a non locking switch or pushbutton for instance, toggle the switch between on and off.

 

Fully explained here http://www.gaugemaster.com/articles/product-spotlight/dapol-semaphore-signals.html

 

Do not apply power to the two yellow wires under any circumstances.

Link to comment
Share on other sites

It's the way that Dapol semaphore signals work Ray.

.

They don't have a separate control wire for clear or danger. They use a single control wire with a current return wire that acts as a 'toggle'. You apply a voltage to the control wire and the signal changes state from whatever state it was in before the voltage pulse was applied. You then pulse the SAME wire again to toggle the signal back again. So once they lose sync it is difficult to get them back into sync again, using anything in RM other than the 'reverse operation' feature (which is basically just changing the icon to point the other way).

.

 

 

Aha - that explains it - thanks Chris. So are they pre-DCC ? They certainly aren't DCC-friendly. It's just as bad as the latching sound functions in loco decoders which need "toggling" too.

 

Ray

Link to comment
Share on other sites

It's the way that Dapol semaphore signals work Ray.

.

They don't have a separate control wire for clear or danger. They use a single control wire with a loop return wire that acts as a 'toggle'. You apply a metallic loop to the control wire and the signal changes state from whatever state it was in before the loop was applied. You then loop the SAME wires again to toggle the signal back again. So once they lose sync it is difficult to get them back into sync again, using anything in RM other than the 'reverse operation' feature (which is basically just changing the icon to point the other way).

.

I thank Rog(RJ) for correcting me (see next post). I was working from memory and had forgotton that the control wire is not voltage based but based upon a metallic loop. I should have known better, because I have previously published a DCC decoder interface circuit for Dapol signals in this very forum. Copy below.

.

I have therefore corrected my original reply and re-posted it as an edit in its corrected form.

.

/media/tinymce_upload/c6466e439c165008f76692cb12fe763e.jpg

.

Link to comment
Share on other sites

An alternative cheap, quick and simple solution to using the RM 'reverse operation' feature.

.

Given that the Dapol signal is changed state by a metallic loop across the two yellow control wires then it would be very easy to implement a manual control overlay system that extended 'Teed in' connections to the two yellow wires to the top of the baseboard adjacent to the signal. Two brass screws for example. Then when a Dapol signal gets out of sync with RM, you just very briefly link the two visible screw heads together (with a paper clip for example) to put the Dapol signal back into sync.

Link to comment
Share on other sites

Ray,

 

My apologies for not apprearing to reply to your original question, but I drafted a reply earlier this morning and clicked on the reply button. However, as it contained a diagram (similar to Chrissaf's) I assumed that it was awaiting approval by Admin before being posted. As it is now over 4 hours since I attempted to reply, I assume it was timed out and got lost in the ether. Since most of the content has now been admirably covered by subsequent posts, I will not repeat my earlier reply.

 

In essence, RM does not know the position of the signal and the next pulse only changes the signal from the last position, whether it be on or off

 

I like Chrissaf's excelent suggestion of providing a means of overcoming the out of sync operation, and may incorporate this should I find out of sync is happening too often.

 

Regards,

 

BarryO

Link to comment
Share on other sites

Ray.

 

Whilst i agree that there slight drawbacks when operating with DCC, I personally do not consider them non DCC friendly. I have been very pleased with them, once I had sorted out the initial problems of the installion instructions giving the incorrect voltages and whether AC or DC.

 

I have 6 on my layout, 4 are stand alone, the other 2 linked to points. With the standalones, I only get out of sync if I have not made certain they are in the "wrong" position for startup when I shut down. With the ones linked to points, initially I had occaisional out of sync on one signal, which I discovered was due to having "double pulse" set in the ini. file. Once I had set this to "0" I have not experienced any further problems.

 

Regards,

 

BarryO

Link to comment
Share on other sites

Hi BarryO,

 

Yes, I understand now how the Dapol signal works. When I said that I thought it wasn't DCC-friendly, maybe I should have said it isn't Railmaster-friendly. Railmaster needs to know the "state" of a controllable object on the layout. Now, accessory and loco decoders don't provide Railmaster with this information, so the only way RM can get itself into sync with these objects is to send a distinct command to the object e.g. a Stop command to a signal, a left command to a point, a Whistle on command to a loco etc. This Dapol signal arrangement, as you say, does not give RM any idea as to the current state of the signal.

 

I mentioned the Whistle On command to a loco. I have been saying for quite a while that the commands in RM programs for sounds should provide the option of On OR Off, rather than the current implementation of one command which toggles it from its current state.

 

Ray

Link to comment
Share on other sites

I agree with your last statement Ray.

 

It is too easy for RM to skip a command, at least to send it and the decoder not get it, such that an on/off function misses the on command, then comes on when it should be going off or vice versa.

 

This is even more frustrating when using a sound function that needs time to play out else it intereferes with the next command. One could do with each function command having to receive an ACK else it repeats the command until it does.

Rob

Link to comment
Share on other sites

I agree with your last statement Ray.

 

It is too easy for RM to skip a command, at least to send it and the decoder not get it, such that an on/off function misses the on command, then comes on when it should be going off or vice versa.

 

This is even more frustrating when using a sound function that needs time to play out else it intereferes with the next command. One could do with each function command having to receive an ACK else it repeats the command until it does.

Rob

 

Hi Rob,

You may be interested in something I've started to do recently. As you know I do most of my running using programs, and I noticed the 2-3 second delay caused by "trigger" functions in RM i.e. those which don't have "on/off" in their description. I've actually changed the definitions of these functions in some of my locos to make them into "latching" functions by adding "on/off" to all of them. This means when the sound is invoked by the first occurrence of the command in the program, there is no artificial delay inserted by RM, and a close-following command will be obeyed without delay. It means, of course, adding a second command for the same sound later in the program, but this can be done at a point where no other commands are being actioned. Of course, this second command for the same sound doesn't cause the actual sound to be played again - it simply switches it off in RM, the controller and the decoder.

 

However, I still wish that, for example, this command ....

 

F1 Sound on/off

 

in the command list in the program editor, could be replaced by these two commands...

 

F1 Sound on

F1 Sound off

 

 and for all other latching commands

 

Ray 

Link to comment
Share on other sites

@Ray

Thanks, I will give that method a go, although for the purpose of my latest programs the spot sound can last for over half a minute before it plays out and I can run more than one spot and/or looped sound together, so picture this - starting up a spot sound, then anytime after that starting a looped sound. My problem has been if I hit a selection twice rapid then it hogs the next slot and the second sound doesn’t start, so my first thought to send a double tap doesn’t solve my problem.

 

If it works I will start a new thread.

Rob

Link to comment
Share on other sites

@Rob

 

Often, I leave all of the "switch off" sound commands to the very end of the program, as long as they aren't needed before then. The thing is, that if you leave a spot sound without the "on/off" qualifier, then RM sends an "on" command to the controller, waits in a loop for a couple of seconds, then sends an "off" command.

I would welcome a new thread to discuss these issues as they aren't relevant to this thread.

 

Ray

Link to comment
Share on other sites

@Rob

Often, I leave all of the "switch off" sound commands to the very end of the program, as long as they aren't needed before then. The thing is, that if you leave a spot sound without the "on/off" qualifier, then RM sends an "on" command to the controller, waits in a loop for a couple of seconds, then sends an "off" command.

I would welcome a new thread to discuss these issues as they aren't relevant to this thread.

Ray

 

New topic started Ray

Link to comment
Share on other sites

  • 5 months later...

@St1ngr4y & @@BagEndJct

 

My layout is currently down for a move. Have either of you time to test V1.70.1 with the very simple diagram (one piece of track & 2 signals) that I posted on page 2 of this thread. Thanks.

Paul

 

Hi Paul,

 

The fault you mentioned appears to be still present in 1.70.1. See also my post on page 3 of the 1.70 thread. HRMS are looking into this.

 

Ray

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.


×
  • Create New...