|
|
|
![]() |
|
|||||||
|
||||||||
|
|
Thread Tools |
Rating:
|
Display Modes |
|
#1
|
|||
|
|||
|
Hello All,
Well, we're down to the last week, and I've been talking to lots of teams. I know many are in great shape, and many are just getting started on their programming. So, I wanted to squeeze in as much help as I could, as quickly as possible. Check out the following 3 videos: 1. State Machines: Writing Flexible, Modular Code. Lifter Mechanism Example (http://www.lvmastery.com/TipJar2009-02-08_1) In this blog entry, I discuss how to use a state machine within LabVIEW to write flexible, modular code. In this example I code and explain the state machine for a mechanical lifting system. much like what many FRC teams may use. I discuss: - What state machines are - How to draw and interpret a basic state diagram - Creating typedefs for state machine data - Creating enums to store the actual state - Storing all sensor inputs and machine outputs in the state machine data for use in debugging and/or the dashboard program - How to write the state machine code using the case structure, including how to speed up development by duplicating similar cases 2. TipJar #14 - Speeding Up Slow Tele-Op Code and How Parallel Loops Can Communicate (http://www.lvmastery.com/TipJar2009-02-08_2) In this blog entry, I discuss how to speed up time-critical code by pulling it out of the Tele-Op.vi, while maintaining the ability to share data. I discuss: - The fact that there is a lot of stuff going on in TeleOp, and the main loop: can take up to 200ms to run, potentially causing robot damage if limit switches are missed - How to move the state machine created in TipJar #13 into its own deterministic, accurate, fast loop - How moving the state machine out of TeleOp causes the debugging dashboard to fail because the state data is no longer available - How to create a global variable to share the state machine data with the main loop for debugging - Race conditions: why you should never write to global variables from more than one VI - How to send info from TeleOp to the parallel loops in an easy, scalable way using a "Command Signal" global - How using a single command signal can help ensure your important code runs perfectly in TeleOp AND autonomous modes 3. TipJar #15 - Simulating and Testing: How to put your FRC code through its paces on YOUR computer. (http://www.lvmastery.com/TipJar2009-02-08_3) In this blog entry, I discuss how to simulate your state machine code. The real benefit here is the opportunity to test your logic on your development PC, without needing a functioning robot. I discuss: - How to simply modify the previous state machine example for simulation - How to use a global "Simulate" boolean variable to selectively replace all Hardware inputs and outputs with front panel controls and indicators - Using case structures to "case out" WPI library calls - How to watch and debug using execution highlighting, watching the global variables and the front panel - How you must be sure to simulate all sensors, which includes things like turning off simulated limit switches when the system "moves" away from them - How to simulate the manual override mode by writing to the "Command Signal" global just like the TeleOp or Autonomous VIs would Last edited by LVMastery : 09-02-2009 at 07:06. |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Good online tutorial explaining the Gravity simulation in Solidworks? | Elgin Clock | SolidWorks | 7 | 24-06-2009 22:05 |
| LabVIEW Video Tutorial - Debugging Your FRC Code | LVMastery | NI LabVIEW | 0 | 26-01-2009 09:28 |
| help me in LabView code | mahmosh | National Instruments LabVIEW and Data Acquisition | 3 | 11-01-2009 00:18 |
| State Based Machines in LabView | Greg Marra | General Forum | 0 | 11-11-2008 11:07 |
| State Machines | doyler | Programming | 7 | 11-01-2005 00:53 |