Portal Problem - my fix

[boleyd]

The Long Portal Basic has been in use on my route for 2 weeks. It starts the session by emitting the first train from Boston in the morning. It drops the incoming train on a siding and returns to the portal. It has been working without any failures for 3 weeks of intensive development work.

The scenario is - the portal emits a train in the morning. It is a consist of tank cars to be filled in Portland, Maine .
Once emitted a local engine picks up the dropped consist and the delivering engine returns to the portal. NO FAILURES in dozens of runs for at least a week as other activities are added to the session. This same session with a short portal was a mess. Note: this is a 3 hopper car consist.

 

[JCitron]

I wonder what the difference is?

Since I use the long portal basic, that may explain why I don't have any issues, or not very often.

 

[boleyd]

Difference- Time in the tunnel subject to the control of the APP, Possibly a different instruction set

 

[paulper]

Interesting. I have had some recent grumbles akin to the OP about portal issues.

I have almost eradicated all issues by doing the following (with thanks to John / JCitron for his advice on some of these):

- all now 'Portal' (kuid:-25:1264), which appears to be the same length as Portal Basic, so perhaps has the same positive effect;
- added a Wait for 20 seconds before next driver command;
- moved all track objects beyond the length of the longest consist out of the portal;
- reduced the number of portals by half (I use the 'Delete Train' rule at the end of the line now).

I did, however, notice one incomplete and lost consist this morning when testing my session.

Cheers,
Paul