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.