unexpected in event resets timer enter2in?

[ron&bram]

WHen an unexpected in event occurs it appears that the enter2in timers are reset by that event, or that the value setting of the timer is added to the timer with every unaxpected in event. I tried by manually (with a wire) triggering the s88 input to generate 4 unexpected in events during one pass of the train. The enter2in timer value was 10000 ms and the in event only after 40 seconds or so. Details are also described here, together with trace files: http://forum.rocrail.net/viewtopic.php?t=1080&sid=1a3188cd56407d5a5f9f8005f2baebc9.
I also made a very simple plan (attached), where a loc drives from block 1 to block 2. Sensor 1 triggers the enter2in event of block 2 with a timer value of 10000 ms. From block 2 (no wait) the loc drives to block 3. Sensor 2 trigges the enter2in event of block 3, timer value 5000. Block 3 also has a enter2route sensor from block 2. In the also attached trace file I triggered sensor 1 (fb 17) many times. You can see the timings going wrong, at 21:59:07 sensor 1 is triggered, so at 21:59:17 there should be the in event, the enter2route event and because of the enter2route event the loc speed should go to mid. Loc speed is reduced at 21:57:30. At 21:57:31 I triggered sensor 2 (fb18), so 5 seconds later the in event of block 3 should come and the loc should stop. The actual stop command comes at 21:58:16.
I experimented a little bit and noticed that the unexpected in events only happen when the sensor is defined for "all" route (I did not test the all-reverse route). When I set the sensor not for all routes, but for a specific route I do not get an unexpected in event and no problems with the timings. I used head revision.

Best regards, Ronald

[ron&bram (ronaldestherbram)]

and the trace

[Rocrail (r.j.versluis)]

Hi Ronald,

you have defined two events:
      <fbevent id="2" action="enter2in" from="2" endpuls="false" ghostdetection="false" byroute="2-3"/>
      <fbevent id="" action="enter2route" from="2" byroute="2-3" endpuls="false"/>

enter2in and enter2route are mutual exclusive.

[ron&bram (ronaldestherbram)]

Hi Rob,

quote:
enter2in and enter2route are mutual exclusive.
unquote

Are you sure? On my real layout the combination of enter2route and enter2in works perfectly (remember forum topic on shared sensors). Because of the short tracks in the station I want to have the enter event before the train drives on the station track, but there is no place to put an unique sensor for each station track. The last block before the station blocks sends an enter2route event op that blocks in event. Station block turns blue, when trains needs to stop it goes to Vmid. Loc enters station block, activates the block sensor which triggers the enter2in event and after the defined time delay the in event is generated and the train stops (on the same spot every time).

I will test tonight the demo without the enter2route, but I think outcome will be the same (I had trouble with reliable stopping on the real layout before using the enter2route event, but as an afterthought I realised it was always the same loc and that that loc was the only one with a car with tail lights and the unexpected in event message).

Is it expected that I only get unexpected in events for the all route and not for specific routes?

[Rocrail (r.j.versluis)]

This sounds more or less like a dialog problem. Or did you also tried to setup by text editor?

[ron&bram (ronaldestherbram)]

Hi Rob,

I changed the demo plan; removed the enter2route and set the departure speed of block 2 to Vmid to get a speed change on the in in event. I ran the plan on the virtual cs, once without "double pulse" and once with.
Without the unexpected in event the timing is just what is to be expected. When the enter2in (10000 ms) sensor of block 2 is activated there is "sensor event addr=17", 10 seconds later the in event occurs and the loc speed is set to Vmid. When triggering the enter2in (5000 ms) sensor (addr 18) of block 3 the speed is set to Vmid (loc has to stop in block 3) and 5 seconds later the in event of block 3 occurs and the loc speed is set to 0.

With an unexpected in event the trace gets a lot more confusing. I triggered the sensor of block 2 twice, the second 3 seconds after the first one to generate the unexpected in event. In block 2 every goes as planned, 10 seconds after the first triggering the speed is set to Vmid.
Next, the sensor of block 3 was triggered. But now, the speed is not set to Vmid right away. There is an unexpected in event message (20 seconds after the first trigger of sensor of block 2; 17 seconds after second trigger; 10 seconds after the in event of block 2; 4 seconds after trigger of sensor of block 3). Only after a delay of 5 seconds speed is set to Vmid and after 10 seconds the speed is set to 0.
Strange thing is that the sensor of block 2 gets triggered twice, but the timings of block 3 are affected. It looks like the unexpected in event generates a delay with the length of the enter2in timer of block 3 between the sensor of block 3 activating and the occurence of the enter (not the in) event in block 3.
I ran another one, this time triggering the sensor of block 2 three times (two unexpected in events), the delay between the triggering of sensor of block 3 and enter event/speed change to Vmid is not 5 but 10 seconds. I also had changed the enter2in timer of block 2 from 10 in 8 seconds. The first unexpected in message came 8 seconds after the in event of block 2, the second 16 seconds. This would suggest that they are connected to block two, because the timing of the messages seems related to the value of the enter2in timer of block 2

The plan file and the three trace files are in the zip attachment, the names of the trace file should be self-explaining.

[ron&bram (ronaldestherbram)]

I forgot to press save after editing some of the trace files to highlight the described events, please use this zip file and not the previous.

Sorry.

[ron&bram (ronaldestherbram)]

Hi Rob,

What do you mean with this:
> This sounds more or less like a dialog problem. Or did you also tried to setup by text editor?

If it concerns this question:
> Is it expected that I only get unexpected in events for the all route and not for specific routes?

maybe I must express myself more clearly. If I define a sensor as an enter2in in the "all" route on the routes tab of the block properties and it gets triggered twice, I get an unexpected in event message. If I define the same sensor as enter2in for a specific route (route from block 1 to block 2 for example) and it gets triggered twice I do not get an unexpected in event message.

More importantly, with the next test I again pulsed sensor of block 2 twice, but waited with the triggering of the sensor of block 3 until the unexpected event message had passed. No timing problems, which brings me to the conclusion that an unexpected in event only disrupts timings of an enter2in sensor when it occurs when the timer is running (so when the enter event has been triggered but the timer for the in event has not yet elapsed).

[Rocrail (r.j.versluis)]

Hi Ronald,

I set this bug to "won't fix" because it is easy to correct is with the right sensor setup.

[ron&bram (ronaldestherbram)]

Hi Rob,

I agree, lets just keep this in mind in case somebody "pops up" in the forum with some strange behaviour. Using the enter2in with specific routes does not generate an unexpected in event upon second triggering. Shall I augment the wiki with the advice that it is better to use the enter2in event with specific routes to avoid an unexpected in event?