We just received the LabView gift package, and will be trying it out next week, thanks NI!
Last year on Team 1388, we instrumented our code by setting a digital output on the RC upon entering a section of code, and clearing the output upon exiting a section of code. We connected an oscilloscope to the output, and could measure exactly how long it took to exececute that block of code.
One problem we encountered was the 26 mS refresh rate produced a flashing and dim trace on the oscilloscope, and it was also jittery since the time through the code is not always the same during each pass through it.
I am hoping to use LabView to solve all of these problems. Using some of the digital inputs on the data acquisition module connected to digital outputs on the RC, I plan to create a multi-trace storage oscilloscope for viewing the timing signals, but more importantly, measure the actual pulse width each time, and track the minimum, maximum, and average times in a given part of the code. Another cool way to do this will be to display the pulse width sample data in a histogram display.
I will post more information in this thread as we work through this application.
Great idea. We also just got our NI package and I am excited about getting into it. Now I have a first task for it.
I am also curious how well my students who are ‘C’ biased for programming take to the icons.
And I will post whatever we manage to get it to do
[laughs] I find that I have to sit down with the students and introduce them to the concept of functional, procedural, and data flow language paradigms before they can begin to appreciate the fact that they’ll most likely be dealing with “non C-or-text-based languages” for the rest of their lives.
Text based functional or procedural programmers will have some transition time before they can effectively program in a graphical dataflow language - this is normal, I recommend that they open example programs in LabVIEW to begin understanding how to write proper graphical LabVIEW code. G-based programs (G is the graphical language name) have their own design patterns, and students who can identify and learn those patterns will be more effective LabVIEW programmers.
Thanks, Danny and NI for the package! It took all of 10 minutes to configure the DAQ for a Greyhill encoder. Visualizing the actual output is an excellent teaching tool for the programmers!
I had heard that NI was going to provide a VI ‘Dashboard’ so that we could connect the RC to the DAQ and watch the output as the program ran. I can also see, having completed the tutorial and started using the device myself, that maybe the idea was for the teams to come up with their own Dashboard.
I only wish I had a tool like this during my EE days!
Give me until Friday to answer that question - we’re putting some additional touches on a tool we’ve been working on for several months now, and it includes everything you’re asking about (improved Dashboard and such). I promise you won’t be disappointed!
The Dashboard we’ve created is part of a “Dashboard Provider” that can be used with the toolkit or as a stand-alone type of client. It uses the NI Datasocket Server to publish dashboard values (you can read those values from another computer if you’re networked) and any LabVIEW application can access the dashboard values and pluck what you want out of a well-structured cluster and display them, plot them, or whatever!
Yep, I was finally able to move everything to the permanent location set up for this project (and others in the future). The links in the original post have been updated to reflect these locations; give it a little while, though, it may take some time for the downloadable tutorial packages to update and become available on the server.
