Rectangle (Target Info) Overlaying on the Dashboard?

[SuperS_5]

I had to checkout the whole dashboard project, I ended up with a few cross-linked files when trying to open it in a standard project. After opening your whole Dashboard project I have noticed a few things.

1. LabVIEW version: It appears that you may be using an older version of the FRC project/LabVIEW. I believe some of the FRC data structures have changed, and I don't think this will work with the latest driver station.
   -I was also missing a few library VIs when I attempted to open your project. I do not have FRC 2010 installed on my VM.
   
2. CommunicationMonitor.vi: This VI has some program flow issues. The local variables will never update the output the way I think you are thinking of.
   
3. General Programming techniques: The above VI is not the only part that has this issue. It seems that you are coding like a C programmer. (Expected, and I have seen this many times.) Unfortunately, this does not work well with LabVIEW's data-flow oriented model. You have made fair use of local variables, something that I would suggest for you to avoid. The local/global variable name seems to mislead programmers when they first switch to LabVIEW. These are not for linear programming, but more for initialization, and thread messaging. (There are better ways to message between threads.)
   
4. Receive DS Packet.vi: It appears that you have modified this VI. Even-though it is not in a library folder, I would still treat it like a library function. Modifying it, especially the connector pane, makes it more difficult for others to view, analyses, and edit surrounding code. All of the required data is passed out, and is available outside this VI.
   
5. DSPacketHighPriority.ctl: Unless you have already changed your packet structure, this appears not to match the C++ code you provided.
   -The unflatten string function is wired in a way where any errors will not be recorded if the low-priority packets are successfully decoded.
   -The use of a local variable here is OK. I would use a different technique, but the world won't end for using a local variable this way.
   
6. Railed CPU threads: A few of the loops do not have any wait calls in them. The main receive loop is probably OK because of the network call will wait. The fault handling loop however will use 100% of a core. This consumption of resources will make the other loops sluggish as well.
   
7. Wire neatness: This is more cosmetic, but highly important. There is a coding conventions page in the LabVIEW help. (F1 when using LabVIEW.) It specifies many conventions that LV programmers should follow. One is that wires should flow from left to right, and not loop back on them selves. Don't let them hide behind other objects, and use as few bends as possible. This makes it much more readable. (By light years. This is even required in professional environments.)