![]() |
Team 39, 2008 LabVIEW Beta Code
http://hhsrobotics.org/forums/viewtopic.php?f=4&t=3
We just released the first revision. More coming soon. rev0.1-- this revision only includes the teleoperated mode. it has been tested on the robot. Enjoy! |
Re: Team 39, 2008 LabVIEW Beta Code
Could you post images of the VIs? My team does not have access to LabView yet.
|
Re: Team 39, 2008 LabVIEW Beta Code
Quote:
I will post the pics sometime tonight |
Re: Team 39, 2008 LabVIEW Beta Code
For the health of your board there, you might want to set permissions so people don't have to register to download this file. Else you'll be getting a rather lot of one-time registrations.
EDIT: Second point, pictures are going to be slightly more meaningful, because all of us out here are lacking the dozens of WPI VIs needed to make sense of your code. Nevertheless, I'd like to suggest that you look into "Enumeration Constants" for passing your states around, instead of variable length strings. Eric will probably swoop in here and declare that we have so much processing power that it doesn't matter... But I think some things just shouldn't be done. Plus, enumeration constants will make your state-flow code immune to typos in your states. |
Re: Team 39, 2008 LabVIEW Beta Code
Quote:
Quote:
Thanks for the suggestions. |
Re: Team 39, 2008 LabVIEW Beta Code
HTML version just posted. :)
http://hhsrobotics.org/forums/viewtopic.php?f=4&t=3 |
Re: Team 39, 2008 LabVIEW Beta Code
The cRIO's PowerPC/FPGA combo is obviously far more processing-capable than the old IFI setup. However, that's no reason to write sloppy and inefficient code.
With a bit of LabVIEW experience, you'll learn to appreciate the value of the enumerated type (as in C/C++). I would strongly encourage every LabVIEW programmer to use this datatype wherever possible. It's always good practice to remove "magic numbers" from your code. Russ |
Re: Team 39, 2008 LabVIEW Beta Code
I looked through the code - and I have to wonder if it isn't time for FIRST to release some explanations of how the system is going to function.
I looked at it and was completely confused as to how it was supposed to work - and I'm betting other people are going to have the exact same reaction. |
Re: Team 39, 2008 LabVIEW Beta Code
Tom,
I think the code looks.... reasonably straight forward. But then, I'm a bit used to deciphering Labview code. It looks like most every function is going to be run through those XYZ-Open,Something,Close function blocks. Open XYZ on Port B at Slot A, either when the robot is turned on or when initializing into a mode. Do something to it. Close it when your robot turns off, stops needing it, or stops running the Labview code. I imagine the latter is important to not forget, since it could possibly confound things if you don't close these ports when you stop the code to make a programming change. I'm a little concerned that I don't see any DaqMX tasks in this code. I realize it's slightly advanced stuff, but it's important slightly advanced stuff. You can set up hardware timed data sampling tasks that run at much higher frequencies than your background processing tasks, as well as setting up custom scales and all sorts of other things. Hopefully it's just that beta teams haven't gotten around to looking at that sort of thing yet, as opposed to it not being an option. Borna, A few followup questions from an interested bystander: 1. I assume the pink wires in and out of the various modules (DigMd, AnlgMd) are carrying module configuration info. Are the shift registers you have on these module configuration lines actually necessary? Could they instead just be simple tunnels, as with the Joystick in your main loop? 2. Is 25 Hz just a random loop timing decision on your part, or is it the recommended max loop rate? 3. The Victor/PWM modules seem to have some sort of deadband and transform setup. Does that configuration happen in a separate module? |
Re: Team 39, 2008 LabVIEW Beta Code
Quote:
Quote:
Quote:
For example, The deadband control for Victor is a boolean value, whether to scale the inputs to eliminate the victor deadzone and center on 127 (rather then 132) or not. |
Re: Team 39, 2008 LabVIEW Beta Code
Quote:
too keep the new data for the next loops, shiftregisters are needed. but in our case as of now, tunnels would work the same. ================================================== ==== For our code as of now, we dont need to sample the inputs more that 25hz since thats the only time they are needed. once we get to gyros or accelerometers, sampling fater would come in handy. I promise the next revision looks much better. |
Re: Team 39, 2008 LabVIEW Beta Code
Quote:
|
Re: Team 39, 2008 LabVIEW Beta Code
Quote:
Also a new Driver Station update was released today that changed the update rate to approximately 50Hz you can also run this loop faster, it is best if the loop OS run at a multiple of DS update rate. eg. 100Hz - 200Hz and make sure your processor doesnt run out of time. |
Re: Team 39, 2008 LabVIEW Beta Code
Responding to the question about DAQmx usage, the cRIO and other reconfigurable I/O devices don't have a traditional driver API to their I/O. The I/O is defined by VIs that run on the FPGA, and accessed by VIs that run on the RT target. In other words, the WPI library really is the API. It is built upon/incorporates the FPGA, and is DAQmx is not in the picture.
Greg McKaskle |
Re: Team 39, 2008 LabVIEW Beta Code
Quote:
Custom scales are implemented by you wrapping the GetVoltage VI with the calculations you want for your scale. The voltage values that are returned to you are scaled with factory calibration constants stored for each channel on each module during manufacturing. Quote:
|
| All times are GMT -5. The time now is 05:18. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi