I have a question about hanging in Vex Toss Up. At the end of the match you are high hanging but when they disable you at the end, your hold on your hanging device is no longer active so you drift down to the field. If you are high hanging the the end of the match and you drift down and touch the field because you no longer have a hold, does this still count as high hanging or no hanging at all?
If i remember correctly, in round up you had to stay hanging. I would think it would be the same for toss up, but I may be wrong.
Although the rule book is vague in some places and needs an update, I believe that it is scored when all objects come to rest, meaning the robot will be scored by however it ends up.
This means that it will have to stay in position for it to be counted as scored. If you plan on having a seperate mechanism for hanging, it would do you very good to invest in some ratchet gears from the winch and pulley kit.
Hmm, looks like I am going to have to figure out how to make a lock on my hanging device. This game is definitely going to be difficult.
From the rules:
While ( IsEnabled() == 0)
{
SetMotor (1,127);
SetMotor (2,127);
}Would this code work and be legal for competition to hold a hanging device?
Ha ha. No.
Wait… MAYBE. But I’m guessing not.
No. Because your motors don’t work while your robot is disabled.
EDIT: Aww, Nate beat me to it.
Yeah I figured that would be the answer. But I had to try anyways.
Q: Would this code work?
A: Not with RobotC or EasyC but the Cortex theoretically can be programmed to keep running the motors when disabled.
Q: Would it be legal?
A: Nope.
Time to start using Pros I guess. 
I really wish I was a year younger - I would love to have a year to mess with it and then use a stable version in competition. As much as I look forward to the release and can’t wait to use it, I’ll probably still end up using RobotC for the competition just because of its maturity. Pros will likely be restricted to side projects for my last year :mad:
So we’re still assuming PROS will be released, I hear it was mostly the work of one student and he wasn’t very forthcoming at worlds. Even if it is, the motors are still handled by the master processor and PROS is user processor code. There is no legal way to keep motors running when field control disables the robot, the only illegal way is to exploit the current bug in the master firmware that was exposed by the static issue with the IMEs. Any good ref or field tech will see what is happening and DQ the robot.
What really happens is that the master CPU, the one that controls the VEXnet and motors, can’t be reprogrammed by non-developers. The User CPU runs all of the robotc code and user code. When the master cpu hears through VEXnet that it should be disabled, it tells the motors: all off. It also disables any communication between the joystick and the user code.
So essentially, at this point, there would be no difference in any programming language you use.
Yes when I said theoretically I meant that it would involve rewriting the master firmware (quick weekend project, right? )
As for PROS, I just kind of assumed it would be released, even if in an unrefined condition that others could hack on. It would be a real shame if the project disappears. Just a proof of concept release would likely spark alot of further development by the community and would likely push RobotC and EasyC into providing better development environments for their users.
If rewriting the user runtime libraries and startup code is a 2 on a scale of 10, rewriting the master cpu code is probably a 10. Never going to happen without documentation from IFI.
I’m thinking a pneumatic cylinder that locks at “0” and releases at “1” so it stays engaged with no power.
I’m a little confused… I don’t think you’d have to re-write the master firmware, but rather just re-write the competition template (for ROBOTC, at least). Still illegal, but much easier.
I could be wrong, though–I don’t have my cortex to test it with.
It could be the other way around, too. They don’t turn your robot off after the match. It’s physically impossible to do that. They disable the robot, which doesn’t affect pneumatics.
Any change to the code on the user cpu is legal, you don’t need to use the example competition template (here’s an alternative), the master cpu will always disable the motors when instructed by field control. The ROBOTC competition template also detects and disables motors, this is good practice otherwise when you disconnect from field control the motors will start up again. I posted a simplified diagram of the cortex (specifically dealing with power and IMEs) here which gives an overview of where motor control comes from.