View Single Post
  #2   Spotlight this post!  
Unread 07-02-2006, 00:09
Danny Diaz's Avatar
Danny Diaz Danny Diaz is offline
Smooth Operator
AKA: FrankenMentor
None #0418
Team Role: Alumni
 
Join Date: Apr 2005
Rookie Year: 2003
Location: Manchester, NH
Posts: 545
Danny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond reputeDanny Diaz has a reputation beyond repute
Send a message via AIM to Danny Diaz
Re: LabView Dashboard

Quote:
Originally Posted by chakorules
Go easy on the little freshman fellow...
I understand he is probably frustrated, let's see if we can shed some light on why you're not getting the correct packets.
Quote:
Originally Posted by chakorules
Being that we tried the default code, which we thought was sending user byte data, I am kind-of lost too.
Just getting basic functionality working shouldn't be too difficult, so that concerns me that you're having so many problems. What any of the Dashboard programs do is parse a specific datastream provided by the OI - the OI has special hardware that snoops the data communications between the OI and the RC and provides a copy of the data stream to the Dashboard, and should provide the same information regardless of the language used to program the RC. The 2 components of the LabVIEW Dashboard work together to parse this datastream and display the data.

Without entirely repeating what is in the documentation, the Dashboard is comprised of 2 programs that must be open and running at all times. The first is the "Dashboard Read.VI", and it is this program that allows you to read packets from the Dashboard port on the Operator Interface (OI). To start and configure the "Dashboard Read.VI" program, do the following,
  1. Open the "Dashboard Read.VI" application.
  2. Press CTRL-R (or the LabVIEW "run" button)
  3. Make sure the "Read from Serial" radio box is selected in "Program Control"
  4. Make sure the correct COM port is selected under "Read from Serial Input"
  5. Press the blue "START PROGRAM" button (once you do this, the blue button should become disabled and the red "STOP PROGRAM" button should become selectable)
Once you've gotten this far, if you're processing packets you should see the "Number of Packets Published" indicator begin incrementing. You will also probably see the "Number of Buffers in Waiting List" indicator also incrementing since the "Dashboard Display.VI" isn't running. DO NOT close this running VI. If you do not see these two indicators incrementing (realize the "Number of Buffers in Waiting List" will eventually max out) then you either haven't selected the correct COM port or your serial cable isn't plugged into the OI "Dashboard" port (or your OI/RC aren't powered).

Now open the "Dashboard Display.VI" application (while leaving the "Dashboard Read.VI" open and running). All you should have to do here is press CTRL-R or the LabVIEW "run" button. Across the top of the VI are some very useful indicators:
  • Packet Processing Delay - This slider controls how fast LabVIEW attempts to poll the queue being filled by the "Dashboard Read.VI" application. Setting this to Zero is probably wasteful, as it will send processor utilization through the roof and slow down everything else in the system. A good value is 10-20, or whatever it takes to keep "# elements in queue" from running away.
  • Packet Number - This shows you the packet number as reported in the "Packet Number" byte in each of the frames received from the Dashboard. This number should be steadily increasing until it reaches 255 at which point it will reset to 0 or 1 (don't remember). Having this value constantly updating is a firm indicator that you're receiving packets.
  • # elements in queue - This indicator shows you how many packets are "queued up" waiting to be processed. The rate at which this number increments is a factor of how high you set your "Packet Processing Delay" and what processing you're doing to a given frame. If you set your "Packet Processing Delay" fairly low (10) you should be able to drop this value down to 1 and keep it there (for the most part). If the number maxes out (I forget the max-out value, maybe 512) then frames are being lost and thrown away by the "Dashboard Read.VI" and that is never good.
  • Team Number - This indicator shows the team number as reported by the OI. Displaying this piece of information was kinda tricky, so I demonstrated how to do this.
  • Frame Type - This is indicative of the types of frames being received by the OI. Realize that in order to get RC or OI Data Frames, you need to set the jumper on the OI to the necessary setting.

Let me know if this allows you to at least process general information. I am going to steal back my "test controller" from team 418 so I can do a short video tutorial on how to modify the dashboard for your own customization.

Quote:
Originally Posted by chakorules
What we have noticed:
1. Labview dashboard seems to be running continuously, and monitoring the block diagram in the background, we can see I guess what you would call a program "pulse" or bulge in the piping coming in simulation data flow, it arrives in the bigger frame on the right, then changes the top left and right arrow selectors to say "False". Common sense to me means the data came in, but didn't find a matching packet or "String" in that block and then went false.
Nope, what it means is that we're constantly polling the data queue that should be filling up with data frames from the serial port. The "boolean" conditional block is asking, "Is there valid data?" It will produce "true" when there is data to process, and "false" when there is none. My guess is that you forgot to start the Dashboard Read.VI program completely.

Please let me know if this helps to get you up and running.

-Danny
__________________
Danny Diaz
Former Lead Technical Mentor, FRC 418
Reply With Quote