Jump to content

LD (Loco Detection) v BD (Block Detection)


RDS

Recommended Posts

  • Replies 218
  • Created
  • Last Reply

After 15 pages, what have we learnt ?

BD can tell you that a block is occupied, full stop, period (if you have a railroad!).

LD can tell you that a virtual block is occupied and tell you the specific loco (or any piece of rolling stock, in theory).

According to @hosh, therefore, BD is better.

Mmmmmm .........

Link to comment
Share on other sites

Thanks Phul007

 

I have downloaded and installed the software to play with and get a feel of.

 

The first thing that is noticable with TrainBrain is how much clearer the schematic layout is, no big chunky pieces. I have always felt that RM pieces are to large and the loco boxes take up far to much screen. They could be smaller and neater.

 

I do wish thy would make it so that both the grid elements and the loco boxes could be smaller, including an option of size now or say 60% of size now. To me once we know what the buttons are for they do not need to be as big.

 

I do like RM (except the above) but we do not seem to get any reply to their statements 'coming soon. and 'coming 2017' for LD.

 

TrainBrain does seem to have a Windows feel to it. Time to play over Christmas and the New Year time allowing I think.

Link to comment
Share on other sites

After 15 pages, what have we learnt ?

BD can tell you that a block is occupied, full stop, period (if you have a railroad!).

LD can tell you that a virtual block is occupied and tell you the specific loco (or any piece of rolling stock, in theory).

According to @hosh, therefore, BD is better.

Mmmmmm .........

 

I don't really think one is better than the other - it's just that there are clear pros and cons either way depending on one's situation and preference.

Technically there is no difference at all - they both sense locos at specific locations and then feed that info back to software programs. The software program will have more to do with things than the type of sensing used.

Link to comment
Share on other sites

@Phul007

Sounds good. What system are you usng?

CTi Electronics Train Brain and Tbrain system.

I can see so much of what Hornby will do in the future  already in this system.

 

Is there an option with the detectors to adjust sensitivity?

 

I can see that even with no trains drawing current on a section of track that there'd still be a little current due to capacitance of the track itself with a pulsing dcc power supply.

 

So my question is, have you had any sensor fails by having a train enter a block at it's minimum speed setting?

Link to comment
Share on other sites

... Amazing what we can learn in 15 pages ... 

 

 

Amazing how many times we can round in circles in 15 pages as well.

 

Amazing how many times people can say software hooked up to detection hardware doesn't know where stuff is in 15 pages! :)

Link to comment
Share on other sites

Thanks Phul007

 I have read a little of the manual and get the impression that  CTi is a DC system, or am I wrong?

And, if so what are the chances of getting it to talk to RailMaster? If that could be done it would mean that we could get on and use Loco Detection without waiting for Hornby to sort out their system.

John B.

Link to comment
Share on other sites

Can I suggest Sloop that you head on over the to CTI website and have a look there for the link to the CTI User Group Yahoo Forum? You can read it without joining but you cannot post anything. Joining is free and very simple though I do warn you it is not as easy to navigate as some forums.There is a discussion about the use of RM (not possible) and an Elite (jury is out) at the moment principally by me and one other. R-

Link to comment
Share on other sites

After 15 pages, what have we learnt ?

BD can tell you that a block is occupied, full stop, period (if you have a railroad!).

LD can tell you that a virtual block is occupied and tell you the specific loco (or any piece of rolling stock, in theory).

According to @hosh, therefore, BD is better.

Mmmmmm .........

 

I don't really think one is better than the other - it's just that there are clear pros and cons either way depending on one's situation and preference.

Technically there is no difference at all - they both sense locos at specific locations and then feed that info back to software programs. The software program will have more to do with things than the type of sensing used.

When you compare the theory of LD v the theory of BD there is only one winner and that is LD.  As we don't have the LD hardware we can only compare the software.

 

Reading between the lines of your postings so far @hosh I believe you see the software in complete control.  Ie it dictates every movement of a loco as it procedes around the layout.  The software knows what is happening now and what will happen next but needs BD to report back that the loco has reached a certain location. 

 

This is a procedural program.  It's a bit like phoning customer services and the operator asks you a series of questions from a pre-determined list.  Unless you interupt them they are in control and one question naturally follows another.  In old computer programming this is like guiding someone around a screen, from box to box, in order without a mouse.

 

Now think of the world in 2015.  When you use a screen you have a mouse (or a finger) and can leap about the screen randomly.  This is known as 'event driven' because the program sits there waiting for an event to react to.  The important thing to understand is that this is, as far as the program is concerned, (almost) completely random.  It happend out of the blue.  When the event occurs it initiates a routine written by the programmer and passes data to it.  That routine must then work out what to do based (almost) solely on that data.  It's kind of scary because the routine will not know what happened before it and will not know what is going to happen next.

 

At first it sounds a bit stupid but actually it represents more accurately the world we live in.  Think about driving from A to B.  You know the route you would like to take but as you drive along 'random' events occur which need taking care of; other vehicles get in the way, traffic lights, diversions etc etc.  As a human you work from what you know but if you come across something new you can always improvise.  A computer program can't do that.  You have to allow for (handle) every conceivable event in some way or another.  As I said, the world is event-driven and so is virtually every computer programming language now and it is not an accident.

 

RM is event-driven (sort of because I believe it is a VB6 program), but the user-written programs are definitey procedural.  However, LD will be the first time user programs will be able to react to a random event - a loco passing a sensor. 

 

An example of this may be LD generating an event as a loco passes sensor 123.  This sensor is just before a station. Loco 65 stops at the station every time.  Loco 97 only stops at the station on alternate, even numbered circuits.  Our other 2 locos, 21 & 25, are goods trains so do not stop at all. 

 

The code in the LD event will first determine if it is sensor 97 - it is.  Then it looks at each loco and compares it to the loco ID passed with the event (BD can't do this).  If it is loco 65 it will slow it down according to how that loco performs.  If it is loco 97 it will determine if it is an odd or even numbered circuit.  This is data not passed to the event but is held in some way or another.  If it is even numbered then it is slowed down according to its performance characteristics, otherwise no instructions are issued (likewise for locos 21 & 25) and the locos continue without stopping.

 

In this manner, once every sensor/loco combination is catered for you end of with an automated layout controlled by individual, seemingly unconnected events.  It is a completely different way of thinking to the way you are used to and will take a lot of getting used to.  When I helped computer programmers (incuding myself !) move from procedural to event-driven languages I reckoned it took about 18 months to come to terms with.  Although LD in RM will be much less demanding it will still require this change of thought process.

 

Sorry for preaching - I'll happily take questions now ;-)

Link to comment
Share on other sites

Sorry for preaching - I'll happily take questions now ;-)

 

Interesting - I'm in the middle of a computer diploma right now.

 

But sorry, i disagree with the entire jist of your post.

 

Any automated model rail program will be procedural. Even the "events" created by sensors and signals are not random. The only example of a random event occuring in this process is the user cancelling a trains program midstream and either running another or taking manual control. Now that would be a good example of an "event driven" modern computer programming language with objects, etc.

 

The other point you made was BD not sending back the locos ID. And I think this mighy be where a lot of people are failing to understand a lot about automation.

 

At any given time on the layout there will only ever be one train headed for one sensor - otherwise there'd be collisions. I point this out for a few reasons -

 

  •  It shows how easy it is for software to track trains
  • Since you can only have 1 train headed toward 1 sensor at a time, the program is indeed procedural.
  • When train A wants to go to Sensor A but train B is already headed there, train A gets a red signal

So there is no random (event driven) aspect to automating a model railway. The fact that Hornby's LD will send loco IDs to RM is a mere gimmick! It is a waste of time and money.

Link to comment
Share on other sites

Hi Roger, I intended to join the forum but came up against '+join group', that then took me to a Yahoo log in screen, so not having a Yahoo address, I did not continue.  Should I have?

On that "Log in" screen is a "register?" option. If you do this a Yahoo e-mail is devised for you. At least, that is what happened in my case. R-

Link to comment
Share on other sites

 The fact that Hornby's LD will send loco IDs to RM is a mere gimmick! It is a waste of time and money.

Well, hosh.......this last sentence of yours proves beyond doubt that you have no idea as to the purpose and benefit of Hornby's proposed LD system...............The whole point of a sensor reading the tag on a loco to identify it is so that the software will execute the series of events that you have programmed for that particular loco and not others that may follow across the same sensor in due course...........they will have their own events programmed as and when which may send them to other routes............I still insist that RM does not know where stuff is, it can only execute events when the program is triggered by each sensor anywhere on the layout...........a sensor could be in your hand and swipe it under a loco tag to fire points and signals etc, RM would know not where, only the relevant decoder addresses to send the data to.  HB

Link to comment
Share on other sites

 The fact that Hornby's LD will send loco IDs to RM is a mere gimmick! It is a waste of time and money.

Well, hosh.......this last sentence of yours proves beyond doubt that you have no idea as to the purpose and benefit of Hornby's proposed LD system...............The whole point of a sensor reading the tag on a loco to identify it is so that the software will execute the series of events that you have programmed for that particular loco and not others that may follow across the same sensor in due course...........they will have their own events programmed as and when which may send them to other routes............I still insist that RM does not know where stuff is, it can only execute events when the program is triggered by each sensor anywhere on the layout...........a sensor could be in your hand and swipe it under a loco tag to fire points and signals etc, RM would know not where, only the relevant decoder addresses to send the data to.  HB

 

What is proven is that what I wrote about the ease of a system that doesn't transmit train ID from it's sensors still knowing what train just passed a given sensor was lost on you entirely. You also must have missed or failed to understand any of Phul007's posts also.

 

As for the sensor in the hand, how about when I look at my fridge I don't know where it is - it's just a bunch of photons being detected by my retina. My retina has no idea where the fridge is.

Link to comment
Share on other sites

@hosh..............You must be living in cloud cuckoo land if you don't know where you fridge is............I certainly know where mine is located and, in fact, if the lights failed right now I would have no trouble in walking to it without bumping into any furniture on the way because my brain has a recording of exactly where I am in relation  to my fridge...........the point being that RM is not a brain and consequently does not know where anything is. :-) HB

Link to comment
Share on other sites

@hosh..............You must be living in cloud cuckoo land if you don't know where you fridge is............I certainly know where mine is located and, in fact, if the lights failed right now I would have no trouble in walking to it without bumping into any furniture on the way because my brain has a recording of exactly where I am in relation  to my fridge...........the point being that RM is not a brain and consequently does not know where anything is. :-) HB

 

And there is the point right there that you're missing. RM, via the program for every train, will have exactly that "recording" of where everything is in relation to everything else.

 

You will duplicate your knowledge into the program, save it (pass it on to RM) and guess what - RM now knows where everything is.

 

And guess what else? If you like, you could apoint any sensor on your layout as the absolute frame of reference for the entire universe and it'd be just as valid as any other. All other locations in the universe could be determined from that point in space.

Link to comment
Share on other sites

Hosh, now we come to the nub of it.   Your software system may well have a "recording of where everything is in relation to everything else" but I can assure you RM definitely does not.  You may well say but the schematic contains that information, but the answer is simple - that information is used only, I repeat only, for displaying the schematic on the screen.  It is most definitely not available for use elsewhere in the program.  The exception is the setup information contained in points, signals, TTs, accessories and LD sensors.  This is available and is used to switch the points, signals, TTs and accessories when they are clicked on screen, and to run program commands also contained in the setup of points, signals and sensors.

 

If the light hasn't dawned now, it never will and further discussion would be pointless, signal-less and senseless.

Link to comment
Share on other sites

Archived

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


×
  • Create New...