Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Java (http://www.chiefdelphi.com/forums/forumdisplay.php?f=184)
-   -   Setting custom disable behaviors (http://www.chiefdelphi.com/forums/showthread.php?t=129254)

gappleto97 01-05-2014 02:06

Setting custom disable behaviors
 
Tried the following snippet on DisabledInit() and DisabledPeriodic(). Neôther worked.

@Override
Public void DisabledInit()
{
Super.DisabledInit();
LED.disable();
}

It didn't like the override. I may have typed it in wrong, as I'm going off of 2-month old memory, but still.

How do I get this to work?

notmattlythgoe 01-05-2014 07:03

Re: Setting custom disable behaviors
 
Quote:

Originally Posted by gappleto97 (Post 1381388)
Tried the following snippet on DisabledInit() and DisabledPeriodic(). Neôther worked.

@Override
Public void DisabledInit()
{
Super.DisabledInit();
LED.disable();
}

It didn't like the override. I may have typed it in wrong, as I'm going off of 2-month old memory, but still.

How do I get this to work?

Should be

Code:

public void disabledInit()
{
    super.disabledInit();
    LED.disable();
}

Unfortunately annotations are not supported in the version of java that runs on the cRIO.

cgmv123 01-05-2014 09:27

Re: Setting custom disable behaviors
 
Note that disabled, by definition, disables all outputs, regardless of what code you write. This is a safety feature (or "feature", depending on who you talk to.) It doesn't look like you're trying to activate any inputs, but it's something to be aware of when customizing disable code.

gappleto97 01-05-2014 14:18

Re: Setting custom disable behaviors
 
Is there an alternate way to override then?

notmattlythgoe 01-05-2014 14:24

Re: Setting custom disable behaviors
 
Quote:

Originally Posted by gappleto97 (Post 1381561)
Is there an alternate way to override then?

You don't need annotations to actually override, just using the same method signature will override the method.

gappleto97 01-05-2014 22:53

Re: Setting custom disable behaviors
 
Quote:

Originally Posted by notmattlythgoe (Post 1381562)
You don't need annotations to actually override, just using the same method signature will override the method.

In that case, where do I put it? Because I tried this, and I distinctly remember it not working. I'm thinking I must have put it in the wrong place or something, maybe.

NotInControl 01-05-2014 23:40

Re: Setting custom disable behaviors
 
Quote:

Originally Posted by cgmv123 (Post 1381430)
Note that disabled, by definition, disables all outputs, regardless of what code you write. This is a safety feature (or "feature", depending on who you talk to.) It doesn't look like you're trying to activate any inputs, but it's something to be aware of when customizing disable code.

Only PWM and Relay outputs are disabled. Digital In, Digital Out, and Analog In are all fully functional during the disabled state of the robot. You can set digital output pins high or low in disabled. Digital IO should never be used to drive actuators as per FRC rules, which is why its state are allowed to be commanded during disable.


Quote:

Originally Posted by gappleto97 (Post 1381725)
In that case, where do I put it? Because I tried this, and I distinctly remember it not working. I'm thinking I must have put it in the wrong place or something, maybe.

Unless you are creating a new class which extends IterativeRobot, the super.DisableInit() does not exist. That implies that disabledInit() exist in the parent class you are inheriting from.

The first definition of DisabledInit() is in the IterativeRobot class, so is you are trying to call super.DisabledInit() inside of IterativeRobot, or CommandBasedRobot, that is probably why its failing.

Also do not include any @override annotations, as mentioned already they are not supported by the JVM on the cRIO.

Hope this helps,
Kevin

gappleto97 02-05-2014 23:23

Re: Setting custom disable behaviors
 
Quote:

Originally Posted by NotInControl (Post 1381741)
Only PWM and Relay outputs are disabled. Digital In, Digital Out, and Analog In are all fully functional during the disabled state of the robot. You can set digital output pins high or low in disabled. Digital IO should never be used to drive actuators as per FRC rules, which is why its state are allowed to be commanded during disable.




Unless you are creating a new class which extends IterativeRobot, the super.DisableInit() does not exist. That implies that disabledInit() exist in the parent class you are inheriting from.

The first definition of DisabledInit() is in the IterativeRobot class, so is you are trying to call super.DisabledInit() inside of IterativeRobot, or CommandBasedRobot, that is probably why its failing.

Also do not include any @override annotations, as mentioned already they are not supported by the JVM on the cRIO.

Hope this helps,
Kevin

While this helps explain why it doesn't work, it doesn't explain how to make it work. Should I just put that in robotcode.java and see what happens?

NotInControl 04-05-2014 01:00

Re: Setting custom disable behaviors
 
Quote:

Originally Posted by gappleto97 (Post 1382192)
While this helps explain why it doesn't work, it doesn't explain how to make it work. Should I just put that in robotcode.java and see what happens?

I am not sure what file robotcode.java is. If that is the file where you have disableInit. Then yes.

It would be helpful if you pasted you full file so we can better assist you.

Cel Skeggs 07-05-2014 21:01

Re: Setting custom disable behaviors
 
Importantly, it's not DisabledInit(), but rather disabledInit(). Capitalization matters. The same thing goes for DisabledPeriodic() - it's disabledPeriodic().

If you aren't sure if the code is getting called, you can try adding
Code:

System.out.println("Yes, I'm working properly.");
to the method.


All times are GMT -5. The time now is 22:38.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi