Announcement

Collapse
No announcement yet.

Linear Op Blocks

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

  • Linear Op Blocks

    Hi,

    Can anyone explain what does these blocks do and what do they do:

    WaitForNextHardwareCycle()

    WaitOneFullHardwareCycle()
    Thanks,
    Programmer - FTC Delta Kappa

  • #2
    We've tried to get a response to that question, but no one really seems to know. What we do know is WaitOneFullHardwareCycle fixed a lot of problems. We inserted it into every loop in our linear Op Mode autonomous program and a it began working the way we wanted it to. Each move of the robot uses a while loop and encoder readings to navigate the field.

    Comment


    • #3
      Both blocks do exactly as they say. The WaitFOrNextHardwareCycle() will wait for the next hardware cycle to occur before it does something. This can either be a long or short period, depending on if it was activated near the beginning or the end of the current cycle. The WaitOneFullHardwareCycle() will exactly one hardware cycle from the time the block was initiated. I don't know exactly what the exact definition is for a hardware cycle, but I like to think of it like this: Your computer(or laptop, or whatever electronic you want to think of) has a refresh rate. This rate determines how often it looks at a block of code. It can be fast, or slow, depending on how old your computer is, and what is type of hardware it has. But it is continually cycling. So I think of a hardware cycle as that rate. You are telling your phone to wait until it checks again before it does your code, or wait until the exact time on it's next cycle before it does the code. This is how I think about it, and I hope it helps you guys.
      FTC 8567 -Lead Programmer, 3-D Print Specialist, Lead CAD Designer

      Comment


      • #4
        Originally posted by tvsknights View Post
        We've tried to get a response to that question, but no one really seems to know. What we do know is WaitOneFullHardwareCycle fixed a lot of problems. We inserted it into every loop in our linear Op Mode autonomous program and a it began working the way we wanted it to. Each move of the robot uses a while loop and encoder readings to navigate the field.
        The "hardware cycle" that's being referred to is the process of reading from and writing to the external device hardware (ie: motor and servo controllers).

        This is done on a regular basis, but the time between updates may vary, and it will happen in the background if you are using linearOpMode.

        So if you want to see sensor inputs change, or your motor outputs change, you need to wait for a hardware cycle.

        When LinearOpmode was first created (initially there was just opMode), WaitForNextHardwareCycle() was added to allow teams to pace their opMode.

        Unfortunately it wasn't as strict as some people wanted. If the program was already doing a hardware cycle, WaitForNextHardwareCycle() would just return immediately.
        Which had the effect that if you had just issued a motor mode change command, and wanted to wait till that command had actually been sent to the hardware, you were out of luck.

        So the developers added WaitOneFullHardwareCycle() which is very strict, and it will guarentee (as much as it can) that you get a full hardware cycle after you issue the call, which means if a cycle is in progress, it will wait for the next one to complete.

        So, if you are just casually looping and reading sensor values, and want to give the program time to read the sensors, call WaitForNextHardwareCycle()

        However, if you are doing critical output calls that need to be processed before continuing... call WaitOneFullHardwareCycle()

        Phil.

        Comment


        • #5
          I do not see the block for waitfornexthardwarecycle() in App Inventor (1.7 beta). What happened?
          https://drive.google.com/file/d/0BwK...ew?usp=sharing

          Comment


          • #6
            From the Release Notes:

            Changes made to make the FTC SDK synchronous (significant change!):
            **waitOneFullHardwareCycle() and waitForNextHardwareCycle() are no longer needed and have been deprecated.
            **runOpMode() (for a LinearOpMode) is now decoupled from the system's hardware read/write thread.
            **loop() (for an OpMode) is now decoupled from the system's hardware read/write thread.
            **Methods are synchronous.

            Comment


            • #7
              Originally posted by FTC8881 View Post
              From the Release Notes:

              Changes made to make the FTC SDK synchronous (significant change!):
              **waitOneFullHardwareCycle() and waitForNextHardwareCycle() are no longer needed and have been deprecated.
              **runOpMode() (for a LinearOpMode) is now decoupled from the system's hardware read/write thread.
              **loop() (for an OpMode) is now decoupled from the system's hardware read/write thread.
              **Methods are synchronous.
              Hi FTC10854,

              FTC8881 is correct, the methods have been deprecated. This means that they are supported, but no longer needed. Eventually, they will go away.

              With the newest software (v1.7 and greater) you no longer need to call the waitOneFullHardwareCycle or waitForNextHardwareCycle methods. The methods are now synchronous or blocking. This means, for example, when you set the mode on a motor (to reset the encoders) the method used to reset the encoders will complete the task before it returns from its execution. So if you call the method to reset the encoders, then control is returned to your op mode, the encoders should be reset (guaranteed by the SDK).

              This should make it a lot easier to write op modes, especially autonomous op modes.

              Tom

              Comment


              • #8
                Originally posted by FTC8881 View Post
                From the Release Notes:

                Changes made to make the FTC SDK synchronous (significant change!):
                **waitOneFullHardwareCycle() and waitForNextHardwareCycle() are no longer needed and have been deprecated.
                **runOpMode() (for a LinearOpMode) is now decoupled from the system's hardware read/write thread.
                **loop() (for an OpMode) is now decoupled from the system's hardware read/write thread.
                **Methods are synchronous.
                Hi FTC10854,

                FTC8881 is correct, the methods have been deprecated. This means that they are supported, but no longer needed. Eventually, they will go away.

                With the newest software (v1.7 and greater) you no longer need to call the waitOneFullHardwareCycle or waitForNextHardwareCycle methods. The methods are now synchronous or blocking. This means, for example, when you set the mode on a motor (to reset the encoders) the method used to reset the encoders will complete the task before it returns from its execution. So if you call the method to reset the encoders, then control is returned to your op mode, the encoders should be reset (guaranteed by the SDK).

                This should make it a lot easier to write op modes, especially autonomous op modes.

                Tom

                Comment

                Working...
                X