Quote:
Originally Posted by Radical Pi
I think I may have a reason for the slowdown and the jitter. In the C++ code, all requests to the CAN driver are routed through either FRC_NetworkCommunication_JaguarCANDriver_sendMessa ge, or FRC_NetworkCommunication_JaguarCANDriver_receiveMe ssage. Also, when the driver is loaded by the OS, the init calls FRC_NetworkCommunication_JaguarCANDriver_registerI nterface with a pointer to the driver class. By the names, I'd assume that all messages are run through the NetworkCommunication library before they get to the driver itself, most likely so a disabled robot cannot continue to send CAN messages. NetworkCommunication is searching for a driver station and communicating with the driver station, so it could account for the delay and the jitter.
As a test, could you put a timer around setTransaction, or even better around the receiveMessage inside setTransaction? receiveMessage directly calls the NetworkCommunication library, so it would be the best place to time the command.
|
Well, what if we changed that? We could open up CAN Send and CAN Receive and make them call the Jaguar plugin directly.
First, however, I'll try what you suggested. But I think I'll actually want it around the "send" and "receive" VIs, because the "set transaction" and "get transaction" use both. However, it might be a good idea to do all of the above: measure how long the transaction is taking as a total, measure the time Send and Receive take to execute, and measure the time in-between them as well.