LabView Dashboard

[Danny Diaz]

Originally Posted by brummer_13

I was worndering if anyone has gotten the dashboard in LabView to work

I wish you wouldn't make such statements, there have been many teams who have gotten the LabVIEW Dashboard to work. The problem you're facing is that you either (1) haven't read the documentation or (2) haven't taken the time to learn how to use it. If you have specific questions maybe I can help - I must admit I don't support EasyC quite yet, it's been on my list of things to do but have not been able to get around to it (darn day job!).

Have you been able to get the Dashboard to receive packets? Have you been able to get the Dashboard to display simple PWM_1 information? Have you been able to get the Dashboard to show you joystick information?

-Danny

[Chris_Elston]

Danny,

Go easy on the little freshman fellow....he is new....

I tried to assist brummer13 yesterday. We loaded MPLAB and downloaded the default code from IFIrobotics. We assumed that all code and bytes would be supported by Labview Dashboard with this configuration. We still can't get Labview to work with the default code downloaded from IFI.

Here is what we know.

1. Labview CMUCam works great.
2. NI-VISA is installed (it works fine with CMUCam Labview
3. IFI Robotics Dashboard works fine, this proves our cable, serial port work just fine on the computer.
4. We installed default IFIRobotics code with MPLAB and C18 2.4 complier. We assumed that this version of software would support all the user byte calls that Labview dashboard is looking for instead of using EasyC, where we have to write our own user bytes to Labview Dashboard.
5. We did write a small EasyC application for the OI LEDs, the OI LEDs work just fine, but Labview doesn't seem to be picking it up.
6. We have read the documentation, the PDF that came in the zip file for the dashboard application, doesn't really say anything about it "not" working. No troubleshooting steps etc..

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.

Being that we tried the default code, which we thought was sending user byte data, I am kind-of lost too.

I do appreciate your other post, I am reviewing the Labview training links you have posted for the sake of our freshman team trying to design an HMI for the robot this year.

Thanks for your patients in the matter. I am glad that other teams have gotten this to work, apparently for whatever reason, we aren't one of them, and I am trying to lead them in such a way that decifers good troubleshooting skills. We are generally a seasoned programming team with good technical skills. We helped find a bug in the EasyC camera function not long ago that was a concern to our team, but so far none of us have grasped the Labview Dashboard application. Apparently we aren't trying hard enough.

Also I believe bummer13 was just asking a general question if anyone had gotten it to work or maybe wanted to hear from a team that got it up and running. Maybe you can direct us to such a team that has it running since their are so many of them. Thank you for you time.

Originally Posted by Danny Diaz

I wish you wouldn't make such statements, there have been many teams who have gotten the LabVIEW Dashboard to work. The problem you're facing is that you either (1) haven't read the documentation or (2) haven't taken the time to learn how to use it. If you have specific questions maybe I can help - I must admit I don't support EasyC quite yet, it's been on my list of things to do but have not been able to get around to it (darn day job!).

Have you been able to get the Dashboard to receive packets? Have you been able to get the Dashboard to display simple PWM_1 information? Have you been able to get the Dashboard to show you joystick information?

-Danny

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