Quote:
Originally Posted by Ether
Did you mean busy-wait ?
|
Block wait.
The Netcomm library (black box compiled code) includes a Read and Read Async function.
Read is fed a message ID and timeout, and returns either 8 data bytes or failure after no more than timeout. So, the function is blocking.
Read Async is fed a message ID and Occurrence. The VI then does a Wait On Occurrence with timeout specified, if the Occurrence is triggered then it calls another function to retrieve the data. This function is not blocking at a Netcomm level, but is blocking at a system library level (Lower than the exposed CAN message interface is the Netcomm interface which is used by the CAN message interface).
Since WPIlib generally pushes teams to put all of their code in Teleop or Timed Tasks, putting a blocking read command in Teleop and having it fail is very bad for deterministic Teleop timing (which is already really jittery because it's timed by Ethernet packets). It gets even worse with multiple jags, or multiple commands per jag (e.g. Set Speed and Get Current would both block-wait, if that jag goes offline then there's 20ms of timeouts just for that one jag to be waited through by the user code).
Basically, all of the CAN send-response interactions are all synchronous, which is a huge time penalty over an asynchronous architecture if it ever has to wait for a response and dosen't get it.