Problems with LabView Default Code

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

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 :stuck_out_tongue:

youiswho and JSzaday

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.

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.

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.

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

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:

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

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

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.

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?

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

You can probably find one on your 2011 LogoMotion robot.

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

I think 3936 would be a rookie number.

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

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.