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

This morning, we set out to get the compressor running.

Our electronics guys wired up the compressor, and I “wired up” the program. It didn’t work. So I re-did the program a few times, and then we ran some sample compressor programs… they couldn’t run the compressor either. The mentor that I was working with was convinced that we have to write the compressor logic on our own, but we decided we should check to see if we have a relay problem first. At that point I found the logic in the WPI Compressor library, and we decided that it’s another issue altogether.

Turns out, the compressor VI wanted the compressor to be on, but the sidecar just doesn’t want to flip that relay. We tried it on slot 4 and slot 6, and we tried 3 different sidecars.

Any ideas, anybody?

Since it is unlikely that that much HW is broken, it could be a wiring problem. The sidecar needs the correct voltage to operate. I assume the PWMs and other I/O on the same digital sidecar work?

It could be a SW problem. Have you checked the diagnostics tab to see if there are errors about the relay not really opening do to a parameter or such?

Greg McKaskle

Do you have your 12V hooked up to the sidecar? Both last year and this year I forgot to hook up the 12V, not allowing a good 5V line to be active, not allowing the compressor or switch to work.

EDIT: Oops, Greg kinda beat me to it. But yeah, check that 12V line, and ensure your 5V and 6V LEDs are on.

Jacob

The sidecar has LEDs that mirror the state of the relays. Check to see whether or not the LEDs mirror what you think the relays should be doing.

If the 5V or Battery LEDs aren’t lit, its your power.

If the Relay LEDs don’t light AND your PWMs aren’t working, it is the ribbon cable.

If the Relay LEDs don’t light AND your PWMs are working, it is likely your code (or your DSC, but not likely since you tried three).

If the Relay LEDs do light, but don’t do the right thing, it is definitely your code.

If the Relay LEDs do light and do the right thing but the relay doesn’t fire, it is the wiring to Spike or the Spike itself.

Yes, the PWMs work flawlessly, and the digital input works. I’d hope a low battery wasn’t to blame, we were running at about 12.3 volts.
I haven’t checked the diagnostics tab specifically for relay errors, I didn’t know those were displayed… I’ll do that on Monday, but from what I recall, the errors there were all camera related.

I didn’t check the electronics too much, but I recall there being 3 LEDs lit… I’ll look into that a bit more on Monday.

That’s actually the check we were doing. When we changed the relay values, no LEDs came on.

From the list you gave me… well, it points right to the code. We got power. We got PWMs. We got DIO… but we used the sample programs, and that still didn’t work. We tried “Compressor With Cylinder.vi” and “Solenoid With Compressor.vi” and “Relay Example.vi” and yes, we did configure them properly when we ran them.

Thanks for all the hints so far, everyone… it’s really a huge help, we were pulling our hair out.

Cut out the middle man and try using the relay VIs directly. I believe there is even a nice example for it - just remember to set the examples IP address*!

  • Every single time I’ve tried to use an example, I forgot to change the IP address.

I did that too, check the post above you :ahh:

And we did manage to remember to change the IP… after a couple complete restarts… haha

OK, so we got the compressor running. We had a bad cable.

Now we got another issue, the compressor stops and starts every 10-15 pounds that it gains. Is that a normal issue? A fuse blew, and we think that’s to blame.

It does this in both compressor examples as well, not just my code.

If you have wired the compressor correctly, it is powered via a spike (powered by a dedicated 20A circuit breaker from the power distribution board) and the spike’s fuse has been replaced by a 20A circuit breaker IAW <R60> part F.

It is possible that

  1. One of the two circuit breakers as bad.
  2. The pressure switch has a bad connection somewhere.
  3. The current draw from the compresser is too high (bad compressor or shorted wiring).

I really do not think that could be a software issue but I’ll defer that issue to others.

Regards,

Mike

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.

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.

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.

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

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.

OK, the camera was not the problem, but our code was. We now have it working!
The root cause was that we had set the relay definition as “Forward Only” in the Begin.vi. Changing it to “Both Directions” did the trick.

Here is my postingwith a picture of what fixed it for us.

Edit: It looks like this is a known issue. Thanks to Joe Ross for pointing this out.