Problems with LabView Default Code

[JSzaday]

We have had issues lately with our Robot's code, I am a member of a rookie team and this is our first time programming with LabView.

We are getting the following errors, and we are not sure why.

Error -44061 occured at "left and right motors" in the VI Path: Robot Main.vi

Watchdog system experation

(Occasionally saying watchdog not being fed in the status field (where it says "telaoperated enabled))

Also, the PWM1 in the code responds as PWM3 on the Digital Sidecar.

Please note, We are indeed running the default code!!!
I know it is a bit late for this, but we did have code working until yesterday, and now it is doing this

Thanks,
youiswho and JSzaday

[MAldridge]

First off the help menu is your friend. If you goto help>explain error, you can type in that error and it will tell you what is wrong. In your case, that won't help though because that is an undefined error.

I suggest that you go to the robotdrive palet and get the safety config off the advanced palet. Wire it directly after the refnum get, set mode the enable and the timeout terminal to 5.

Be aware that this makes your safety thread significantly slower, so you will need to be sure that you have a hand near the E-Stop when you are working with the robot and it is not on blocks. Additionally, if it pulsing PWM 3, then somewhere, your code is telling it that that is the correct channel to use. I suggest you go back through and re-read you code. Also, If you say that you HAD working code, perhaps you should improve your backup system.

Good luck and don't hesitate to come back if you have further questions.

[StealthMentor]

Actually, this sounds a lot like the incorrectly made ribbon cable problem We had a similar problem until we "fixed" our KOP ribon cable. PWM 1 was responding to the signal sent to PWM 3.

[SenorZ]

We've had some ODD errors in the Driver Station using LabVIEW this year. I changed a Relay channel, and got a message in the diagnostics saying the Left/Right motor code was running slow.

Wish I could help, but we just reprogrammed the cRIO and it worked.

[Greg McKaskle]

The System watchdog message will show up each time the robot is disabled via the field, DS, or when communications is lost or the robot is estopped.

The Safety Config is kept happy by calling a given I/O update each expected period. It can be disabled or reconfigured, but wouldn't it be better to understand if and why your code is missing updates.

Greg McKaskle

[MAldridge]

I agree, it would be good to know why it is throwing errors (what does the 44061 even mean?), but with one day left until ship, I'm sure that a rookie team just wants to bag a functioning robot.

My team, LASA Robotics, was encountering this same issue. We lengthened the safety timeout to 3 sec. and all our errors went away.

On the original issue, if you are using the KOP ribbon, you should read this:
http://www.usfirst.org/sites/default...structions.pdf

that would explain the mismatch of channels in software and hardware.

[Greg McKaskle]

The error is -44061 and the Explain error tool describes it as ...

FRC: The loop that contains RobotDrive is not running fast enough. This error can occur if the loop contains too much code, or if one or more other loops are starving the RobotDrive loop.

Greg McKaskle

[MAldridge]

hmm, sounds pretty generic, how fast is fast?

[plnyyanks]

Originally Posted by MAldridge

hmm, sounds pretty generic, how fast is fast?

As fast as you tell it to be. The error is caused by the Motor Safety for the drive code (since the error cites RobotDrive as the error's source). That means that the code has exceeded the time limit (defaults to 100 ms) set for the maximum time between updates to a motor's speed (this prevents runaway motors). Each time you set a new value to the motor, the timer is reset until the next update. You can change the timeout for the safety by using the Safety Config VI (WPI Robotics Library->RobotDrive->Advanced) and setting the timeout to whatever value you want.

But in order to solve the bigger problem, I'd recommend going through your code and trying to fix anything that could be slowing it down this much. Often, an unhandled error somewhere in your code is the culprit. Or you could have loops executing within your teleop code that cause one iteration to take too long. Or you could just have too much code in your loop and it simply takes too long to execute.

[JSzaday]

Originally Posted by MAldridge

First off the help menu is your friend. If you goto help>explain error, you can type in that error and it will tell you what is wrong. In your case, that won't help though because that is an undefined error.

I suggest that you go to the robotdrive palet and get the safety config off the advanced palet. Wire it directly after the refnum get, set mode the enable and the timeout terminal to 5.

Be aware that this makes your safety thread significantly slower, so you will need to be sure that you have a hand near the E-Stop when you are working with the robot and it is not on blocks. Additionally, if it pulsing PWM 3, then somewhere, your code is telling it that that is the correct channel to use. I suggest you go back through and re-read you code. Also, If you say that you HAD working code, perhaps you should improve your backup system.

Good luck and don't hesitate to come back if you have further questions.

Originally Posted by MAldridge

On the original issue, if you are using the KOP ribbon, you should read this:
http://www.usfirst.org/sites/default...structions.pdf
that would explain the mismatch of channels in software and hardware.

The back ups started failing after we drove the robot to a "before the bag competition." I came in to work on it the next morning and everything went wild (the robot started turning on it's own when we enabled it!). With all this talk about bad KoP ribbons, I wouldn't be surprised if that is what is causing all of our problems. Today when I go in, I will look into it. Do you know any places (like nation-wide chains preferably) where we could get a DB37 M/F Cable on the spot?

Originally Posted by plnyyanks

As fast as you tell it to be. The error is caused by the Motor Safety for the drive code (since the error cites RobotDrive as the error's source). That means that the code has exceeded the time limit (defaults to 100 ms) set for the maximum time between updates to a motor's speed (this prevents runaway motors). Each time you set a new value to the motor, the timer is reset until the next update. You can change the timeout for the safety by using the Safety Config VI (WPI Robotics Library->RobotDrive->Advanced) and setting the timeout to whatever value you want.

OK, thanks for this too, I will try and change this in the code.

[Alan Anderson]

Originally Posted by JSzaday

Do you know any places (like nation-wide chains preferably) where we could get a DB37 M/F Cable on the spot?

You can probably find one on your 2011 LogoMotion robot.

[JSzaday]

Originally Posted by Alan Anderson

You can probably find one on your 2011 LogoMotion robot.

We could, if we had one, this is our first year as a team!

[rsisk]

Originally Posted by Alan Anderson

You can probably find one on your 2011 LogoMotion robot.

I think 3936 would be a rookie number.

The DB37 cables are used in computers, try a local computer store.

[Alan Anderson]

Originally Posted by JSzaday

...this is our first year as a team!

Oops. I misread your team number as 3636. Sorry about that.

Look to local teams as resources. You might try contacting someone on Team Hammond (team 71), The Black Knights (team 135) in Mishawaka, or the RoboDogs (team 2171) in Crown Point.