I had some spare sensors, so had a go at adding multiple occupancy sensors to a block and configuring JMRI so that, if any of those occupancy sensors go active, the block they're sensing will go occupied.
Yeah, there's so much to JMRI, the documentation can sometimes be a little scientific and doesn't always actually explain what can be done! Regards, Chris
Thanks Mike! And, I guess, exactly what I set out to do. I think it's maybe not widely known that JMRI can do this kind of thing relatively simply. Thanks for taking the time to comment. Regards, Chris
@@WirenwoodModelRailway Oh, you cruel, cruel person. Is there any way to add a timing element to the release block condition? E.g. don't release the block until it has been clear for x seconds.
@@ianjeffery4773 Ha! Yes - but you'd just use the standard debounce functionality for that, rather than add it with logic - so add 2 second debounce to off on either or both of the actual sensors. You could see in the video, actually, that the LDR has a 2 second to off debounce on it, so there was a delay between me clearing the block and the screen reverting it to inactive.
whats the overhead when you start using the logic stuff instead of just the basic hard coded stuff? does this start to hit the responsiveness as these scripts are run? have short blocks here, diamonds, just current sensing - I've sort of committed to resistor wheelsets "eventually", but this sort of thing will be very useful where I have a block split by a board join to combine two physical sensors into a virtual block
Hi again! I think in the grand scheme of things, impact is minimal - it's just a tiny bit of logic compared to most of what JMRI does. This is actually a small part of a much bigger project which I kind of touched on in the video, for which responsiveness and speed are very important. And as I'm very much sensitive to that, well, all I can say is it's simply instant - not just through the JMRI user interface itself, but also in the API, json server etc. - which is just what I need! As a small aside on performance, and this is just my experience - once I started introducing sensors, automation etc., the Raspberry Pi 4 that I originally ran JMRI on quickly put its hand up and asked to be excused from class, let's say. Just my experience - but once you start really asking quite a bit of JMRI, I think that the only really suitable hardware is PC, Mac etc. I think that the scenario you described, where a block continues over a board join, would be ideal for the multiple sensor approach. Regards, Chris
Interesting. How reliable do you find the LDRs are? I have been working with adjustments for varying light levels in the room. But I still have problems with light coming in from the side of the coaches and not going active.
Hi Sven - they seem to be 100% reliable now. They're connected to an ESP and I've written code to read their values. It allows for a little fluctuation, so the sensor has to be giving readings below the active threshold for 100ms before the sensor state in JMRI is changed. And they have a 2000ms off debounce too. Regards, Chris
Wow, you’re still trying to eradicate the problems on your layout. I watch from time to time, and getting JMRI sorted to run trains automatically or semi automatically appears to take up all your time. How long have you been building your layout?. I do find it interesting even though I don’t use JMRI. DO YOU EVER FIND IT FRUSTRATING (sorry caps lock was on) that you can’t move on to doing scenic etc. to move your layout forward?. Do you think totally automated programs like yours are really worth it or they are too much trouble to get right. Especially as some of us are not computer programmers, and you do seem to be very into doing this programming and adding the correct sensors and associated electronics to make it all work. I’m not knocking your system, I’m sure itrains and train controller are probably the same levels of difficulty. Keep the videos coming to educate those of us who don’t understand how these systems work. Thanks.
Hi - I think you make some very valid points there! I could probably write an essay on this but I'll try not to! Yes, I get frustrated - not with JMRI as much as the wiring, the components. Much of that is down to my own deficiencies though, bad cabling and dreadful cable 'mismanagement' causing interference etc. Automation is an interesting one - I do think that a fully automated layout, if I ever got there, would bore me. For me I think the process of getting to fully automated is much more interesting than being automated. I made another video at the same time as this one, which I'll publish soon, in which I, to some extent, explain the 'why'. It's about making operating the layout unpredictable. Creating scenarios where the trains I'm manually driving have to take remedial action (slow, stop) due to caution, danger etc. And that caution and danger would be triggered by automated trains operating on the same lines at the same time and everything having to work around each other. Just like the real world. I've been building this layout for just over 2 years. You raise another interesting point though, around moving on to scenic. I have no scenic skills at all and it's something I'm really quite apprehensive about. Much as many who are not programmers would be apprehensive about doing some of the things that come more naturally to me. So I think an element of what I'm doing is actually deliberately delaying the technical completion of the layout, because it will move me way out of my comfort zone! Not sure I succeeded in keeping it brief, but hopefully that explains what's going on inside my head! Regards, Chris
