Block detection and automation test/practice layout

[gavino200]

I leveled the layout surface as well as I could and glued down the tracks, as suggested by @inobu Using nails was a about as successful as it sound like it would be. I also tidied up the wiring a bit. All that mess was really bugging me. I'm hoping this track layout will be the last before moving to the new layout and setting up my station with a simple loop.

 

 

Next up I'm going to get another DR4018 and use it to start playing with signals.

 

 

[Madsing]

Digikeijs has a new accessory decoder, the DK50018. I don't have it, but reading the specs it seems that it is programmable via Bluetooth using their app (instead of via DCC and CVs). This looks interesting.

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

[gavino200]

4 hours ago, Madsing said:

Digikeijs has a new accessory decoder, the DK50018. I don't have it, but reading the specs it seems that it is programmable via Bluetooth using their app (instead of via DCC and CVs). This looks interesting.

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

 

That's good news. I think @chadbag mentioned before that that was on the way. I'll definitely get one for my signals. The DR4018 was a bit difficult to program and reset, so I think this will be an improvement.

 

I had a long day trying to trouble shoot a problem on my practice layout. Trains weren't stopping on one particular yard line. I spent hours trying to solve it, but couldn't, so I just removed the yard line, and started playing with the automation. I got four trains running completely autonomously. It was pretty cool. The work is starting to pay off.

 

Watching the trains move and all the planning on the switchboard I got to wondering what kind of computing power is needed for this. I'm guessing not that much if a RasPi can handle it. But I wonder what the ideal computer would be to run this stuff. I'm running iTrain on an old Lenovo Thinkpad that I got free from a previous job. It's about 8 years old. I would have thought it would be good enough for train automation. But iTrain does seem to be glitchy. It seems to jam or just get things wrong from time to time.

 

What computer parameters would be ideal for running software like this to it's limit with as few glitches as possible?

[Madsing]

37 minutes ago, gavino200 said:

I got four trains running completely autonomously. It was pretty cool. The work is starting to pay off.

I have exactly the same feeling. Of course we are all different, and we are probably each looking for different things, but I also feel that watching multiple trains move autonomously in a realistic way is really rewarding.

 

39 minutes ago, gavino200 said:

what kind of computing power is needed for this

Good question. I have never seen Rocrail require more than 2 or 3% of CPU power, but that's probably not the right metric. We need a system that is responsive, i.e. that can react to sudden events very quickly, without latency, even if these events don't happen often (two events within one second is like an eternity for a computer). What I am going to write is just an opinion, based on personal feelings. I do think that Linux is better than Windows for that, especially on an old computer. It is a lighter OS, less bloated. I have often installed Linux on old laptops to get them a second lease on life. Could you ask on the iTrain forum if users are happy with Linux?

[gavino200]

9 hours ago, Madsing said:

I have exactly the same feeling. Of course we are all different, and we are probably each looking for different things, but I also feel that watching multiple trains move autonomously in a realistic way is really rewarding.

 

Yes, it was fun, and a relief. I'm going to fine tune the practice layout so there are no derailment traps. But then I'm going to keep it as it is so I can fine-tune loco issues and go forward with learning proper automation.

 

 

9 hours ago, Madsing said:

Good question. I have never seen Rocrail require more than 2 or 3% of CPU power, but that's probably not the right metric. We need a system that is responsive, i.e. that can react to sudden events very quickly, without latency, even if these events don't happen often (two events within one second is like an eternity for a computer). What I am going to write is just an opinion, based on personal feelings. I do think that Linux is better than Windows for that, especially on an old computer. It is a lighter OS, less bloated. I have often installed Linux on old laptops to get them a second lease on life.

 

This makes sense. I'm planning on running my layout using a designated device. I'm still not sure what that will be - PC, Mac, or RasPi. I have the disadvantage that I've started using three complicated systems at the same time - DCC, controllers, block detection, and automation software. So when there's glitchiness (and there is), I can't tell which of the three is responsible.

 

What I want is to have a stable, minimilly glitchy setup that I can use for many years. I like iTrain, but I have a small doubt that it's made mainly for Mac and may be glitchy on PC. I have no specific reason to say this, but it's a possibility, and therefore a doubt (a potential variable?). I'd like to test this by running iTrain on a very nice Macbook that my wife has but doesn't use. However the Digikeijs system doesn't seem to play well with Mac so I'm still working out how to test this. But reading about other peoples experiences I don't see people complaining about this so it's probably not the issue. Per Iain on the iTrain forum "This is because iTrain is truly multiplatform and uses the underlying Java platform to work in the same way for all platforms.".

 

The Digikeijs system is another issue. The DR5000 is widely used but many bugs are mentioned. The iTrain developer especially doesn't like it and says it caused him a lot of headaches. He is however primarily a Mac user and the DR5000 can't be configured on Mac, which is part of his issue. I asked him more about his dislike for it and this is what he told me.

 

"Sometimes there are issues with the USB-connector or other components If you want to reduce costs by using cheap components that is not the right way to go, but that is what I heard from resellers in the Netherlands.

"What I don't like is that it tries to be too much at the same time. USB, wired network and WiFi, XPressNet and LocoNet, all kinds of busses. This makes the setup complicated for most people. I prefer hardware that is not tries to be chameleon and please everyone, but just keeps it simple, but high quality.

For iTrain it behaves more or less 100% as an Intellibox II even reporting the name IB back and using the exact same serial settings. This seems like making a cheaper copy of an existing product. If I were Uhlenbrock I would not like that. Of course it is okay to LocoNet, but then at least return your own credentials and name and do not copy that as well. I know the reason is software compatibility with older software like Koploper, but then make a compatibility mode instead of doing it right out of the box."

 

The second part of this seems like just a general dislike on principle. Ironic because iTrain has the same one-size-fits-all philosophy, that also makes learning it quite difficult. I bought Digikeijs for two main reasons. One was their full screen computer graphical interface. The second reason was that they made a very full range of devices, so I could get everything from one source and not worry about incompatibilities. That's the opposite of how most people seem to use Digikeijs.

 

Lastly, there are some issues with the Digikeijs block detection and turnout control/signaling units that sound a lot like issues I've been having. As I use the system more and more, I should be able to diagnose them better. A component that simply doesn't work is easy to trouble shoot. But an unreliable or sometimes glitchy component is extremely hard for me to understand. This from a user of the DR4018 and DR4018.

 

"My experiences with Digikeijs kit is mixed:
DR4018 - a nice device and inexpensive; however, it does try to be "a jack of all trades and an expert in none". It can support multiple types of accessories and works well with turnout solenoids (SEEP, Atlas and PECO) and stall motors (Tortoise type switch machines). It has limitations when used with multiple accessory addresses, particularly, with led signals - where it does not always re-set all the aspects correctly. It also tends to lock-up for no apparent reason when used with mixed accessories on one unit - turnouts and signals together - and needs to be re-set. The screw terminals are easily over-tightened. DCC device does not need LocoNet. Documentation is good. I have 26 of these and they all react the same.

DR4088 - again inexpensive compared to ESU, but it does also suffer from the screw connector weakness. With ESU I have to use it through an L.Net Converter for LocoNet, it works well in most situations and if connected via Cat6 Ethernet cables for the LocoNet and S88 links it has no problems over long distances. However, problems of missed occupancy detection do occur if the wire used to power the detector rail is over 1M in length. There are also problems with cross-talk if the occupancy wires are routed together. This never occurs with ESU ECoSDetectors - I use the same 18 gauge wire for both detector makes. It cannot support RailCom - you need the DR5088RC for that - but ECoS cannot read RailCom via LocoNet anyway. Documentation is good. I have 11 of these and they all react the same."

 

Before I go any further I'll need to decide whether to stick with Digikeijs or to switch to something else. Likely ESU.

 

9 hours ago, Madsing said:

Could you ask on the iTrain forum if users are happy with Linux?

 

Yes, I'll do that. But I want to make my way through their 'operating systems' and 'interfaces' subforums first, before I ask my questions. I'll post back what I learn.

[gavino200]

I decided to make a mindmap schematic of the train system so I can plan more methodically. It's getting a bit complicated. Basically it's a four tiered system. I can extend it as needed and highlight priorities. Just a way to keep everything on one page, so I can keep focused.

 

1. Track, Decoders and locos

2. Detection and peripherals.

3. DCC and Network

4. Computer and software.

 

Edited February 27, 2022 by gavino200

[Madsing]

Interesting remarks.

I use the Digikeijs DR4088RB-CS, that’s the current sensing feedback module with R-Bus (Roco bus) connection to the Z21. I have 5 of them. It’s advertised as compatible with the very old Roco feedback module, so it works seamlessly with the Z21. That’s the reason I bought it. It’s funny. Compatibility with existing products seems to be Digikeijs’ thing. That said, I have no reason to complain about it. 
For switches, I use an LDT module directly compatible with Tomix switches (https://www.ldt-infocenter.com/shop/en/Decoder/Turnout-decoder/).

None of these modules are programmable.

For signals, I have made my own Arduino-based decoder. In terms of settings, and understanding of the (DCC) protocol, I have the impression that signals are the most difficult device to understand. There is a huge variety of signals, aspects and number of aspects, and my opinion is that the DCC protocol is not at all adequate for controlling signals. It makes everything so difficult! Currently, I could program Rocrail to control two- and three-aspect signals through the Z21 then the DCC bus towards my Arduino decoder. But in terms of protocol and electronics, that’s an incredible waste of resources…

[Martijn Meerts]

I've used iTrain both on a Mac and a Windows PC (as well as on a Mac running Windows through Bootcamp), and it works the same across all platforms.

 

As for CPU power, programs these days are quite optimised so you wouldn't need a top of the line computer. Especially not for home layouts where you're not likely running a large amount of trains at a time. 

 

For occupancy detection, there are various reasons it could fail, some due to the command station, others due to wiring. What I've found out myself:

• Selectrix (likely no one uses this anyway ;)) sets all detectors to occupied on a short circuit. So control software will think all trains have arrived in the next block while they obviously haven't. This happens on shorts that are just a fraction of a second, a longer short shuts down the system (eventually)
• Unreliable bus cable. Another one I had happen, the bus cable was a bit iffy which caused false positives once every 100 detections or so, very hard to figure this out
• Bad USB to serial hardware. Always go for a USB to serial dongle thingy with an FTDI chip if you have an old command station running on a serial cable
• Bad solder joint on the hardware (this can also happen on pre-built hardware)

What I've heard from others (that seem like they could be an issue)

• If you use power bus wires which you solder the feeders onto, the power bus could cause interference with unshielded detection bus wires
• Low gauge wires, as in, using wires more meant for decoder installs rather then regular electrical wire
• Too long cables, either from the track to the occupancy detector, or the bus cable

 

 

[gavino200]

Thanks. That's great information. The more variables I can eliminate, the better. 🙂

 

[gavino200]

21 hours ago, Madsing said:

Interesting remarks.

I use the Digikeijs DR4088RB-CS, that’s the current sensing feedback module with R-Bus (Roco bus) connection to the Z21. I have 5 of them. It’s advertised as compatible with the very old Roco feedback module, so it works seamlessly with the Z21. That’s the reason I bought it. It’s funny. Compatibility with existing products seems to be Digikeijs’ thing. That said, I have no reason to complain about it. 

 

Thanks. That's good to know you're having a good experience with the Digikeijs feetback modules.

 

 

21 hours ago, Madsing said:

For signals, I have made my own Arduino-based decoder. In terms of settings, and understanding of the (DCC) protocol, I have the impression that signals are the most difficult device to understand. There is a huge variety of signals, aspects and number of aspects, and my opinion is that the DCC protocol is not at all adequate for controlling signals. It makes everything so difficult! Currently, I could program Rocrail to control two- and three-aspect signals through the Z21 then the DCC bus towards my Arduino decoder. But in terms of protocol and electronics, that’s an incredible waste of resources…

 

That's interesting. How does your Arduino-based decoder fit in with the rest of your system? Does it connect directly to the Z21 R-Bus? Or the track? It would then be controlled by RocRail through the Z21 interface?

 

I only know the basics of how DCC works. I can't really compare it to anything else in a meaningful way. It does seem to be a bit hit-and-miss even for regular decoder programming. In what way is it unsuitable for signals? In what way is it a waste of resources?

 

Is this a bandwidth issue? Or is it draining on the Z21's computation capacity? Would it be better to have a designated DCC control center to handle signals and switches,  while a different one handled train control? I think @Martijn Meertsmentioned that if he continues with his n-scale layout he'll soon overload his ESU Ecos's capacity.

[gavino200]

I'm starting to think that all the components of my system are working fine. I think my issues are related to how I'm using iTrain. After achieving success the other night, I decided to make the layout a little more complex. After doing this it became buggy again. Right now none of the routing is working but I can drive in manual and see all the feedbacks light up as I pass them. So the feedbacks are all working. The switches are all working. The manual drive is working so the DCC controller must be working. I know from success the other night and from @Martijn Meerts's information that iTrain is working on my computer. The last remaining variable is me and how I'm programming iTrain.

 

I'm noticing that in iTrain there are often many different ways of doing the same thing - but some work and others don't. The sequence in which things are done seems to make a difference between them working and not working. Some things like "autofill" seem like a convenience measure, but actually seem to be essential. In fact the iTrain forum 'step-by-step' trouble shooting guide, seems to include "did you use autofill" as a step for quite a few bugs. Also while I mostly understand the magnet function, I'm realizing I don't fully understand why it exists and what it's real purpose is. I seem to have most problems when I take a layout and adjust it. The successes I've had are generally after total rebuilds after deletion. This is fine on a practice layout, but I can't afford to do that on a real layout.

 

I have trouble with this as I tend to find an unorthodox path in most situations. In the physical world this works but with software often this causes frustration. It seems I can't feel my way around iTrain. I'm going to focus on finding and recording what the absolute correct sequence is in which a layout has to be done. I'll make a written pathway/guide from this and follow it every time until it's habit. There also has to be some special protocol for adding and changing an existing layout. I just re-read the manual and there's nothing in there that's specific about this. But there are quite a few essential subtleties that aren't in the manual. I'm currently starting to rewatch the video series. It's much easier to watch at 2x speed. I think the guy speaks extra slow for Euro ESL viewers, but it makes it really hard to follow. At 2x he sounds normal.

 

I'm starting to get actually quite familiar with iTrain. At times it seems impossible and setbacks are disappointing, but at this stage I'm a bit obsessed. I'm going to make this thing work, dammit! I'm close. I can feel it!

Edited March 1, 2022 by gavino200

[Martijn Meerts]

9 hours ago, gavino200 said:

Is this a bandwidth issue? Or is it draining on the Z21's computation capacity? Would it be better to have a designated DCC control center to handle signals and switches,  while a different one handled train control? I think @Martijn Meertsmentioned that if he continues with his n-scale layout he'll soon overload his ESU Ecos's capacity.

 

There's a difference between the Z21 and the ECoS though, the ECoS is essentially a small computer running a customised version of Android. It also has the capability of automation without using an external software. Even when using an external software, the ECoS will still allow you to have a track plan on it with occupancy feedback and everything, and it'll need to update those. It can definitely handle quite large layouts, but with lots of turnouts, occupancy detectors and several trains running, it will at some point get behind. Also, my yard alone probably has more turnouts and occupancy detectors than a lot of completed home layouts have, so pretty sure my layout isn't really anything to go by 🙂

 

For iTrain, I've had a fully automated layout running on it for quite a while. The old Tomix layout I built up on the attic used the Selectrix system and (eventually) iTrain for automation. It has a through station, a terminal station and a yard with 4 through tracks and 3 terminal tracks. It could have 5 or 6 trains running at any given time, with several more waiting at stations / yard. It did take me a month or 2 to set everything up though, and I did have the advantage of already having the layout running on a different software before switching to iTrain.

[Madsing]

On 3/1/2022 at 6:26 AM, gavino200 said:

That's interesting. How does your Arduino-based decoder fit in with the rest of your system? Does it connect directly to the Z21 R-Bus? Or the track? It would then be controlled by RocRail through the Z21 interface?

 

I only know the basics of how DCC works. I can't really compare it to anything else in a meaningful way. It does seem to be a bit hit-and-miss even for regular decoder programming. In what way is it unsuitable for signals? In what way is it a waste of resources?

My Arduino-based signal decoder is connected to the DCC bus, the same DCC signal that goes to the rails and the switch decoders. I'll try to briefly explain what I mean here.

 

DCC is very slow. Partly because it's last century's technology, but also because the DCC signal has to travel through long, uneven, unshielded cables, then through the rails, then the multiple wheels of the train before reaching the decoder. So it's probably slow on purpose to make the transmission more reliable. Slow means that it takes in average 158 microseconds to transmit one bit on the DCC bus, that translates to a little more than 6 thousand bits per second. For comparison that's 150 thousand times slower than the Ethernet network at 1Gbps (which is also considered slow today). DCC commands (also called packets) are highly variable in length, but the shortest command is 38 bit long. All in all, I have evaluated that there is bandwidth for about 100 DCC commands per second on the bus. That's probably ok for most applications.

 

On my layout, I plan to have 15 trains running at the same time. I'll probably have 25 or 30 signals. I already have 24 switches (turnouts). All connected to the same DCC bus. In addition, don't forget that speed commands for the trains are constantly resent (repeated) by the command station.

 

The NMRA DCC protocol specification contains a command format (called Basic Accessory Decoder Packet Format) that is well supported and was initially designed for and used by switch decoders to actuate turnouts.

 

Apparently, the same Basic Accessory Decoder Packet Format is also used for signals. However, while switches are very easy to control (they just have two positions), signals are more complex with three, four or more aspects. I studied the default way the Z21 app, the Z21 itself and Rocrail handle signals and found out that they use several DCC addresses per signal to cope with that situation. With three-aspect signals, two addresses are required. In addition, for strange reasons, the Z21 activates and deactivates signals for every aspect change (probably a side effect of using the same commands as for switches). Conclusion, changing a simple signal aspect from red to green generates four DCC commands on the bus. If Rocrail, for any reason, wanted to update the aspect of all my layouts signals at the same time, it would require the entire bandwidth of the DCC bus during more than one second...

 

I am looking for a better way. One possible solution would be to use the Extended Accessory Decoder Packet Format. This type of command seems more suitable for signals as it has a 5-bit field able to choose one of 32 aspects for the signal in a single command. Unfortunately, when I built my Arduino decoder, this packet format was not supported by the Z21 and by Rocrail. This has changed last year and Roco has added support for this extended packet at the end of 2021. Rocrail has added support at the beginning of this year. I have not that tried yet.

 

Alternatively, I could try to remove all signals and switches from the DCC bus. That's why I mentioned LCC on another thread. LCC would be a perfect solution. However, @pbunter mentioned in this other thread that the Z21 developers are not planning to add LCC support. Maybe I could just try using the "raw" CAN bus.

 

Sorry for the long explanation. I tried to put in writing what's going through my head about this right now.

 

Marc

Edited March 2, 2022 by Madsing

[gavino200]

Thanks, Marc for that great explanation. What about splitting the DCC system? Using one DCC to control the trains, and then using a second interface to control switches and signals. Something relatively cheap like a DR5000. I'm fairly sure this is possible with iTrain. It allows you to add multiple different interfaces operating different elements of the layout? You could even have three controllers connected to the software. One for trains, and on each for turnouts and signals. Please forgive me if my reasoning is very simplistic and naive.

[Madsing]

Hi Gavin,

You are right. This is a perfectly valid idea 😀. Rocrail and probably iTrain support multiple command stations. In addition, I have built last year a simple Arduino-based command station that I keep on my workbench only to program decoders and test trains. I could simply build another one to control signals and switches on the layout.

Advantage: No (or very little) change of wiring required. Just split the DCC bus in two.

Drawback: The Z21 app will not be able to control switches and signals anymore as it only sees the Z21.

Thanks for the recommendation. I'll definitely keep that in mind.

Marc

 

[Martijn Meerts]

iTrain supports multiple command stations, the amount depends on which license you have. I can't remember the exact numbers, but with my license I can use 3 command stations.

 

@gavino200Since you're using iTrain, you could have a look at http://www.vpeb.nl/english/solutions/accessories/oc32/. It's not necessarily the easiest bit of hardware to get used to, and probably not the cheapest either, but it supports a lot of external devices, anything from simple LEDs to complex signals to various types of motors and servos. The OC32 itself can be programmed to to show the various aspects of a signal for example, so in iTrain you don't have to do much configuration, nor does iTrain have to send a ton of commands to the OC32 to get things to work.

 

I have an OC32 at home, including the interface to hook it up to the computer, but I've not yet done any testing with it. My plan was to use them to control mainly signals and lighting in houses, as well as some servos here and there. I'll see if I have some time in the coming weeks to experiment with it a bit and do a write up about it. I did have the older version of it at some point, but the new one is a lot more advanced.

 

[pbunter]

I am wondering if the RR-CirKits LCC-LocoNet Gateway would be of benefit here. If you have an LCC network set up to handle switches, signals, and occupancy detection, would you be able to use the LCC-LocoNet Gateway to hook all that into a DCC controller (ie, Z21) / iTrain / JMRI?

 

I do not have LocoNet so am unfamiliar with how a DCC controller / iTrain / JMRI interacts with it. I would assume that commands to LocoNet-connected devices are routed directly via LocoNet, thus reducing the DCC signal traffic on the rails? I do not know how devices are defined/addressed as LocoNet-connected but the Gateway would have to be able to convert that to an LCC node address as well as convert LocoNet commands to (reasonably) equivalent LCC events. As usual, switches and occupancy would probably be easier than signals.

 

I have to do some more reading...
 

[Madsing]

7 hours ago, pbunter said:

I have to do some more reading...

Yes, me too 😀. I know very little about LCC, and how the Z21 uses its CAN bus.

[gavino200]

This is an nice example of an iTrain glitch. I'm fairly sure I'm causing these by doing things in in the program in an undesired way. Yesterday, I made a very strict step-by-step for building a layout in iTrain. I'm planning on starting a new file this weekend and rebuilding this layout in iTrain from scratch. I'm 99% sure it will work.

 

There's something I'm doing when altering an already working layout that's making glitches. My next job will be to find out what that is. All the examples, video, manual, forum, describe how to build a layout/switchboard from scratch. There doesn't seem to be a guide to changing and altering one without causing glitches. Well, I'm going to make one.

 

I had a layout working fine last weekend running 4 trains automatically. I decided to add the center loop by extending a siding and connecting it to the east side of the loop. At first I was having trouble getting trains to run on the south east corner. After changing and redoing a few parts, this happened.

 

All the turnouts work. All the feedbacks light up at the right time. The trains can be run everywhere in manual. So, every part of the system is working.......except.

 

Look at the iTrain block occupied indication - the block should go purple when the train is in the block. If I drive the train around the loop, all the blocks stay grey until I get to the outer west block. Then they all go purple. I'm not concerned at all about this glitch. In fact I feel a bit vindicated by it. Almost happy. All my previous glitches were small oddities that could have been caused by anything from wiring to decoders to software. They were real head wreckers. This one, is nice an visual. It's so obviously a software glitch, caused undoubtedly by something I did. So it's down to iTrain and me. The chase is on!

 

 

 

 

 

Edited March 3, 2022 by gavino200

[Madsing]

May the force be with you!

[Martijn Meerts]

That's not something I've ever seen happen, and I have changed a layout plenty times to add and remove tracks / detectors / turnouts / etc. 🙂

 

[gavino200]

Finally, I have some real automation, without glitches. I can't be sure exactly what fixed the problems, or if they'll stay fixed. I made three changes.

 

1. I opened a new file and rebuilt everything from scratch, using a checklist I made to ensure that everything was absolutely correct.

 

2. I updated Java. I'm not sure if I did this when I installed iTrain originally or if iTrain checks for this automatically.

 

3. I downloaded all possible windows updates. I'm not sure what the last time I did this was.

 

Currently everything is working. I'm going to play with this for a while and go through the video series again. I'm also going to switch my main focus to modeling and designing the new layout for a while.  🙂

 

 

 

[Martijn Meerts]

Nice one!
 

It's always great motivation when something works, and seeing trains run fully automated is extra motivation ... To make more complex automations, which then don't work anymore 😄

 

[gavino200]

I finally took apart the practice layout, so I can use the tables for some track laying experiments. Overall, this was a great learning experience. I can't imagine how frustrating it would have been learning the automation system on a new permanent layout. Next level of learning will be on the real thing.