Help

Read This First

Reliable automatic operation begins with a reliable physical railway. These practical checks will prevent many problems that can otherwise look like software errors.

Before automatic operation

First verify the layout with one locomotive under manual control. Check every route at low speed, operate every turnout in both directions and confirm that each feedback contact changes at the expected location. Automatic operation should be the final step after the physical railway and its RailKernel definition agree.

The physical railway is part of the system

A route can be logically correct and still fail when a turnout does not complete its movement, a locomotive loses power or a feedback contact is missed. RailKernel can detect and recover from many unexpected situations, but it cannot repair wiring, track, rolling stock or mechanical equipment. Treat the railway, command stations, network and software as one operational system.

Check turnouts carefully

Turnouts are electro-mechanical devices and deserve special attention. Make sure points move freely, the decoder address is correct and the indicated position matches the physical position. Mark a turnout as unreliable in RailKernel when it needs extra time or should be avoided by route selection. Repair recurring failures instead of compensating for them indefinitely in software.

Feedback contacts are the eyes of RailKernel

Feedback information determines where trains are and whether blocks are available. Test every contact in the Feedback Monitor and verify its command station, bus, module and contact address. Investigate false occupancy, missed detection and unstable states before starting automatic driving.

  • A contact becomes occupied when the train enters its detection section.
  • The same contact returns to free after the complete train has left.
  • The feedback shown on the canvas matches the Feedback Monitor.
  • No other contact changes unexpectedly at the same time.

Keep track and wheels clean

Dirty rail and locomotive wheels cause hesitation, missed feedbacks and stops at precisely the places where reliable low-speed movement matters most. Clean the track and wheels before analysing an intermittent software problem. Also check pickups, traction tyres, couplings and freely rotating wagon wheels.

Begin with a dependable train

Use a locomotive that runs smoothly at low speed and a train whose length and composition are known. Calibrate the complete train, because a locomotive behaves differently when pulling a load. Introduce difficult, very long or unusual trains only after a simple train has completed the same route reliably.

Start small and increase gradually

Begin with one train and a short, well-understood route. Then add a second train and observe reservations, turnout operation and feedback transitions. Increasing complexity gradually makes configuration errors much easier to locate than starting with the complete timetable.

Keep the operational monitors visible

The Train Monitor, Feedback Monitor, Accessory Monitor and Drive Log show why RailKernel made a decision. Use a second screen when available, but a single screen is sufficient if you arrange the windows carefully. When reporting a problem, save the relevant log and note the train, route, block and time of the event.

Save and back up your project

Save after verified changes and keep dated backup copies before regenerating blocks, changing addresses or editing a large part of the layout. Operational state can often be recovered, but a backup remains the safest protection against a wrong edit, hardware failure or power interruption.

When something goes wrong

Do not assume immediately that either you or RailKernel is at fault. Reproduce the event safely, collect the Drive Log and screenshots, and describe the last confirmed feedback and accessory states. Clear reports help distinguish configuration, hardware, communication and software problems.

Open the RailKernel Forum

Enjoy the railway

Automation should make the railway more enjoyable, not turn it into a permanent debugging exercise. Build confidence one route at a time, keep manual control available and increase complexity only when the previous step is dependable.