View Single Post
  #7   Spotlight this post!  
Unread 08-03-2011, 16:40
boomergeek's Avatar
boomergeek boomergeek is offline
Registered User
AKA: Mr. D (Dick DiPasquale)
FRC #0241 (Pinkerton Robotics)
Team Role: Mentor
 
Join Date: Feb 2009
Rookie Year: 2009
Location: Derry, NH
Posts: 191
boomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant futureboomergeek has a brilliant future
Re: Robot Code Error issues

Quote:
Originally Posted by jhersh View Post
This is not quite how it works. The Network Communication task does not search for a DS. It simply blocks waiting for a packet. A variable in the Network Communication object keeps track of status of the communication and if the robot has been enabled. The SendMessage entry-point simply reads that variable to decide if a message should be sent. It should not affect timing.
If the CAN Message is flowing through the Network Communication task and the NC task is blocked waiting for a DS message, does that imply the CAN messages won't be processed through the NC task until the next DS message comes in?
If so, that could be a serious bottleneck when the DS message flow is intermittent due to software errors or radio problems. Is it possible that could be multiplying the impacts far worse than a PWM set up would.


Quote:
Originally Posted by jhersh View Post
I'm not aware of anything in the parts that I have access to that even distinguishes that the FMS is involved, except for NetConsole deciding to squelch output if the FMS is attached and the robot is enabled (to reduce extraneous traffic on the field radio).

-Joe
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.

Is there any user documentation on "* Squelch the NetConsole output when the FMS is attached and the robot is enabled"?
Is the NetConsole output NOT squelched while robot is disabled but still attached to the FMS?

Internet search points to
http://firstforge.wpi.edu/sf/scm/do/...E58FC99BE6 C5
which indicates that the source for that change was committed on Feb 7th 2011 at 1:02am. (working late?)

Last edited by boomergeek : 08-03-2011 at 17:06. Reason: added comments on the NetCom task