Quote:
Originally Posted by boomergeek
What does "squelch" mean in this context? Does it slow the NetConsole flow down or does it just not produce messages for NetConsole?
(We did have NetConsole.out populated on our CRio for monitoring in our pits.- we did not remove it during competition runs)
If attached FMS is intentionally delaying NetConsole messages (as opposed to eliminating all of them), then does that means the errors are getting delayed if NetConsole is active and the entire processing is getting delayed?
If that were the case, that certainly could explain a mechanism that could cause different behavior within FMS versus a practice field.
|
When the FMS is attached and the robot is enabled, the NetConsole server will read any data from the pseudo terminal and then do nothing with the data, immediately going back to read from the PTY. The result is that anything traced to the console while the FMS is attached and the robot is enabled with be lost forever. It is not delayed or saved or anything like that. I don't think the NetConsole behavior will do anything other than reduce the CPU load and network load.
Quote:
Originally Posted by boomergeek
Is there any user documentation on "* Squelch the NetConsole output when the FMS is attached and the robot is enabled"?
|
No. Fundamentally it is an attempt to not waste radio bandwidth while competing. In a field configured to spec, the NetConsole ports will be blocked at the router anyway (though I've seen them open).
Quote:
Originally Posted by boomergeek
Is the NetConsole output NOT squelched while robot is disabled but still attached to the FMS?
|
Correct. When the robot is disabled, the NetConsole output is enabled. The idea here was if you get lucky and the port is not blocked (or you are debugging the FMS), it would be nice to be able to see the cRIO console on the field while preparing for the match.
Quote:
Originally Posted by boomergeek
|
Always working late!
...but that commit log entry is dated for when the change was replicated from the internal SVN server to the public one, not when the actual change was submitted. If there were actually files for this on the public server (as there are in the WPILib for C++ source), I believe that log would show you the correct date of check-in and the person who checked it in. The distinction here is that the record you are looking at is part of the source forge data, not the SVN data.
-Joe