MetmanUK

I use plaster cloth over bubble wrap. Once dry, the bubble wrap is easily removed and can be re-used.

My reason for commenting on this thread is because I think the issue we are experiencing is the same. Ie some form of incorrect ID being generated by RM. It hasn't been reported before so I assume it only happens in certain circumstances which at the moment I cannot work out. BUT it is repeatable. Also, as both points (with the same ID) operated I deduce that it is not the point motor(s) or signals that are wrong.

Hi, If your signals are early TrainTech, be aware that they only catered for addresses in the range 1-255. If you try to address one of these as, say, 259, then it will truncate the address by subtracting 256, leaving it with an address of 3. If this then conflicts with a point with that address, then that would account for what you are seeing. TrainTech can, I believe, offer a free firmware upgrade, which would allow longer addresses to be used. Ray Hi Ray, I first noticed this problem some time ago so they may have been early models (Train Tech) but the same thing happened with 4 signals purchased recently. All IDs were below 100. 3 worked fine but I had to change the address of the 4th. I can’t remember precisely but it was something like this. I set the 4 signals to IDs 85 to 88. 3 were ok but 87 also operates the 2 cross over points with ID 24. I changed 87 to 89 and it was ok.

@hosh I think you are missing the point. BD has no feedback other than something is in the block. Relying on speeds and timing set by the software are just not accurate enough to reliably position a loco at a specific point. LD provides that feedback. Also, it should be easy to retro fit LD (within reason) but BD is much more invasive.

I can't understand how anyone thinks LD will be able to do things that BD can't. Care to give an example? BD needs - BlocksGood softwareThere is plenty of good free software out there and any "proper" layout should have blocks as well anyway. I really can't see the fuss - I must be missing something. Any sort of "detection for the masses" seems like a contradiction in terms to me. Detection is not a "for the masses" thing. Probably from either a purist point of view or a marketing one. On a real railway block detection (something is in it the block or not) is supplemented by the on-site loco driver who knows what loco he is driving, how fast it is going and where precisely in the block it is. LD adds all of those to BD. Simple!

I'm not too concerned about how fixing a bug is progressing but I would like to know if it has already been reported and also acknowledged as a bug by HRMS so that I can avoid unnecessary work.

;-) @RAF96. I think your misunderstanding of my suggestion is also an important point. If you look at it logically, when you commence a problem report, HRMS ask if you have read the manual and troubleshooting guide. This would save you and HRMS from wasting each other's time. However, think of the time you might spend re-checking possible solutions and constructing an in-depth report even though HRMS are fully aware of the bug. Providing a known bug list may not save HRMS any time but it could save you and me a lot of time, but are HRMS worried about that (perhaps 'should HRMS be worried' is more appropriate) ? Are you suggesting that the bug list is provided from within RM itself or on the Forum? If the former, then it would have to be only those users who have bought the license and activated it who could access the list. Otherwise (and also if displayed on the Forum) it would probably discourage potential customers from buying it. Ray Naturally, displaying your dirty linen in public takes courage but it would be the sign of a company confident in its product. I hadn't thought about access only through RM but the idea is growing on me. It would certainly be a good place for HRMS to start just as long as access is via standard means and not via an HRMS in-house designed tool.

;-) @RAF96. I think your misunderstanding of my suggestion is also an important point. If you look at it logically, when you commence a problem report, HRMS ask if you have read the manual and troubleshooting guide. This would save you and HRMS from wasting each other's time. However, think of the time you might spend re-checking possible solutions and constructing an in-depth report even though HRMS are fully aware of the bug. Providing a known bug list may not save HRMS any time but it could save you and me a lot of time, but are HRMS worried about that (perhaps 'should HRMS be worried' is more appropriate) ?

Only of general interest to forum members as HRMS reporting system collects data about your system and the fault which a forum thread would not. Unless what you mean is a list of reported bugs and their state of play for being fixed. I was thinking of something more immediate - ie a web page that says, for example, "Our bug reporting system is not operating at present" or "The problem reporting system will be undergoing maintenance on Sunday" or even " Everything is OK with the world ...." !

In addition to the above, I was unable to report problems to HRMS yesterday - the facility responding with different messages. Because I am using a new (old) PC and had experienced problems previously, although I did eventually get a report to complete, I suspected my PC. This led me to various checks and general time wasting. The report completed first time this morning. Therefore, an RM (bug reporting and activation) status web page would be really useful.

I have, at long last (!), got around to writing a few short programs. I have reported a few bugs to HRMS an also some suggestions which I will mention here for completeness. 1. When making a bug report it would be nice if my email address was automatically inserted when the dialog box appears. And if auto inserted then there is no need for the email repeat box (unless the address in the first box is altered). 2. The is a button "Mark all program steps for testing". There should also be a button to unmark all marked steps. I know you can exit/re-edit the program to clear the marks but that is not the point. UPDATE: HRMS have just confirmed that both of the above will be included in a soon to be released update.

I think you are incorrect PJ. The operation of signals is just one of many things you can do when a LD event is triggered. Whilst it would be nice for everything in RM to be working, I don't think Hornby would stop LD's launch. They are losing customers to other LD systems all the time so the risks associated with delaying a launch are already building up. When it is ready, in it's boxes and in the warehouse, it WILL be launched (I think!).

At the risk of repeating myself (it was a long time ago so I have some excuse!) the requests for interface customisations and easier programming could both have been met by a programming API. I know it won't happen but those of us who are slightly more proficient at coding, for example, could then have used a proper IDE (Integrated Development Environment) and not have to wait for Hornby to re-invent the wheel. I can completely understand how the project got to this stage - it's just a real shame that someone in Hornby didn't stand back and see the value to the company of an army of free programmers inventing all sorts of useful ideas for RM. Oh well !!!!!!, i dont recall call this having been mentioned but ..... The loco dialog boxes are set to 'always on top' and therefore get in the way of other windows on my screen. In particular, whilst setting CVs, I need to refer to the instruction manual PDF and it is a right pain trying to move them out of the way. I expect Hornby will say it is to prevent basic users from losing the dialogs but ......

Phil, you have it in one! The object-oriented (event-driven) world that includes LD is simple in design but boy can it be chaotic in nature and complicated to control. You have to be aware that, when an event occurs (whether it be an LD trigger or something else), the only things you know are what is passed to the event (in the case of LD it could be Loco ID, speed etc). You do not know what else is going on in the world or what has just happened so you don't know what that loco was doing previously, nor what other signals are set at etc etc. Trust me, its going to be a lot of 'fun' setting it up!!

As a software developer I'm well aware of the conundrum facing Hornby. Of course you want to test every bit of code to destruction BUT realistically the real testing occurs once we get our hands on it. There will come a time when further testing with yet more accessory decoders or signals has little or no payback. That's when they have to take a deep breath and go with what they've got. For that reason, initial versions may have a number of unexpected problems. However, LD is not really mainstream so I would have thought initial users would be prepared for an initial bumpy ride. The main thing from my perspective is getting the hardware in and installed, much like I have played a little with eLink/RM but not yet tested it fully.

On the contrary PJ. My layout is at the stage where I am looking to install signals and LD before I commit to too much scenery. I really wish I had it now as retro fitting will not be easy.

Hi WTD, It looks like it doesn't it. Or maybe the other two who are interested are happy to just wait until it appears and do other things. 1st May 2015. There you are, a nice round 10.

I meant to add ..... The apparent limitations in the RM programming language can be seen in the context of the requirements for LD that posters have mentioned previously. These will be especially noticeable as users wish to (or are 'forced' to) push it's boundaries.

GerryPerry said: HI Some REALLY interesting thoughts here and clearly indicate experience and knowledge. Let me make a remark on the API point on which it was said ( I paraphrase) that Hornby might not wish to invest the resource ( or implied commercial risk) to publish an open source document. One only has to look at the most successful SW and HW companies we admire most to see this IS a route to success ( and domination in many cases ). It is in fact a very effective way to get both FREE resource for the supplier and a wider more committed "buy in" from a significant slice of their customer base. Be in no doubt :- That is why the companies we most admire do it ! To illustrate the negative commercial aspects of any cloak of mystery:- After 60 years of parental urging I am about to retire and join this hobby. With my professional interest of Electronics and software I expect my emphasis to be operational rather than extreme modelling and I really like the potential in this direction ( especially the VERY cheap RFID / NFC for LD and so much more ). But one simple question to which I cannot find an answer : will ELINK work with JMRI ? If so I will use RM and ELINK and so be "Hornby" for sure and then explore JMRI. If not I will be disappointed and go a different route. Of course I am but one individual but the fact that I find contradictory views on the simple question does, I submit, illustrate a certain 'cloudiness'. As I say at the top : a great and thought provoking forum thread Gerry Hi Gerry, It is my posts on the other thread that RDS refers to. Its good to hear another voice supporting the API concept especially in such a powerful yet succinct way. I fear that Hornby are not open to such a proposal as they concentrate on their own programming language and development environment which must be very expensive to develop and support. Short sighted, yes, but understandable given the market they are aiming at.

PJ_model_trains said: Hi MetmanUK I apologise if that is how it came over, it was not intended to. Occasionally certain people shoot things down, come over abrupt, don't seem to want to see both sides. That's OK PJ - I wasn't aiming at you at all. My working life was spent talking to prospective users who wanted a computer system to be designed for them personally or for their team. They usually had some ideas but wre often handicapped by what they thought a computer could do. I would tell them to forget that as that was my job. I asked them to just dream of anything and everything that they wanted to help them with their work and when they come up with something note it down on a piece of paper that they should always keep to hand. That way I got a better idea of what may be required - it was still only a starting point though. That's why these threads should be useful to Hornby because there just might be something useful to them and ultimately us.

PJ_model_trains said: Well put MetmanUK. It is good to share ideas because by doing so other ideas come from them. The main facts are, although not in the first LD to come out, the main point here is data is being sent back from the sensor that RM 'could' use to further enhance the software. To be discussing these matters now just shows the interest in the system, ad excitement as to what it can do in the future. In another thread I made the case for a programmer's API. One of my assertions was that Hornby cannot have ALL of the best ideas, especially as they probably have/use a very small development team. So, if their software developers are good at their jobs, they will appreciate all feedback (can't think of a better word at present) as it will help them to confirm/amend/improve their plans for RM and LD. PJ and Hornby are not the only ones who can have (or initiate) eureka moments!

Fishmanoz said: PJ_model_trains said: But, RM knows where we put the blue square for LD. His is what I believe to be the fundamental fallacy in a lot of the thinking here. It doesn't, and isn't likely to anytime soon. But I'm perfectly happy to be proved wrong. None of us know whether if, when or never, Fishy. Also, I'm not sure why you want RM to display what loco was last at what sensor, Why not? It has that info available. or how there will be sufficient room on a practical schematic to display it. That's a different problem! And it can't switch the display of this off when the loco reaches the "next" sensor as it has no concept of next. It could of course do it when the loco reaches another sensor. Exactly. All an LD sensor cares about is that it carries out the steps defined in its setup when it makes a detection. But the event that the detection fires off can do anything the programmer desires.

Hello PJ, Rather than repeating your previous posts can I just say that I think you now 'get it'! Programatically, from Hornby's perspective, all they have to do is create an 'image' that can display the detected loco ID (or whatever). It should also be straight forward to code the relevant support routines to make this happen AND to tidy up afterwards. either by switching off the loco identification after a few (or specified) seconds OR when that loco is next detected. The method chosen should be parameter-driven so that we can select what suits our current level of loco detection capabilities. As you say, the current sensor limit may well be easy to increase.

Fishmanoz said: Hi Metman, a lie down might be good. There are 2 issues with what you say. The first is that you will quickly run out of sensors given the number you can put on your layout. So every foot will be impractical. The second is that, even if you have them every foot, the program still doesn't know where those pieces of track are, only that a sensor is there, but just where where is remains a mystery. The track pieces are only there for your convenience, not for any practical use by Rm am in controlling your locos. At least that is what I think. I'm happy to be corrected. You are right ....... and hopefully that was what I was trying to get across!

Hi Fishy, I started reading your last post and immediately thought 'Yes, I agree completely'. Then my brain started to tick over and my thoughts changed a bit as follows. You are right in that the track plan is merely a representation of the important parts of the layout and that RM cannot therefore link the real world of what is happening on the track with the schematic drawing. However, suppose the detection decoders when dropped onto the layout plan are linked to a piece of track, in much the same way as the red/green blobs are to points. When you change points the blobs react and the grey lines in the points change. Now, when a detection point sends an event message back to RM I see no (obvious) reason why the linked detection blob couldn't flash or maybe display the loco ID briefly. This would be good programming as it provides positive feedback to the controller that a/the loco has passed a certain point. From this you could go completely overboard and include detectors every 30cm (!) and match this to your track plan so that each track section represents roughly 30cm. Overkill, I know, but its something to think about. I should say that it still wouldn't show which blocks have locos in, only the passage of locos around your layout. Should I go and lie down now ?