Show GSB Command

This command displays communication status information for all connected Guidance Slave Board (GSB), Guidance IO (GIO), Safety Check (SFT) boards, and servo network slave controllers.

Show GSB [ node ]

Prerequisites

None

Parameters

node

An optional numeric expression that specifies an Integer servo network node number. If omitted or zero, status information is shown for all nodes. If specified and > 0, only the statistics for that single node are shown.

Remarks

The command "Show GSB" displays the statistics for node 1 (the master) followed by the statistics for each slave node, in order of their node number. For slave nodes, the software version and model number of the board is also shown. Only non-zero statistics are displayed.

Since each node is polled in turn, each set of statistics reflects a slightly later point in time than the previous node's set.

The tables below describe the meanings of the various statistical counters.

This first table is only statistics. These counts indicate the number of standard communication messages sent and received by each node.

Label

Description

sync packets sent

Number of synchronous messages sent by this node.

Normally counts up at the trajectory rate. Node 1 is tied to the trajectory generator and counts up no matter what. Slave nodes count up each time they send a response to a received sync packet, unless some error is occurring and being counted below. For slaves, the sync packets sent should be within 1 or 2 of the sync packets received.

sync packets received

Number of synchronous messages received by a node.

For node 1, this is the total of all sync messages sent by all slaves. So it is normally about n * sync packets sent, where n is the number of slaves. For slave nodes, this should be about equal to the sync packets sent by the master.

async packets sent

Number of asynchronous messages sent by a node.

These messages are sent as part of a command-response sequence, normally to read or write a remote DataID value. These counts are small unless you are doing some dynamically polling of a DataID from a GPL program.

async packets received

Number of asynchronous messages received by a node.

These messages are sent as part of a command-response sequence, normally to read or write a remote DataID value. These counts are small unless you are doing some dynamically polling of a DataID from a GPL program.

The following statistics indicate that a communication error has occurred.

Label

Description

async retransmits

An async packet was retransmitted.

If a packet containing an async message was lost or corrupted, the protocol notices and retransmits the packet. This messages is almost never seen unless there are a large number of other errors.

unexpected bytes received

A number of unexpected byte was received

These bytes were not part of any valid received packet. If no other errors are occurring, the bytes were received in the idle time between valid data packets. This may be due to a reflection after a message is complete, or noise that occurs just as the driver is switching off and the bus is returning to its idle state. If the protocol gets out of sync due to errors, this counter may count up substantially as bytes are flushed while looking for the next packet.

If this count is non-zero, you should verify that the RS-485 bus termination is properly set on the master controller and all slave controllers. Please see the appropriate controller or robot hardware manuals for a description of how these jumpers should be set.

invalid packets received OR received packet too long

An invalid packet header was received or an invalid length was found in a receive packet header.

The received packet started out valid, but some fields had impossible values. Random noise may have looked like the start of a packet, but turned out not to be. Noise may have corrupted the data bytes. A software timing problem may have caused two nodes to transmit at the same time. Probably you will get a large number of unexpected bytes received errors while the protocol attempts to re-synchronize.

received bad checksum

A received message had a bad checksum.

A properly formatted message was received, but the checksum was incorrect. Noise may have corrupted some data bytes. In this case, there would not necessarily be any other errors except for a timeout error. A software timing problem may have caused another node to begin transmitting near the end of this message, corrupting the checksum. In this case the second message would be badly corrupted, resulting in a large number of unexpected bytes received by some other node.

received packet dropped

A received packet was ignored.

A new packet was received but there were no buffers available for storing it. Normally this is due to a software memory leak and indicates a system software bug. It might also indicate a large amount of noise that looked like the start of messages, but that is unlikely.

sync receive timeouts

A synchronous packet was not received when expected.

On the master node, a sync setpoint from one of the slaves was not received when expected. On a slave node, the synchronous packet broadcast by the master node was not received when expected. If the received sync packet was corrupted, you will get this error in addition to one of the errors above. If all slaves get the error, the packet was likely corrupted by noise, or a bug on the master prevented sending the packet. If only one slave reports the error, it could be a timing bug on that slave. For debugging, this error can be suppressed by DataID 2106

send packet dropped

A packet was not sent.

Indicates a software bug on the node that reported the error. On node 1, a synchronous packet with an invalid format was ignored by the sender. On slave nodes, there was no room in the sender FIFO for an asynchronous message packet.

sync send overflow

The previous sync message was not transmitted when expected.

This error only occurs on slave nodes. The slave has a synchronous packet ready to send to the master, but it cannot post it because the previous sync packet has not completed transmission. The new packet is dropped which will lead to a sync send underflow the next cycle. For a given node, sync packets are only sent after a message is received from the previous node. Node 2 only sends after a sync setpoint from node 1. Node 3 only sends after seeing a sync status from node 2, etc. So if any node fails to receive a packet from the previous node, all downstream nodes will generate this error.

sync send underflow

No synchronous status message is ready to send when expected.

This error only occurs on slave nodes. A synchronous packet was received from the previous node which should trigger the current node to send its sync status message. But no sync status message is ready to send. This happens after a sync send overflow. All downstream slave nodes will get a sync send overflow error. Otherwise indicates a software timing problem on the local node, possibly due to CPU overloading.

Label	Description
sync packets sent	Number of synchronous messages sent by this node. Normally counts up at the trajectory rate. Node 1 is tied to the trajectory generator and counts up no matter what. Slave nodes count up each time they send a response to a received sync packet, unless some error is occurring and being counted below. For slaves, the sync packets sent should be within 1 or 2 of the sync packets received.
sync packets received	Number of synchronous messages received by a node. For node 1, this is the total of all sync messages sent by all slaves. So it is normally about n * sync packets sent, where n is the number of slaves. For slave nodes, this should be about equal to the sync packets sent by the master.
async packets sent	Number of asynchronous messages sent by a node. These messages are sent as part of a command-response sequence, normally to read or write a remote DataID value. These counts are small unless you are doing some dynamically polling of a DataID from a GPL program.
async packets received	Number of asynchronous messages received by a node. These messages are sent as part of a command-response sequence, normally to read or write a remote DataID value. These counts are small unless you are doing some dynamically polling of a DataID from a GPL program.

Label	Description
async retransmits	An async packet was retransmitted. If a packet containing an async message was lost or corrupted, the protocol notices and retransmits the packet. This messages is almost never seen unless there are a large number of other errors.
unexpected bytes received	A number of unexpected byte was received These bytes were not part of any valid received packet. If no other errors are occurring, the bytes were received in the idle time between valid data packets. This may be due to a reflection after a message is complete, or noise that occurs just as the driver is switching off and the bus is returning to its idle state. If the protocol gets out of sync due to errors, this counter may count up substantially as bytes are flushed while looking for the next packet. If this count is non-zero, you should verify that the RS-485 bus termination is properly set on the master controller and all slave controllers. Please see the appropriate controller or robot hardware manuals for a description of how these jumpers should be set.
invalid packets received OR received packet too long	An invalid packet header was received or an invalid length was found in a receive packet header. The received packet started out valid, but some fields had impossible values. Random noise may have looked like the start of a packet, but turned out not to be. Noise may have corrupted the data bytes. A software timing problem may have caused two nodes to transmit at the same time. Probably you will get a large number of unexpected bytes received errors while the protocol attempts to re-synchronize.
received bad checksum	A received message had a bad checksum. A properly formatted message was received, but the checksum was incorrect. Noise may have corrupted some data bytes. In this case, there would not necessarily be any other errors except for a timeout error. A software timing problem may have caused another node to begin transmitting near the end of this message, corrupting the checksum. In this case the second message would be badly corrupted, resulting in a large number of unexpected bytes received by some other node.
received packet dropped	A received packet was ignored. A new packet was received but there were no buffers available for storing it. Normally this is due to a software memory leak and indicates a system software bug. It might also indicate a large amount of noise that looked like the start of messages, but that is unlikely.
sync receive timeouts	A synchronous packet was not received when expected. On the master node, a sync setpoint from one of the slaves was not received when expected. On a slave node, the synchronous packet broadcast by the master node was not received when expected. If the received sync packet was corrupted, you will get this error in addition to one of the errors above. If all slaves get the error, the packet was likely corrupted by noise, or a bug on the master prevented sending the packet. If only one slave reports the error, it could be a timing bug on that slave. For debugging, this error can be suppressed by DataID 2106
send packet dropped	A packet was not sent. Indicates a software bug on the node that reported the error. On node 1, a synchronous packet with an invalid format was ignored by the sender. On slave nodes, there was no room in the sender FIFO for an asynchronous message packet.
sync send overflow	The previous sync message was not transmitted when expected. This error only occurs on slave nodes. The slave has a synchronous packet ready to send to the master, but it cannot post it because the previous sync packet has not completed transmission. The new packet is dropped which will lead to a sync send underflow the next cycle. For a given node, sync packets are only sent after a message is received from the previous node. Node 2 only sends after a sync setpoint from node 1. Node 3 only sends after seeing a sync status from node 2, etc. So if any node fails to receive a packet from the previous node, all downstream nodes will generate this error.
sync send underflow	No synchronous status message is ready to send when expected. This error only occurs on slave nodes. A synchronous packet was received from the previous node which should trigger the current node to send its sync status message. But no sync status message is ready to send. This happens after a sync send overflow. All downstream slave nodes will get a sync send overflow error. Otherwise indicates a software timing problem on the local node, possibly due to CPU overloading.

Examples

GPL: show gsb
 
************ Node 1 (master) ************
      5106: sync packets sent
      5105: sync packets received
       120: async packets sent
       362: async packets received
************ Node 2 (GSB_1) ************
  Software: GSB-1100T.3, Version 1.3E6, May  6 2016, Release (130911)
     Model: G1100T.3
      5118: sync packets sent
      5117: sync packets received
       724: async packets sent
       121: async packets received