|
APIs, concepts, guides, and more
|
|
|
APIs, concepts, guides, and more
|
Status structure for individual EtherCAT node diagnostics. More...
Attributes | |
| uint64_t | AkdAsciiCount |
| Cumulative count of Kollmorgen AKD ASCII commands the network firmware serviced for this node since network start (see AKDASCIICommand). Only the nodes where IsAKDASCIICommandSupported() is true accept AKDASCIICommand, so on every other node this and AkdAsciiFailCount stay 0. These always use the mailbox, on the same service channel thread as SDO and register access. Counted when the firmware picks the command up, so it can differ from the number of AKDASCIICommand calls your application made, and unlike the SDO counters it can be LOWER: a call that gives up with RSIMessageTIMEOUT withdraws its command, so one the firmware had not reached yet is never serviced or counted. When the service channel is starved this is exactly the node that under-counts, so read a low count next to timeouts in your application as a symptom. A command overwritten by a later call on the same node before the firmware got to it is likewise never counted. Not cleared by StatusClear. Compare with AkdAsciiFailCount for a failure rate, and against the other nodes to find which one dominates the service channel load. | |
| uint64_t | AkdAsciiFailCount |
| Cumulative count of AKD ASCII commands for this node that failed since network start. A command fails when the firmware could not send it or when no usable response came back. A response carrying a drive error string is still a response, so it counts as a success here. Counted by the network firmware, so it can differ from what your application observed. Not cleared by StatusClear. Compare with AkdAsciiCount for a failure rate. | |
| uint32_t | AlStatus |
| EtherCAT AL Status register (0x0130) value. This is a snapshot value primarily useful for detecting unexpected state transitions. May not reflect current state after network shutdown. Bits 0-3 indicate Device State Machine state: 1=Init, 2=PreOp, 3=Bootstrap, 4=SafeOp, 8=Operational. Bit 4 is the Error Flag. | |
| uint32_t | AlStatusCode |
| EtherCAT AL Status Code register value. This is a snapshot value captured when the node reports an error or unexpected state change. Non-zero indicates an error condition. See ESI file or vendor documentation for device-specific codes. | |
| uint64_t | CoeEmergencyMessage |
| CANopen over EtherCAT (CoE) emergency message. 8-byte value containing error code and additional data per CiA 301 specification. Updated when the node sends an emergency message. | |
| int32_t | CoeEmergencyMessageNetworkCounter |
| Network counter value when the current CoeEmergencyMessage was received. Use to determine if the emergency message is new since last check. | |
| uint64_t | EoeHostToNodeFrameCount |
| Cumulative count of EoE (Ethernet over EtherCAT) frames sent from the host to this node since network start. Use to confirm EoE traffic is reaching this drive. (Broadcast EoE frames are counted network-wide only; see MotionController::NetworkStatus.) See EoE - Ethernet over EtherCAT. | |
| uint64_t | EoeNodeToHostFrameCount |
| Cumulative count of EoE (Ethernet over EtherCAT) frames received from this node by the host since network start. Use to confirm EoE responses are returning from this drive. See EoE - Ethernet over EtherCAT. | |
| RSINetworkNodeInitializationState | InitializationState |
| How far this node has progressed through network startup. UNINITIALIZED means the node record is empty (zeroed): either the network has not been started, or the topology was cleared. DISCOVERED means the node was found on the wire, so its identity fields (Vendor ID, Product Code, Revision, Serial Number, Station Alias) are valid. CONFIGURED means the RMPNetwork configuration parser has run over the ENI file and NodeInfo.xml for this node, so its I/O counts and index tables are valid. Written only by the network firmware, so StatusClear does not clear it. UserLabelSet requires at least DISCOVERED; the per I/O point label methods require CONFIGURED. See RSINetworkNodeInitializationState. | |
| bool | Present |
| true if the node responded to the master's most recent AL-status read; false if it did not respond (physically disconnected or unpowered). When false, AlStatus/AlStatusCode are stale and should not be trusted. | |
| uint64_t | SdoReadCount |
| Cumulative count of every ServiceChannelRead the network firmware serviced for this node since network start: CoE SDO (service data object) uploads and also EtherCAT register reads (an index below 0x1000), which skip the mailbox but occupy the same service channel thread. Counted when the firmware picks the request up, so it can differ from the number of ServiceChannelRead calls your application made: a call that already gave up with RSIMessageTIMEOUT leaves its request in place, so the firmware still services and counts it when it gets there (as a success if the node answers), and the count can exceed what your application saw succeed. Only a request overwritten by a later call on the same node before the firmware got to it is lost and never counted. Not cleared by StatusClear. Compare with SdoReadFailCount for a failure rate, and against the other nodes to find which one dominates the service channel load. | |
| uint64_t | SdoReadFailCount |
| Cumulative count of service channel reads for this node (SDO uploads and register reads) that finished unsuccessfully since network start. A read fails when the request could not be issued, when the node returns an SDO abort or another error status (reported to your call as an error), or when the firmware's own completion wait runs out without a response. That wait is longer than your call's timeout (the master's mailbox wait plus a retry loop of about a second), so a failure can be counted a second or more after your call already returned RSIMessageTIMEOUT. Counted by the network firmware, so it can differ from what your application observed. Not cleared by StatusClear. Compare with SdoReadCount for a failure rate. | |
| uint64_t | SdoWriteCount |
| Cumulative count of every ServiceChannelWrite the network firmware serviced for this node since network start: CoE SDO (service data object) downloads and also EtherCAT register writes (an index below 0x1000), which skip the mailbox but occupy the same service channel thread. Counted when the firmware picks the request up, so it can differ from the number of ServiceChannelWrite calls your application made: a call that already gave up with RSIMessageTIMEOUT leaves its request in place, so the firmware still services and counts it when it gets there (as a success if the node answers), and the count can exceed what your application saw succeed. Only a request overwritten by a later call on the same node before the firmware got to it is lost and never counted. Not cleared by StatusClear. Compare with SdoWriteFailCount for a failure rate, and against the other nodes to find which one dominates the service channel load. | |
| uint64_t | SdoWriteFailCount |
| Cumulative count of service channel writes for this node that finished unsuccessfully since network start. A write fails when the request could not be issued, when the node returns an SDO abort or another error status (reported to your call as an error), or when the firmware's own completion wait runs out without a response. That wait is longer than your call's timeout (the master's mailbox wait plus a retry loop of about a second), so a failure can be counted a second or more after your call already returned RSIMessageTIMEOUT. Register writes (an index below 0x1000) are fire and forget and never count as failures, though they do count in SdoWriteCount. Counted by the network firmware, so it can differ from what your application observed. Not cleared by StatusClear. Compare with SdoWriteCount for a failure rate. | |
| uint32_t | SyncGroupId |
| Sync group this node belongs to, populated by the master from the ENI at startup. 0 = default group. This is the node's ACTUAL membership (the staged Config.SyncGroup is consumed at ENI generation). See MotionController::NetworkSyncGroupStatus and Sync Groups. | |
Status structure for individual EtherCAT node diagnostics. Use this structure to monitor the state of an individual EtherCAT node (drive, I/O block, etc.). Contains AL status, status code, and CoE emergency message information. Every field is also recordable: get its host address with AddressGet (::RSINetworkNodeAddressType), except SyncGroupId which uses MotionController::AddressGet with RSIControllerAddressTypeNETWORK_NODE_SYNC_GROUP_ID and the node index as the object index.
1.15.0