Announcement

Collapse
No announcement yet.

Program Timing

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

  • Program Timing

    There are certain items I want to time in labview.

    For instance, I want to time the Opponent-Position Sub VI that I have written so that I only perform it at the same interval that I run my camera framerate at.

    If I open the Sub-VI and place a timer in it, will the subvi then run at that speed? There is NO loop in that Sub-VI.

    What I'm asking is, do I need a loop to use a timer, or will it time a Sub-VI just by putting it in the Sub-VI?

    Any other comments on timing might help. It's one part of labview I've never had to touch on before.

  • #2
    Re: Program Timing

    The best way to make sure that your VI runs at the same rate as the camera is to make it have a dataflow dependency on the camera data.

    The wait VI should wait regardless of whether it's in a loop or not.
    Team 330 beta tester

    Comment


    • #3
      Re: Program Timing

      Another question, not so much regarding timing:

      In the teleop.vi, there are a lot of values that I want to pass to the next iteration.

      Will it cause a problem if I put all my user code in the teleop.vi in a while loop that is set to false, so that:
      #1 it will only execute once per teleop.vi call
      #2 I can use shift registers to pass values back rather than the backwards pointing arrows?

      Will these values still be in the shift registers when teleop.vi is called again?

      I ask because shift registers end up being so much cleaner to wire when you have tons of wires running everywhere.

      Comment


      • #4
        Re: Program Timing

        The while loop will do its "first iteration" every time teleop.vi is called. The shift register inputs will be their default values.

        What I'd do in a case like that is to bundle together all the things I wanted to remember and use a global variable. Read from the global and unbundle on the left, use the values, then bundle the results and write to the global on the right.

        Comment


        • #5
          Re: Program Timing

          That makes sense. Thanks!

          Comment


          • #6
            Re: Program Timing

            Ok... next question.

            So - if, I open an encoder in the "Init" case of the teleop.vi. What is the "proper" way to pass the devref and error code back to the "front" of the case statement for use in the "Execute" case? Feedback nodes, global variables, other?

            Comment


            • #7
              Re: Program Timing

              Originally posted by Alan Anderson View Post
              The while loop will do its "first iteration" every time teleop.vi is called. The shift register inputs will be their default values.

              What I'd do in a case like that is to bundle together all the things I wanted to remember and use a global variable. Read from the global and unbundle on the left, use the values, then bundle the results and write to the global on the right.
              If you leave the shift register uninitialized, it will not get set to to its default value each time. This is often used to create global variables called Functional Globals. In fact, during the beta period, before the creation of the advanced framework, the framework did exactly what Tom described. You can see this in some of the early code the beta teams posted.
              Team 330 beta tester

              Comment


              • #8
                Re: Program Timing

                Originally posted by jross View Post
                If you leave the shift register uninitialized,...
                You can do that?! My quick introduction to LabVIEW at work (version 7.1, I believe) included the knowledge that I couldn't run a VI if any inputs to a loop were disconnected. It just goes to show: it's not what you don't know that can hurt you. It's what you do know but which ain't so.

                Comment


                • #9
                  Re: Program Timing

                  Perfect! Thanks guys. That's the method that we used (functional globals) for opening items in the init step and then passing the devref and error back around. Of course, at the time we didn't know what they were called: we saw them in 2519's (or was it 2529's) code and thought it was a slick way of doing it.

                  Comment


                  • #10
                    Re: Program Timing

                    Originally posted by Alan Anderson View Post
                    You can do that?! My quick introduction to LabVIEW at work (version 7.1, I believe) included the knowledge that I couldn't run a VI if any inputs to a loop were disconnected.
                    You can't have tunnels unconnected, but you can have shift registers unconnected.
                    Team 330 beta tester

                    Comment


                    • #11
                      Re: Program Timing

                      Originally posted by Tom Line View Post
                      Another question, not so much regarding timing:

                      In the teleop.vi, there are a lot of values that I want to pass to the next iteration.

                      Will it cause a problem if I put all my user code in the teleop.vi in a while loop that is set to false, so that:
                      #1 it will only execute once per teleop.vi call
                      #2 I can use shift registers to pass values back rather than the backwards pointing arrows?

                      Will these values still be in the shift registers when teleop.vi is called again?

                      I ask because shift registers end up being so much cleaner to wire when you have tons of wires running everywhere.

                      You can do what you describe to store data, but you must leave the initializer (wires from the left on the outside) unwired. Otherwise you get the behavior that Alan described.

                      Edit: Ugh... didn't read the whole thread first.

                      Comment


                      • #12
                        Re: Program Timing

                        Originally posted by Tom Line View Post
                        Perfect! Thanks guys. That's the method that we used (functional globals) for opening items in the init step and then passing the devref and error back around. Of course, at the time we didn't know what they were called: we saw them in 2519's (or was it 2529's) code and thought it was a slick way of doing it.
                        The advanced framework was designed to handle this for you. Just define the dev ref in the Robot Data cluster and then it will be available in all your VIs in a way that helps you to avoid race conditions (in case you don't want to have to think too much about it).

                        Comment


                        • #13
                          Re: Program Timing

                          Originally, we wanted to use the devrefs in the clusters, but we couldn't figure out how to do it - took us an hour to slog through how to do it once. So we went back and were using loops.

                          But when lvmastery posted tutorial 9 that walked you through how it was supposed to work, a lightbulb went on and we all went "Ooooooooooooh."

                          So now we've redone it using the clusters with devrefs. Thanks again guys!

                          Comment

                          Working...
                          X