[Solved] Unexpected IN. Loc put into Idle?? Topic is solved

rvooyen
Posts: 979
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

[Solved] Unexpected IN. Loc put into Idle??

Post by rvooyen » 07.01.2019, 21:35

I have a large set of schedules and tours and these have not changed much in at least a year or so and have always run as expected.

However recently (newer RR versions?) I am sometimes getting the error message below, when running (many) trains.

20190107.122427.109 r4201E 00000D5C OLcDrive 0243 unexpected IN event for [NS Mat46], state=[5][LC_GO]
20190107.122427.109 r4101W 00000D5C OLcDrive 0272 Setting state for [NS Mat46] to LC_IDLE and stop running auto mode.


This is mostly for the same loc in the same block at the start of a new tour.
The block is relatively short, so I have an enter2in sensor (and an in). The enter2in time is 1000ms.

After seeing the message I thought the IN might be the issue so this was removed and the block only has the enter2in sensor.
But this did not stop the error message from occurring.

In order to try to resolve this I need to know why and for what reason the error message is generated? Rob?

I have watched the situation closely and can find no reason for the message or where this unexpected IN is coming from.
Also why is the loc put into idle?

The situation is far too complex to add the usual files and it takes upto 45 minutes of acitivity for the message to appear.
Again I have run the tours and schedules for more than a year, before this message has started to appear.

I have the theory that it occurs under heavy load and the enter2in timer is lost, so when it times down and the IN is generated virtually, the system says -- Where did this IN come from??? and generates the message.

It is annoying because my daily run schedule is disrupted with the loc going idle.

Anyone any ideas?

Robert
Last edited by rvooyen on 08.01.2019, 18:59, edited 2 times in total.

rjversluis
Site Admin
Posts: 42306
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: Unexpected IN. Loc put into Idle??

Post by rjversluis » 07.01.2019, 21:58

Maybe 1000ms is too long or the train too fast?
The IN event is neither related to the current block nor to the destination block.

Relying on long timers is not a good approach for tracking trains; User real sensors instead.

rvooyen
Posts: 979
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: Unexpected IN. Loc put into Idle??

Post by rvooyen » 07.01.2019, 22:14

Rob,

1000ms is only one second or about 20cm travel. I have also removed the second sensor, these is only an enter2in.
The train is nowhere near any other sensors, the in is virtual.
The train is still well within the current block when this message is generated. Why go idle?
It also does now always occur, train passes this block a number times.

Maybe you can explain exactly why/when this message is generated so I can look for an answer.
Message only recently being seen.

Robert

rvooyen
Posts: 979
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: Unexpected IN. Loc put into Idle??

Post by rvooyen » 07.01.2019, 22:39

There. I was able to capture the issue with just one train running and immediately created and issue.zip, so all the info should be there.

The Loc Mat46 was in block 67 when this happens (as it sometimes does). It stops in this block (forced to idle).

There was no other traffic so load is not an issue.

See the attached.

Robert
You do not have the required permissions to view the files attached to this post.

rjversluis
Site Admin
Posts: 42306
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by rjversluis » 08.01.2019, 08:16

Hi Robert,

check sensor 133; Seems to be waggly:

Code: Select all

20190107.122427.109 r4201E 00000D5C OLcDrive 0243 unexpected IN event for [NS Mat46], state=[5][LC_GO]
20190107.122427.109 r4101W 00000D5C OLcDrive 0272 Setting state for [NS Mat46] to LC_IDLE and stop running auto mode.
20190107.122427.125 r4202E NS Mat46 OBlock   0631 Ghost train in block [66], fbid=-, code=-
20190107.122914.500 r4202E 00000DF8 OBlock   0631 Ghost train in block [65], fbid=133, code=
20190107.122914.546 r4202E 00000DF8 OBlock   0631 Ghost train in block [66], fbid=133, code=
20190107.122915.281 r9999W 00000DF8 OBlock   1106 Ghost train no longer in block 65, fbid=133, code=
20190107.122915.281 r9999W 00000DF8 OBlock   1106 Ghost train no longer in block 66, fbid=133, code=
20190107.122915.968 r4202E 00000DF8 OBlock   0631 Ghost train in block [65], fbid=133, code=
20190107.122916.015 r4202E 00000DF8 OBlock   0631 Ghost train in block [66], fbid=133, code=
20190107.122916.656 r9999W 00000DF8 OBlock   1106 Ghost train no longer in block 65, fbid=133, code=
20190107.122916.718 r9999W 00000DF8 OBlock   1106 Ghost train no longer in block 66, fbid=133, code=
20190107.122917.453 r4202E 00000DF8 OBlock   0631 Ghost train in block [65], fbid=133, code=
20190107.122917.453 r4202E 00000DF8 OBlock   0631 Ghost train in block [66], fbid=133, code=
20190107.122918.593 r9999W 00000DF8 OBlock   1106 Ghost train no longer in block 65, fbid=133, code=
20190107.122918.609 r9999W 00000DF8 OBlock   1106 Ghost train no longer in block 66, fbid=133, code=

rvooyen
Posts: 979
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by rvooyen » 08.01.2019, 09:47

Rob

136 is the enter2in 137 was the in.
133 is from the previous block and is an enter for two blocks. This is of no concern has been there for years.

I have now seen exactly what happens:

Mat46 passes the 136 enter2in time now ar 500.
The virtual in is fired and the loc stops as required. The route is then cleared the signal changes and the loc starts.
But now as it passes the old in 137, now not used, the loc-idle error is given and the loc stops.

Somewhere in memory the 137 sensor is still seen? This occurence does not always happen but I can now repeat it regularly.

I am now going to delete the 66-67 route and receate it to try to remove the 137 memory.

I have noticed other instances of route memory like trying to change a speed. Only after deletiing and recreating a route did the speed change.

Is not all routes only some.

Robert

hermannk
Moderator
Posts: 1145
Joined: 06.07.2014, 12:32
Location: Kiel Germany

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by hermannk » 08.01.2019, 10:26

Hi Robert,
I had a look to the issue you gave us 07.01.2019, 22:39
Feedback "137" ist defined and used havily in block "67".
Do not only delete a feedback definition; check the usage additionaly.
Hint: reduce defining feedbacks in blocks only for the global routes "all enter +" and "all enter -". It's enough and makes live more easy.
King regards
Hermann

Besra
Moderator
Posts: 3790
Joined: 10.08.2009, 17:54
Location: North Rhine-Westphalia, Germany

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by Besra » 08.01.2019, 10:34

Hi Robert,

in addition to Hermann's statement:

In Block 67, route 65 to 67: enter2in and in are defined
Zwischenablage-1.png
Regards
Besra
You do not have the required permissions to view the files attached to this post.

rvooyen
Posts: 979
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by rvooyen » 08.01.2019, 11:11

I have now been able to create even in virtual mode --see the issue.zip.

I have removed all instances of 137 in the 136>137 direction. This is a two-way block so 137 is enter for the other direction.

So all sensors were hand set. In this case the loc did not even get to 137 since it was put into idle before I could even set the 137.
This is very strange and needs to be looked at. AGain I have these routes configure for years now.

The only change has been to make fb 136 an enter2in instead of an enter. This was needed to get the loc to stop in time since the 137 in is too close to a crossing rail.

I will continue to try now by deleting the route and re-creating it.

Robert
You do not have the required permissions to view the files attached to this post.

hermannk
Moderator
Posts: 1145
Joined: 06.07.2014, 12:32
Location: Kiel Germany

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by hermannk » 08.01.2019, 11:37

Hi Robert, did anyone tell you to delete routes?

I was talking about block "67". There you should modify:
- block "67" / Preferences / Routes / ....
-- configure the sensors for "all enter +" and "all enter +" properly;
-- remove in this dialog all configured sensors from the listed routes "Route 52-67" ...;
-- they are (normally) not needed.
Kind regards
Hermann

rvooyen
Posts: 979
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by rvooyen » 08.01.2019, 11:59

All,

I attach an issue.zip in which you can all recreate the issue. As I have done now a couple of times.

Open the plan to layer 1 and place the loc Mat46 into block 66.
Set auto mode.

Set destination to block 53, eg by moving the mouse to this. The loc will start and go thru 67 to 53.
If it does not bring up the loc_idle in 66 first time, soft reset the loc in 53, SWAP it. Set destination back to 66.
Now start again by set destination to 53.

You should now see that when you activate sensor 136 (enter2in) the loc will stop shortly until route cleared, when the signal goes to yellow and loc starts it will got to Loc_Idle (or when you pass 137).

I can repeat this. I have deleted the route 66-67 and recreated it. Still happens,

The issues does NOT happen if the loc is started in block 65 and sent to 53 and back.

So very weird and annoying because it disrupts my daily train flow.

Robert
You do not have the required permissions to view the files attached to this post.

rjversluis
Site Admin
Posts: 42306
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by rjversluis » 08.01.2019, 12:17

Sensor 133 is Enter for block 65.
Ghost detected if Mat46 starts and runs over it.

rjversluis
Site Admin
Posts: 42306
Joined: 10.04.2006, 08:48
Location: Speyer, Germany
Contact:

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by rjversluis » 08.01.2019, 12:23

Check this:
sen133-65.png
You do not have the required permissions to view the files attached to this post.

rvooyen
Posts: 979
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by rvooyen » 08.01.2019, 12:31

Rob,

Not the issue. Does not matter.
Here is a very simple and very repeatable test that causes the loc idle every time.
Start loc mat46 in 53. Set dest to 66. In 66 set dest to 53 and as you pass 67 voila! It also throws a ghost into 66 for some reason??

It only happens in the case that Mat46 comes from 52 or 53 and goes to 66 and back again to 53.
If started in 66 the loc goes thru 67 ok.
It does not happen if the loc goes to 65 which has all the same ghost issues. Also I have accpeted ghosts in both 65 and 66.

Please do the test and see the error. It is only when going to 66 and back. I have spent a lot of time localising this. There must be something to check out in the SW I think.

Robert

rvooyen
Posts: 979
Joined: 08.12.2012, 11:31
Location: Netherlands (Hilversum)

Re: [Issue] Unexpected IN. Loc put into Idle??

Post by rvooyen » 08.01.2019, 12:50

Further info and the difference in blocks means a SW issue. (I think)

The difference between the blocks 65 (does not occur) and the 66 (does occur) is that the 66 has a short2in at 133 so a timer is set. Block 65 has only an enter (no timer) at 133.

When the loc leaves 66 - even after waiting for the timer to complete I.e. train is IN 66 , when the train leaves the 66 and goes to the 67 the 66 timer still seems to be active and causes the unexpected in and the ghost in 66.

This I feel must be a software issue. I have tried the 66 with an enter and the error is NOT shown.

So If 66 has a timed enter (Enter2in or Short2in) then the issue occurs. If no timer (Enter) the issue does not occur.

Again I have seen this error only recently so I think some SW issue has arisen.

Now exact cause and situation is known.

Robert

Post Reply

Return to “Automatic mode”