Quote:
Originally Posted by Alan Anderson
Chris, what caused the packets to be missed/delayed in the first place? I've been using UDP to send the vision processing results to the robot without noticeable issues. Can you show the code you used to test it?
|
As soon as I saw that behavior, I deleted the code and replaced it with the TCP version. I was reading that TCP has error checking for delayed and missed packets while UDP didn't, so I thought I would give TCP a try immediately.
The code was basically the example UDP client / UDP server code from the example folder, just reworked to pass the counter. On the cRIO side, the receiving was being done in the fast loop of Periodic Tasks (which we have set to 20 ms). The laptop was running a bare-bones dashboard project, and the transmit was being done in a 20 ms loop.
I'm pretty sure the problem on the receive side was we were over loading the CPU occasionally (sometimes more than occasionally). We have a lot of test code in there and running in debug mode slows things down even further. However, the behavior seen is still troublesome because I can almost guarantee there will be occasions that we'll overrun the CPU this season.
The troublesome part was that the transmission is a straight-forward FIFO queue. In the example of my previous post, if we had stopped the laptop when the counter was at 250 and the cRIO was showing the counter at 210, the cRIO would show the counter counting up 211, 212, etc as if the laptop was still alive and sending, even though it was stopped. The cRIO would continue to count up until it reached 250 (the value that the laptop was at when we stopped it), and THEN it would notice that it was stopped. The cRIO side didn't notice an issue until about 2 seconds AFTER stopping the laptop from transmitting.