Go to Post DonRotolo used COMMON SENSE. ... ... FIRST/Chief Delphi Community fainted! - PayneTrain [more]
Home
Go Back   Chief Delphi > Technical > Programming
CD-Media   CD-Spy  
portal register members calendar search Today's Posts Mark Forums Read FAQ rules

 
Closed Thread
Thread Tools Rate Thread Display Modes
  #1   Spotlight this post!  
Unread 05-01-2014, 22:57
Kevin Phan's Avatar
Kevin Phan Kevin Phan is offline
College Student
FRC #0357 (Royal Assault)
Team Role: Alumni
 
Join Date: Apr 2013
Rookie Year: 2010
Location: PA, United States
Posts: 95
Kevin Phan will become famous soon enoughKevin Phan will become famous soon enough
Smile Team 357's Introduction to LabVIEW

Hello everyone! My name is Kevin Phan as my username says and I am a student programmer on the team. This year I taught a seminar on LabVIEW during kickoff. I hope this document I made for kickoff as a kick-start guide help some of you who are currently having trouble with LabVIEW or unfamiliar to LabVIEW. There is a survey that I had made for this kickoff and if you want to help me make this document better, please feel free to fill out my survey here:

https://docs.google.com/forms/d/1IRe...X2Nes/viewform

The document only covers what I consider the basics when using LabVIEW. As the season progresses I hope to create more LabVIEW documents that will be posted on the team's website.

http://team357.org/RA_iWeb/index.html

For anyone who is having issues in LabVIEW and the document does not cover what you want and need answers. You can email me at:

team357royalassaultlabviewhelp@gmail.com

Once again, thank you for participating in the survey and using my LabVIEW guide. I hope to do another one next year!
Attached Files
File Type: docx LabVIEW handouts.docx (1.65 MB, 75 views)
  #2   Spotlight this post!  
Unread 08-01-2014, 14:24
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Team 357's Introduction to LabVIEW


Hi Kevin, would you mind posting a PDF instead of (or in addition to) DOCX so those of us using Linux can have a look?


  #3   Spotlight this post!  
Unread 08-01-2014, 15:25
Kevin Phan's Avatar
Kevin Phan Kevin Phan is offline
College Student
FRC #0357 (Royal Assault)
Team Role: Alumni
 
Join Date: Apr 2013
Rookie Year: 2010
Location: PA, United States
Posts: 95
Kevin Phan will become famous soon enoughKevin Phan will become famous soon enough
Re: Team 357's Introduction to LabVIEW

Here's the pdf version of the guide. Sorry for those of you who couldn't access the docx file.
Attached Files
File Type: pdf LabVIEW handouts.pdf (1.47 MB, 80 views)
  #4   Spotlight this post!  
Unread 08-01-2014, 16:23
Ether's Avatar
Ether Ether is offline
systems engineer (retired)
no team
 
Join Date: Nov 2009
Rookie Year: 1969
Location: US
Posts: 8,125
Ether has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond reputeEther has a reputation beyond repute
Re: Team 357's Introduction to LabVIEW

Quote:
Originally Posted by Kevin Phan View Post
Here's the pdf version of the guide. Sorry for those of you who couldn't access the docx file.
Thank you. It looks like you put quite a bit of work into this.

Not being a LabVIEW guru myself, I'm hoping some veteran LabVIEW people review this.


  #5   Spotlight this post!  
Unread 08-01-2014, 19:06
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Team 357's Introduction to LabVIEW

A couple clarifications:

-In the disabled VI, any time the robot is disabled the outputs are disabled as well, so you can't command any actuators even if you try to. I usually have a lot of code that runs when disabled (in many cases all of my code runs when disabled) so I can debug without allowing actuators to actuate. I always copy a call to Teleop alongside Disabled so that I can debug teleop with the robot disabled.

-Finish runs when the code is requested to stop by the front panel control on Robot Main.vi and it is impossible to get there using 'burned' code. I stopped writing code in this file a few years ago and my new custom templates do not even include it at all. If the FPGA watchdog works and is used properly there is no need to do anything here at all.

-A key distinction between a potentiometer and encoder is the fact that a potentiometer is absolute while an encoder is relative (there are 'absolute encoders' also, the type often used in FRC mimic the behavior and analog output of potentiometers). This can be important if you need to know the position but don't know the starting position (it's possible for an arm to be anywhere, if you don't have another sensor to tell where zero is you will never know if you're incremental position is right).
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
  #6   Spotlight this post!  
Unread 08-01-2014, 20:38
Kevin Phan's Avatar
Kevin Phan Kevin Phan is offline
College Student
FRC #0357 (Royal Assault)
Team Role: Alumni
 
Join Date: Apr 2013
Rookie Year: 2010
Location: PA, United States
Posts: 95
Kevin Phan will become famous soon enoughKevin Phan will become famous soon enough
Red face Re: Team 357's Introduction to LabVIEW

Thanks for the clarifications apalrd. I guess I need to do more researched into how the vis are work. My assumption for disabled vi came from testing pneumatics and seeing it release when the robot was disabled. I put code in the disabled vi to make sure the pneumatics did not release, which it did work. The FGPA watchdogs, I only know that they exist, but I don't know how to use them. As for the potentiometers and encoders, I know when and how to use them and after reading that clarification it made total sense .

I'll make sure to edit these soon. I also will be making some small additions to cover things that I forgot to include.

Last edited by Kevin Phan : 08-01-2014 at 21:03.
  #7   Spotlight this post!  
Unread 09-01-2014, 14:53
apalrd's Avatar
apalrd apalrd is offline
More Torque!
AKA: Andrew Palardy (Most people call me Palardy)
VRC #3333
Team Role: College Student
 
Join Date: Mar 2009
Rookie Year: 2009
Location: Auburn Hills, MI
Posts: 1,347
apalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond reputeapalrd has a reputation beyond repute
Re: Team 357's Introduction to LabVIEW

There are a few watchdogs in the FRC control system. Two exist in the FPGA, and many in user code only.

The FPGA has two watchdogs ('system' and 'user') which are reported to the debug console on the Driver Station when they trip. System reports watchdog errors between Netcomm (FRC communication, not user modifyable) and the FPGA (also not user modifyable) while User reports errors between the user code and FPGA. The 'user' watchdog is no longer really used, although I continue to use it in my code.

The 'user' watchdog is accessed by the red Watchdog blocks in WPI Robotics Library->Utilities->Watchdog and only one exists. Basically, you set a timeout (Default is I believe 500ms, I set mine to 50ms) and must call 'FEED' (there's an FPGA block which sets a boolean to 1 to trigger the FPGA timer) within that time interval or the FPGA will kill all of the outputs (motors, relays, and solenoids). This protects you if all of your code is in 1 thread (as multiple threads separately feeding it could allow code that has gotten stuck in 1 thread to be ignored, and a few but not all of the outputs to be unsafe). It also protects you if your code totally crashes or you stop it with the red stop button in Robot Main. It is IMHO a better protection than the pure software 'watchpuppies' as it involves a second processor.

There are also 'watchpuppies' which can be created for each motor, as the 'safety config'. These are watched by another thread as part of the user code (Actually in Driver Station Start Communication) which checks the timestamp of the last update against the current time. These can exist (if they are enabled) for any motor, relay, or solenoid separately.

Depending on your programming architecture, you can use one or the other or both. I use the FPGA user watchdog only in my code (safety checks code completely removed), set at 50ms, with a 10ms hard loop time. All of my code runs in the same task, so I am not worried about independent code failures. Many programmers run lots of tasks, and should do something else.

What you probably saw with the pneumatics is the effect of the pneumatics after entering an enabled state, as the output was set when exiting an enabled state or in the last enabled state (when teleop ran), but the FPGA enables the outputs faster than the user code can run (so teleop has not yet run since the code entered enabled state). There were issues in the past (not sure if they were fixed) with the relays not respecting the disabled state (due to the hardware and the way the FPGA handles disabled states).
__________________
Kettering University - Computer Engineering
Kettering Motorsports
Williams International - Commercial Engines - Controls and Accessories
FRC 33 - The Killer Bees - 2009-2012 Student, 2013-2014 Advisor
VEX IQ 3333 - The Bumble Bees - 2014+ Mentor

"Sometimes, the elegant implementation is a function. Not a method. Not a class. Not a framework. Just a function." ~ John Carmack
Closed Thread


Thread Tools
Display Modes Rate This Thread
Rate This Thread:

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT -5. The time now is 03:21.

The Chief Delphi Forums are sponsored by Innovation First International, Inc.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi