|
|
|
![]() |
|
|||||||
|
||||||||
![]() |
|
|
Thread Tools | Rate Thread | Display Modes |
|
|
|
#1
|
||||
|
||||
|
Re: So apparently flat sequence structures don't work well in Teleop.
Can't you click on the node (in LabVIEW of course) and get pop-up help which explains what it does?
|
|
#2
|
|||
|
|||
|
Re: So apparently flat sequence structures don't work well in Teleop.
I have before, but I still haven't figured out how that would be useful in that particular situation. Which is where I don't understand its use. The program I made works fine for ours, with the caveat that hitting A at any time the robot isn't enabled requires the limit switch also be hit again to "reset" the cycle by ending the frame diagram. This is likely a non-issue, as the limit switch will always be pressed when our motor-driven gate is closed, although if anybody has some way to avoid this (not activating when not in Teleop, maybe?) we'll take it.
|
|
#4
|
|||||
|
|||||
|
Re: So apparently flat sequence structures don't work well in Teleop.
The feedback node in that use prevents the sequence from running again immediately if the driver continues to hold down the button.
The button must be released and pressed again after the sequence ends to get the sequence to run a second (or nth) time. It's particularly useful with short sequences or forgetful drivers. You can add in a Disabled check as well to prevent the sequence from being pre-triggered. |
|
#5
|
|||
|
|||
|
Re: So apparently flat sequence structures don't work well in Teleop.
Quote:
The tele function is effectively a callback. It is called eery 20 milliseconds/fifty times per second. Your teleOp code therefore needs to respond to the joystick inputs and finish in about 20ms or it will be too busy to process the next one. The events aren't queued or you would have the robot running delayed joystick info - acting laggy and generally very difficult to control. So if you put code into tele that doesn't return, that doesn't work very well. If it takes seconds to return, then tele is delayed for that time. It is the code inside the sequence that delays, not the sequence itself. The sequence simply runs one frame after the other. When if finishes, the other code downstream runs. When tele is finished, it waits for the next joystick input. Greg McKaskle |
![]() |
| Thread Tools | |
| Display Modes | Rate This Thread |
|
|