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

[kavisiegel]

Originally Posted by Greg McKaskle

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

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.

Originally Posted by whytheheckme

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

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.

Originally Posted by EricVanWyk

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.

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.

[EricVanWyk]

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.

[kavisiegel]

Originally Posted by EricVanWyk

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

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

[kavisiegel]

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.

[Mike Betts]

Originally Posted by kavisiegel

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

[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