6 hours, 4 mentors and 2 students couldnt figure out whats wrong with our relays

[kavisiegel]

Well we found the underlying issue of that, too. The watchdog timed out - it was software.
We put the light on for the first time, the bracket just got it, and we noticed that the light turned off every time the compressor turned off. Then the diagnostics tab told us the rest of the story.



So now, the new issue, WHY is our watchdog timing out?

It was originally hard wired, and we thought maybe we might have more luck wireless. Same thing. We tried it with the default robot project, no changes at all, and we tried sevral examples. It always did the same thing. We thought maybe the program was timing out because we didn't have a camera on there and the request wasn't going through, but then we attached that and nothing changed at all.

[nick1023]

Make sure you have installed the latest driver station and labview updates from www.ni.com/first.

These updates have resolved some of the watchdog issues.

Here is my very broad understanding of watchdog issues at the moment. Each time the watchdog encounters an error it pauses your code running on the crio (watchdogs want to stop the machine from hurting itself if there is an error). If you call something in teleop.vi that is not opened in Begin.vi the whole control system will "pulse" in between pauses for example.

The update addressed this by making the watchdog ignore smaller errors. Ignore more small errors and you will have less watchdog errors. If you do something to cause a more "major" error you will still see watchdog timeouts.

Again, people who really know what the watchdog does are likely to wince at my explaination but it boils down to
-make sure the update is installed.
-make sure you have error free vis.

I think there was a "watchdog for beginners" explaination thread somewhere on the boards today ...

[kavisiegel]

Originally Posted by nick1023

Make sure you have installed the latest driver station and labview updates from www.ni.com/first.

These updates have resolved some of the watchdog issues.

Here is my very broad understanding of watchdog issues at the moment. Each time the watchdog encounters an error it pauses your code running on the crio (watchdogs want to stop the machine from hurting itself if there is an error). If you call something in teleop.vi that is not opened in Begin.vi the whole control system will "pulse" in between pauses for example.

The update addressed this by making the watchdog ignore smaller errors. Ignore more small errors and you will have less watchdog errors. If you do something to cause a more "major" error you will still see watchdog timeouts.

Again, people who really know what the watchdog does are likely to wince at my explaination but it boils down to
-make sure the update is installed.
-make sure you have error free vis.

I think there was a "watchdog for beginners" explaination thread somewhere on the boards today ...

We had the update installed on the laptop being used, but for good measure we installed them on the driver station pc as well. Then we imaged the cRIO from the driver station and deployed the unmodified default FRC project.

Everything was as fresh as possible. And we STILL couldn't get it working.

We think it may be hardware, because with some testing, it seems we don't get watchdog errors when we unplug the digital sidecar.

I got to the school at 10 am and I left at 7 with this issue still unresolved.

[Mark McLeod]

Do you get Watchdog errors if you leave the DSC connected, but disconnect all your DIO, Relay, & I2C connections?

Possible bare wires shorting on the Wago connector?

[kavisiegel]

Originally Posted by Mark McLeod

Do you get Watchdog errors if you leave the DSC connected, but disconnect all your DIO, Relay, & I2C connections?

Possible bare wires shorting on the Wago connector?

Yep, it was a bare sidecar connected to power, the cRIO, and the status light. And we also tried it without the status light.

We didn't try a new power cable, but I doubt that's the issue because we checked all the connections with a multimeter and it read the same as any other connection - the same exact voltage of the battery. And I don't think shorts can be that intermittent, while at semi-regular intervals... we'll try it tonight, anyways, though.

[Mark McLeod]

Have you tried connecting one of your other DSCs to see if the problem follows the board or occurs with any DSC?

You can do replacement tests on the cRIO module and on the cRIO slot as well to eliminate each step in the electrical chain.

[kavisiegel]

Originally Posted by Mark McLeod

Have you tried connecting one of your other DSCs to see if the problem follows the board or occurs with any DSC?

You can do replacement tests on the cRIO module and on the cRIO slot as well to eliminate each step in the electrical chain.

Yeah, we tried 2 empty DSC's.

We also replaced the entire cRIO, using the modules from the old one. We then swapped slot #4 and #6, then took out #6 all together, then re-imaged in case anything was dependent on #6

[billbo911]

I know this is a shot in the dark, but we are having very similar problems, so I thought I would throw in my $.02.

By any chance are you running your compressor code in the timed loop section, either 10ms or 100ms?
If so, by any chance is the camera not currently hooked up?

Here is why I ask.
In the past we have had lots of trouble when our camera cable had come unplugged and we had a lot of robot code that was included in the same loop. The huge amount of load placed on the system with bad or no data from the camera prevented the rest of the code from completing. What I am wondering is if the same thing is happening now. We currently do not have our camera plugged in, but the code is still running. The vision code runs in the same "Frame" as the periodic loops. Could the camera errors be preventing the periodic loops from updating the output to the relay controlling the compressor?

I will be investigating this around 4:30pm PST today.