Quote:
The UDP listener should have errors trapped and a timeout set to a fairly low number (I use 1000ms) - I use trapped errors as a source of determining if I actually should unbundle the packet and use it
-The UDP listener should exist in its own thread (While loop) throttled by nothing other than itself - There should be no waits. The UDP listener will block for new packets, and if you are behind in receiving packets then it's a bad thing.
|
Thank you, I fixed this, and created a much more simplified communication system. It actually works flawlessly now (even through repeated power ups/downs between robot and driverstation) I have some screenshots of it included.
Quote:
|
When you say crash - exactly what happens? If you can reproduce a crash with a simplified program, please contact National Instruments via our FRC forum. We can have application engineers look into it.
|
The crash that occurs was happening whenever I was trying to debug the robot through running the robot program
while still in labview with probes set up. It seems that when the driverstation tries to connect with the robot, it boots off labview's connection with the cRIO. A "Connection with the cRIO was lost" would appear, and there would be no way to put more code on without closing the driverstation. This was causing me to think it was crashing, and causing a lot of hair pulling in the debugging process, but was eventually figured out.