Britannia Builder Posted January 31, 2018 Share Posted January 31, 2018 Since upgrading to Railmaster 1.67 I've noticed if I select a spot sound function such as 'Brake' or 'Whistle' (which is not latching on/off, but lasts for a couple of seconds) and then move the throttle (eg click the stop button) while the sound is still working, the throttle command is ignored. The problem is in Railmaster rather than the TTS decoder, because the little green square towards the top left of the screen doesn't light up as it should to show that a speed command is being sent to the eLink. I have to wait for the greyed-out sound button text to turn black again before I can use the throttle successfully. And strangely, if I keep clicking the throttle button while the sound button is greyed out, it remains greyed out indefinitely until I stop clicking. So I have to remember to change the throttle before sounding the brakes, otherwise the train runs into the buffers! I hadn't noticed this behaviour under 1.66. Has anyone else encountered it? Regards, John Link to comment Share on other sites More sharing options...
Britannia Builder Posted January 31, 2018 Author Share Posted January 31, 2018 Thanks Chris, I hadn't spotted that piece in the programming section of the manual and I guess that it probably does apply to manual sound commands as well. So as you suggest it's probably always been like that and I haven't noticed it before. It's a bit strange though, because clicking a throttle button while the sound is on isn't completely ignored - it updates the user interface in Railmaster correctly, so you'd think that it would be able to send the speed command to the eLink too. Does a non-latching sound function completely tie up the communications link for its duration? A latching (on/off) sound function doesn't have the same problem - I can quite happily control the speed of my Black 5 while the fireman is shovelling coal. Regards, John Link to comment Share on other sites More sharing options...
Chrissaf Posted January 31, 2018 Share Posted January 31, 2018 John (BB), not in any way saying you are wrong and it is not a bug, but could it possibly be a case that it has always been this way and you have just never noticed it before. The reason I make this suggestion, is due to the documented comment in the manual - copy below. Granted, this extract comes from the 'automation programming' part of the RM manual. But, I would have thought that any command timing restriction that is applicable to the program function would also be applicable to live control as well../media/tinymce_upload/748c0a93ccd4d465cc5a50bf7a5d1c1a.jpg.However, that said. I would like to think that live control works differently and has a buffer where DCC commands are stored and transmitted in strict chronological order. Such that commands are not missed. It's possible that the live control is supposed to work this way, and your observation is indeed a bug. Whereas with a program the buffer is replaced by the timed steps in the program thus the timing of commands sent is more critical..Only HRMS can really answer this one, so if you think it is a bug, then I suggest you report it through the 'help system'. Run through the actions that generate your issue just before sending the support request, that way HRMS will be able to see what is happening in the log file that RM automatically attaches to your request.. Link to comment Share on other sites More sharing options...
Chrissaf Posted January 31, 2018 Share Posted January 31, 2018 John, I don't know any more than what is either written in the manual, what I read on this forum from other user's experiences and what I experience myself in the flesh. Your guess is as good as mine..PS - As you can see managed to sort out my posting error in the end with your reposting assistance. Link to comment Share on other sites More sharing options...
Britannia Builder Posted January 31, 2018 Author Share Posted January 31, 2018 Thanks Chris. I'd be interested to hear if anyone still on 1.66 or earlier can reproduce this behaviour - if so, I'll assume that RM is designed to work like this and won't report it to HRMS. I don't have any experience of using the Select or Elite controllers - do they also ignore throttle movements while playing a sound? Regards, John Link to comment Share on other sites More sharing options...
Chrissaf Posted January 31, 2018 Share Posted January 31, 2018 Although I have an Elite, I tend to use it via RM most of the time..Just touching back on my previous reply for a minute..However, there might be a clue to the difference that you described in your later reply, in the manual text I pasted above. The manual text extract has this line in it:"especially if you have set up a sound macro function".When you look at the macros included as standard for the different sound function buttons (click the F button in the Loco Setting screen to see them), some of the 'spot sounds' have a P2 command. P2 is pause for 2 seconds. I suppose it is possible that when whatever is pausing is in its pause state then the opportunity exists for a command sent during this pause period to be missed. Else, why would HRMS specifically highlight the macro as a potential issue in their text..PS - A latching sound doesn't have a P (Pause) command in the Function button macro. So this could also tie in with your observations..Or of course, can anyboby else reproduce this behaviour John is seeing on 1.67 as well. Because if they can't, then that would also indicate a bug that only you are affected with..So come on forum members please start testing and report back.. Link to comment Share on other sites More sharing options...
St1ngr4y Posted February 1, 2018 Share Posted February 1, 2018 Hello everyone,Just to add my two-penn'orth... A few weeks ago I was experimenting with various sound functions, and I came to the conclusion that the purpose of the sound macros is, at least, questionable. Because I use an Elite as my controller, I was able to select a particular sound loco on my Elite, and display the first page of functions F0-F9. Then when initiating sound functions for that loco from RM, I observed the sound markers along the bottom edge of the Elite display. For a latching function with on/off in the desription, one click on RM switched the function on and its marker appeared on the Elite display, a second click on the same RM function switched the function off and the marker disappeared. For a non-latching function (or spot function as described above) with NO macro attached to it, a single click on the RM button initiated the sound, the marker button appeared on the Elite display, then about one second later the marker disappeared from the Elite display. This indicates that two commands are being sent from RM to the Elite, one to switch on the sound and the other to switch it off. However, I would guess that if the second command arrives at the Elite before the sound has finished playing, it will not cause the actual sound to be truncated. It just means that the Elite status for that sound is now off so that if the Elite is used for that function it will play the sound.It could be that when RM goes into the program code which sends these two commands it executes a "hard" loop between the first and second, thereby effectively ignoring any keyboard input during this time. Very speculative, I know, but a possibility. Ray Link to comment Share on other sites More sharing options...
Britannia Builder Posted February 1, 2018 Author Share Posted February 1, 2018 Thanks Ray, that's interesting. Perhaps the only reason for the RM non-latching sound buttons being greyed out and blocking other communications for a few seconds is so that RM can turn off the Elite function indicators, as you describe. It doesn't seem to send a message to the TTS decoder to stop the sound, because some sounds are shorter and some longer than the fixed grey-out time on the function buttons. I guess it was easier to write the software so that it didn't allow other communications during this grey-out period. I do wonder whether earlier versions queued up the throttle movements and sent them after the sound had finished, rather than discarding them. I've tried changing the Brake function on one of my locos to be latching (on/off). This doesn't affect the sound, which still just lasts for a few seconds, but it avoids the risk of crashing into the buffers because the throttle can still be moved while the brakes are squealing. Regards, John Link to comment Share on other sites More sharing options...
St1ngr4y Posted February 1, 2018 Share Posted February 1, 2018 Hi John,With your Brake function, if you restart the loco then use the Brake function again, does it work the second time? Ray Link to comment Share on other sites More sharing options...
Britannia Builder Posted February 2, 2018 Author Share Posted February 2, 2018 Hi Ray, Yes, obviously I have to un-latch the brake function at some convenient point, then I can use it again. The other problem I get is that if I sound the whistle on a stationary loco and then immediately click the throttle button this is ignored, but this at least doesn't cause a collision. I'll report the issue to HRMS and see what they say. Regards, John Link to comment Share on other sites More sharing options...
St1ngr4y Posted February 2, 2018 Share Posted February 2, 2018 Hello again John,I've been playing around with a whistle function set up as F2 on a newly-installed King TTS decoder. I configured it first as latching, with on/off in the description. With Task Manager recording CPU usage in the background, I pressed F2 twice with 3 or 4 seconds in between. The loco played the sound once. The first Task Manager image below shows a "spike" for each press of the button.Then I reconfigured F2 to be non-latching, without the on/off in the description. This time I pressed the button once only, and the CPU usage is shown in the second Task Manager image. The shape and duration of the usage is no longer a "spike". It shows that CPU is being used for the duration of the F2 i.e. between the first and second commands sent by RM to the controller to toggle the function on then off a second or so later. Ray /media/tinymce_upload/0379efe06a0924a60124d9dbba0ece6d.png Link to comment Share on other sites More sharing options...
Britannia Builder Posted February 2, 2018 Author Share Posted February 2, 2018 Hi Ray That does indeed suggest that the communications task is sitting in a tight loop watching the clock while the non-latching function is greyed out, and hence presumably not receptive to other requests. I've now run task manager myself and seen the same results. I assume that you're on 1.67 and seeing the same symptoms? It's very strange that clicking a throttle button while this is happening seems to reset the timer and lengthen the greyed-out period, so the comms task is in some sense aware of the throttle action. I've now reported the issue to HRMS. Regards, John Link to comment Share on other sites More sharing options...
St1ngr4y Posted February 3, 2018 Share Posted February 3, 2018 Hi John,Yes I am on 1.67 and have seen the symptoms you describe. I am thinking of changing a lot of my locos' sound functions to latching, because I do most of my operating using programs. That way could minimise the adverse effects while running a program. The program could then repeat the command, say, at the end of the program to return the function to its "off" state. For example, if I have a F2 whistle command followed one second later by a signal change command, it could be that the latter is being delayed by a "spot" F2. A little experimentation might be in order .... Ray Link to comment Share on other sites More sharing options...
OssieB Posted February 3, 2018 Share Posted February 3, 2018 Hi John and Ray, Just to add that I have experienced the same problem. However, up to you raising this thread, I had taken it to be either an error by me or too quick a click of the mouse on a command. I had usually noticed it after giving two blasts of the whistle and then opening the throttle with shunt or cruise. I had wondered why the throttle indicator operated but there was no movement of the loco. I think this may have occurred before 1.67, but I cannot be certain. If I get chance later, I will revert to 1.66 to see if the problem existed then. The workaround on/off latching is fine, but you have to remember to switch off each time, especially in programmes. It would be much better if HRMS can resolve the issue and eliminate the delay.BarryO Link to comment Share on other sites More sharing options...
OssieB Posted February 3, 2018 Share Posted February 3, 2018 I have now reverted to 1.66, which is the earliest I have on my current RM laptop, and the same delay on the non latching functions is there.I have timed the delay from the start of the function to the release and confirm that it is 3 seconds.BayyO Link to comment Share on other sites More sharing options...
St1ngr4y Posted February 3, 2018 Share Posted February 3, 2018 After some experimentation, here are two extracts from the RM log file when running a program. The first is with the F2 whistle as a latched function, the second as a spot function.... 03/02/18 15:55:39 00:01 Executing: F2: Whistle med on/off for: 4-6-0 Thompson B1 Early BR Black03/02/18 15:55:40 00:02 Executing: Signal clear for: Signal: 010103/02/18 15:55:43 00:05 Executing: F2: Whistle med on/off for: 4-6-0 Thompson B1 Early BR Black03/02/18 15:55:44 00:06 Executing: Signal clear for: Signal: 0101In the first run, all four commands are executed at the expected time. 03/02/18 15:58:42 00:01 Executing: F2: Whistle med for: 4-6-0 Thompson B1 Early BR Black03/02/18 15:58:44 00:02 Executing: Signal clear for: Signal: 010103/02/18 15:58:46 00:05 Executing: F2: Whistle med for: 4-6-0 Thompson B1 Early BR Black03/02/18 15:58:48 00:06 Executing: Signal clear for: Signal: 0101 In this second run, each signal command is executed one second later than expected. Ray Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.