Autonomous timing of events are to fast
 

In auto we want to 1)move forward for two seconds, 2)stop driving and spin up our shooter motors for a couple of seconds, 3) then retract a pair of cylinders with shooter motors still spinning with about a second wait to make sure the cylinders have fully retracted, 4) and finally stop the shooter motors and extend the cylinders. see attached code

We use a stacked sequence to complete these tasks. It drives forward for 2 seconds just fine. The PROBLEM... in the seconds step the shooter motors (frontMotor and rearMotors) start for a split second and stop. Then after about the two seconds the cylinders (frontliftCylinder and rearliftCylinder) retract for a split second and then extend.

Why are the shooter motors and cylinders only acting for a split second in sequence 2 and 3?

Re: Autonomous timing of events are to fast
 

Did you enable the motor safety on those two motors? If you did, that will shut the motors off if you don't constantly set their values at least every 100 milliseconds. The safety is off by default on non-drive motors, and there's usually not a good reason to turn it on.

Are the lights on the Solenoid module turning on for the appropriate amount of time, with the cylinder itself just taking a while to respond? Or do the module's lights also act for only a split second?

Show us your Begin vi and we can make a better judgement of where your problems might lie.

Re: Autonomous timing of events are to fast
 

We did not enable the motor safety.

The solenoid lights turn on only for a slight second also.

We use the same sequences 2 and 3 in periodic tasks during teleop and it works fine.

I've attached a picture of our Begin VI.

Thanks for helping...

Re: Autonomous timing of events are to fast
 

Periodic Tasks also runs during Autonomous. It might well be turning things off immediately after your autonomous code turns them on. If you don't understand what to look for, post your Periodic Tasks vi and we can help you check for conflicts.

Re: Autonomous timing of events are to fast
 

attached is the periodic task code that works when a button is pressed

Re: Autonomous timing of events are to fast
 

I don't see where you're turning off the motors or setting the solenoids back to Forward. If that's being done in the False case, as I suspect, then we've found your problem. Before I start giving suggestions, I would like to verify my suspicions. Can you post the actual vi, and not just a screen capture of it? If you don't want to share your entire Periodic Tasks, least give us a vi snippet of the relevant loop.

Re: Autonomous timing of events are to fast
 

Alan- you are correct. Our false case, in Periodic Tasks, turns the motors off and sets the solenoids forward. So, are you suggesting we should turn motors off and set the solenoids forward in the true case of the Periodic task? Then deleting these actions in the false case of the Periodic Tasks.

attached is the Periodic Task VI and a screen capture...Please make any suggestions as to how to improve our code. Everything we know we have learned through CD. Learning code this way is kind of like learning calculus through youtube. We can usually make it work, but we're not so efficient at it.

Re: Autonomous timing of events are to fast
 

Moving the things out of the False case and into a final frame of your sequence should work. That'll make it stop interfering with the auto code.

But I have a different suggestion. Since your Periodic Tasks code works properly, why not just make use of it in Autonomous as well? I'd add a boolean global variable and OR it with the joystick button into the Case block. To fire the sequence in Autonomous mode, just set the variable True for a half second, then set it back False, to simulate someone pressing the button. That way you don't have the same function duplicated in multiple places, and if you ever want to change how the firing sequence works there is exactly one place to do it.

Re: Autonomous timing of events are to fast
 

Works!!! I delete the code in the false case and added a sequence to the code in the periodic tasks.

Also, thanks for the suggestions of using global variables. I'm not going to try this before this weeks competition, but will play with them in the off season.

Thanks again!

Re: Autonomous timing of events are to fast
 

Help again!? We have another similar issue with the frontMotor not running in autonomous. The frontMotor twitches but does not stay on. I believe it is because in periodic tasks we have the frontMotor set to turn off in a false case. (see attached) I believe like before telling the frontMotor to be zero in periodic tasks is interfering with the frontMotors turning on in autonomous...true?

How do I fix this?

Re: Autonomous timing of events are to fast
 

Is there a button press that executes the case structure? Since you can't press the button during auto and periodic runs at the same time as auto the two will conflict.

Re: Autonomous timing of events are to fast
 

Yes, the a button press is used to turn on the frontMotors in periodic tasks. The frontMotors are turned off in the false case of the button press.

How do I fix this so they do not conflict with eachother?

Re: Autonomous timing of events are to fast
 

In periodic task, you can set-up a case structure where when the robot is in auto, it does not do the function you have in periodic task. This structure would go over the entire function of what you're doing when you press the button. There's other ways, such as developing a global Boolean variable that executes your periodic task function during auto. I highly recommend doing the global Boolean method, after reading the posts before this.

Re: Autonomous timing of events are to fast
 

There are better ways to integrate Periodic Tasks actions with Autonomous, but you'd have to completely revamp how you do things, and now is probably not the time to do that. The "cheap" fix is actually pretty easy:

Instead of setting the motor itself in your Autonomous sequence, set a global variable. Where the Periodic Tasks case is setting the motor value to 0, set it instead to the value of that global variable.

Re: Autonomous timing of events are to fast
 

Thanks again for helping.

I've never used global data before so I watch a youtube video. I think I added the global variables, but don't have access to the robot to check. I've attached screenshots with the changes I've made. Could you check to see if I've added them correctly?