RSI NetworkStart Timeout: Late Completion, Not Failed Start

MotionController::NetworkStart() returns error 1000000022, yet RapidSetup later reports the EtherCAT network as OPERATIONAL. That combination points to two separate completion boundaries: the C++ caller stopped waiting, while the EtherCAT master continued processing and ultimately started the network. Missing Axis objects are a second issue caused by configuration-file resolution or a stale host object created before discovery completed.

Where does the start request stop?

Follow the packet and the control request. The application creates its host-side motion-controller object with MotionController::CreateFromSoftware(char*), starts RMP.RTA, and calls MotionController::NetworkStart(). The real-time component then discovers and starts the EtherCAT network. Drives respond as nodes, and RapidCode uses the discovered topology plus its XML configuration to construct Axis and I/O objects.

The first checkpoint is temporal: record when the API throws, then continue observing the master state without immediately issuing another start. If the state later becomes OPERATIONAL, the request passed into the real-time subsystem and the timeout occurred at the caller’s completion boundary.

Is layer one actually failing?

Layer one first. A network that operates reliably when started entirely from RapidSetup makes a persistent cable or drive fault less likely, but it does not clear the physical path under machine load. Observe link state, drive indicators, node presence, and the network log while reproducing the application start. Do not treat the text EtherCAT communication broken during system operation as proof that the start failed before correlating its timestamp with the exact attempt.

On this system, the Windows and INtime event logs contained no unusual event. INtime takes a processor core for its work; high Windows-side load primarily affects cache and resource access and can appear as jitter. The Graphical Jitter Tool provides the deciding measurement under normal and peak machine load. Poor jitter would normally present as network errors rather than only a host timeout, while network-start duration also varies with PC processing power and node count.

The physical-layer checkpoint passes when the same nodes remain present, no repeatable link loss occurs, and jitter stays acceptable during the attempted start. Only then move to file and API behavior.

Can the application resolve the RapidCode files?

The no-argument NetworkStart() call assumes the important RapidCode files, including EtherCATNodeInfo.xml, are available through the working-directory arrangement used by the application. RapidSetup commonly operates with those files together in a directory such as C:\RSI\X.X.XX\. A correct environment variable does not prove that the application has the same working directory or resolves the same file set.

EtherCATNodeInfo.xml supplies Axis-count and I/O-count information. Without it, a discovered drive can appear by node name with no Axis or I/O subitems. That presentation must not be confused with a failed EtherCAT discovery: the node exists, but RapidCode lacks the description needed to construct its children.

1. Capture the application’s actual working directory at runtime.
2. Confirm that EtherCATNodeInfo.xml and the other RapidCode files used by the working RapidSetup installation are present at the location expected by the no-argument call.
3. If the files live elsewhere, use the NetworkStart overload that identifies the location of the required RapidCode files.
4. Search the normal Windows loading locations for duplicate RapidCode installations or stray RSIQVC.dll copies. Compare the failing machine with a working machine rather than relying only on environment variables.
5. If the layout is correct but file integrity remains suspect, refresh the RSI directory from the controlled installation set.

The file-resolution checkpoint passes when the application and RapidSetup resolve one controlled RapidCode installation and a newly created client displays the expected Axis and I/O children.

Does NetworkStart time out before the master finishes?

NetworkStart() performs discovery before completing the network start. Its duration changes with processing power, current system load, and EtherCAT node count. In version 8.0.7, the application uses the timeout behavior built into that release. Configurable NetworkStart(...) timeouts were added in 8.1.4 for slower PCs and systems with higher node counts.

The reported sequence fits late completion: the C++ call raises 1000000022, the application sees a timeout, and another client subsequently sees OPERATIONAL. The correct response is not an immediate second start based solely on the exception. Poll the network state for a bounded application-defined observation period, record every transition, and distinguish “API wait expired” from “master entered an error state.” Select that observation period from measured start times on the production machine; no fixed duration is supplied for this installation.

An upgrade is a controlled engineering option, not the first commissioning change. Moving from 8.0.7 to a release with configurable timeouts requires rebuilding the application against the new software and testing the production behavior. The rsiconfig utility offers a separate way to validate configuration and start the network without compiling application code; as of 8.1.6, it can also generate an ENI file when one is missing.

The timing checkpoint passes when repeated measurements show whether the master reaches OPERATIONAL after the exception and quantify the interval from request to final state.

Why can the network be operational while axes are missing?

Network state and host-object population are different views. The master can be operational while RapidSetup or the C++ application still displays the object collection captured before discovery finished. RapidSetup does not automatically refresh its list when another process performs Discover/Start.

RapidSetup handles its own start workflow by refreshing itself: it deletes and recreates its MotionController object after starting the network. That recreation is required for the client to detect and configure newly discovered Axis objects. The same behavior explains why closing the application—which calls MotionController::Delete()—and restarting it makes the already operational network appear with all axes.

1. After the C++ timeout, wait for the network state to settle.
2. If RapidSetup is open, select View->Refresh before judging the discovered object list.
3. In the application, stop using references obtained from the old MotionController object.
4. Call MotionController::Delete(), recreate the controller with MotionController::CreateFromSoftware(char*), and reacquire node, Axis, and I/O objects.
5. Read the network state again from the recreated object. If it is already operational, do not start the network again merely because the earlier object timed out.

The object-model checkpoint passes when refresh or delete/recreate exposes the expected axes without another physical network start.

What do the timeout log messages prove?

Clear the network log immediately before each attempt, preserve the timestamps, and read the sequence as a state machine. The captured run began with Network State: (262): SHUTDOWN and Starting EtherCAT network. It later reported that the main network loop finished, listed nodes #(0) through #(3) with AL Status (0x0), Code (0x0), exited the service-channel thread, and stopped the EtherCAT driver.

The log checkpoint passes when one cleared capture ties the API call, state polling, refresh or recreation, and driver messages to the same clock and attempt.

How do you verify the complete commissioning path?

1. Start from SHUTDOWN and record CPU load, jitter, working directory, resolved RapidCode file set, and visible EtherCAT nodes.
2. Clear the network log, timestamp the call, and invoke NetworkStart() once.
3. If 1000000022 occurs, record it and continue polling state without issuing an immediate second start.
4. If the state becomes OPERATIONAL, refresh RapidSetup or delete and recreate the application’s MotionController object.
5. Verify that nodes #(0) through #(3) appear as expected for this installation and that every configured drive node now exposes its Axis and I/O children.
6. Repeat under normal and peak machine load. Compare start duration, jitter, final state, object counts, and log transitions across runs.
7. Test shutdown through MotionController::Delete(), recreate the object, and confirm that the application reads the current network and object state without depending on stale references.

The end-to-end test passes only when one start request reaches OPERATIONAL, the recreated client contains all expected objects, no repeatable physical-layer loss appears, and the same sequence succeeds under peak production load.

FAQ