Block detection and automation test/practice layout

[gavino200]

5 minutes ago, inobu said:

The problem is you keep thinking routing. When you use RailCom to your advantage it is a different story.

 

In this example a Railcom section is placed at each entry of platform 1. The system can know from which direction the train entered and who it is without any

concern of the switch or route. The way you have it set up it is dependent on routing. In this scenario it is based on detection not routing. 

 

 

 

Inobu

 

So railcom detection blocks can be scattered around the layout and still give the same result as having all the blocks railcom detected. There should be no real advantage to having all blocks RailCom detected. 

[Martijn Meerts]

6 minutes ago, inobu said:

The problem is you keep thinking routing. When you use RailCom to your advantage it is a different story.

 

In this example a Railcom section is placed at each entry of platform 1. The system can know from which direction the train entered and who it is without any

concern of the switch or route. The way you have it set up it is dependent on routing. In this scenario it is based on detection not routing. 

 

 

 

Inobu

 

How does it detect which direction the train is coming from in this case? If for example RC-PTFM-1-E detects a train, it can still be coming from both directions. It'll only know which direction it's coming from by checking which was the previous block it was in (which essentially makes it a route), or check which of the 2 entry/stop sections gets triggered first.

 

[inobu]

1 minute ago, Martijn Meerts said:

 

How does it detect which direction the train is coming from in this case? If for example RC-PTFM-1-E detects a train, it can still be coming from both directions. It'll only know which direction it's coming from by checking which was the previous block it was in (which essentially makes it a route), or check which of the 2 entry/stop sections gets triggered first.

 

RC-PTFM-1-E The translation for the section......RC = Railcom............PTFM = Platform 1 E = East.

 

How can a west bound train activate RC-PTFM-1-E?

RC-PTFM-1-W  is the West.

RC-PTFM-1-STN is the Station  

 

This configuration has its own basic logic.

 

Inobu

 

[inobu]

8 minutes ago, gavino200 said:

 

So railcom detection blocks can be scattered around the layout and still give the same result as having all the blocks railcom detected. There should be no real advantage to having all blocks RailCom detected. 

People are so locked into a certain usage they cut themself short. Like Chadbag said you can use the systems which ever way you want just keep them in order.

 

Railcom can be cut off or not used. What I tell my clients get it and use it whenever you need to. As time progresses it will get better and better.

 

In the early 90's I had a friend to build a custom home. I told him to run CAT5 in every room and on 2 walls. The builder questioned it but he said he told the builder to just do it.

15 years later we were laughing about it. People don't know what they Don't know. 

 

Railcom is a safe bet.

 

Inobu

[Martijn Meerts]

Ah, so you're not using the east and west sections as stop sections? Often in a multidirectional track, there's 3 sensors, where the 2 outer ones function as both entry and stop. That's how I read the diagram.

 

So, train comes in, activates W and starts decelerating, then activates STN, and then stops at E. Form the other direct, it starts braking at E and then stops at W. But you probably have it set up to enter in for example W, and then stop inside STN without ever triggering E. In that case, yes, it can detect the direction. The same setup can be done in most programs without using RailCom and without any routing as well, but again, you won't get the the confirmation there.

 

I think it's also a different way of thinking how JRMI compares to iTrain / Traincontroller / RocRail and the like. Those are much more focused on a switchboard, and in most cases also routing and then just running trains. JRMI seems used a lot more for layouts that are for a large part also manually operated for simulating real operations etc.

 

 

Again, I'm definitely not against RailCom (I have a Lenz digital system, as well as the ECoS, so plenty RailCom capable stuff), but the investment can be too big if you have (part of) an existing layout that doesn't use RailCom yet. For example, S88 doesn't support RailCom I believe, so if you have S88 occupancy detection, the entire detection system would need to be replaced. In that case, it wouldn't be worth it. If you're starting now, and you don't need a lot of detectors, or at least don't need to buy them all right away, there's definitely a reason to go for RailCom enabled detectors. If, on the other hand, you need 10 detection modules right away, the RailCom enabled ones would be quite a hefty extra investment at that time, although relatively speaking it'd be a small part of the cost of the rest of the digital system.

 

I do wonder if they're going to expand on RailCom though. Since it's introduction, very little has happened. Lenz seems to have more or less given up on it, and only when ESU got involved, they did the RailComPlus thing. When Lenz initially announced it, they only had the loco address display module, and they said a lot more features were coming. At the moment, they still only have the loco address display module 😄

 

 

 

[gavino200]

14 minutes ago, Martijn Meerts said:

 

I do wonder if they're going to expand on RailCom though. Since it's introduction, very little has happened. Lenz seems to have more or less given up on it, and only when ESU got involved, they did the RailComPlus thing. When Lenz initially announced it, they only had the loco address display module, and they said a lot more features were coming. At the moment, they still only have the loco address display module 😄

 

What kind of things could be added to RailCom?

 

[Martijn Meerts]

No idea, I’ve always wondered that as well. I just remember that when they announced it, they made it sound like a lot more was to come. I guess you could send back more info on the locomotive, but that’s not really needed unless you do computer control, and if you do computer control, it’s just as easy to just ask the loco for those details after it was detected in a block, saves on bandwidth too.

[inobu]

3 hours ago, Martijn Meerts said:

Ah, so you're not using the east and west sections as stop sections? Often in a multidirectional track, there's 3 sensors, where the 2 outer ones function as both entry and stop. That's how I read the diagram.

 

So, train comes in, activates W and starts decelerating, then activates STN, and then stops at E. Form the other direct, it starts braking at E and then stops at W. But you probably have it set up to enter in for example W, and then stop inside STN without ever triggering E. In that case, yes, it can detect the direction. The same setup can be done in most programs without using RailCom and without any routing as well, but again, you won't get the the confirmation there.

 

I think it's also a different way of thinking how JRMI compares to iTrain / Traincontroller / RocRail and the like. Those are much more focused on a switchboard, and in most cases also routing and then just running trains. JRMI seems used a lot more for layouts that are for a large part also manually operated for simulating real operations etc.

 

 

Again, I'm definitely not against RailCom (I have a Lenz digital system, as well as the ECoS, so plenty RailCom capable stuff), but the investment can be too big if you have (part of) an existing layout that doesn't use RailCom yet. For example, S88 doesn't support RailCom I believe, so if you have S88 occupancy detection, the entire detection system would need to be replaced. In that case, it wouldn't be worth it. If you're starting now, and you don't need a lot of detectors, or at least don't need to buy them all right away, there's definitely a reason to go for RailCom enabled detectors. If, on the other hand, you need 10 detection modules right away, the RailCom enabled ones would be quite a hefty extra investment at that time, although relatively speaking it'd be a small part of the cost of the rest of the digital system.

 

I do wonder if they're going to expand on RailCom though. Since it's introduction, very little has happened. Lenz seems to have more or less given up on it, and only when ESU got involved, they did the RailComPlus thing. When Lenz initially announced it, they only had the loco address display module, and they said a lot more features were coming. At the moment, they still only have the loco address display module 😄

 

 

 

You don't use Railcom for stop detection. That is a completely different method. You use different types of sensors to stop trains.  When I complete these jobs I will set up a station

showing the different aspects.

 

Inobu

[Martijn Meerts]

I know you don't use RailCom for stop detection, I just assumed you were using the "traditionally recommended" setup of 3 sections per block, which you probably aren't.

 

[gavino200]

My little junction switches came today, sooner than expected, so I wired up the junctions and the junction controller. The test layout is pretty much ready to go now. And I have no work obligations this weekend so it's time to start learning how to use the software. I just started the free iTrain trial. Looking forward to playing around with it. 

 

I also picked up another two detector blocks, a bunch of junction switches, a loconet hub, and the optical sensor receiver. I'll test it out on my tram optical sensors at some point and probably install them in the "station" part of the test layout. This is a convenient time to learn how to use them as I currently have my platforms and station buildings taken apart for an overhaul. I'll look at installing optical sensors into the platform sides while I'm working on them. 

 

 

 

 

[inobu]

Testing and mock up is where all the fun in learning happens.

 

Inobu

 

 

 

 

[gavino200]

With the exception of one massive temporary setback, I've been making good progress. It's been enjoyable with the exception of the setback. The Digikeijs DR4018 is a unit that can turn switches with the help of an accessory relay, or operate signals and lights. To use on Kato switches, nothing at all needs to be done to it. All the factory settings are just what they need to be for Kato switches. I had it functioning about 90% but then made a wiring goofup. Not spotting the error, I went back to the beginning with the unit and followed a video titled "setting up the 4018". Unfortunately it was for using it with tortoise switches. Before I realized this I changed a CV value without first writing the original value (dumb right?). Well, the unit then wouldn't work at all and I wasn't able to reset it using the manual instructions. Trying it one last time, I got it to reset and it works now. I guess it's better to be lucky than wise. Or as good? Well, I'm happy anyway.

 

So I have the basic track plan in iTrain, and the junctions are responding to iTrain commands. Using the Digikeijs command center, I can see that the blocks are being detected, but the block data isn't yet added to iTrain. That's the next step. 

 

I like iTrain a lot. And I found a great YouTube tutorial that guides through the process very clearly and calmly. The link is below. 

 

 

 

 

Edited February 1, 2021 by gavino200

[inobu]

You have to really pay close attention to the Digikiejs stuff. The manuals are kinda hard to follow. I would write the configuration down in order to

get a good visual. I know its a typo in the DR4088 but it takes time to get things straight as all the numbers are similar.

The DR4018 is the turnout and the DR4088 is the feedback module and the 50 is railcom. 

 

It will be interesting to see the effects of the control and programming being conducted by track power. The noise on the track has the tendency to

interfere and look like POM which changes the CV's. I'm working a ECoS build right now so I'm watching your Digikeijs work to save time. 

 

Inobu

[gavino200]

Well, yes. Writing things down is a good idea. For me the lesson is to make modest gains and move to a different task. I spent a long time on the test layout yesterday, and ended up making a mistake I wouldn't have made if I wasn't tired.

 

The Digikeijs instructions are a mixed bag. Some of the English translations are a bit iffy, but the German translations are better and I can use those to bridge the gap. They do, have very nice diagrams and their computer graphical interfaces are nice, so overall I don't hate the Digikeijs manuals. 

 

The problem with resetting the junction/signal control unit is with the unit itself. I've found lots of people online who've had problems with it. Digikeijs recommend using a 150-270 ohm resister across two of the outputs to allow the unit to be detectable. I found a video of a guy setting this unit up for signaling. He used a "grain of wheat" lightbulb instead of the resistor. He said the unit is detected much better that way. The rep who I spoke to, quickly advised me to drop the resistor method. When I finally got it to work it was with programming on main with the unit powered by it's own transformer. 

 

It's a nice little unit but it doesn't seem quite as good as the other Digikeijs units, which are quite slick. I hope they redesign it at some stage. All it is, is 8 DCC function decoders in a box. A LocoNet device would be far preferable. 

Edited February 1, 2021 by gavino200

[Martijn Meerts]

8 hours ago, gavino200 said:

With the exception of one massive temporary setback, I've been making good progress. It's been enjoyable with the exception of the setback. The Digikeijs DR4018 is a unit that can turn switches with the help of an accessory relay, or operate signals and lights. To use on Kato switches, nothing at all needs to be done to it. All the factory settings are just what they need to be for Kato switches. I had it functioning about 90% but then made a wiring goofup. Not spotting the error, I went back to the beginning with the unit and followed a video titled "setting up the 4018". Unfortunately it was for using it with tortoise switches. Before I realized this I changed a CV value without first writing the original value (dumb right?). Well, the unit then wouldn't work at all and I wasn't able to reset it using the manual instructions. Trying it one last time, I got it to reset and it works now. I guess it's better to be lucky than wise. Or as good? Well, I'm happy anyway.

 

So I have the basic track plan in iTrain, and the junctions are responding to iTrain commands. Using the Digikeijs command center, I can see that the blocks are being detected, but the block data isn't yet added to iTrain. That's the next step. 

 

I like iTrain a lot. And I found a great YouTube tutorial that guides through the process very clearly and calmly. The link is below. 

 

 

 

 

 

That's the video series I linked to earlier in the thread 😄

 

I know pretty much all of what's explained already, but it's still a very nice set of videos to watch, and Bob explains things very well.

 

[inobu]

I've started to migrate the ECoS system into Rocrail and it seems like iTrain and Rocrail uses the same programming engine.

 

Inobu

[Martijn Meerts]

RocRail is c/c++ based, iTrain is Java based. Visually they're very similar, but iTrain's UI is more refined. RocRail does have more features and often supports some of the more custom / exotic DCC equipment.

 

[chadbag]

Digikeijs is coming out with the DK50018 switch decoder

 

https://www.digikeijs.com/en/dk50018-switch-decoder.html

 

I don't know how different it is other than having a wireless app for configuration.

 

[chadbag]

15 hours ago, inobu said:

 

It will be interesting to see the effects of the control and programming being conducted by track power. The noise on the track has the tendency to

interfere and look like POM which changes the CV's. I'm working a ECoS build right now so I'm watching your Digikeijs work to save time. 

 

 

It is still using the "track" lines but I control my DR4018 using the Railsync lines on a Loconet output from the DR5000 or a Loconet compatible booster (and of course its own power transformer).

 

Not kn owing how "filtered" the railsync lines are in a Loconet connection, will this help with what you described?

 

[gavino200]

54 minutes ago, chadbag said:

 

It is still using the "track" lines but I control my DR4018 using the Railsync lines on a Loconet output from the DR5000 or a Loconet compatible booster (and of course its own power transformer).

 

Not kn owing how "filtered" the railsync lines are in a Loconet connection, will this help with what you described?

 

I think this will come down to whether or not the DR5000 is still sending the switching messages out over the rail wires in spite of your clever Loconet trick

 

The theoretical interference would only occur if the switching messages were sharing a conduit with train control messages.

 

This is the “bandwidth” question from the LCC discussion. Many people say that for anything less than a giant layout, it’s a moot point. It’s been tested to an extent on huge temporary t-track layouts.

 

If I can separate the messages I will. If not,  I’ll just go ahead and see what happens.

Edited February 1, 2021 by gavino200

[chadbag]

I would expect everything on the railsync wires to be on the track itself and vice versa -- from the command center output point of view.. I was wondering about the actual physical effect of the switch decoders being hooked to one or the other and any interference from the physical devices on the lines and whether that can be isolated.

[inobu]

1 minute ago, chadbag said:

I would expect everything on the railsync wires to be on the track itself and vice versa -- from the command center output point of view.. I was wondering about the actual physical effect of the switch decoders being hooked to one or the other and any interference from the physical devices on the lines and whether that can be isolated.

That is a good move. Its a common issue with the DS64 using track power in that it often loses its configuration.  I think the lower level Loconet railsync may provide a quieter signal needed

to mitigate the reprogramming issue.  I would suspect the issue occurs on power up.

 

Inobu

[gavino200]

11 minutes ago, chadbag said:

I would expect everything on the railsync wires to be on the track itself and vice versa -- from the command center output point of view.. I was wondering about the actual physical effect of the switch decoders being hooked to one or the other and any interference from the physical devices on the lines and whether that can be isolated.

 

I very much doubt that. It's a one way input.

 

[gavino200]

1 minute ago, inobu said:

That is a good move. Its a common issue with the DS64 using track power in that it often loses its configuration.  I think the lower level Loconet railsync may provide a quieter signal needed

to mitigate the reprogramming issue.  I would suspect the issue occurs on power up.

 

Inobu

 

Track power? Or signal from the track output? The DR4018 receives signal from the track output wires of the command center. It can also be wired be powered by those wires too but it's recommended that it should be powered independently. 

 

Can you explain more about why the DS64 (whatever that is) loses it's configuration by being "Powered" by the track?

[chadbag]

5 minutes ago, gavino200 said:

 

Track power? Or signal from the track output? The DR4018 receives signal from the track output wires of the command center. It can also be wired be powered by those wires too but it's recommended that it should be powered independently. 

 

Can you explain more about why the DS64 (whatever that is) loses it's configuration by being "Powered" by the track?

 

 

I feed my DR4018 using the Railsync wires from a Loconet output from the command center (or a booster in my case)  (the outermost wires in the loconet cable).