SIGM20 puzzle

[TimP]

I am testing out a CML electronics SIGM20 on my layout with the intention of standardising on it, but have a little problem that I have failed to solve so far, and fear there is no solution - but I'd appreciate any thoughts from other more experienced users.

 

I am using digitrax/loconet

I use BDL 168s for occupancy detection, these work fine and I use them to connect to RR&Co software as well as for loconet inputs to the SIGM20

The RR&Co software does not want/expect occupancy detection over pointwork and seems to work fine with that

 

If have I have say three blocks (1,2, 3) with the second and third blocks connected by some pointwork, each block has occupancy detection. The direction of travel is from block1 to block 2 to block3.

 

Then I run a light engine or other short train - the short train will "disappear" when in the pointwork, when this happens the SIGM20 logic will put preceding signals to green -

 

so looking at the signal say at the end of block 1 it starts GREEN then goes RED when loco enters block 2, then GREEN when it disappears into the pointwork between second and third blocks then AMBER when it "reappears" in the third block then GREEN again when it exits the third block. This is annoying!!

 

Any ideas greatly appreciated!

 

TimP

[two tone green]

This sounds like a config problem in the way you have RR&Co and hardware set up and not a fault of RR&Co or your hardware. But, it is showing that things are in effect working correctly.

 

If you have been following my thread about the basics of automation you will notice my comments about continuous tack circuiting and you have just found out why it is good to have it.

 

Can I ask, do you use RR&Co to control your signals or does the SIGM20 do it. I mean the changing of the aspects. Does the SIGM20 make use of block occupancy and change the signals or is the changing of the signals controlled by RR&CO making use of the info coming from the block occupancy detectors.

 

If you can let me know this, I can go on more.

[TimP]

This sounds like a config problem in the way you have RR&Co and hardware set up and not a fault of RR&Co or your hardware. But, it is showing that things are in effect working correctly.

 

If you have been following my thread about the basics of automation you will notice my comments about continuous tack circuiting and you have just found out why it is good to have it.

 

Can I ask, do you use RR&Co to control your signals or does the SIGM20 do it. I mean the changing of the aspects. Does the SIGM20 make use of block occupancy and change the signals or is the changing of the signals controlled by RR&CO making use of the info coming from the block occupancy detectors.

 

If you can let me know this, I can go on more.

 

Hi TTG,

 

Thanks for prompt response

 

I will look up your automation notes,

 

SIGM20 and RR&Co work independently (other than that they both look at same occupancy detection (and other) loconet messages) with the intention of having the signals work correctly even if manually controlling.

 

So SIGM20 controls signals RR&Co does not and yes SIGM20 makes use of block occupancy to decide.

 

TimP

[two tone green]

First off I don't use Digitrax or Loconet with RR&Co so some of this is 'guessing' but I know a man who does. I expect he will be along soon as he is a Digitrax, RR&Co expert as I tend towards Lenz side of things.

 

But irrespective of this, I think you may need to consider making a few changes and handing over control of your signals to RR&Co if additional track circuiting info cannot be readily introduced into the SIGM20. The configuration and control of signals in RR&Co is very flexible and can be as complicated as you want to the point of replicating actual practice. The Digitrax man arriving soon will tell you all about this as he is famous for it.

 

But there are ways of solving things but best wait until Dave has had his say before I go any further as he may have already solved your problem. I can do it for you in RR&Co with some additional hardware but Dave may know a way of doing it by using your existing hardware.

 

Regards

 

TTG

[Nigelcliffe]

If this thread doesn't get an answer, there is a CML_electronics Yahoo group, where the Laurence the maker of the devices replies to questions.

http://uk.groups.yahoo.com/group/cml_electronics/

[TimP]

If this thread doesn't get an answer, there is a CML_electronics Yahoo group, where the Laurence the maker of the devices replies to questions.

http://uk.groups.yahoo.com/group/cml_electronics/

 

Thanks Nigel and TTG,

 

The answer from Laurence at CML is to put occupancy detection on the points just don't put that occupancy detector into a block in RR&Co if that is what you are using, glad i have done a test layout now as i will be better able to plan my detection for the real thing

 

Tim

[two tone green]

Exactly. Continuous track circuiting.

 

You then use the track circuiting for the points in combination with block occupancy detection to control the signals in RR&Co. The track circuiting also forms part of the interlocking side of things as they are allocated to routes, the bits of track connecting two blocks. In your case your point work.

 

It allows the software to see when a train has cleared point work more reliably then just using the train length set in RR&Co and a calculated guess system. If the train stutters on the point work without the track circuiting being in place, the 'timer' that is set in motion within the software to work out when a train of a certain length at a speed X has cleared a route starts to fail as it thinks the train has passed but its speed has changed so the back end of the train can still be on the point work. So it releases the point work allowing it to be changed and the train goes off in two different directions because it has not cleared the points.

 

So install continuous track circuiting and allocate the sensor to routes and you will find the extra protection useful.

 

It is exactly what I have done and advise people to do to get their signals to work correctly. It is why I wanted to know what controlled your signals, software or hardware.

[TimP]

Exactly. Continuous track circuiting.

 

You then use the track circuiting for the points in combination with block occupancy detection to control the signals in RR&Co. The track circuiting also forms part of the interlocking side of things as they are allocated to routes, the bits of track connecting two blocks. In your case your point work.

 

It allows the software to see when a train has cleared point work more reliably then just using the train length set in RR&Co and a calculated guess system. If the train stutters on the point work without the track circuiting being in place, the 'timer' that is set in motion within the software to work out when a train of a certain length at a speed X has cleared a route starts to fail as it thinks the train has passed but its speed has changed so the back end of the train can still be on the point work. So it releases the point work allowing it to be changed and the train goes off in two different directions because it has not cleared the points.

 

So install continuous track circuiting and allocate the sensor to routes and you will find the extra protection useful.

 

It is exactly what I have done and advise people to do to get their signals to work correctly. It is why I wanted to know what controlled your signals, software or hardware.

 

while i am at it, your automation thread is excellent - i look forward to more installments.

 

TimP

[two tone green]

Thanks. Will be adding more to it next week once I have got this bug out of my system. It will be back to work and I'll have time to sit and type lots.

 

Hope all my efforts have been of help.

 

TTG