Announcement

Collapse
No announcement yet.

Cruch Time Help! 3 LabVIEW Tutorial Videos: State Machines; Faster Code; Simulation

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Cruch Time Help! 3 LabVIEW Tutorial Videos: State Machines; Faster Code; Simulation

    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

    __________________
    Ben Zimmer
    email: [email protected]
    Phone/Fax: (905) 864-1858
    Toll Free: (877) 872-4619
Working...
X