I don’t know anything about Labview, however felt compelled to check it out and maybe make a simple HMI (human machine interface) panel from it to our OI (Operator Interface).
I’ve looked at this Labview briefly, and I am lost. Maybe it’s simplier than it looks. Can anyone give me the beginners explaination?
Speficily, the Dashboard application.
We are using EasyC this year, so none of the default OI information is being sent to the controller, unless we create those varibles. But I can’t tell by looking at the block diagram view how the “varibles” are called or accessed in Labview. I see the LEDs panel that was created in Dashboard (labview) version, but I can’t find that in the block diagram, nor make a relationship of if that graphic is assigned to a varible which is updated by a packet or protocol stream somehow.
My back ground is PLCs (programmable logic controllers) I use GE, Allen Bradley PLCs. These brands support their HMIs, PanelView, and Total Control products which our HMI touch screens. When a graphic is created in those HMIs, you can double click them and assign a varible or memory location in the PLC at which you want to poll this address, and display your PLC value in the place of your graphic you made in your HMI.
Is this how this Labview is suppose to work? It appears that we have to create the driver first, then what…sort it out? Confused…
Have you read the “Labview Dashboard Documentation.pdf” included with the labview app? The driver is already written, you just need to modify the display file (although both have to run).
Each variable passed through the dashboard port gets stuffed into a different “frame” (I’m not sure the real labview term as I just started using it last week). See my attachement initial.gif to see where you change the frames. Clicking the down arrow gives you a list like in choosing.gif. Between the two “frames” you can choose from every variable sent over the dashboard port. Each variable is brought to the edge of the “frame” and you add whatever display stuff you want within the frame and connect it to the edge. So, rather then placing your HMI element and clicking on it and choosing your variable, you place the HMI element in the correct “frame” for your variable and draw a wire connecting it to the dge.
It would be worthwhile to read IFI’s dashboard documentation included with the IFI dashboard viewer to see what gets sent by the IFI default code, which was what labview was designed to display. I don’t know what EasyC does by default, but it would probably be easier with labview if you copied the IFI format.
I did my first modification to the battery display. I used some simple addition and multiplication to convert the battery from a 0-255 range to volts. Then I branched to adding graphs for other variables. That’s as far as I’ve gotten though, but it’s been really easy so far.
One thing that makes it easy to find where your controls and indicators are on the block diagram is you can double click on them in the front panel and it will switch to the block diagram and highlight the node. Every control or indicator on the front panel has a node on the block diagram. It is really the same object. If you delete a control or indicator from one of them, it will disappear from the other one too. The only thing to watch out for (I’m not sure how much it is used in the dashboard application) is that you can also access those controls and indicator using a Local Variable node (see the data communication palette) or a property node to change or access the value of them.
Just play with it… if you mess something up, you can click on the run arrow (that will now be a gray broken arrow) and it will tell you where the error is. If you double click on the error, it will highlight the error for you.
Actually when writing the Dashboard Display VI I tried to show the use of both methods. Realize that many bytes are duplicated in multiple data frames - this means there are possibly 4 different frames where updated information can come from. Look at the “packet number” byte, it’s included in each and every frame. Unfortunately when you create a front-panel numeric indicator (like that of the “packet number” indicator) you only get one block-diagram node for that indicator (so it’s only possible to write to that front-panel object directly in one place on the block diagram). I want the packet number to be updated in the same front-panel numeric indicator each time a new packet comes in, so I have to reference the front-panel numeric indicator in multiple locations (since it is present in every frame type). Some of the ways I write to the numeric indicator are directly (RC Data frame 2), through a local variable (RC Data Frame 3 and OI Data Frame), and through a reference (RC Data Frame 1); there are even more ways than this!
You have a Front Panel and a Block Diagram. The Block Diagram can be looked at kind of like an electronic circuit - wires carry data from one “execution node” to another, and this is where the actual algorithm of the program is executed. The Front Panel is the place where information can be gathered by the block diagram (via controls) or displayed (via indicators). Front panel objects have block-diagram-nodes which are created in the block diagram for the block diagram to interact with. When you create a Front Panel object, you can double-click on it to show the location of its block-diagram-node on the block diagram. It is usually necessary to move the block-diagram-node to a different location than the one that is automatically selected.
In the simple example of the Dashboard Display VI, you would create a Front Panel object (an indicator, for example) and double-click on it to show you the block-diagram-node for that front panel object. You would then move that block-diagram-node into the appropriate “data frame case block” and then wire the blue data wire attached to the left of the condition block to the block-diagram-node. Whenever the appropriate data frame comes in, the data byte selected will be written into your block-diagram-node so that you can view it on your Front Panel.
A video tutorial sounds like an interesting proposition. What kinds of things would you like to see in a LabVIEW video tutorial?
Personally, I’d like to see one that is more broken down into a need-to-know section (for example, how to get LabVIEW going, working with the VIs, perhaps even fiddling with the Dashboard VI to make it display what you really want it to, et cetera), then one that goes deeper into the nitty-gritty parts of LabVIEW (the same nitty-gritty parts that I keep wanting to read about, but get drawn away from doing by external forces screaming out “Billfred, put down that manual! We only have 17 more days to get this robot done!”).
It’s kinda like the free newspapers students get at USC–there’s The Wall Street Journal (which gives more information than I’ll ever be able to get through, but it’s good information) and USA Today (which, while not as information-packed as the Journal, is a paper I can get through, get the news, and move on to my bagel).
I’ve started making the LabVIEW Dashboard “training” videos. Right now I’ve got 2 short videos, both aimed at extremely simple uses of the LabVIEW Dashboard - the first demonstrates simple use of the Dashboard, and the second demonstrates the data logging and replay capabilities of the LabVIEW Dashboard. I’m working on a third video, aimed at looking at ways to improve performance of the Dashboard and also at customizing the Dashboard for your own use; when that video is completed and posted, it will appear on the source website below.
You can get to the Macromedia Flash videos (developed using a 30-day free trial of Camtasia Studio 3) from Team 418’s website, more specifically from this forum post. As videos are added, they will appear on the forum posting previously referenced.
WOW…Excellent work Danny! I can’t wait to get back to our labview project. I hope we can get it to work. I forwarded your video links to brummer13. We kind of had to work on other projects right now instead of labview, however if we get it to work, I can see a HUGE benefit to using it.
Example: PID TUNING!!! Woweeee…Your second video was great. I hope teams can see the value in the logging. That’s an amazing tool.
Can’t wait for the third edition where you show us some examples of how to edit or customize dashboard.
Excellent work!
PS: Nice voice too, you sound like a pro. My video tutorials don’t have any voice overs, here is an example That’s really great software “camtasia”, I might try that out.
Thanks for those videos Danny. I can’t wait for the next edition.
Question:
Is there any way to receive other data from the Dashboard port on the OI into the Labview Dashboard? Like, can I get my own variables? For instance, I have an int in my user_routines.c file that counts how many balls we have queued up to shoot. Can I read that variable into the Labview Dashboard and have an indicator showing me that number? I really hope this is possible. I’ve looked through the block diagrams and they make sense for the most part.
If I were for some reason to run out of PWM’s and USER_BYTES to put my values to, is there any way to change what values are being sent to the DASHBOARD? This isn’t a problem, but I’m just wondering.
We got labview to work today. Turns out we had some issues with our serial port. I used my laptop which is a DELL D800 with a “Real” serial port and it worked the first try.
Matter of fact we used it today to tune our PID controls. Wow…it worked just like I pictured it would work. We have three “POTS” connected to analog 14,15,16. 14 = P term, 15 = I term and 16 = D term. We can tune our PID system on the fly, and now with Labview as feed back with a graph…it only took about 5 minutes to tune our PID control. Amazing tool…amazing…what a time saver.
The Dashboard output is just a “copy” of the data being sent across the radio/tether between the RC and the OI (think of the Dashboard as spying on the communications). That data protocol is proprietary to IFI (with good reason!) and unfortunately there isn’t a way to “change” the data being output. There is also no way to synchronize the data communications for faster throughput of data in the user_bytes variable (since the computer cannot control any aspect of the input to the OI). You could “label” data packets pretty easily, and have your Dashboard process the user_byte information “smartly”, you just need to be careful to use the PutData command correctly in your RC code.
Excellent! Unfortunately NI-VISA does have some incompatabilities with some third-party USB-SERIAL devices that don’t support all the features that our NI-VISA configuration VIs attempt to enable. I don’t have a list of the devices that are and aren’t supported, but if you guys would like to share what USB-Serial device you’re using and whether it works or not, I think it would be very useful for teams to know…
Slick! Do you care to explain how you did that within the dashboard? Did you use the user_bytes? Care to share any screenshots?
Were you able to figure out how to write to the user_bytes using EasyC? I’ve been unable to figure out how its done. Thanks in advance for any help that you can provide.
Danny - Is there a new place to get your Dashboard Tutorial Flash videos that you mentioned in the post up above? The LASA Robotics site seems to have switched to Joomla, and the Forum no longer seems to be there. My team is really hot to use the Labview Dashboard this year, and as I remember, those videos were very useful to my understanding of the whole process when I first checked it out.
What you want to use is the Simulation Toolkit, it has a much better and easier to use dashboard mechanism built into it. If you use the default VI as your template for your dashboard program, everything you need is right there. Can you give me the weekend to install my presentation-generation software into my new laptop and create a quick video to show you how to do it? I promise it will be WELL worth the wait…
I’d recommend grabbing it again, I needed to update some of the error handling code - Team 418’s test platform with a 2004 RC/OI is starting to get flaky, and some bytes are getting corrupt every so often. I needed to update the toolkit to better handle getting corrupt data so that you either get good data or nothing at all.
But, anyway, I promised a new tutorial and I’m here to make good on it. I didn’t add any voice to this tutorial, but I think it’s going to be very easy to follow and understand. What I did was showed you how to use the components from the FRC Robot Modeling toolkit to create a really basic Dashboard, but it’s very easy to expand to add much, much more capabilities, especially if you’re sending back data via the user bytes. I went through the actual build phase pretty quick, and made a few "uh oh"s that I did correct, but you’ll see. I did the whole thing in under 5 minutes, and should be easily reproducible by anyone on your LV programming team. Remember it’s assumed that you’ve installed the FRC Modeling Toolkit.
As always, if you have any questions, feel free to ask.
To download the tutorial, download the ZIP file and open the HTML page to view the FLASH video.
)