We’re using the RapidCodeRemote gRPC api and implementing DS402 drive-based homing following your documented approach with NetworkOutputOverride:
In the C# example, the control word PDO output index is retrieved via:
int axisCtrlWordIdx =(int)axis.NetworkIndexGet(RSINetworkIndexType.NetworkIndexTypeCONTROL_WORD_INDEX);
The RSINetworkIndexType enum is already defined in rsienums.proto (values 0-15 including NetworkIndexTypeCONTROL_WORD_INDEX = 9 and NetworkIndexTypeSTATUS_WORD_INDEX = 1), but there is no gRPC action or info field that exposes the actual resolved index values.
The AxisInfo message has network_index_invalid in its Constants (the sentinel value for invalid indexes), which suggests this was planned but not yet implemented.
Could you add the resolved network indexes to AxisInfo? For example:
message AxisInfo {
// ... existing fields (index, addresses, node_info, constants,
// motion_supervisor_index, drive_index) ...
// Resolved PDO network indexes for this axis.
// Maps RSINetworkIndexType enum values to global network output/input indexes.
// Equivalent to Axis.NetworkIndexGet() in the C#/C++ API.
map<int32, int32> network_indexes = 7;
}
Or alternatively, add a network_index_get action to AxisAction:
message AxisAction {
// ... existing actions ...
optional NetworkIndexGet network_index_get = 21;
message NetworkIndexGet {
RSINetworkIndexType type = 1;
int32 index = 2; // populated in response
}
}
Use case: DS402 drive-based homing requires NetworkOutputOverride on the control word PDO output. Without NetworkIndexGet() in the gRPC API, the only workaround is querying
NetworkInfo.pdo_outputs and matching by PDO name string, which is fragile across different ENI configurations and drive types.
We need the control word index (NetworkIndexTypeCONTROL_WORD_INDEX) and status word index (NetworkIndexTypeSTATUS_WORD_INDEX) at minimum, but exposing all RSINetworkIndexType values would be most useful.
Thanks!