Here’s the thing, he hasnt taught us all this yet. He kinda gave us the problem and told us to figure it out.
Problem 4: Crane and Cable Winding Mechanism
A construction contractor needs your team to design a crane that can rotate 90 degrees and lower a basket 18 inches for supplies to be moved around the job site. The crane should be run with a series of buttons and switches that can activate the rotation, lowering, and raising of the basket. The device must also be able to be started and stopped (emergency) by using a switch.
So I don’t really know what you mean by estop but I think just what you had in main was good but what I don’t get is why can’t you just put the stop within the while loop. like for example (I don’t know what the estop sensor is but lets just pretend its a button) all you have to do is just say if the value == 1 or <500 I guess and then break; that should end your while loop so
Your point about an emergency stop’s requirements does not correlate with your point about it being in a separate task.
Tasks are not threads!
Tasks do not run in the background while you have other code executing. Lower-priority tasks only run during higher-priority tasks’ waits/delays.
Which means, even if you use a task, it would be effectively no different from doing what @WChen20 suggested.
Side note: This is why I agree with @WChen20 that multitasking should be avoided when possible. Most people don’t understand how multitasking actually works, resulting in an overuse of tasks and code that I would generally consider lazy.
You are making the assumption that they are incapable of using threads, priority, and waits correctly.
But in general, an E-Stop should not be a Task or a Function, it should be a completely independent electrical system. That is unfortunately not an option in VEX. I would love to see V6 include some safety equipment. Deadman switch on the controller, e-stops, a separate safety circuit. Its not necessary for robots with such low power, but it would be a good introduction to industrial equipment.
All it means is that your approach to using eStop is perfectly valid. The eStop task will stop the main task and all motors when you detect whatever analog sensor you are using going below the threshold you have set. Using a check for that sensor in the main loop would be ok, but as soon as the program becomes more complex and you possibly have other tests and while loops, it will not work so well, that’s why putting it in another task is really the correct approach. You can read about ROBOTC tasks in detail here (it gets complicated)
and you can see an old implementation of eStop in this project