MetmanUK

Hello PJ, In my previous post I tried to keep things simple and steer you away from doing too much forward planning. I obviously failed so I'll try another way of explaining. Lets look at a real-world scenario. I want to go by bus to a shopping centre, buy some clothes and have a meal, then return home. In the 'plan everything in advance' world - we'll call it 'prescriptive'. In this world I would :- 1. Leave house at 11am and walk to bus stop 2. Catch 11:06 bus. 3. Arrive at shopping centre at 11:39. 4. At 11:42 commence shopping. 5. At 12:57 finish shopping. 6. Arrive at restaurant at 13:00 for meal. 7. Finish meal and pay bill at 14:10. 8. Catch 14:15 bus home. This world is akin to your detailed planning of routes and timings. There is scope for things to go wrong with the plan. It will most likely take longer than expected. You may be lucky but the more times you try it, eventually it WILL fail. So what would the event-driven plan look like. Perhaps something like this. 1. Leave house at 11am and walk to bus stop. 2. Catch next bus. 3. Arrive at shopping centre. This should be 11:39, in which case continue with plan. If it's later then consider changing plan - you may wish to eat straight away to avoid longer queues later. 4. Assuming we stick to our original plan, do our shopping. 5. At 12:57 revise our plan if necessary. Have we completed the shopping? Do we finish shopping regardless, not eat or get a later bus home? 6. Carry out the rest of our (revised) plan at the shopping centre. 7. Go to bus stop. 8. Catch next bus home. This is much more real-world. We have a sort of plan which, as events occur (eg the bus detector tells us it is 20mins late !), we change/refine as necessary. So, for loco detection, we still have a route/plan but it's mostly in our head with only small bits prescribed/coded (eg we know precisely how long it will take us to walk to the bus stop or a train to wait at a station for passengers). As the route/plan progresses we revise it as events are notified to us (eg train breaks down so all routes passing that point are suspended until train removed. Yes, its much, much more complicated, but so is the real world. You may have a plan of how long it takes to go from station A to station B but in reality the time it takes is dependant on how quick it is 'passed' from signal to signal. How long it should take is almost irrelevant - what is more important is knowing that it has arrived at station B. Our routes/plans just have to be flexible and responsive to events (detections) that happen. Hopefully that makes some sense!

What I can't seem to grasp is, if loco 003 is programmed to go from A to D via B & C and in the program it remembers all points, speeds etc. (we will stick to the one loco) it does so in the program according to the time allowed. That loco has a tag and the tag goes over a sensor, if a sensor says loco 003 do this or that or all trains do this or that, will this not change the program by the instruction just read and received? This is something we will not know for sure until the manual is available. My guess is that RM will run both sets of code asynchronously meaning that they can/will interfere with each other. The onus would then been us to ensure that they do not do so. But that is only a guess!

PJ You are, understandably, getting confused between prescriptive programming and event-driven or reactive programming. Your routing programs are prescriptive because they tell each loco precisely what to do, when and how long for. There is no allowance for unexpected events like a loco running slower than normal. Loco detection introduces a feature which will allow you to do just that, to a greater or lesser degree. You can still set up your routes but allow them to be slightly more flexible and less prescriptive. You will, for example, be able to cope with a slow, late running train by queuing others behind it. Yes, this will be more complicated but also more life-like and interesting I think. What loco detection does is alert you that a detection event has occurred and allow you to respond to it given that it will tell you what loco has triggered it, it's speed and direction. What it will not do is control things in the way that you currently understand it. Please don't try to understand it in detail yet as I believe you will find it quite difficult without trying things out with the hardware and software. There is going to be quite a learning curve to climb! PS As I am currently building my layout and plan to include detection I am just as impatient as you!!!

Mousehole said: As reported in other posts, I have only just become operational with eLink and Railmaster and have started looking at point control. On my layout all my points are operated by Peco PL10W point motors on Peco points controlled with Peco point switches. All work well, even where two are operated simultaneously on crossovers and on Peco three-way points. I have a Hornby 8247 decoder that I have set up successfully on Railmaster and it will operate a point motor when stand-alone but when attached to a point there does not seem to be enough energy to throw it. I have set a pulse length of 600ms. Is there any reason for this failure? Are there any other accessory decoders that will be more successful by providing more power? I have seen several comments on the ADS-8, would these be a suitable alternative? Hi Mousehole, My experience with Peco motors is that they require a fair amount of power to operate. Even with a dedicated Peco CDU (R8247s were not available) I had to allow a long (re-)charging time between throws. I was using the e-Link 1amp power supply at the time. As for the ADS-8s, even with the 1amp supply, they work very well with almost no recharging time required.

Sorry if its already been mentioned but ..... On entering the Track Plan Design mode it would be sensible if the current plan in use was made available by default, with the drop down list enabling this to be changed if necessary. I can't think why you would want to make a selection everytime you entered the designer.

walkingthedog said: When I retired in 2006 it took me about a day to get used to it. I now live by the 'why do something tomorrow when you can do it another day' plan. ......... by which time,with any luck,you've forgotten about it?

walkingthedog said: Looking at what you've just written, I reckon I've been living an event driven world all my life. Events are just one element of object-orientation (OO - now there's a coincidence!) theory which is used by most modern programming languages as it can describe most aspects of our world. So, yes, you live in an OO world one way or another !!!

PJ_model_trains said: Considering the program route technique and the event do this technique, I know which I prefer. Maybe its because I have now retired, I don't have to get up before 7am, I don't have tocheck emails and orders all day, or list items online. I don't have to work 7 days a week, I work to this happens do that, that happens ok do this. Yes I prefer this method but it is taking some adjusting. The event-driven concept best describes our chaotic world but programming for it WILL take some getting used to.

You could (should ?) be moving from a prescriptive, procedural world, ie do this, then do that and afterwards do something else, to an event-driven world, ie when this happens do this, if that happens do something different. Its could be a completely different way of looking at things.

Now I'm getting a little excited! I really must have a play with 'program' mode. My hope is that Detection will introduce a form of event-driven programming where detector will fire a detection event back to RM containing the detector ID, loco ID, speed and direction etc. It will then be the programs job to decide what to do. Time, of unknown size, will tell !

St1ngr4y said: In another thread I have described a method of running a chosen program at RM Startup. This means there are three different ways of configuring RM:- 1. The System Settings window 2. The Railmaster.ini file 3. By a command line parameter. Could not categories 2 and 3 be merged with category 1 so that all of the settings are accessed in a similar way? Ray My guess is that the settings in 1 are stored in 2 (or should be!) so the latter gives a quicker way of developing 'programs'. Option 3 gives flexibility of when/how to run 'programs'. Therefore I think all 3 should be retained. Sorry to disagree!

LMSTim said: As explained in my previous message, a DCC controller can only process one command at a time, therefore the answer to your question "Does it also mean that, for the duration of the 8 to 12 seconds, no other commands can be actioned ?" is yes. DCC controllers do not include multi-threading processors and there is no room in memory to create firmware complex enough to multi-task. You still haven't said why you would want RailMaster to read every loco on your layout. What use would it actually be? You say you think it should logically work but haven't told us why you would like to see the function. At the heart of a DCC controller is a tiny, low-powered microcontroller. The microcontrollers in DCC decoder chips are even smaller and lower-powered. To put it in perspective, a PC's processor is around 1,000 times more powerful than that built into a typical DCC controller and 10,000 times more powerful than that in a decoder chip. This means the DCC controller and chips, as explained earlier, are where the limitations are and any PC software has to work around these limitations. I'm sure we would all still like to know what value you put on obtaining details of all locos on a layout automatically, especially when you bear in mind that RailMaster will start up with a built in list of locos it expects to be able to find on your layout and when you run programs, they are for specific locos, which you ned to set up first. Please let us know as I'm sure many of us are curious. I may have this completely wrong but doesn't e-Link effectively become your DDC controller and therefore not suffer from the lack of power in existing physical controllers? Also, to satisfy your curiosity, all I was saying was that I find it logical that, on firing up a DCC system, it should present me with a list of locos currently on the layout, whether mine or a.n.others. That's all!

LMSTim said: NetManUK, just to answer your previous post about the API, you used one example, that is to develop your own front end control interface to allow your grandchildren access to only certain locos/functions on your layout. This can already be done on RailMaster by setting up a networked PC running another copy of RailMaster (you can have upto nine) where the second PC shows only the locos you want. In fact you can go further by limiting points and signals which can be operated too, so that your grandchild can only operate in a particular area of your layout. I did say it was a trivial example but ..... if I wanted "Start" and "Stop" buttons only ? If you are a PC developer with 36+ years experience then you are bound to have another PC knocking about. You can also achieve the same thing using a hand-held iPad, iPod, Android and so on and you can also dictate which first two locos are usable and even what area of your layout you want controlling. So, in answer to your example, there are two ways RailMaster can achieve than. I could .... but that is not what I said I wanted in my trivial example. Now, do you see what I mean about it being somewhat pointless allowing API access to the system. You also did not address the major support headache it would add to Hornby for RailMaster. Sure it wouldn't cost much to deliver the software, and detailed documentation would have to be produced, but the support would need more staff. Any product that introduces such a technical level of control will inevitibly cause a support nightmare. Hornby is not a development software company. Again, it is not feasible and I don't see Hornby providing an API any time soon. Whilst there are a handful of people who would undoubtedly like it I again question the value. You are correct, Hornby are not a software development company! Therefore they will always be limited in what they can produce so why not open it up to those with the time and effort to extend RM's capabilities. If, as you say, only a handful of people want it then there will be minimal support required. If, however, RM with its extendable capabilities proves to be the best controller around the there will still only be low level support required because the API users will be the more technical savvy and will be supported by the 'API' community. That's how it works elsewhere on other APIs. You said yourself that you have not used RailMaster. Presumably, then, you have not thoroughly read the manual to see what it can do (that would be suggested by the example you used to justify an API). You also mention that you do not have a model railway yet. You've been reading my posts again ! ;-) If you have 36+ years as a developer and want to get "down and dirty" with PC model railway control then I would really recommend that you go for something like JMRI. It will allow you to control a Honrby Elite and play about with the source code infinitely - far more than RailMaster. As I understand it, JRMI is not a true API and will require me to learn a new language. 2 reasons to not go down the JRMI route. Also, I like the idea of having software and 'hardware' from the same supplier - less problems. A I said earlier, there are different packages for different users. Hornby is not a JMRI producer or primarily a software development company. Their users just want something that works straight out of the box. I would compare your desire for an API against those who don't with those modellers who prefer to build their locos from scratch or from kits and wouldn't buy from Hornby because it's too easy. .... and with an API Hornby can meet the demands of a very wide range of enthusiasts from one package and increase revenue at the same time. Do you see now the logic in why Hornby are highly likely not to make an API available .. maybe in 20 years time when the current generation of mainly computer-illiterate users are goine and everybody is very computer-savvy. If Hornby do not make an API available it is highly likely due to a lack of vision which would be contrary to the vision shown in developing e-Link.

LMSTim said: Whilst the software my be able to utilise multi-threading or multi-tasking technology, the DCC controller cannot, so there is still a sequential operation in gathering the loco information. The DCC controller can only handle one operation at a time. Indeed the NMRA specification for DCC supports this. As stated before it is the loco decoder chip that takes up to 12 seconds to respond. Therefore, it will take many, many hours, if not days to enumerate all potential locos on a layout. Whilst it may sound like a reasonable request (although you haven't explained why you would want the resulting information or what it would be used for) It's just not feasible. Fair enough if its a DCC limitation. I wonder if NRMA have considered changing this ? Does it also mean that, for the duration of the 8 to 12 seconds, no other commands can be actioned ? Sorry for asking these questions but, when I feel something should logically work a certain way I tend to like to really know why it doesn't as experience has shown me that there is ofter another way (or two!).

Hi LMSTim, Thank you for the detailed reply. I will answer your points as best I can, bearing in mind I don't have RM, nor a model railway at the moment. However, I have been researching in earnest for about a year. I was drawn towards RM (more than the other available products) when e-Link was announced as I thought it showed an innovative and logical way forward for computer control. Because of my IT background (36+ years, much of it on PC development and the last 15 years or so using various APIs to produce enhanced and integrated solutions) I could at last see the potential for a product that excited me. I have looked at the other products, not in great detail yet, but nothing said "this is the one". So, why an API for RM ? Firstly, if the developers of RM have been wise they would have first developed an API or similar as its fundemental ingredients are the base routines that will be used to support the user and layout interfaces. Such a planned and structured approach will ensure a maintainable and supportable application. If the developers have not taken this route then it doesn't bode well for RM as a world-beating product. Assuming the developers have been wise then an API is close to being available and can be distrubuted it little additional cost. There is little testing required as logic dictates that RM would itself use the API. Why would I want my own interface ? Here is a trivial example. My grandson is 2 years old an loves trains. I would like him to be able to control his Thomas loco on his special section of track but to do so he would have to be set loose on the full RM screen. Now, knowing my grandson, that would be dangerous!!!! If, using the API, I was able to write a small program (I like VB.Net) that only has 2 buttons, "Start" and "Stop" and only controls Thomas then I could let him play in safety. Now, I wouldn't expect Hornby to offer that as an option, nor would I expect them to develop the best interface in the world because (i) Hornby do not have all of the best ideas and (ii) they could not expect to meet everyones expectations, especially as we wouldn't be able to agree what was best !!!!! So, to help other users of RM with small grandchildren I could make my program available via this forum. Similarly, someone with too much time ontheir hands could develop a supa-dupa, all bells and whistles alternative interface to RM and make it available. Then, as part of their sales literature, Hornbt can refer to these additional resources that are available and copatible to their product. Its win-win for Hornby. You referred to loco profiling. You are correct to ask why anyone would want to re-do all of that work. The answer is they wouldn't. By using an API you would use the same RM loco database. I am assuming here that the Hornby developers have taken a generic approach to functionality whilst using the database data to drive it. As for Hornby revealing their technical secrets - of course not. I don't need to know. Expanding the example above. lets say moving the speed slider on the RM interface calls a routine SetLocoSpeed with a parameter for the loco ID and another for the speed (ranging from 0 for stop to 100 for full speed). My Stop button would call the same routine with 0 as the speed parameter and my Start button would use 50 as the speed parameter (because I don't want Thomas going too fast!). I don't need to know any more than that in this simplistic view. To sum up, an API is not "pointless" or "counter-productive". It is, in fact, something that should already exist in some form, including documentation, and would help to push RM to the top of the control software tree - but it requires a vision that the company may not have. Regards, MetmanUK

LMSTim said: RDS, just to answer the point about detecting locos on a layout, it is not the power of the PC that makes it non-viable, but rather the time it takes for the loco decoder chip, in conjunction with the DCC controller, to feed back to the PC the fact that the loco is there. In practice, the software would have to cycle through each of the 1 to 9999 potential locos that could be on the track and send a command, in effect asking "Are you there?". The loco decoder chip (depending on the manufacturer and model) will take between 8 and 12 seconds to respond. You do the maths and you will see it is not feasible to scan all locos. Even if you were to think laterally and say, okay, only scan the known locos in the RailMaster database that have been set up by the user (this of course will leave any other - visiting or unknown locos out) it will still take ages. If the software being used supports multi-threading then I would expect this type of task to run asynchronously so the overall elapsed time should be not much more than the 8 to 12 seconds quoted. For the record, it sounds like an entirely logical function for RM to perform. I think this is an entirely logical request.

RDS and LMSTim, Could I ask if there is any specific reason for you dismissal of my API suggestion ? I'll happily provide a fuller explanation (once I've finished decorating tonight!) if you can guide me in the right direction. Regards, MetmanUK

Hi All, I am only at the early stages of planning my model railway but having just retired from an IT development background I am very interested in the possibilities of Railmaster/e-Link. So, what I would like is an API. For those who do not know what an API is ..... It's an Application Programming Interface. Sounds boring but if an application, such as Railmaster/e-Link, is (preferably) built using an API or has one added later it enables interested parties to provide alternatives to the Hornby product. Whilst Hornby retain complete control of the base product, including licensing, it would be possible, for example, to build an alternative user interface with controls placed in different positions. This is a trivial example but would enable the more nimble or innovative modellers to build alternative (better) solutions and let Hornby get on with developing the base functionality. There would also be the potential for commercial organisations doing similar. The result would be a superior Railmaster/e-Link product from which Hornby and users would both benefit. An example of a real-world free API is Google Maps. Most of us make use of the standard Google Maps but many also use greatly enhanced maps which have been developed using the Google Maps API eg www.flightradar24.com . If you've got this far ..... Well done and thanks for reading!