stopped due to dectection outside the assigned route

[Rupert van Swol]

Hello Forum , I am in deadlock so to speak with windigipet 2021PE.

I have two trains ( AC38 em AC 40 ) that continuously shuttle back and forth to the tracks of Wadebridge station 1 and 2 and back to Wantstow tracks 1 and 2.
These shuttle trains run continuously back and forth without any problem.

However if I want to manually start a sequence consisting of a build up of separate routes for the train named DMU, it goes wrong and I get this message.
“DMU was stopped due to dectection outside the assigned route. ”

I do not understand this correctly ,
the train departs from the start position and immediately comes to a full stop.
It does not even drive down the 1st route of the sequence.

The sequence is built from track 4 to 5 and then with a longer route ( #39 ) to bridge the station track wadebridge 1. So that the train DMU is always driven at once to the destination LR North ( LR North is right behind switch 14) .

In the route No. 39 ( TSW5 > LR North ) at the switch condition tab, so-called extended conditions are included. Here is determined that the VHD 53 and VHD 57 may not contain a train.

This option is also included to prevent two trains from blocking each other with a so-called Dead Lock.
on the singletrack “ Main Line ”.
If the sequence is started with RTS-ID4,  I get this error message. 

Also I regularly see that trains disappearing from a mIVD, see track #6  ( train 2727 ) is now missing ,  to spontaneously appear somewhere else. 
I call this so called Railcom Jumpers and it is especially with the new Zimo MS decoders.
Also this has a lot of influence on train operation.
Q,
Is this a software thingy,  or am I applying the extended conditions incorrectly.
Or should the monitoring be built via the dispatcher.

Please advise.
With kind regards,
Rupert van Swol

[Markus Herzog]

Hello Rupert,

Please activate the feedback log in the logbook, reproduce the situation and attach the log here

Regards
Markus

[Rupert van Swol]

Hello Marcus,
As you requested, I was able to reproduce the log ( 2727.txt ) of a Railcom Jumper situation.
It concerns a train (2727) with a the decoder address 27
Train 2727 was on hold on siding 6.
The DMU had just departed from Wadebridge1 in to the Siding 4 .
The DMU has to run over the Run around Loop #5 .

However out of nowhere comes the Lok 2727 on this track 5# . 
The DMU is stopped at a red signal as it should be . 

The departure time of the DMU from wadbridge 1 is in the log at 17:43:18 .
The added project plan is at the time the trains were stalled
Hope you discover something , which I have overlooked. 

Kind regards
Rupert

[Markus Herzog]

Hello Rupert,

please take a look at the log at this line:

17:38:27   2.LoDi-S88-Commander LX Railcom reporter Module 5 Connector 4 Vehicle address 27 Direction 1 Transponder enters Block (-> FB 37)

There is no corresponding line telling WDP, that the decoder has left this section. And thus for WDP the vehicle still (also) reported to be at FB 37....
WDP is just telling you what your system reports...

And the system told WDP just a few milliseconds before that the contact is also occupied

17:38:27   2.LoDi-S88-Commander LX S88.2 Module: 5 Connection: 4 occupied
17:38:27   Feedback contact 37 occupied (TSW6/TSW6)

This log is reporting 1:1 the hard facts reported by your digital system.

Regards
Markus

[Rupert van Swol]

Hello Markus ,
thanks for your response and that on Sunday. 

I can well follow your logic and also agree with you that Windigipet cannot report anything,  but only the status change of the elements on the layout plan.

However it does not map, how the train 2727 moved from track 2 to track 5. 
Two routes are available for this movement ,namely route with ID 10 and the route 24

Route 10 contains the following detectors , 37, 38, 50,43,44
Route 24 contains the following detectors 15,16,17,42,50,40,44

In the timeline of the Log of the 2727 , none of the above detectors became active.

I think the problem is not with the Physical reporters. B
ut more in the processing of data coming from the Local Railcom detector assigned to a Windigipet detector.

In the long term observation I have observed that in case of an event,  that can be triggered internally by windigipet or externally ( emergency stop  ) the railcom messaging from the Local railcom detectors drops out.

While the physical detectors remain at occupied.

Very remarkable is that only feedback contact 37 shows the true situation which also corresponds to the status data shown in lodi FX.

see Youtube movie . https://youtube.com/shorts/iDuGk3SUk88?

Only when operating the emergency stop,  I can trigger a similar situation.
Again it sometimes occurs also with internal events in Windigpet.

In short something is happening internally in the Lodi System on an instruction from Windigipet  or a wrong instruction in the API of the LOdi S88 LX , that temporarily turns off the Railcom message .

However in very certain environmental conditions it seems the Windigipet is not  able,  to link the railcom information to the corresponding active feedback contact , in this case number 37.

With the exception if the emergency stop is used and terminated.

I do not know if it belongs to the normal behavior of Digipet.
In lodi FX all railcom messages fall away . In my WDP track plan only one detector is affected , and that is detector 37.

[Markus Herzog]

Hello Rupert,

First of all:
I misunderstood you first, that you had the problem, that the train 2727 was realy moving from siding 6 to another place an it did not delete the message in siding. I Understood now, that when another train was moving to detector 16 train 2727 address 27 appeared there, but in the end effect it will make no difference. But lets start….

Very remarkable is that only feedback contact 37 shows the true situation which also corresponds to the status data shown in lodi FX.

That is very easy to explain:
For this VHD you have activated the option "If vehicle is no longer reported, delete vehicle display entry".
If have checked several other VHD in your track diagram and at none of the checked VHD this option is activate. Thus this first difference is absolutly correct and just based on your settings

In the long term observation I have observed that in case of an event,  that can be triggered internally by windigipet or externally ( emergency stop  ) the railcom messaging from the Local railcom detectors drops out.
While the physical detectors remain at occupied.

This also absolutly normal. The detectors (and this applies to most occupation detectors) are constructed in a way that even when the main track power is off they still report the occupation (some store it simply other make it with a substitute current measurement).
But for Railcom a real track power is needed and the detector say some short time after power off: "We don´t see any loco anymore". Andreas Hornung confirmed this in a longer phone call also to me.

In short something is happening internally in the Lodi System on an instruction from Windigipet  or a wrong instruction in the API of the LOdi S88 LX , that temporarily turns off the Railcom message .

I also discussed this with Andreas Hornung and he confirmed, that there is absolutly no way for WinDigipet to instruct the Lodi System that this could happen.

ut more in the processing of data coming from the Local Railcom detector assigned to a Windigipet detector.

I can not show you the code producing the present log messages, but you can believe me if in the log a message like "address 27 Transponder enters block xy" appears this 1:1 the message received via TCP.
And before there even appeared message like "address 27 Transponder exists…block x" (or y)

Andreas told me, that had also contact with you. And the absolutly agreed, that he is also the opinion, that it is no WDP problem and even not a LoDi problem. He told me that he informed you about his idea regarding your problem. But I will not write this idea here in Public because I don´t want to take about potential third party problems. But Andreas assumption in this case sound absolutly reasonable to me in contrast to your assumptions.
Take a look at 17:39:02 or 17:39:04 at the log. This amount out different vehicle detections for the contact 56,54 and so on can´t be an invention of WDP.

I am sorry but I don´t know how to solve this situation from WDP-side.

Regards
Markus

[Rupert van Swol]

Dear Markus,
Last night I had contact with Andreas Hornung, there has been a suspicion for some time that the phenomenon is due to a so-called third party.
But that it is difficult to put the finger on the sore spot .
In short a claim to a non conformity will have to be proved 100%.

Tonight on my hardware ( lodi system ) , measurements will be made with a Picoscope 3000 , to get that data where “the problem ” can catch in hard copy.

It is then up to the third partner how quickly it comes up with an adjustment in the form of a firmware update.

I will check the option in Windigipet at all detectors “ If vehicle is no longer reported , delete vehicle display entry””  I do not know yet what the effect is then on the trains without axle detection “ But I suspect none , since this is railscom issue.

Another option is to turn off the railcom option in CV29 and disable the railcom on the boosters. Until the firmware becomes available.

This topic can be closed , as it is clear that the cause is not Windigipet and the hardware of Lokstoredigitaal , I think also on behalf of Jan Stienstra who also knows the phenomenon.

I want to thank you very much for your great effort in this matter , but actually I want to thank the whole Windigipet team , considering the amount of time in answering questions on the forum and the development in recent years considering the Promo movie about Windigipet 2025 .
Best regards
Rupert van Swol