Desirable features for future Railmaster Software updates

[wiggy25]

LMSTim, be careful on saying it will be the best in the world, it depends on what you actually want the software to do and what you're comparing it with.

 

Again as we have all come to expect your defence of RM without EVER saying there is anything

 

wrong with it is very funny.

"The detection system when out will clearly be the most sophisticated available" .....sales rep RM programmer talking ;-)

 

If you want full automation RR&Co is probably going to be the best at this moment and I really

 

can't see how RM will be able to do what that software does.

To program a loco in RailMaster to just go off and do what it likes, obeying all signals and points set against it you will need, as you so nicely put it, to be a nerd or geek as the automation

 

program would be something else to try and write even with the detection system fitted and operating.

There would need to be many detectors all over the layout to be able give the sort of full automation that RR&Co currently achieves and the programming

 

required for all the possible eventualities if only one of the detectors being operated is vast, never mind any of the others.

 

I've used the trial version of RR&Co and yes it is harder to set up initially but RM will be just as hard, ( as we don't yet

 

have any detection system hard "could" be the wrong word) so I will use time consuming, writing all of the automation programs that would be needed.

 

If you try to be unbiased along with being honest about your involvement with RM it would make your

 

comments so much better instead of coming across as the top RM programmer all of the time :-)

 

Cheers

 

[LMSTim]

If you read my post carefully you will see that I did not say railMaster will be the best in the world. I said that Hornby's aim is that it is. There is a difference. Please do not misquote me. Do you work for a tabloid newspaper? (You see, I can make

 

daft assumptions too).

 

Secondly, it is obvious to a child that the loco detection proposed by Hornby is going to be superior than anything out there. All you have to do is drop a loco detection box on your plan in the current available version of RailMaster

 

to see all of the options, even without documentation. You show me where in RailRoad and Co. or JMRI or indeed any other program, that shows 1) which loco has passed a detector 2) what speed it is doing 3) what direction it is facing and take decisions based

 

on those factors. Current systems use block detection to merely know that an object is there and nothing more.

 

You make the statement "I really can't see how RM will be able to do what that software does". How can you say that? So, by your reasoning,

 

no other company that starts later than the supreme champion can ever produce a better product? If I am not mistaken, Railroad and Co is written by a chap in Germany, working from his home? Surely a company like Hornby can put their resources into producing

 

something better as well as easier to use in a shorter space of time.

 

You say that RM cannot obey signals set against locos. Of course not. There is no loco detection system. Are you saying that Railroad and Co can do that without block detection? Of

 

course not. Again, you are not comparing like with like. Who says that RailMaster will not be able to do that when the loco detection system is available. I just look forward to it.

 

You make great assumptions without knowing the facts. I make statements

 

based on the known facts.

 

I simply recognise when something good is out there, whether it be a piece of software, a TV set or a car. I don't have to be a "Sales rep" or "programmer" for a company to recognise what is obvious.

 

If you know something

 

the rest of us don't then please share it with us. Perhaps you work as a UK sales rep for Railroad and Co?

 

[DCCTinker]

Move over Eastenders!

 

Can I add a suggestion to the list: 'intelligent' control of double slip, single slip and 3-way points. You know how, for example, a Peco 3-way point doesn't just switch left or right for each set of blades, but when switching

 

one set of blades switches the other automatically.

 

I would also like to see support for multi-aspect light signals (not just two lights) and also the ability to automatically change one set of signals upon pressing one. For example, setting one 4-aspect

 

signal to red, automatically changes the preceding one to two yellows and the preceding one to that to green. Does that make sense?

 

 

[wiggy25]

LMSTim,

 

Pot kettle black springs to mind about reading posts.

Hey Ho, never mind.

 

I have said at the exhibitions I go to that RM is a cracking bit of software for the price, what it can do and how easy it is to use and set up and show

 

everybody it running and operating on the layout, no automation as the kids just like to play using the controllers or sliding the speed control up/down.

They actually ask if Hornby has sponsored me as I have all the Hornby DCC system running on an N-gauge

 

TrakMat layout.

 

Unfortunately not sponsored, which would be nice!

 

Most of the folks who ask about it would love for it to be available to use on other systems as they would then buy it!!

 

So that's my point to add to the desirable features

 

list!

 

Can the software be made to work on other DCC systems as that could allow many more users to buy the software.

 

 

 

 

 

 

[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.

[LMSTim]

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.

 

[MetmanUK]

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

[MetmanUK]

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!).

[LMSTim]

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.

 

[LMSTim]

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.

 

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.

 

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 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.

 

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.

 

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.

 

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.

 

[MetmanUK]

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.

[MetmanUK]

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!

[Fishmanoz]

On eLink, I have been thinking of it as an interface rather then a controller. It seems to me it just translates a RM command into a DCC signal including the data packet for the command. It would be nice to know just how it does work.

[Fishmanoz]

Going back to the original purpose of this thread - to provide Hornby with a list of possible future updates, it seems to me that Metman has established sufficient justification for inclusion of his suggestions in the list.

 

Surely it would be better

 

to have Hornby provide a response rather than have a long hypothetical discussion here on feasibility. I'm not knocking the discussion as such, just saying I think we are the point where putting it to Hornby may be more productive.

[Graskie]

RDS said:

Thanks Graskie. It would be good if you word it such that it fits in the list. If you want to split it up, no problem I will move the rest of the numbers down as required.

Sorry, RDS, I have only just returned from my wife

making me go away for our 47th wedding anniversary. I still can't understand why she didn't come with me, though!

To be serious, however, I'll now have a go at trying to explain my point.

First of all, it doesn't necessarily have to be separate

regions. It could be express locos, goods locos, mixed locos, tank locos, in fact any groups you wish to split your locos into. I happen to have gone for BR regions and diesels. You can split into absolutely any grouping. I have hard copy of "PC Model Railway

Elite DCC Controller" version 1.40 (Revision July 2012) downloaded for RailMaster. Please refer to page 25. The picture shows that the black 5 has been set up under Locomotives group "LMS", although I notice there is no ticked box against it, which means it

couldn't have been selected yet! Please also refer to page 33 headed "Loco Groups" - a very useful feature if you have a lot of locos. With regard to grouping a particular loco, I can find no mention of how to do that, except that the facility exists. When

programming a loco into RailMaster,you can input whatever new or change any existing group already allocated to it, tick the box and that's it. However, if you set another group and tick the box, on referring to the loco again on that screen, it defaults to

the first group and you have to scroll down to see which box has been ticked for that particular loco. All I'm saying is why not default a specific loco already set to the grouping you set it in? You could still scroll down and perhaps reallocate it to another

new or existing group if you want to. Mine defaults to "Eastern Region," for instance, whatever loco I display. You could have a large amount of groupings, in which case it would be a fag scrolling down to see which group you had set a loco in. Should be a

simple fix. Am I being too pedantic? It just threw me a bit at first and people tell me I'm quite clever!

[RDS]

Hi Graskie

I love your comment in your first line - classic!

Best wishes to both of you.

 

With regard to your suggestion, I hope others will comment on it because it does seem like there is a bit of an issue there.

I would like to send the

 

combined list to Hornby in the same sort of bullet format I listed last week. I think I will also try to point Hornby towards this thread so the background can be seen. In the meantime though, can you please summarise your suggestion as a point that will go

 

in the list (or maybe more than one point)

 

[96RAF]

@Graskie

I just fired up RM demo (still waiting for my eLink+RM to turn up)and it said v1.5 was available, installed it no problem in Win 8 64 bit.

At restart it went through the can't find the Elite port scenario, gave me an alternative port in

 

the high Com numbers, when the actual port in use was the one it rejected as couldn't be found - odd. Still it works fine after I told it to use that port.

 

Desirable features - I've trawled the previous comments but can't see a recommendation for being

 

able to re-orient text (to either vertical or 45 deg each way).

 

 

[PeterCook]

Hi All,

i have version 1.5 working fine under windows 7 64Bit. I do have a suggestion for Railmaster. The ability to re-initialize the elite controller port without having close Railmaster down and restart it. This would be useful because when you get

 

a short circuit caused by a derailment etc and the elite goes into ERROR mode you have to shutdown both the elite and the Railmaster to be able to link back to the track. If it was possible to just re-establish the link it would save a few issues such as points

 

resetting.

[DCCTinker]

You don't hve to restart RailMaster when you get a short circuit.

 

I got a short circuit on my layout (steam loco bogie derailed going over pointwork) and the Elite displayed Error. I simply pressed the Escape button on the Elite to clear the error

 

and carried on as though nothing had happened.

 

I am using RailMaster 1.50 and my Elite is on 1.3.

[RDS]

@DCCTinker

Thanks - I must admit I found it a little strange that you would have to restart everything.

I have only ever had to press the Escape button to reset the Elite.

 

Does anyone else have a comment on this aspect?

[Graskie]

Ever so sorry, RDS. I reckon I was recently bitten by a tsetse fly recently! Right, here I go (for what it is worth)

 

Suggestion Summary

 

Having set a grouping for a particular loco in the pull-down box “Locomotives Group” in the locomotives

 

definition screen:

 

- Whenever that loco is subsequently reviewed on that screen, the Locomotive group box should default to that loco’s previously specified group, not to the first group set up, whatever it is.

 

- This would save having to scroll

 

down to see which group that loco had actually been set up in initially.

 

[steamfreak]

Hi all

re. desirable features for railmaster.

I would like to be able to use different colours on the track plan symbols so that it would be easier to see different circuits as seen in the track plan books for instance. I think this would help on

 

larger layouts where the whole plan cannot be seen on a single screen.

Hope this makes sense

steamfreak

 

 

 

[Fishmanoz]

I'd just like to reinforce the need for point icons at 45 degrees. I have quite a few places on my latest layout where the turnout track on one point connects to the straight track on the next. Without 45 degree icons, you end up with non-existent 45 degree

 

elbows all over the place and the schematic ends up looking quite different to the actual track.

[Pete172]

RDS said:

The need for point icons at 45 degrees seems to be quite a popular choice.
I am just compiling the list again and will post the combined list again at the weekend but can I just check: Have all desirable features now been listed

and are there any others out of the ones that have already been submitted, that are supported by more than one person. (The combined list was presented on sheet 2 of this thread).

Don't forget the 3 way point icon ! there's loads of these units

about...
Also, what about a click & drag platform icon, useful on a complex layout.
P.

[Tee1707818014]

Am I too late to suggest in 50% zoom to be able to see the signal & points numbers still