You do not have to wait for one command to finish before sending the next. However, there is also no handshaking between the controller and computer if the buffers do get full. Some verbose commands such as send all the switch data or send the network ID data will flood the buffers if pinged back to back and will eventually cause an overflow (All buffered commands would then get dumped). The HW has no set delay between receiving a command and sending the data. If fact each character of the command is parsed when received, the controller does not wait for a full command before starting to parse it (this is why the responses are so FAST) . All data is collected continuously in advance (like switch data), ready to send at any time (we never wait for data to be gathered based on a command). Even data like the ID of the nodes on the network is done the same way(all in advance). Obviously waiting for the response before sending a new command is the best way to handle information exchange, but as long are you are not requesting data back to back or pinging continuously with no delays between commands you should be fine. A good rule of thumb is to send no more characters then you receive back at any given time. If you continuously send 5 characters (as a command) and get 20 back as a response, the rules of communication physics will eventually rear its ugly head. From a support standpoint, I would say wait for a response. If you ever do see a delay in one of the commands, something is not working correctly. The only exceptions to this rule are some of the LED commands like RA:(led color value). This command sets all of the LED’s to a given color. This command is writing to 256 32 bit locations. It is very fast to do, but it is doing this in real time taking some CPU cycles. Normally LED data is sent as a long string of bytes (binary data). This method does not take time between bytes, it is being parsed in real time. I hope that helps some.