LabView Dashboard

[Danny Diaz]

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.

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.

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

[kaszeta]

Our team started fiddling around with the LabView Dashboard under OS X, and while it's in general working well, we're finding that the execution is quite slow, and the number of buffers in the waiting list in Dashboard Read.vi keeps swiftly increasing, and as a result the Dashboard Display.vi starts to lag. Increasing Packet Processing Delay (I started with 5) just makes it worse.

This is on an OS X 10.4.4 1 GHz G4 laptop that's basically idle except for Labview.

Any ideas on speeding this up? The dashboard really isn't producing all that much data to be processed.

[Danny Diaz]

Originally Posted by kaszeta

Any ideas on speeding this up?

I've made some performance improvements in the update I provided here, give it a shot if you haven't already. Turns out that in LabVIEW 8.0 if you have any "while" loops that could go on forever in your code that LabVIEW thread can potentially run out of control and can send processor utilization through the roof (i.e. there are no "blocking" calls that forces the loop to wait for "something to happen"). I noticed this on team 418's laptop that it was dreadfully slow because the while loops were eating so much of the processor - oddly enough I didn't have this problem on a comperable desktop, but then again you never see any problems when you're developing software just when it gets out into the public . I added "wait for millisecond multiple" VI's in each loop which caused the thread to block (or yield to other processes/threads) and this greatly enhanced performance on the machine (and thusly I submitted the update). I debated on whether or not to have the packet processing delay automatically start at 10 by having a "10 + packetprocessingdelay" in the code but that would honestly be arbitrary and might or might not be right on a given machine. Sure, the 100ms multiple I added was also arbitrary, but sometimes you have to just make a decision and live with it.

Let me know if the update helps. I can gain access to a Mac OS X 10.4.4 desktop here at NI for a bit (through the careful use of bribery) so if this doesn't seem to do the trick I can potentially see what else might need a little TLC.

-Danny

[kaszeta]

Originally Posted by Danny Diaz

I've made some performance improvements in the update I provided here, give it a shot if you haven't already.

That's the version we're using.

Originally Posted by Danny Diaz

Turns out that in LabVIEW 8.0 if you have any "while" loops that could go on forever in your code that LabVIEW thread can potentially run out of control and can send processor utilization through the roof (i.e. there are no "blocking" calls that forces the loop to wait for "something to happen").

I'll check the Activity Monitor tonight when I run it to see what's going on. I'll also probe around and see if I can find anything else that's going on, although my labview skills aren't what they used to be...